PJSIP: Fallback according NAPTR priorities?

Hi community

I’m am Kamailio Registrar and I am using NAPTR to instruct clients where to connect.

reg 300 IN NAPTR 10 100 s SIPS+D2T _sips._tcp.reg.example.com.
reg 300 IN NAPTR 20 100 s SIP+D2T _sip._tcp.reg.example.com.
reg 300 IN NAPTR 30 100 s SIP+D2U _sip._udp.reg.eample.com.

There are correcponding SRV records pointing to the port and host:

_sips._tcp IN SRV 0 0 5061 reg.example.com.

pjsip.conf I use the ‘hostname’ without port or transport to have Asterisk perform NAPTR lookups:




TLS is not yet configured. So I would have expected asterisk, after failing to register on TLS to use the next on the priority list and try TCP and then UDP.

But from what I see, asterisk keeps retrying to register on TLS.

Am I missing something?


What does “TLS is not yet configured” mean? If there is no TLS transport, then TLS shouldn’t be used at all. You can check what transports will be used by looking at output from res_pjsip at startup where it tells you, and if you enable core debug the DNS resolution will tell you precisely what it is doing and the choices it has made.

Port 5061 not yet listening on the registrar. So registrations attempt from Asterisk to Registrar port 5061 either get ICMP rejected or dropped (need to check on the Firewall).
But either way, I would have expected asterisk to fall-back to another transport as multiple are provided via NAPTR entry.

It should. The core debug may provide additional insight, however if you are using 16 as your other thread indicates - that version no longer receives bug fixes.

core debug 9999 does not produce more output on the transport selection. I’ll try to dig deeper.
16.28 is the ‘stable’ debian branch. I guess I have to wait until next debian release :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.