SPA122: Number key presses not recognised for phone surveys, services etc

[Erft]

I've seen a couple of posts from 2010 and 2013 that seem similar to this, but I couldn't see any resolution...

So, we all know how important it is that the touch tone numbers we press be recognised when we're navigating a phone tree system. For the most part, my number presses are usually recognised by the system and I can find my way to the department I need. But sometimes they're not. And sometimes they will be for part of the way, but not all. Or usually, I'll get to talk to whom I want, and then there's a survey at the end, and my number presses aren't recognised. Also, when a robo survey or poll comes calling, it doesn't recognise that I've pressed a number.

For example, with my Service Ontario call today, I got through the phone tree and was asked if I want to answer a survey at the end of the call. I pressed "1" for yes, and it "heard" that — it told me to stay on the line after the end of my call. After the agent and I finished speaking, the survey started and it kept saying "We're sorry, we did not get a response from you," despite my pressing the number key.
Multiple businesses and services phone systems cannot "hear" that I've pressed a number, no matter how many times I press it. This can be scary when it's banking or a government service.

The problem seems to be how the tone is generated by the VoIP. Is there a way to change my ATA settings so my key presses will be recognised and accepted by all the phone systems?

I use a Vtech handset with a Cisco SPA 122.

[Liptonbrisk]

The problem seems to be how the tone is generated by the VoIP.

Your Vtech handset generates the audible DTMF tones. The Cisco SPA 122's job is to interpret those tones and transmit them over the internet to your SIP service provider. A problem can arise in how the ATA handles this transmission.

Is there a way to change my ATA settings so my key presses will be recognised and accepted by all the phone systems?

While using Auto for DTMF Tx Method is supposed to come close to accomplishing this, the reality is that it's impossible to guarantee acceptance by all phone systems with a single setting since different IVRs (Interactive Voice Response systems) can have unique or outdated configuration requirements. Your issue, where tones work initially but fail later (on a survey after speaking to an agent), often happens when the call is transferred to a different system that expects a different DTMF method than the one your ATA is using or has already negotiated.


There are two primary DTMF methods:

A) In-band

The audible tones are sent within the main audio stream in the same manner your voice is. This method is highly dependent on the audio codec used. If a compressed codec (such as G.729a) is active, the tones can become distorted and unrecognizable.

G.729a is a lossy codec, and I can't stand it. There's really no reason for anyone to be using it anymore unless that individual is desperately seeking to conserve data usage.

This is generally considered the least reliable method, especially if a compressed audio codec (such as G.729a) is being used. The compression process can distort the precise tone frequencies, making them unrecognizable to the receiving system (such as a survey menu). Inband might work passably well if G.711u is being used exclusively, but network issues, such as packet loss, can still degrade the tones.

There are certain circumstances where using Inband DTMF may be necessary. For example, some door-entry or intercom systems use access panels that require audible DTMF tones to unlock doors or activate gates. Those panels lack SIP-info or RFC 2833 stacks, so in-band audio is the only way to use them properly.

If an older alarm panel or the central station receiver doesn't properly support RFC 2833 signals, communication will fail. In that case, if you were using the G.711u audio codec for the connection, trying Inband DTMF might be a last-resort troubleshooting step, as it sends the tones as audio. Most alarm communicators simply dial in DTMF over the line. They do not support RFC 2833 or SIP INFO natively. Here's an example: viewtopic.php?p=75441#p75441.

You may come across an Interactive Voice Response (IVR) system (such as phone banking with customer service menus) that is older or poorly configured and doesn't recognize the standard RFC 2833 signals being sent. If your key presses aren't registering on a specific system when using RFC 2833, and you are using the G.711 codec, switching to inband might work for interacting with that specific system.

However, generally, avoid InBand DTMF unless out-of-band methods are failing first.




B) RFC 2833 (out-of-band)

The keypress is converted into a special data packet, separate from the audio stream. This is the modern, generally more reliable standard because it is not affected by audio compression.

Again, this method sends the DTMF tones out-of-band as specially formatted data within RTP packets, separate from the voice/audio packets. It uses a specific payload type defined by the RFC 2833 standard (sometimes called NTE or Named Telephone Events). The receiving end reconstructs the tone based on this data.

RFC 2833 is considered the most compatible method for VoIP. Since the tones are sent as data separate from the audio stream, they are not affected by audio codec compression or typical levels of packet loss/jitter. RFC 2833is the standard method providers tend to recommend.

RFC 4733 replaced 2833:

"RFC 4733 is a technical document from the Internet Engineering Task Force (IETF) titled "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals," published in December 2006. It specifies how devices should package touch-tones (DTMF), dial tones, busy signals, and other telephone-related sounds into data packets for transmission over IP networks using the Real-time Transport Protocol (RTP). RFC 4733 officially replaces (or "obsoletes") the earlier standard RFC 2833 by expanding and clarifying its framework. Although RFC 2833 has been formally replaced, the method is still commonly referred to as "RFC 2833" in practice, and most implementations remain backward compatible. Like its predecessor, RFC 4733 defines a reliable way to send DTMF tones out-of-band relative to the audio stream—meaning as separate data packets rather than audio mixed with voice—thereby avoiding problems caused by voice compression. Key changes introduced by RFC 4733 include removing the strict requirement that all compliant devices must support DTMF events, making support negotiable during call setup; adding procedures for handling long events through segmentation, reporting multiple events in a single packet, and reporting "state events"; and establishing a formal registry, managed by IANA, for assigning new telephony event codes. In essence, RFC 4733 serves as the updated standard for reliably transmitting DTMF tones and other telephony signals within RTP data streams for VoIP communications." (An A.I. explanation)

https://datatracker.ietf.org/doc/html/rfc4733




Cisco SPA122 DTMF Method Comparison

i) AVT (RFC 2833) Out-of-Band (as Data)

AVT sends DTMF digits as special data packets. With the AVT method, DTMF digits are not sent as audible tones within the voice path. Instead, they are transmitted as distinct data packets, which are separate from the voice packets but sent within the same RTP (Real-time Transport Protocol) media session. This is the modern standard for VoIP DTMF, also known as Named Telephony Events (NTE). The keypress is converted into a special data packet, separate from the audio packets. This is the modern, generally more reliable standard because it is not affected by audio compression.


This method sends the DTMF tones out-of-band as specially formatted data within RTP packets, separate from the voice audio packets

Pros

• Typically reliable and not affected by audio compression codecs
• This is the most widely supported and recommended method.
• Relatively low bandwidth

Cons:

• There was a SPA122 specific bug, supposedly. The ATA can sometimes fail to filter the original audio tone, sending a "double-digit" signal: https://community.cisco.com/t5/voice-sy ... -p/1997003. I suspect (but am not positive) this has been fixed in firmware updates, which is why I listed #1 below.
• Compatibility
  May not be supported by very old IVR systems

---

ii) InBand (as Audio)
Inband sends the actual, audible DTMF tones directly within the primary audio path, treating them exactly as if they were part of your speech.

Pros

• Universal Concept
  Mimics traditional phone lines, making it compatible with older systems.
• This method is a simple fallback and a good troubleshooting option if out-of-band methods fail.

Cons

• Codec Dependent
  Only works reliably with uncompressed codecs, such G.711u. Tones will be distorted by compression.
• Uses more bandwidth than sending data packets.

---

iii) INFO
Out-of-Band (as SIP Message)
This method sends the DTMF digits using a special SIP INFO message, which is a command sent separately from the audio stream.

This method also sends the DTMF tones out-of-band, but instead of using RTP packets, it uses SIP INFO messages, which are part of the call (Session Initiation Protocol or SIP) control signalling.

SIP INFO is generally reliable as it also avoids audio codec issues. However, support for SIP INFO for DTMF is less universal across all providers and equipment compared to RFC 2833. I've tested SIP INFO DTMF and found it works with FPL's voicemail system, but RFC 2833 is usually preferred for broader compatibility.

