We are seeing an issue with several S505 and S705 phones configured to use NAPTR-based DNS. Each phone is set with two SIP servers: pbx1.domain.com and pbx2.domain.com, both of which are NAPTR records. pbx1.domain.com resolves to 192.168.1.1 and pbx2.domain.com resolves to 192.168.1.2.
Randomly, 192.168.1.1 receives REGISTER requests from the phones where the Request-URI host is still pbx1.domain.com. Other phone brands using the exact same DNS records do not exhibit this behavior and never send these unexpected REGISTERs.
Has anyone seen this with Sangoma S-series and NAPTR/SRV, or know how to properly troubleshoot or work around it? Any guidance would be appreciated.
Can you provide more specific details. NAPTR/SRV may be a DNS option in devices but it means look at NAPTR first then SRV. You use NAPTR to point to an SRV when a device doesn’t support SRV.
An NAPTR record
proxy.domain.com. IN NAPTR 10 100 "s" "SIP+D2U" "" _sip._udp.proxy.domain.com.
Yes, they do. That is for redundancy/failover. NAPTR/SRV records are for redundancy/failover. You mixing two flavors together for this and getting mixed results.
The example I showed you of the NAPTR/SRV is for using it in proper redundancy/failover. I just have SIP Server 1 programmed to point to proxy.domain.com, the SRV records have pbx1 with the higher priority (0) and pbx2 with a lower priority (100). By doing this, the phones registered to pbx1 as long as it is up and responsive.
This avoids the phone being registered on two servers at once, having two servers sending keepalives or any other MWI, etc. or the phones using the wrong server for outbound requests.
Yes because A/AAAA records don’t work the same way. If you have three A records for pbx1 pointing to three different IPs, each lookup against pbx1.domain.com could return any of the IPs as the resolved IP to the name. It’s a poor way to handle failover.
My advice is to pick only one of these methods. Either use both SIP server settings in the phone or do correct SRV records and have them use proxy.domain.com or whatever you want to call it for the SRV FQDN.
To clarify: the issue I’m seeing is not mixed or inconsistent DNS responses. It happens regardless of whether we use NAPTR/SRV or plain A records. The problem is that these Sangoma phones will sometimes send REGISTER requests to the primary phone system using the DNS name of the secondary SIP server.
I understand that approach and we do use that model with some customers. It works fine in those environments.
In our case, having phones registered to two SIP servers at the same time is intentional, not a misconfiguration. Many of our customers specifically chose Yealink (and other brands) because they maintain simultaneous registrations to both servers. That eliminates DNS or REGISTER/OPTIONS failover delays: when a call hits the secondary server, the phone is already registered and can ring immediately. For MWI, most vendors (Grandstream, etc.) let you point MWI to a specific server, so dual registration does not inherently cause MWI issues either.
The concrete behavior we are trying to troubleshoot is:
PBX1 = pbx1.domain.com → 192.168.1.21
PBX2 = pbx2.domain.com → 192.168.1.22
Yet, at random times, we see REGISTER requests going to 192.168.1.22 but using pbx2.domain.comas the host while the phone should be using the primary system at that moment.
This is the part that does not match how other phone brands behave with the same DNS setup, and this is what we are trying to understand or confirm as a bug/quirk on the Sangoma side.
Not really, I’m trying to figure out why you have a NAPTR and SRV record for each domain. It makes using those pointless. You might as well just use A records with the two sip server approach.
So you have two problems then?
So it will send a request to 192.168.1.21 but RURI or FURI domain is pbx2.domain.com?
Then you have the phone using the secondary server when it should be using the primary server?
I’m curious does this problem exist if the phone is using a single FQDN that has SRV that points to the two FQDN’s.
If you just use the IPs in the primary/secondary server on the phone does this problem go away or does it persist? If it goes away, you have a DNS issue.
Indeed. At the time of querying this particular customer has only one SRV record. We usually setup with more SRV and A records. This was just an example, and I agree, if we use only one SRV/A then the NAPTR is probably an overkill.
Correct. We bumped into this issue when we deployed SBCs that do domain filtering at each site and saw that only Sangoma phones register to the primary PBX with the RURI from the secondary. This is across all customers, only with Sangoma phones.
I can test it, but that’s aside from the current issue.