[SR-Users] NAPTR priorities doesn't seem to work properly

Iñaki Baz Castillo ibc at aliax.net
Wed Jun 15 14:32:24 CEST 2011


2011/6/9 Iñaki Baz Castillo <ibc at aliax.net>:
> 2011/6/9 Alex Hermann <alex at speakup.nl>:
>> The way I read rfc2915, there is no failover mechanism. The application pick
>> the first target that it supports and uses that. There is no mention of trying
>> other records afterwards. Matching/finding NAPTR records stops once the first
>> match is completed. All other records are discarded. From  section 2:
>
> Hi Alex, two comments:
>
> 1) What you say does not explain my issue (as in any case TLS or TCP
> have more priority in my NAPTR's than UDP). In fact, my exact problem
> is that my Kamailio is not performing NAPTR query.

The problem is fixed now, it was an error related to the NAPTR service
flag (sip-router expected it to be "s" case-sensitive, while it should
also allow "S").


> 2) About your quoted text, indeed RFC 2915 says that. But that just
> means that, an application (in this case a SIP client) must take
> *first* the valid NAPTR record with better "order" (lowest value). But
> RFC 2915 is just about NAPTR, it can not mandate that applications or
> protocols cannot try other NAPTR records as failover mechanism. Any
> SIP client or proxy implementing NAPTR records does failover to the
> next NAPTR record in case the first one failed (at least those I've
> tested).

It seems that sip-router behaves exactly as you describe. This it, it
performs the NAPTR resolution, chooses the record with best 'order'
(for the supported transports) and just uses it (it would do SRV
failover and so, but would never try other NAPTR records with less
'order').

However I've seen other SIP stacks also performing failover by taking
next NAPTR records. But indeed, RFC 2915 does not mandate it, instead
it says MUST NOT. So you are right.


Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>



More information about the sr-users mailing list