When VoIP and SIP were first developed in the late 1990s and early 2000s, many technical standards were still incomplete. At that time, voice calls used RTP streams to carry audio, but there was no standard method for sending key presses needed for phone menus. To address this, SIP INFO was introduced (RFC 2976). It allowed phones to send key press information as separate SIP messages during a call. For example, when a person pressed "5," the phone would send a special SIP INFO packet to inform the system. However, in real-world VoIP networks, SIP signalling often travels separately from audio streams and can experience delays, packet loss, or be blocked by firewalls and other network devices. Some systems require multiple SIP messages for a single key press, while others expect only one, leading to compatibility problems, especially with automated systems such as banking menus. A better method was later developed, called RFC 2833 (also known as out-of-band RTP). It sends key press signals as special RTP packets separate from the regular audio data but within the same RTP stream. Because these signals are not treated as audio, they avoid distortion from voice compression and are much more reliable, even under less-than-ideal network conditions. Today, most phone systems and automated menus expect key presses to be transmitted using RFC 2833/RFC 4733 (NTE).


Pros

• This is a standardized, official, out-of-band method.
• Keeps DTMF signalling entirely separate from the audio path.

Cons

• Not universally supported by all VoIP providers and gateways. It's outdated.

---

iv) Auto
The SPA122 attempts to automatically negotiate the best DTMF method with the other end of the call. In this mode, the SPA122 attempts to automatically negotiate the best DTMF method (AVT, InBand, or INFO) with the system on the other end of the call during the initial call setup.

Pros

• In theory, Auto should work without manual configuration.

Cons

• Auto can be a frequent cause of intermittent DTMF problems. The negotiation can fail or become confused when a call is transferred.

---

So, as a troubleshooting step, you try to avoid the Auto DTMF setting and manually set the DTMF Tx Method to AVT. If that fails for a specific IVR system or service, try InBand, but ensure your audio codec is set to G.711.




1) The latest firmware version for your ATA is located at https://software.cisco.com/download/hom ... .4.1%20SR5

I accept no responsibility for failed firmware updates. Instructions are here: https://www.cisco.com/c/en/us/support/d ... pa122.html.

Read https://community.cisco.com/t5/voice-sy ... -p/2260834 (possibly a firmware update might help, if you're using an old firmware version in your ATA)

If you do update firmware, then test DTMF using “Auto” again before proceeding.


2. a) Dial **** (four stars)
b) Then dial 110#
c) Enter the IP address you hear into a web browser.
d) Login to your ATA. (default username and password is admin)
e) Always choose the admin login and advanced view menus (select "advanced" in the upper right).

3. Navigate to Voice --> Line (the one used for FPL) --> Audio Configuration
Make the following changes
a) Preferred Codec: G711u
b) Second Preferred Codec: G711u
c) Third Preferred Codec: G711u
d) G729a Enable: no
e) DTMF Process INFO: no
This prevents the ATA from attempting to use this less-supported method, forcing it to use the more reliable AVT standard.
f) DTMF Process AVT: yes
This enables the processing of AVT events, which is Cisco's implementation of the RFC 2833 standard.
g) DTMF Tx Method: AVT
This forces the ATA to transmit all keypresses using the AVT/RFC 2833 standard.
h) DTMF Tx Mode: Normal
This mode is less restrictive than Strict and is known to resolve recognition issues, particularly with systems that might be sensitive to DTMF timing.
i) DTMF Tx Strict Hold Off Time: leave at default
Since this setting will be inactive when DTMF Tx Mode is Normal, there is no reason to change it from its default value.

4. Submit settings, and reboot ATA.

5. Do not use speaker phone (hands free) when pressing numbers.

6. And if that still doesn't work, you can try "DTMF Tx Method: Inband". However, AVT is more likely to work for you, overall.

7. Lastly, the Vtech handset itself might be generating tones that are too short for some IVR systems to recognize as well (I think that's less likely in this case to be your issue though). You may want to look for increasing the tone duration in the handset's settings, if the option exists (I don't know your phone). That's not an ATA setting.

8. You can also test DTMF by calling the Toronto or B.C. numbers from https://thetestcall.blogspot.com/.
Wait for the beep, press #, and then press 2. Then press every single digit on your phone. Then press #. Wait to hear if each button was successfully pressed. Then end the call. That way you can test to ensure DTMF is working properly--for that specific IVR system.

[Erft]

Hi Liptonbrisk, thanks for jumping in to help me with this.

Major roadblock to figuring anything out: I am unable to access my ATA settings.
I went into router settings to see what the assigned IP address is since the one it's supposed to be, timed out. I copied and pasted the new IP address, and it still timed out. I confirmed it by dialing into the configuration menu on my analog phone.

I got a new router (cbn CH8568 Docsis 3.1) when I got Teksavvy service about 7 months ago. I have old security cameras that only work with older routers, so I've bridged the new router to my TL-WR841N so I can continue using them. I don't know if that could have messed with the ATA. It doesn't make sense to me that even though I'm trying to access the ATA settings on the IP address the router tells me it's assigned, I still can't get in. Also, Teksavvy had me alter the setup a little. This is the first time I've tried accessing ATA settings since I got Teksavvy.

Now it goes:
-Cable to modem
-Modem to router
-Router to ATA
-Router to PC

It used to go:
-Cable to modem
-Modem to blue ATA
-Yellow ATA to blue Router
-Yellow router to PC

Not able to get into the ATA settings on my PC (Chrome and Edge)...

Can you offer any help with this?

[Liptonbrisk]

A) Does step 2 from my previous post not work?
i) Dial **** (four stars)
ii) Then dial 110#
iii) Enter the IP address you hear into a web browser.
iv) Login to your ATA. (default username and password is admin)
v) Always choose the admin login and advanced view menus (select "advanced" in the upper right).


B) Alternatively, refer to step 1 from the PDF guide located at download/file.php?id=1742

(If the steps below don't work, set your PC’s IP to 192.168.15.2 with subnet 255.255.255.0; revert back to obtain an IP address automatically after configuring your ATA.)

That is,
i) Connect an ethernet cable from your computer directly to the yellow ETHERNET port on the back of the SPA122.

ii) Ensure your computer is set to obtain an IP address automatically (DHCP enabled).


iii) Access the web interface

iv) Open a web browser on your computer

v) Enter the default IP address: 192.168.15.1

vi) Enter the login credentials:

Username: admin

Password: admin

(those are default values)

https://www.cisco.com/c/en/us/support/d ... pa122.html

[Erft]

