...
Ace Innovative has recently introduced a high availability service and has begun migrating most of their clients to this ITSP node named csp1.acepbx.com. There are actually two target nodes behind csp1.acepbx.com - csp1.acepbx.com (66.114.83.74 ) and csp2.acepbx.com (66.114.83.75). csp1.acepbx.com is provisioned in the address field (PSTN gateway address in the Devices->Gateways->SIP trunk menu) when the SIP trunk is defined. The way Ace has defined the service is that all traffic goes through the primary csp1 nodeand the backup csp2 node is used only when csp1 is unavailable. In the above diagram, Ace Innovative has defined a NAPTR record for csp1.acepbx.com called
_sip._udp.srv.csp1.acepbx.com. That NAPTR record is then used to query the SRV records - two are returned. The target node csp1.acepbx.com is the record with the lower priority (10) and Sipxbridge should register to this node. Sipxbridge queries for the NAPTR and SRV records correctly - the issue is that Sipxbridge prior to 17.10 does not process the SRV records correctly, and registers the trunk to csp2.acepbx.com about 50 percent of the time. . sipXbridge in 17.10 and later now handles ITSP connections with SRV records.
The good news is that on a busy Sipxcom system, there is no impact when the SIP trunk registers to csp2.acepbx.com. Sipxbridge always sends a keep-alive UDP packet every 20 seconds to csp1.acepbx.com regardless of whether the SIP trunks registers to csp1 or csp2. If there are incoming PSTN calls that arrive within the 10 minute SIP trunk registration window, then the invites will continue to be delivered from the primary csp1 node. The firewall state for csp1 is maintained by the 20-second Sipx keep-alive packet, so the incoming call successfully traverses the firewall to the Sipxcom server.
...