Sip Trunks Failover Not working, NAPTR record succeeding then but then no lookup being done for srv records

[timamplex]

Having an interesting issue in testing a 3CX config for some of our clients, SIP trunk failover isn't working when a switch doesn't respond. The sip trunk appears to be doing a lookup for NAPTR records and receiving correct one but then does not do a followup lookup for the SRV records.


Based on:
https://www.3cx.com/docs/sip-trunk-failover/


Example NAPTR lookup for lighthousesol.com.nms0.amplex.net


Answer

Type	Order	Preference	Flags	Services	Regexp	Replacement	Name	Class	TTL
NAPTR	10	10	s	SIP_D2U		_sip._udp.nms0.amplex.net	lighthousesol.com.nms0.amplex.net	IN	1199

SRV lookup for: _sip._udp.nms0.amplex.net

Answer

Type	Priority	Weight	Port	Target	Name	Class	TTL
SRV	20	10	5060	nms1.amplex.net	_sip._udp.nms0.amplex.net	IN	947
SRV	10	10	5060	nms0.amplex.net	_sip._udp.nms0.amplex.net	IN	947

Yet results are just chain registration attempts to nms0.amplex.net, never any attempts to nms1, nor do I see in tcpdumps any SRV lookups being done. Just an A query.


Trunk Config Registra/Server/Gateway as lighthousesol.com.nms0.amplex.net it's a registered SIP trunk. If I unblock from nms0.amplex.net the testing IP the trunk registers/processes fine, it just seems to be failing due to not following any NAPTR or SRV records. I've got "Auto Discovery" checked on registrar/server/gateway.

3CX Debian 16.0.3.676 is my testing platform.

Anyone have any advice? Very odd behavior from other systems I've seen.

Tim

 

[YiannisH_3CX]

Hi @timamplex

When a trunk is registration based the PBX will failover to the next SRV record when a registration attempt fails or when a call attempt fails for 32 seconds.
In your scenario if you block the first target "nms0.amplex.net" you must wait for the PBX to try to re-register. Once that happens the PBX will attempt to register to the same target for 32 seconds before switching target. Make sure you are providing the PBX enough time for the switch.

 

[timamplex]

@YiannisH_3CX the problem is this is not actually happening that way.

In fact, I've left this demo machine up a while and the last failed register attempt was 12/18/2019 at 6:36:37 PM. It appears to just randomly give up trying to register and never performs the correct record checks and attempts.

I had to manually click "Enable all" and then it sent a single register attempt and failed again, never trying the secondary SRV records.


The trunk host is lighthousesol.com.nms0.amplex.net set to Auto Discovery which again, passes NAPTR record checks and SRV checks.

Something is broken and not working as intended here.

I'm happy to perform packet captures for 3CX support team if you want to open a ticket. You can reach me at tima at amplex dot net ( trying to avoid the forum scrapers signing me up for the random_spam_lists)

Tim

 

[cobaltit]

@timamplex

Try this article:

https://www.3cx.com/docs/sip-trunk-dns-record-resolution/

 

[cobaltit]

And now that Update 4 is out, I'd try under that as well in case it was an issue in Update 3. They aren't going to go back and fix it.

 

[YiannisH_3CX]

Let's take it one step at a time. First update to SP4 so you are on the latest version of 3CX and try again. If the behaviour is the same start a pcap on the test machine and while the pcap is running restart the SIP server. Once the service is back up replicate the issue while leaving the pcap running. Once replicated save the pcap and send me a p.m.

 

[timamplex]

Tried all of the steps outlined above, I see the NAPTR lookup but never any srv lookups and never any secondary registration. On latest code release.

PM'd you @YiannisH_3CX

 

[cobaltit]

Instead of leaving it at auto discovery can you try specifically setting the protocol to UDP and the port to 0. Should be what autodiscover does automatically but can determine if it's a problem with the autodiscover setting or with the NAPTR lookup