Thank-you.
Regarding step 2; before I posted my reply, I did the first part (****, 110#) to confirm the IP address. I was very uneasy about making the changes you listed, through the IVR if I still wasn't able to access the admin settings through web browser, so I decided to keep trying for a visual interface.

By changing the PC ethernet cable from the blue ATA port, to the yellow ATA port, I was able to access the SPA122 admin settings with the 192.162.15.1.
Should I just keep it like that? PC internet, phone, and wifi are all still working fine.

I made the changes you listed, clicked "Submit", and then I just got a blank page with the Setup, Network, Voice etc headings at the top. The modem didn't reboot, but when I tried to go back into Line 1, I was booted out. So I logged back in and, since no changes had taken effect, I made them again. This time the ATA rebooted when I clicked "Submit". I tested the DTMF and it works...with that system, as you say. So I take heart from that success.

Regarding the firmware update; my ATA's firmware is out of date (present update is 1.4.1 SR5, and mine has 1.3.3 (115)). Since you help a lot of older people with their phone lines, I'm sure you are familiar with people being nervous about making changes to the technology. I am willing to update the firmware but I am nervous. You made a disclaimer before, so I don't hold you responsible if things go belly-up, but in your opinion, do you think it will improve things further? Is there a lot to gain from a firmware update?

[Liptonbrisk]

Thank-you.
Regarding step 2; before I posted my reply, I did the first part (****, 110#) to confirm the IP address. I was very uneasy about making the changes you listed

For step 2, in my initial response, there are no changes. You're just accessing the ATA via its Web UI.
Anyway, if step 2 doesn't work, I suspect either remote management is disabled in the ATA or two different subnets in conjunction with a double NAT is the likely cause of your inability to access your SPA122 ATA’s web interface from your PC, given your current network setup. Double NAT occurs when you have two routers in sequence, each creating its own private network (subnet) and assigning IP addresses via DHCP. Devices connected to the second router (your TP-Link) are on a different subnet than those connected to the first router (your CBN CH8568). If your ATA is connected to the TP-Link router and your PC is connected to the Teksavvy router (or vice versa), they may be on different subnets and cannot communicate directly.

If the IP addresses assigned to your PC and ATA are in different subnets (ex. 192.168.0.x vs. 192.168.1.x), you have double NAT.
If you can access the internet from both, but not local devices across routers, this is a classic symptom.

You could set your TP-Link router to Access Point (AP) mode (not router mode). This disables its NAT and DHCP, making all devices part of the same subnet as your Teksavvy router. Alternatively, connect both your PC and ATA directly to the Teksavvy router.

After making these changes, reboot your devices and check the IP assignments. They should all be on the same subnet (ex. 192.168.0.x).


Using a ethernet cable between the PC and the ATA, and accessing it via 192.162.15.1, bypasses that problem.

By changing the PC ethernet cable from the blue ATA port, to the yellow ATA port, I was able to access the SPA122 admin settings with the 192.162.15.1.
Should I just keep it like that? PC internet, phone, and wifi are all still working fine.

As long as FPL works, that's fine.

I tested the DTMF and it works...with that system, as you say. So I take heart from that success.

Well, it's success with that specific IVR system that you called into. That doesn't mean the survey IVR works for you.

Regarding the firmware update; my ATA's firmware is out of date (present update is 1.4.1 SR5, and mine has 1.3.3 (115)). Since you help a lot of older people with their phone lines, I'm sure you are familiar with people being nervous about making changes to the technology. I am willing to update the firmware but I am nervous. You made a disclaimer before, so I don't hold you responsible if things go belly-up, but in your opinion, do you think it will improve things further?

Never update firmware if there's even a tiny chance of a power outage occurring. So if there's a storm in your area, if you see lights flickering, etc., don't perform a firmware update. Your ATA and PC must not lose power or turn off in the middle of a firmware update.

If all IVR systems that you dial into work as expected now, then there's no need to trying updating firmware. If they still fail and if both AVT and InBand also fail to work for you (after testing with each DTMF method, respectively), then, yes, I would update firmware to see if anything improves.

Otherwise, in your case, I probably wouldn't bother.

Is there a lot to gain from a firmware update?

As I noted previously, bug fixes, for one.

https://community.cisco.com/t5/voice-sy ... -p/2260834

Updating firmware to 1.3.1 or higher will fix DTMF issues

.

[Erft]

Thank-you Liptonbrisk.
Yes, I am able to access my ATA's web interface now that I have the PC ethernet cable going into the yellow port on the back of the ATA. What you say about different subnets makes sense. I don't understand all you tell me, but that little piece makes sense.

The next time I choose to do a customer service survey, I'll be interested to see if it works. Sometimes the key presses are accepted, sometimes they're not. But I did make those changes you said to make, and hopefully that'll get all key presses accepted. If not, I guess I try "g) DTMF Tx Method: AVT" changing AVT to Inband and see how that works?
Should I try changing "f) DTMF Process AVT: yes" to "No"?

[Liptonbrisk]

If you change the DTMF Tx Method to Inband, then yes, set DTMF Process AVT to “no” since you no longer want the ATA to generate or process AVT events but, instead, want the ATA to pass the actual audio tones through unchanged.

If AVT does not work,
1. Set DTMF Tx Method to Inband
2. Set DTMF Process AVT to no
3. Ensure your Preferred codecs are set to G.711u (mandatory for Inband DTMF to work reliably)
4. Save settings, and reboot the ATA

Do not change DTMF Process AVT to “no” while still using AVT as your transmission method. That would disable AVT DTMF entirely, and your keypresses would not be sent as RFC 2833 events, likely breaking DTMF for most IVRs.

Inband is considered less reliable overall than AVT though.

[Erft]

Thank-you.

[Liptonbrisk]

You’re welcome!

[Liptonbrisk]

By changing the PC ethernet cable from the blue ATA port, to the yellow ATA port, I was able to access the SPA122 admin settings with the 192.162.15.1.
Should I just keep it like that? PC internet, phone, and wifi are all still working fine.

As long as FPL works, that's fine.

That was a pretty sloppy and lazy response on my part.

You should enable bridge mode in your CBN CH8568 modem/router combo.

https://help.teksavvy.com/teksavvy-faq/ ... vLxGWZ9v1P

1) Remove all other ethernet cables to all other LAN ports on the CH8568.

2) Connect TL-WR841N via an ethernet cable to the 1st LAN port. Attach ATA to TL-WR841N using an ethernet cable.

3) Connect PC to CH8568 via its 2nd LAN port. Open a web browser, and enter 192.168.0.1.

4) Default username is cusadmin

5) Password is CM MAC address (in upper-case). I'm guessing that's found at the bottom of your CBN CH8568 (check somewhere on the unit or the box it came with).

For example,



6) Click on the Internet tab.

7) Select Bridge Mode, and Apply Changes.

8) Afterwards to access CBN CH8568 (while it's in bridge mode), enter 192.168.100.1 in a web browser.


You want CBN CH8568 in bridge mode--->TL-WR841N-->ATA and PC

9) Disconnect PC from CBN CH8568. Connect PC to TL-WR841N.


Then you want to disable SIP ALG in TL-WR841N.

To understand why SIP ALG often causes horrible problems, please visit
https://www.voip-info.org/routers-sip-alg/ (scroll down to the section on SIP ALG problems).

9) Visit http://tplinkwifi.net, and log in with the username and password you set for the router. The default is admin (all lowercase) for both username and password.

10. Navigate to Security --> Basic Security-->ALG

https://www.tp-link.com/us/user-guides/ ... ub-title-8


11. For SIP ALG select "disable".

12. Click "Save".



By the way, if you're not making use of any of these services, I would disable all of the ALGs since they present potential security risks.


"FTP ALG - To allow FTP clients and servers to transfer data across NAT, keep the default Enable."

a) Are you running FTP clients or FTP servers? If not, disable FTP ALG.


"TFTP ALG - To allow TFTP clients and servers to transfer data across NAT, keep the default Enable."

b) Are you using Trivial File Transfer Protocol for anything? If not, disable TFTP ALG.

H323 ALG - To allow Microsoft NetMeeting clients to communicate across NAT, keep the default Enable.

c) Are you using Microsoft Netmeeting? If not, disable H323 ALG.


SIP ALG

d) Disable it.

RTSP ALG - To allow some media player clients to communicate with some streaming media servers across NAT, click Enable.

e) You have webcams. Are you using webcams or media players that need RTSP? If not, disable RTSP ALG. Otherwise, leave it enabled.

Disabling other ALG stuff is optional, but you should disable SIP ALG.

Lastly, it is extremely important to update router firmware when updates patch security holes: https://www.tp-link.com/ca/support/download/tl-wr841n. Again, I accept no responsibility for failed firmware updates.

[Erft]

Wow, I'm sorry Liptonbrisk; I didn't get a notification of your reply. I only see it now because I've encountered another problem and logged back in to re-read this post.
I did bridge the modem when I got it, so I could use the old router I have, but I very much appreciate you showing me the steps.

I was going to reply, tomorrow, that I successfully answered a phone survey, which felt wonderful! However, tonight the internet got slow—half speed. Problems went from there.

Normally it's the old router causing the slowdown. If I power cycle the whole network, or even just the router, problem solved. Internet speeds back to 40+ Mbps. That didn't happen tonight. They remained at around 18 Mbps despite multiple power cyclings. The router was not the problem.

Teksavvy determined that the issue was that the ethernet to the PC was coming from the ATA (yellow port so I can see web interface). I plugged the PC directly into the modem, and the speed went up to 44 Mbps (Speedtest.net). My wifi also went up to 44 Mbps from about 20 Mbps (Meteor on Android phone).

Anyway, I then found I didn't have a phone. If I hit "Talk" on the handset, the ATA lights indicated that Line 1 was active, the handset showed "Handset 1" instead of "No Line", but there was no sound of a dial tone. When I called the line from my cell phone, my call went to voicemail. The first two times it took about 30 seconds to reach voicemail, try three it was immediate.

