DHCP

I have recently been having a problem with my VoIP in that during a call I would loose the incoming audio. Not easy to determine whether my VoIP supplier, my FTTC connection or my VoIP adaptor.

Decided to purchase a new Cisco ATA191 to replace my Cisco SPA112.

Armed with a full printout of my SPA112 settings, I thought this would be an quick and easy job.... Not so.

I was able to obtain the unit's IP address using the handset to access the web setup page. As supplied, the ATA was set for "Automatic Configuration - DHCP" and initially I changed this to Static IP and inputted the IP address as just found. Similarly keyed in all the other settings and no connection or in/out calls.

Messed around and after changing back to "Automatic Configuration - DHCP" all came good. Not really sure why, but at this stage, any port in a storm as us ancient mariners say.

Since the previous adaptor was set up for a Static IP, I cannot see why this one does not and instead requires DHCP.

Is there anything obvious I should now be thinking?

Many thanks.

Cheers!

Depending on how you previously set things up on the Draytek it may only allow the previous ATA's MAC address to use the static IP address. Have a poke around and see if it's in the BIND IP to MAC section - https://www.draytek.com/support/knowledge-base/5681

DHCP can provide (via the INFORM) much more than just the IP for the client device.

Other (non-exhaustive) things to check:
Subnet mask
Gateway (router)
DNS (1 or more IPs)
DNS domain (suffix for FQDN and unqualified lookups)
NTP (preferably 2 or more unless you already have something internal serving your LAN)
MTU
STUN, TURN or ICE (but I think these days SIP providers offer to be a NAT proxy to help maintain incoming calls and 2-way voice)

If still stumped try to get some complete status/report of what settings the ATA has autoconfigured when on DHCP.
When you set DHCP does that apply to both IPv4 and v6 (does ATA also get a global scope IPv6 addr) ?

When on DHCP it is possible that the ATA uses uPNP or NAT-PMP to ask the router to open some incoming ports, and might not do that when on static.
Another possibility is whether with the previous ATA you created any port forwards to it to workaround earlier problems, such that they no longer relate to the new ATA.

In general with DHCP working you are better off creating reservations for specific clients as it keeps the addresses (both fixed and dynamic) managed from a central place, and one place to go if renumbering.

The only things I configure manually now are routers and hosts acting as DHCP/DNS servers.

Edited by prlzx (Mon 01-Feb-21 17:58:58)

Thanks Sarah & Paul.

I had a look in the Draytek's "Bind IP to MAC" and my previous SPA112 was not there.

Strangely(?) with the new ATA191 set to DHCP everything seems happy. My other items on the network also seem happy, so for the moment at least I will leave things as they are. This working on the "if its not broke, don't fix it".

In the back of my mind I am sure that when I first fitted the SPA112 it would only work on a Static IP. I have had some DHCP issues previously, https://forums.thinkbroadband.com/multiuser/f/462472...

Thanks again.

Cheers!

I have had an SPA112 with a fixed IP address for the past 5 years without problems. There are two accounts. A Voipfone account where I can only have one IP device active and a Sipgate account where multiple IP devices will ring if the number is called.

I would recommend you switch off DHCP for anything related to VoIP, especially gateway devices like your ATAs. This could well be a reason for your intermittent one-way audio issue.

Best to leave it with a static IP address internally - that will certainly make any port forwarding easier and more reliable too.

If choosing a fixed IP address - *do not* use the exact same address one that has already been assigned from the DHCP address pool from your router, there is a risk that the router will hand out this address (to another device) and it will clash with the same fixed IP address you've just assigned. You need to choose one outside of the address pool. Netmask and gateway should otherwise match up.

Edited by Pheasant (Wed 03-Feb-21 18:59:16)

I don't know if you've actually read all of Ancient_Mariner's posts in this thread, as they indicate it all works correctly under DHCP, and they were just wondering out of curiousity why they could not recreate the same experience under a static IP. They only had problems when the ATA or SPA was using static IP.

It's not necessary to use a static IP to have reliable port forwarding to a known LAN IP, this is also what DHCP reservations let you do.
Furthermore, with some routers like the Fritz Box and Thomson/Technicolor models, when you assign the device by DHCP they can populate the DNS with the hostname provided by the client, and treat it as an object allowing you to pick by name from a list as the target of your port forward.

The only part I can agree with is not taking the automatically assigned lease and manually setting that as static on the client device. However even here the reason that causes problems misses the point - it is because doing this makes the lease expire without being renewed, not because of any problem with DHCP, but precisely because you *stopped using it* and configured an IP in a way which was likely to conflict.

For completeness, I should note that typical DHCP behaviour is to check if an IP is already in use (via ARP) before offering (on server) or accepting (on client, by then DECLINEing), iterating until it finds a free one.

By all means people can do whatever they want to experiment and learn but in the vast majority of cases turning off any auto configuration protocol creates additional administrative workload which the protocol was invented to save.

Unless you understand when it actually solves some problem it's not an improvement or optimisation and can come from a need to feel in manual control or desire to endlessly tweak. I will freely admit to wanting to tinker with Windows' RWIN in the old days but not now.

Edited by prlzx (Thu 04-Feb-21 02:39:10)

A handful of statically assigned addresses (in a home network) really isn't going to be particularly burdensome from and "admin" perspective. Once set they will likely never need to be changed unless of course you decide to change the whole IP addressing scheme, which for most folks is unlikely.

Personally I've lost count of how many home routers I've changed and swapped out over the years and what is quite burdensome is the setup factor if you're using DHCP address reservation, new router have to do it all over again. Whereas if they're statically assigned, adjust the DHCP address pool accordingly, plug and go.

I believe the OP did link back to some previous DHCP issue, but I've not looked directly at that. In my experience DHCP certainly isn't a completely bullet proof protocol. I've had issues for example over the years with various Cisco endpoints and DHCP servers from other manufacturers simply not playing nicely together. You can spend an inordinate amount of time getting to the bottom of things - or to get things up and running just statically assign them.

Anyhow your mileage may vary as they say.

For the last few days I have had the Cisco ATA191 VoIP adaptor plugged into my network next to a phone and all has been fine with it set to DHCP. and I could access the Configuration Utility on 192.168.1.19

Yesterday unplugged and took it to where it will live adjacent to my DrayTek Router. In order to keep cables tidy, I needed to power down the Router. The Tel 1 output from the adaptor is connected to my internal wiring where it is connected to two analogue desk phones.

Powered up the router and the adaptor and a test of my VoIP number, in/out was good. Returned to my pc and found that I could no longer access the adaptor on 192.168.1.19 and accessing the IP via one of the phones showed that the address had changed to 192.168.1.10 Likely due to the router being power cycled since the ATA191 had been unplugged a few times.

Probably this is what I should expect, but no obvious downside as the router and the adaptor found each other and calls and CLI are fine.

Whether the fault, loss of incoming call audio reappears, which is why I bought this new adaptor, time will tell.

Cheers!