When using an SRV record to relay to a destination, OpenSIPS will repeatedly attempt to send the message to the second result in the lookup reply.
Here's an example (assume no response is received to the message):
- call t_relay() to relay to sip.example.com
- OpenSIPS performs SRV lookup for _sip._udp.sip.example.com
- DNS responds with sip1.example.com, sip2.example.com, sip3.example.com, sip4.example.com (equal priority)
- OpenSIPS performs A lookup for sip1.example.com
- OpenSIPS relays the message to sip1.example.com (including retransmits)
- OpenSIPS performs A lookulp for sip2.example.com
- OpenSIPS relays the message to sip2.example.com (including retransmits)
At this point, OpenSIPS should attempt to use sip3.example.com, but instead continues to lookup and then send the message to sip2.example.com until these errors show up in the log:
Feb 18 16:36:08 bgw1 opensips[1745]: ERROR™️add_uac: maximum number of branches exceeded
Feb 18 16:36:08 bgw1 opensips[1745]: ERROR™️t_forward_nonack: failure to add branches
Corrects the infinte loop.
The attached patch (against the 1.6 branch) causes OpenSIPS to correctly walk through all of the SRV responses instead of continuing to use the same entry.
Hi,
Could you post the logs (debug=4) for such a scenarios ? it will be easier for me to understand what is going on.
Also, if the DNS record is public, maybe we could let me know its name, so that I can try for myself.
Regards,
Bogdan
debug=4 log for this scenario
Log attached. DNS record is SRV _sip._udp.wholesaleorigination.acc.globalipcom.com.
Hi Byron,
Thanks for the fix - indeed, it is correct. I applied the same fix to the NAPTR iteration also. Both fixes are available o trunk, 1.6 and 1.5
Regards,
Bogdan