I tried various things, like plugging the ATA right into the back of the modem, plugging the handset cord into Line 2, multiple PC restarts and network power cycling. Nothing worked. So I plugged the ATA back into the router, and then I had my phone back, all three lights (power, internet, line active) on the ATA lit, all the time, whether I'm using the phone or not (which is new).

Since the ethernet is no longer going directly from the PC to the yellow port on the back of the ATA, I can't access the web interface. I went into the ATA IVR and found that the IP address had changed back from 192.168.15.1 to 192.168.1.100 (default address). I thought that was interesting...possibly indicating some kind of reset or change that resulted from all the power cycling, and/or related to the internet speed slowdown?

Please correct me if I'm wrong, but if I want to manage the ATA through the web interface, I must have that ethernet going directly from the PC to the yellow port on the ATA. Thing is, though, I'm scared that if I do that so I can take a look inside the ATA to try to see what's going on, I'll end up without a phone again.

The current setup is Modem —> PC, Modem —> Router, Router —> ATA.
I have more ethernet cords and a 5-port desktop switch I can toss in if necessary, although I think that would add another layer when you said fewer is better?

Also, as I'm sure you've guessed, I can't access my router with the current setup. I feel tied up in a conundrum.

In answer to your question about my webcams, I don't think I have RTSP. I can see/hear a live feed, and I can go into setup to set video clips and SD card recording etc. I can stream sound and video from them, but I can't do anything like pause it.
I think the router firmware is the most recent, but I'm not sure, and I can't check right now.

So my questions right now are;

1. Could the ATA have been responsible for the internet slowdown? I have another ATA of the same model, never used, ready to replace the present one if that's needed (a pain, so I hope not).

2. If I temporarily plug the PC ethernet into the ATA yellow port so I can peek into ATA settings to see ATA setting, am I going to have the same problems with the phone again? Will they persist after going back to the current setup? It was difficult to get the phone back tonight, and I really can't do without it.

I need to be able to have my key presses heard, and I need my phone, my internet speed, and access to the router and ATA's web interfaces.
3.Do you think there is a way to get all of these working together?

Thanks for all your help.

[Liptonbrisk]

Normally it's the old router causing the slowdown. If I power cycle the whole network, or even just the router, problem solved.

Power cycling a router clears its memory, restarts all its processes, and re-establishes connections. If rebooting/power cycling consistently resolves performance issues for a period, that indicates that the TP-Link router is accumulating errors, overheating, or suffering from memory leaks that build up over time. Consumer-grade routers are not designed for indefinite operation. Over time, components can degrade, especially capacitors, which are sensitive to heat. Another possibility is firmware or RAM faults that leak resources: after enough corrupted tables accumulate, forwarding/routing data to devices slows or stops. Rebooting reloads the code into the router's RAM and clears the tables, only temporarily. This behaviour, where performance degrades over time, requiring a reboot to temporarily restore functionality, may suggest the router is starting to die.

1. Could the ATA have been responsible for the internet slowdown?

Your ATA contains a router. SPA122’s WAN-to-LAN throughput is limited to approximately 20 Mbps. Consequently, it's pretty useless as a router.
If your PC is connected behind the SPA122’s LAN port and the SPA122’s WAN port is connected to your main router or modem, your internet traffic passes through the SPA122’s router. In this case, the SPA122’s throughput limit (~20 Mbps) can cause noticeable slowdowns, especially if your ISP provides speeds higher than this. Your observation that when the PC was connected to the SPA122’s yellow port, speeds dropped to ~18 Mbps aligns with the SPA122’s throughput limitation.

Anyway, I then found I didn't have a phone. If I hit "Talk" on the handset, the ATA lights indicated that Line 1 was active, the handset showed "Handset 1" instead of "No Line", but there was no sound of a dial tone. When I called the line from my cell phone, my call went to voicemail. The first two times it took about 30 seconds to reach voicemail, try three it was immediate.

i) When the CBN CH8568 is in bridge mode it no longer performs NAT and DHCP (no longer assigns LAN IPs) for you. In other words, CBN CH8568 no longer functions as a router while it's in bridge mode. In bridge mode, CBN CH8568 is a modem only. The modem simply passes through the first public (WAN) IP address it receives from the ISP to the first device that asks for it, in this case, your TP-Link router.

ii) When the CBN CH8568 is configured in bridge mode, it effectively becomes tied to a single device's MAC address and only allows connections from that specific device, which is your TP-Link router. It is highly unlikely that Teksavvy (cable internet) permits multiple WAN IP addresses while your CH8568 is in bridge mode, which would allow other devices, such as your ATA, to also gain internet access. So, your TP-Link router (the first device connected to CH8568) will have internet access. However, other devices connected directly to CBN CH8568 should not have internet access while CBN CH8568 is in bridge mode.

iii) Freephoneline uses a 1 hour registration interval. The ATA registers while it's connected to TP-Link router. You then connect the ATA to CBN CH8568 instead. If you didn't reboot the ATA, after it's connected to a LAN port on the CBN CH8568 in bridge mode, while the TP-Link router is also connected to another LAN port on CH8568, your ATA still thinks it's registered despite having lost WAN/internet access when connected to CBN CH8568 (in bridge mode), until the next registration attempt fails, up to 1 hour away. Power cycling or rebooting the ATA forces a registration attempt.

The current setup is Modem —> PC, Modem —> Router, Router —> ATA.

This makes no sense to me. Is the CBN CH8568 in bridge mode or not? If you can access it by using 192.168.0.1, it's not in bridge mode. If you can access it only using 192.168.100.1, then it is in bridge mode.

If CBN CH8568 is in bridge mode, then only one device connected to its LAN port should have internet access directly from CBN CH8568: it's either your PC or TPlink router. Likely, the TP-Link router has internet access, and it, in turn, is providing internet access to the ATA.

If the ATA is also connected to the PC, it's (possibly) receiving internet access from the ATA.

If the CBN CH8568 is not in bridge mode, then anything connected to its LAN ports has internet access.

2. If I temporarily plug the PC ethernet into the ATA yellow port so I can peek into ATA settings to see ATA setting, am I going to have the same problems with the phone again?

You need to enable Remote Management in the ATA, and being able to log into your ATA is a separate issue from whether it can register.

Anyway, before you can enable remote management in the ATA, you must change its password. The ATA will not allow remote access with the default password, as a security measure. In other words, to access the ATA's webUI without having your PC connected directly to the yellow ETHERNET port on the back of the SPA122, you must perform the following steps.

A. Login to ATA.

B. Navigate to Administration --> User Management, and set a new, strong password for the admin. Click Submit. Don't forget the password. Make note of it. You will need to log in again with the new password.

C. Enable Remote Management: navigate to Administration --> Management --> Web Access Management.

D. Find the Remote Management section.

E. Click the Enabled radio button.

F. For the Web Utility Access method, ensure HTTP and HTTPS are checked.

G. You can leave the Remote Management Port as the default (usually 80 or 8080).

H. Save and reconnect. Click Submit at the bottom of the page to save all changes.

I. Return your SPA122 to its correct position in your network: connect the blue INTERNET port on the ATA to a LAN port on your primary router.




How to Use the IVR Code

This method allows you to enable web access from your main network without needing to connect a PC directly to the yellow port, but it has a critical prerequisite.

The full procedure is

Pick up the telephone connected to the ATA.

Dial **** to enter the configuration menu.

Dial 7932#.

The voice prompt will ask you to enter a value. Press 1# to enable remote web access. (Pressing 0# would disable it).

The system should confirm the change. You can then hang up.


There is a very important condition for this to work, as stated in the ATA's manual: "the system will allow WAN access only if the default admin username and password have been changed in the Configuration Utility."

This means the 7932 command will fail or have no effect if your ATA's administrator password is still the default (admin). This is a security feature to prevent unauthorized remote access to a device with a known, insecure password.

IVR vs. Web Interface

