[SIPForum-discussion] SIP NAPTR

Wed Jan 13 07:35:11 UTC 2010

Hi Basling et al.

Please find my reply inline:
> Read the below content and you will find answer to your self
Sorry but i didn't catch it fully. Can you please clarify it little bit 
more.
> First when we want to place a call to 2125551212 at example.com.,we don't 
> know what IP address, port or protocol to send this call to.
> To find out, we start with a *NAPTR record lookup* for the domain we 
> were given:
>
> #* host -t NAPTR example.com <http://example.com>*(The -t option is 
> used to select the query type.)
> example.com <http://example.com> NAPTR 10 100 "S" "SIP+D2U" "" 
> _sip._udp.example.com <http://udp.example.com>.
> example.com <http://example.com> NAPTR 20 100 "S" "SIP+D2T" "" 
> _sip._tcp.example.com <http://tcp.example.com>.
> example.com <http://example.com> NAPTR 30 100 "S" "E2U+email" 
> "!^.*$!mailto:info at example.com!i" _sip._tcp.example.com 
> <http://tcp.example.com>.
>
The last NAPTR is valid? I am confused.
According RFC3402-RFC3403 i saw that only can be one from "regexp" OR 
"replacement" be set.  But i didn't find a statement MUST or SHOULD in RFC.
They are exclusive as you wrote too bottom? What is it if both are set?

"REPLACEMENT field and the REGEXP field together make up the 
Substitution Expression in the DDDS Algorithm. It is simply a historical 
optimization specifically for DNS compression that this field exists.  
_The fields are also mutually exclusive."_
> From the above look up we can come to know that we can contact 
> example.com <http://example.com> domain in three ways
> First using SIP over UDP protocol  _sip._udp.example.com 
> <http://udp.example.com>.
> Second using SIP over TCP protocol  _sip._tcp.example.com 
> <http://tcp.example.com>.
> and third is using Email over UDP.
>
> In the above NAPTR response 10 refers to the preference for the 
> record. The lower number is always tried first.100 is the order and is 
> only important if the preference numbers are the same
This Order and Preference is not clear to me too. What's about fallback?

RFC3403 states:

The important DIFFERENCE between ORDER and PREFERENCE is that once a 
match is found the client MUST NOT consider records with a different 
Order but they MAY process records with the same Order but different 
Preferences.

So according your example it can't fallback to tcp if the server is 
supporting both protocol?!
It will find with order 10 so can't retry with 20 according the above 
statment from RFC3403?
What is your opinion?

example.com NAPTR 10 100 "S" "SIP+D2U" "" _sip._udp.example.com.
example.com NAPTR 20 100 "S" "SIP+D2T" "" _sip._tcp.example.com.

Only can fallback if the zone file seems like this?

example.com NAPTR 10 10 "S" "SIP+D2U" "" _sip._udp.example.com.
example.com NAPTR 10 20 "S" "SIP+D2T" "" _sip._tcp.example.com.

> The "flag" field, in this case "S", is next  which denotes that an SRV 
> lookup is to be performed on the output of this NAPTR record
I read, that if the "flag" is not set, then the rule is not terminal rule.
Can i use not terminal rules during NAPTR resolving?
Like in my last example:
;;                 order pref flags service    regexp replacement
example.com        IN NAPTR 10 10    ""    "SIP+D2T" 
""                          redirect
redirect  IN NAPTR 5  10    ""    "SIP+D2T" ""                          .
redirect  IN NAPTR 10 10    ""    "SIP+D2T" ""                          
redirect2.
redirect2 IN NAPTR 10 10    "s"   "SIP+D2T" 
"!(.*)$!_sip._tcp.\\1!"             .

If i start resolving with example.com with the above zone, if i am not 
wrong i will get in the end: _sip._tcp.example.com SRV record as the 
next step to resolve. Is this valid example, and am i right?
> "SIP+D2U" is SIP over UDP, "SIP+D2T" is SIP over TCP E2U  email over 
> UDP.The next field  "". This is the "regular expression" field. The 
> regular expression is used to mutate the original request (in this 
> case "example.com <http://example.com>") into something new.The last 
> item we have is the "replacement". In the first result from our 
> example above, we have "_sip._udp.example.com 
> <http://udp.example.com>". Regular expressions and replacements are 
> mutually exclusive. If you have one, you shouldn't have the other. The 
> replacement is used as the "result" of the NAPTR lookup instead of 
> mutating the original request as the regular expression in the 
> paragraph above.
>
I hope i good understand You and the RFC, but i am uncertain on some field:

   1. regexp and replacement are mutually exclusive. It's OK, but:
         1. Is it a must or a Should?
         2. Can please you point me on RFC where it is stated?
         3. What happens if both are set, what has precedence?
            (replacement?)
   2. In every naptr lookup loop the same original Application Unique
      String is used as input to the rule?
      In my mind a DDDS rule is a regexp or replcaement field(mutually
      exclusive).

> So because we have the *"S" designation in the "flag" field, our next 
> step is to find the SRV record for the replacement*
>
 From this point it is clear from the process of the lookup.
I am only uncertain about host to process the above NAPTR.
> #* host -t SRV _sip._udp.example.com <http://udp.example.com>*
> _sip._udp.example.com <http://udp.example.com> SRV 5 100 5060 
> sip-udp01.example.com <http://sip-udp01.example.com>.
> _sip._udp.example.com <http://udp.example.com> SRV 10 100 5060 
> sip-udp02.example.com <http://sip-udp02.example.com>.
>
> We get two answers here so first we'll try sip-udp01.example.com 
> <http://sip-udp01.example.com> because it has the lower of the two 
> priorities. (priority 5 before priority 10. 100 is the weight which is 
> used to differentiate between records of the same priority.) *Next we 
> do an "A" record lookup to find the IP of the server to use to send 
> our SIP INVITE
> *
> *#host sip-udp01.example.com <http://sip-udp01.example.com>*
> sip-udp01.example.com <http://sip-udp01.example.com> has address 
> 11.22.33.44
> So in this example, our top preference would be to send a SIP INVITE 
> via UDP to port 5060 on 11.22.33.44.
>
> I think u should be understanding this
>
> So first *NAPTR lookup--->Next --->SRV lookup---->Next ----->A lookup* 
> next send the request.
>
Sorry about lot questions.

Indeed thank YOU very very much for Your answer!!
Can you please help me understand, and shading light on the above topics.

Many thanks!

Best Regards,
Misi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100113/3ce4ac5c/attachment-0002.html>