Enabling remote access via the phone keypad (7932#) and enabling it via the web interface (Administration --> Management --> Web Access Management) achieve the same result. The IVR method of dialing is simply a convenient alternative if you don't have a computer handy to perform a direct connection. However, since changing the admin password is a required first step, you will inevitably need to access the web interface at least once to set a new admin password before the IVR command will function anyway.


What I've just bolded is what you MUST do to access the ATA's webUI without having your PC connected directly to the yellow ETHERNET port on the back of the SPA122.





How to access the ATA from now on . . .

With Remote Management enabled, you will no longer need to connect your PC directly to the ATA, provided your PC is connected to the same LAN as the ATA.

J. Pick up the telephone connected to the ATA.

K. Dial **** (four stars) to enter the configuration menu.

L. Dial 110# to hear the IP address that your main router has assigned to the ATA.

M. Enter that IP address into your web browser from your PC to access the login page.






Anyway, since your TP-Link router seems, at best, unreliable (you claim you need to reboot it to fix problems), I would suggest this:

Primary modem/Router combo (CBN CH8568) not in bridge mode → All Devices
↓
┌─ PC (wired/WiFi)
├─ SPA122 ATA (blue WAN port)
└─ TP-Link Router (for cameras)


So, I suggest using CBN CH8568 as the main router and isolating the potentially faulty TP-Link router so it can only affect the webcams.



1) Take the CBN CH8568 out of bridge mode. Since you don't want the TP-Link to be the primary router (since you're having to reboot it periodically to fix problems), you should use the CBN's built-in router functionality.

a) Connect your PC directly to a LAN port on the CBN CH8568.

b) Log in to CBN CH8568. If it's truly in bridge mode, you'll use http://192.168.100.1. If that fails, it may have already reverted to router mode, so try http://192.168.0.1.


If neither of these options work, here is the sequence of events that likely created the problem:

- Your TP-Link router was connected to the bridged modem. Its MAC address was sent to the ISP.

- The ISP's network assigned your public IP address to the TP-Link's MAC address. This creates a binding.

- You then disconnected the TP-Link router from to CBN CH8568 and connected your PC to to CBN CH8568.

- Your PC presented its own, different MAC address to the ISP's network.

- The ISP's network saw this new MAC address and, because the public IP was still leased to the TP-Link's MAC address, it ignored or rejected the PC's request for an IP.

The result is that your PC is connected but has no access because it was never assigned a public IP address.

How to Fix This Issue?

The goal is to force the ISP's network to release the old MAC address binding and accept the new one from your PC. Here are the most effective methods.


This is the typical method to clear the cached MAC address:

- Shut down everything. Power off your PC and unplug the power cord from your CH8568 modem.

- Connect the new device. Ensure your PC is the only device connected via ethernet to the CH8568.

- Wait: leave the modem unplugged for at least 60 seconds. This ensures it loses its session with the ISP's network (in theory).

Power On in Sequence:

First, plug in and power on the CH8568 modem. Wait 2-5 minutes for it to fully initialize and for its lights to become solid (usually Power, DS/US, and Online). Then, power on your PC.

The PC should now be able to successfully request and receive a public IP address from the ISP.



c) Navigate to the Internet or Gateway Function tab, and disable Bridge Mode. Click Apply. This will re-enable its NAT and DHCP functions, making it your primary router. The device will reboot.


2) Ensure your PC is still connected to a LAN port on the CBN CH8568.

3) Disable SIP ALG on the Main Router (CBN CH8568). I would ask Teksavvy about this because my searches didn't find an exact location.

i) Log in to the CBN CH8568's admin panel (192.168.0.1).

ii) See if you can find the Application Layer Gateway (ALG) settings, which may be under a Security or Administration tab.

iii) Disable SIP ALG. Click apply.

It is entirely possible the option to disable SIP ALG in CH8568 doesn't exist at all, which is why you should contact Teksavvy to confirm.


4) Connect the blue INTERNET port of your SPA122 ATA to another LAN port on the CBN CH8568.

5) Leave the TP-Link router completely disconnected for now.

6) Power Cycle and Verify:

a) Power off and then turn on the CBN CH8568 (wait for it to be fully up and running first before turning on the ATA) and the ATA.

b) From your PC, confirm you are getting full speed (44+ Mbps).

c) Check for a dial tone on the ATA, and make an incoming call to your FPL number.

d) If an incoming call doesn't work, click viewtopic.php?t=20532. If incoming calls fail, do steps 9, 12, and, particularly, step 13 from that link. Test incoming calls again.

e) At this point, you should have a stable network for your PC and ATA.


7) Connect an ethernet cable from a LAN port on your CBN CH8568 router to the WAN port on the TL-WR841N. Check if cams work.

Your cams will be on TP-Link's LAN network, which is a separate LAN network from the one your PC is connecting to on CBN CH8568. Consequently, it's possible (if not very likely) your PC may not be able to log into your cams or TP-Link router since your PC and cams with be on different LAN networks.



a) I would, personally, try TL-WR841N in access point mode, so that the cams are on the same LAN/subnet as your PC.


[If you want to do that, then


i) Disconnect the TL-WR841N from the CBN CH8568. Connect your PC directly to a LAN port on the TL-WR841N.

ii) Log in to TL-WR841N's web interface (usually http://tplinkwifi.net). The default is admin (all lowercase) for both username and password.


iii) Configure Access Point Mode:

Case A (If "Operation Mode" is available):

- Navigate to Advanced --> Operation Mode (or System Tools → Operation Mode)

- and select Access Point Mode, and save the settings. The router will reboot

or

Case B (If "Operation Mode" is NOT available):

- In TL-WR841N, go to Network --> LAN

- Change the LAN IP Address to an unused IP within your CBN CH8568's subnet, but outside its DHCP range (ex, if CBN CH8568 is 192.168.0.1 and its DHCP range is 192.168.0.100-199, set TL-WR841N to 192.168.0.250). You may need to login to CBN CH8568 to find its subnet.

- Enter the same subnet that your CBN CH8568 is using on your LAN (if you need help finding CBN CH8568's LAN subnet, ask Teksavvy)

- In TL-WR841N, navigate to DHCP → DHCP Settings, and select Disable the DHCP Server



iv) Save changes and reboot TL-WR841N.

v) After the TL-WR841N reboots, connect an ethernet cable from a LAN port on your primary CBN CH8568 router to any LAN port on the TL-WR841N (do NOT use the WAN port for this connection in Access Point mode). Connect your webcams to the remaining LAN ports on the TL-WR841N or connect wirelessly to TL-WR841N's Wi-Fi network (ensure the Wi-Fi settings are configured with a compatible SSID and password).]

Other than what I've presented, I doubt I can help much. I feel supporting your cams is beyond the purview of these forums (and, respectfully, troubleshooting why they may not be working as expected also presents a lot of additional work that I don't feel is my responsibility).

3.Do you think there is a way to get all of these working together?

I've answered the DTMF aspect of this previously. While using Auto for DTMF Tx Method is supposed to come close to accomplishing this, the reality is that it's impossible to guarantee acceptance by all phone systems with a single setting since different IVRs (Interactive Voice Response systems) can have unique or outdated configuration requirements. Your issue, where tones work initially but fail later (on a survey after speaking to an agent), often happens when the call is transferred to a different system that expects a different DTMF method than the one your ATA is using or has already negotiated. Obihai 2xx/3xx/Poly 4xx ATAs seem to have an advantage: viewtopic.php?p=82479#p82479. However, even then there's no 100% guarantee.

In order to access everything, you should enable Remote Management in the ATA. Also, TP-Link router, CBN CH8568, and PC need to be part of the same LAN. Using TP-Link router as an access point is one way to accomplish that when CBN CH8568 is not in bridge mode.

[Liptonbrisk]

For what it's worth, I have a dentist appointment tomorrow morning that's probably going to leave me feeling very uncomfortable for the rest of the day. I doubt I'm going to be feeling up to responding to much of anything on Saturday.

[Erft]

Hi Liptonbrisk. I am slowly going over everything you have given me in your latest reply. My old brain has difficulty understanding much of it, so a lot of Googling and re-reading is required. I appreciate all the information. I hope I don't seem contrary or bypassing things you've said, if I don't immediately implement things you suggest; I'm trying to not get stressed, but my head is figuratively spinning with it all.

I need to do things step by step.

"The current setup is Modem —> PC, Modem —> Router, Router —> ATA."

This makes no sense to me. Is the CBN CH8568 in bridge mode or not? If you can access it by using 192.168.0.1, it's not in bridge mode. If you can access it only using 192.168.100.1, then it is in bridge mode.

That's an excellent question. I tried to view the cameras, today, and none of them can be reached. Has Bridge mode been disabled? I accessed the web interface via 192.168.0.1, which you say is not bridge mode. However, the modem says it's in bridge mode on the main page, and bridge mode is enabled under the Internet tab. This IP address is unchanged since I first put it in bridge mode when I got it.

In other words, to access the ATA's webUI without having your PC connected directly to the yellow ETHERNET port on the back of the SPA122, you must perform the following steps.

A. Login to ATA...

Right now I can't do that. The ATA IVR (****, 110#) tells me the IP address is 192.168.1.100, but my web browser can't access it. It looks like you're telling me that in order to access the web interface, first I must access the web interface. BUT you're saying that entering 7932# will tell the ATA to allow web access. I find this a bit confusing. Will the present setup allow it? Is the ATA currently disallowing web interface even though the setup should be fine?




FIRST STEP: I am buying a couple of new TL-WR841N routers. That'll hopefully take care of the fried-router issues. I wish I'd taken screenshots of the present setup so I could just duplicate it in the new one.

Over time, components can degrade, especially capacitors...

Do they degrade if the device is unused, sitting on a shelf, waiting for the day that its predecessor dies and it can step up? I'm going to get two, and wrap one carefully and keep it in as temperature-controlled an environment as I can.

In the meantime, could you please pick the simplest way for me to set up the network so I can see the router settings to screenshot? If the setup is temporary and can be reversed after I've done the screenshotting, that's fine. I just want to see the router settings, screenshot them so I can apply them to the new router, and then set up the network after seeing how everything's working.


And good luck with your dental visit.

[Liptonbrisk]

That's an excellent question. I tried to view the cameras, today, and none of them can be reached. Has Bridge mode been disabled? I accessed the web interface via 192.168.0.1, which you say is not bridge mode.

For clarity, it's not me saying it. It's Teksavvy: https://help.teksavvy.com/teksavvy-faq/ ... vLxGWZ9v1P

"Web UI Address:

Routed mode (default): 192.168.0.1

Bridge mode: 192.168.100.1"

This presumes the PC is plugged directly into one of the CBN CH8568's LAN ports via ethernet cable.

[Liptonbrisk]

Right now I can't do that. The ATA IVR (****, 110#) tells me the IP address is 192.168.1.100, but my web browser can't access it.

That's because you haven't

1) enabled Remote access in the ATA, and possibly,

2) your PC may be on a different LAN than the ATA


SInce #1 hasn't been performed yet, you must,

i) Connect an ethernet cable from your computer directly to the yellow ETHERNET port on the back of the SPA122.

ii) Ensure your computer is set to obtain an IP address automatically (DHCP enabled).


iii) Access the web interface

iv) Open a web browser on your computer

v) Enter the default IP address: 192.168.15.1

vi) Enter the login credentials:

Username: admin

Password: admin

(those are default values)

[Liptonbrisk]

I am buying a couple of new TL-WR841N routers.

I would not advise that for use with Freephonline, specifically (routers that support firmware at the bottom of this thread are better for SIP: viewtopic.php?p=78976#p78976), but if that's what you're most comfortable with, then okay.

Do they degrade if the device is unused

No. Electricity in conjunction with heat is bad, and it's impossible to avoid electricity. In the summer, it may also be impossible to avoid heat, particularly without strong air conditioning or fans.

Heat is generally bad for electronics.

Power outages/spikes/brownouts are also bad for electronics.

And, I feel, a lot of stuff simply isn't built to last.

In the meantime, could you please pick the simplest way for me to set up the network so I can see the router settings to screenshot?

For your TP-Link router? Just connect your PC via ethernet cable to one of the TP-Link router's LAN ports. Then login in to TPlink's router web interface (usually http://tplinkwifi.net). The default is admin (all lowercase) for both username and password.

And good luck with your dental visit.

Thank you. I'm not looking forward to it. Heh

[Erft]

I got on the phone with Teksavvy to find out why the IP address on the bridged modem was the one for routed mode. For nearly two hours the guy had me change things, move cords about. I took the modem out of bridge mode, immediately lost my cameras, and then he discovered that the modem does not allow you to change the IP address. You can change the last digit, and only the last digit. He couldn't believe what he was seeing.

Anyway, after a lot of cord swapping, button clicking, a modem factory reset, and multiple reboots, the modem retained its routed IP address, and I was left with no operating cameras. One camera with the most recent firmware (given that the cameras are DLink DCS-936Ls) was able to connect properly and be viewed, but then partway through the whole rigmarole, it was lost along with the others. The Teksavvy guy thought it had been able to connect because it had the upgraded firmware to deal with the more recent WPA2, and the others were still WPA. So we went into the router settings (TL-WR841N, the only router the cameras work with) and changed the WPA around. We did this, and we did that, even though the cameras had been able to connect fine before, and I was left with no cameras at all. I put it back on WPA2-PSK as I can at least see and control one camera with that.

• I rebridged the modem. The IP address stayed at 192.168.0.1. The cable setup is currently PC —> Router LAN, Modem —> Router Internet, Router LAN to ATA Internet.
• I enabled Remote Access, although, because they're radio buttons, I cannot select both HTTP and HTTPS. I selected HTTP.
• I disabled SIP ALG.
• I can access both the ATA and router web interfaces.
• All my devices, including cell phone and cameras, show up in my router's DHCP client list.
• My cell phone is connected to the router's wifi.
• My PC internet and phone's wifi speeds are ideal.
• Although my security cameras all show in the router's DHCP client list, I cannot access three of the four, through the web browser. I can access all of them through the phone app, with very limited capability.

In the app, under Wireless Settings for the one camera I can see, it says that my phone is not connected to the same wifi network as the camera. For the other three cameras (that I can't see via web), there is no such alert. My phone is connected to (wifi *name), and my PC is connected to (wifi *name 4). Yet they, and all the cameras (seen via web, or not), are listed there in my router's DHCP client list, so they should all be on wifi network (wifi *name).

I troubleshot one of the invisible camera's web interface address, and the troubleshooter says my broadband modem is experiencing connectivity issues. It suggests all the usual reset and recycling steps, but since there's no connectivity issue when it comes to the visible camera, it must be something else.



I feel so defeated. All I wanted was to be able to have my key presses recognised, and then to have my key presses recognised AND have my full internet speed. Now I don't have web interface for three of the four the security cameras, so I can't set them up to email me video clips when I'm not home. I live in an unsafe area so the cameras and the video clips are kind of essential. My brain is overwhelmed and I feel unwell.

I understand if you don't feel well enough to help anytime soon after your dentist's visit. When you do feel up to it, can we please try on this some more?

[Liptonbrisk]

I got on the phone with Teksavvy to find out why the IP address on the bridged modem was the one for routed mode.

1) Was your PC connected directly to CH8568 via ethernet cord?

2) Did you try clearing browser cache or using another browser (Firefox, Chrome, or Microsoft Edge)?


It's not just Teksavvy. Other ISPs in other countries are also stating that, in bridge, mode, CH8568's web access IP, itself, changes to 192.168.100.1.

So either everyone's documentation is wrong--or there's something weird going on (CH8568 firmware updated changed something or something happened on your end with the CH8568's LAN configuration).

For nearly two hours the guy had me change things, move cords about. I took the modem out of bridge mode, immediately lost my cameras

As, I mentioned before you have to put TP-Link router in access point mode if CH8568 isn't in bridge mode--and all devices, besides cams, need to connect to CH8568. That's step 7a.

However, now that I read you have Wi-Fi cams, step 7 should have been to ditch the TP-Link router and to connect everything to CH8568.

The goal is to have 1 LAN--not 2.

That can be accomplished in one of two ways, which I will discuss below.

and then he discovered that the modem does not allow you to change the IP address

I'm not sure what that individual is saying. Web IP access should change immediately to 192.168.100.1 after bridge mode is enabled and the CBN CH8568 reboots. You don't physically change the modem's IP address yourself.

https://help.teksavvy.com/teksavvy-faq/ ... vLxGWZ9v1P

"Web UI Address:

Routed mode (default): 192.168.0.1

Bridge mode: 192.168.100.1"

If that's not true anymore after a firmware update, Teksavvy needs to update its website.

You can change the last digit, and only the last digit

Honestly, I have no clue what either of you are talking about. As soon as you enable bridge mode and reboot CH8568, it should only be accessible via 192.168.100.1 using a web browser with the PC attached to the first LAN port on CBN CH8568. Otherwise, you enter 192.168.0.1 (default with router mode enabled), and login. Those IPs are defaults.

Basically, all online documentation states that, including your ISP's.


Wait. Are you not using a CBN CH8568? Is it a different model?

He couldn't believe what he was seeing.

Again, I have no clue what he's talking about or seeing.

The Teksavvy guy thought it had been able to connect because it had the upgraded firmware to deal with the more recent WPA2, and the others were still WPA.

Okay, so you must have Wi-Fi cams, which I didn't know previously.

Click https://help.teksavvy.com/teksavvy-faq/ ... vLxGWZ9v1P


You have 2 options:

A. Connect everything to CBN CH8568 (not in bridge mode), via ether it's Wi-Fi network or using ethernet cables to CBN CH8568's LAN ports, and disconnect/ditch TP-Link router because it's not needed and seems to be dying

or

B. Connect everything to TP-Link router, because it is needed for the cams to connect to Wi-Fi, with CBN CH8568 in bridge mode


Option A requires that your Wi-Fi cams can connect to CBN CH8568's Wi-Fi. Click https://help.teksavvy.com/teksavvy-faq/ ... vLxGWZ9v1P Then refer to "How to Set Up the WiFi Username & Password". I think you've been down that road before. I think you have old wi-fi cams that must not be able to connect to CH8568's 2.4 Ghz Wi-Fi. That must be why you're using the TP-LInk router.

I don't have a CBN CH8568, and I don't know what Wi-Fi Authentication methods CBN CH8568 support. That's Teksavvy' job to know.

https://support.dlink.com/resource/PROD ... _US_EN.pdf

"For security, you can choose None or WPA-PSK / WPA2-PSK. Select the
same encryption method that is being used by your wireless device/router.
If you chose WPA-PSK or WPA2-PSK, choose whether to use TKIP or AES."

So, DLink DCS-936L supports WPA2-PSK with AES. If CBN CH8568 does as well, great. That's Teksavvy's job to know. I don't have a CBN CH8568. They obviously have tons. Find someone competent that can answer what wi-fi authentication methods are supported by CBN CH8568. It needs to support WPA2-PSK with AES. If it doesn't, trying to connect DLink DCS-936L to CBN CH8568 is pointless, since it won't work.

https://lightspeed.ca/wp-content/upload ... CH8568.pdf (another ISP using CH8568 says CH8568 does support WPA2-PSK)



Option A

If Teksavvy says that WPA2-PSK with AES is supported by CH8568 , and if you want to pursue option A (since it's the ideal option that gets rid of dying TP-Link router), this is what I would do:


1. Factory reset the CBN CH8568: with the modem powered on, press and hold the rear RESET button for 10-15 seconds. This erases any lingering problematic settings (like the failed bridge mode) and ensures it is in its default Router Mode.

2. Connect Your PC and ATA: plug your PC and your SPA122 ATA into two of the four available LAN ports on the back of the CBN router.

3. Log In and configure Wi-Fi.

a) On your PC, open a browser and go to http://192.168.0.1.

b) Log in using the username cusadmin and the CM MAC password printed on the router's sticker.

c) Navigate to Wireless-->Wireless Signal

d) Select Disable under Wireless Band Steering. Wireless Band Steering is enabled by default (combines both 2.4Ghz and 5Ghz networks with a single SSID), which you don't want. You want two distinct networks to avoid confusion and potential issues arising from having both networks use a single SSID.

e) Click "Apply Changes"


This will create two separate and distinct Wi-Fi networks: one for the 2.4GHz band and one for the 5GHz band. You want the 2.4 Ghz band for your cams. If both networks are showing the same SSID name, then change the SSID name for the 2.4 Ghz network to something else if possible (and remember if you change the password, to make note of it). I don't know if it's possible to change 2.4Ghz SSID name and password in the CBN router. I'm sure Teksavvy knows.



4. Disable SIP ALG: while logged in, go to the Security or Administration tab and confirm that SIP ALG is disabled.






5. Connect your cellphone to the 2.4 Ghz Wi-fi network in the above pic.


Now we need to reconnect your cameras to the correct Wi-Fi Network (in the above pic)

6. Now that you have a stable 2.4GHz network, you can connect your cameras to it, provided Teksavvy said you can (WPA2-PSK with AES is supported) and isn't wrong.

7. This is up to you, but again, this is what I would try. Take one of the cameras that you cannot access and perform a factory reset. This should clear its old, invalid network settings.

I'm guessing the process is something like this:

a) Locate the reset button. It is a small, recessed pinhole on the back of the camera.
Use an unfolded paperclip or a similar pointed object to gently press and hold the reset button.
Keep the button pressed for 6 to 10 seconds. One guide suggested up to 15 seconds to be certain.

b) Release the button. You should see the LED light on the front of the camera change state, often turning red or flashing, to indicate that the reset process has begun

c) Wait for the camera to reboot. This process can take a minute or two as the camera erases its settings and restarts with its factory defaults.

d) After the reboot is complete, the camera will be ready to be set up again from scratch using the My Dlink app as if it were a brand-new device.
Choose the 2.4GHz Network: during the setup process, the app will ask you to choose a Wi-Fi network. You might see two networks from your CBN CH8568. It is essential that you select the 2.4GHz network. Do not connect the cameras to the 5GHz network.

8) Test web access. Once the camera is online and visible in the app, find its IP address in the CBN router's DHCP client list. From your PC's web browser, try to access that IP address. The camera's login page should now appear.

9) Repeat for other cameras. If the first camera works, you have found the solution. You can now use the D-Link app's settings for the other three cameras to switch their Wi-Fi connection to the new 2.4GHz network, likely without needing to factory reset them.




Option B

Option B isn't ideal since TP-Link router appears to be dying, but we know that option B can work--and we don't know whether option A can.

1. Enable bridge mode

a) Remove all other Ethernet cables to all other LAN ports on CH8568.

b) Connect PC via an Ethernet cable to the 1st LAN port.

c) Open a web browser and go to 192.168.0.1.

d) Click on the Internet tab.

e) Select Bridge Mode and Apply Changes. After CH8568 reboots, it should be accessible only via 192.168.100.1--unless Teksavvy's documentation is wrong and something has changed in CH8568 firmware.

2. Disconnect PC from CH8568.

3. Connect TP-Link router's WAN port to CH8568's 1st Lan Port.

4. Connect PC to a LAN port on TP-LINK.

5. Connect ATA to another LAN port on TP-Link.

6. Ensure cellphone is connected to TP-Link's 2.4 ghz Wi-Fi network only.

7. Take a webcam that doesn't work and factory reset it. Then you would basically follow the same process as steps 7, 8, and 9 from option A--but this time you're connecting to TP-Link's 2.4 Ghz network. Don't confuse CH8568's 2.4 Ghz Wi-Fi SSID with TPLink's 2.4 Ghz Wi-Fi SSID.

[Erft]

Thanks for the detailed reply. It's too detailed for me to thoroughly read right now, but I will later.

However, now that I read you have Wi-Fi cams, step 7 should have been to ditch the TP-Link router and to connect everything to CH8568.

For now I will just mention that when I first got the CBN modem, I did try to set the cameras up with it, no router. But they would not connect. This is not the first modem-router that the cameras wouldn't connect to. Even the more up-to-date routers don't work with them. Teksavvy and I worked on it for along time, and that's how I came to bridge the modem and insert the router back into the network. Even the camera with the most up-to-date firmware only showed me an inactive and compressed Settings page. So I have no options, I have to use the modem in bridge mode and a router that the cameras can connect to (which so far, has only been the TL-WR841N)

At the beginning of our journey, yes, the modem (CBN-C73F0)and the PC were connected directly.
He told me that in bridge mode, only one port at the back of the modem will work, so then it was unplug the PC and plug in the router, at one point the ATA was also plugged in there, and the PC cord migrated from location to location.

The only browser the camera interface properly works on is Internet Explorer. I have the pages set up in Internet Explorer Mode in Edge.

I have looked at getting more recent models of security cameras, but money is tight and nothing I've looked at will give me the ten-second video clip that the DCS-936L will, and none have the fabulous web interface that allows you such great and speedy control, that the DCS-936L does. Through the DCS-936L web interface you can set it up to send you a ten-second video clip to your email when motion is detected. You can quickly choose the motion detection area, and have motion detection all the time, cyclically, only sending you a video clip upon motion when you save that particular preference. It takes seconds as opposed to many, many minutes in the phone app, which is much better when you have to fly out the door. Plus the video clip is only available in the web interface. And they will not connect to the modem, no matter what Teksavvy tech support and I tried.
Perhaps if I could afford data on my phone, it would be an easier situation, but this is not the case.

The tech and I factory reset the modem and took it out of bridge mode. The IP address did not make him happy, so he asked me to go into the modem settings and manually change the IP address to be what it needed to be. The settings showed the IP address, and the last two digits were in a field box so you could change them, but not the digits before the last dot, which was what he wanted to change. He couldn't believe that the makers didn't make both the fourth and third sets of digits changeable.


A replacement TL-WR841N is arriving tomorrow. I was hoping to avoid having a faulty router in the mix anymore. But I have looked at other security cameras before. I will look again.

[Liptonbrisk]

For now I will just mention that when I first got the CBN modem, I did try to set the cameras up with it, no router. But they would not connect.

I think you've been down that road before. I think you have old wi-fi cams that must not be able to connect to CH8568's 2.4 Ghz Wi-Fi. That must be why you're using the TP-LInk router.

However, I'm uncertain whether you disabled band steering first in CH8568, as per my instructions in the previous post.

I'm also uncertain if Teksavvy says that WPA2-PSK with AES is supported by CH8568.


D-Link says,
"For security, you can choose None or WPA-PSK / WPA2-PSK. Select the
same encryption method that is being used by your wireless device/router.
If you chose WPA-PSK or WPA2-PSK, choose whether to use TKIP or AES."
https://support.dlink.com/resource/PROD ... _US_EN.pdf

So, we know DLink DCS-936L supports WPA2-PSK with AES, but I don't know that CH8568 does until Teksavvy confirms (I think CH8568 is supposed to).

At the beginning of our journey, yes, the modem (CBN-C73F0)

I got a new router (cbn CH8568 Docsis 3.1)

What model are you using right now? What device am I supposed to be troubleshooting?

The IP address did not make him happy, so he asked me to go into the modem settings and manually change the IP address to be what it needed to be.

The desired configuration is pretty straightforward: if you're using TP-LINK, cbn CH8568 needs to be in bridge mode, TP-Link wan port needs to connect to cbn CH8568 lan port--and everything else needs to connect to TP-Link either via ethernet cables or TP-Link's Wi-Fi.

That's how you get 1 LAN.

You've enabled remote access/management in the ATA, so the previous WAN port access problem is gone. The ATA's WAN/internet port can just be connected to a TP-Link's LAN port, and you can access the ATA while the PC is connected to another TP-Link LAN port.
i) Dial **** (four stars)
ii) Then dial 110#
iii) Enter the IP address you hear into a web browser.
iv) Login to your ATA. (default username and password is admin)
v) Always choose the admin login

[Erft]

It is in bridge mode.
Sorry, I was looking at the wifi network name on the side of the modem, My eyesight isn't so good. It's CH8568. I sincerely apologise.

It's really simple: if you're using TP-LINK, cbn CH8568 needs to be in bridge mode, TP-Link wan port needs to connect to cbn CH8568 lan port--and everything else needs to connect to TP-Link either via ethernet cables or Wi-Fi.

Yes, that is how it's set up.

RTSP ALG - To allow some media player clients to communicate with some streaming media servers across NAT

-I have no idea if I'm using this or not. I have disabled everything but this ALG.
-There's only one firmware upgrade, and it's for V14.0, which is the hardware version of my router. I have downloaded it.
-Every ALG but RTSP is disabled (because I don't know if I need it or not).
-I can log into the SPA122 with the admin username, but I don't see anything resembling "Advanced view menus". In the top right it has admin(Admin), Log Out, About, Help. Nothing else.

Your answers are very in-depth, incredibly detailed and, to someone who doesn't speak the language, extremely complicated. I don't know the terminology, I'm Googling everything as I go, and understanding half of it, while translating acronyms "WAN" into regular words. I am trying to understand multiple steps while trying to get my mind around how it all works, and I dont think I'm capable of learning all this. I am trying. I'm getting all the steps mixed up, which is why I need to go step by step.

For now, why don't we leave this for a couple of days or so? You are stressing over Saturday and I imagine you're going to feel unwell for a while, I'm actually living this nightmare and the stress is exacerbating some health issues. I was unable to cancel the router, so it's on it's way, but I am going to look at new security cameras that could work so the router isn't necessary and I can just connect everything to the modem.


I really do appreciate all the help you're trying to give, and I know this is a frustrating situation. Hopefully I can find some affordable security cameras that can do something halfway to what the DCS-936L can do, that will all connect up nicely to the modem, no bridging required.


I hope all goes well and you recover quickly.
Take care, and thank you.

[Liptonbrisk]

It is in bridge mode.
Sorry, I was looking at the wifi network name on the side of the modem, My eyesight isn't so good. It's CH8568. I sincerely apologise.

No problem

Yes, that is how it's set up.

Okay, then that tech didn't need to fiddle with your CH8568. All that needed to be done was to enable remote access/remote management in the ATA and then connect the ATA to TP-Link router and the PC to TP-Link router, respectively.

-I can log into the SPA122 with the admin username, but I don't see anything resembling "Advanced view menus". In the top right it has admin(Admin), Log Out, About, Help. Nothing else.

Just use admin login. That part of the instructions applied to some older Cisco/Linksys ATA models.

while translating acronyms "WAN" into regular words

Wide Area Network (WAN) = basically the outside world/internet

Local Area Network (LAN) = basically inside your home

You don't (usually) want two (LANs) areas with devices inside your home that can't communicate easily with each other because they are on separate networks/subnets (there can be cases where people want that, but, for you, you don't). If CH8568 is not in bridge mode, it represents one LAN. Your TP-Link router represents another LAN when it's not operating in access point mode.


I would just focus on this post for now: viewtopic.php?p=82492#p82492 (the two options)
Choose option A or B. Maybe if you can get option A to work, it saves you money (but I wouldn't bother trying it unless Teksavvy answers for you the question that I have about WPA2-PSK first) insofar as not needing to buy another router.

If option A doesn't work after trying to make it work with all cams, you're probably going to have to factory reset all cams in order to try to make them join TP-Link Wi-Fi (option B). I'm not positive because I'm not familiar with the method of trying to setup the cams to join different Wi-Fi networks within the smartphone app.

[Erft]

Hah. Now I have four working cameras. I just went looking for the IP addresses instead of trusting the DHCP client list. Found 'em. And since I did, now the DHCP client list updated itself, too.
O.M.G.

Earlier today I tried calling a doctor's office, and the phone rang and rang for about a minute, until a robo-voice told me to enter my remote code. After I got my cameras back tonight (I think that had something to do with disabling the SIP ALG...twice), I tried again. Same problem, but when I called using my cell, it went straight through to the office voicemail. So it's not just surveys and navigating company systems; it's also calling out. This has been an occasional problem for over a year and I never realised it was related to my phone being VoIP. When you're feeling up to it, I hope we can clear that up for good.


I'm still going to look for new cameras.

Take care.