[SIPForum-discussion] SIP NAPTR
baslingappa bhujang
basling99 at gmail.com
Wed Jan 13 06:11:49 UTC 2010
Hi,
Read the below content and you will find answer to your self
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*(The -t option is used to select the query
type.)
example.com NAPTR 10 100 "S" "SIP+D2U" "" _sip._udp.example.com.
example.com NAPTR 20 100 "S" "SIP+D2T" "" _sip._tcp.example.com.
example.com NAPTR 30 100 "S" "E2U+email"
"!^.*$!mailto:info at example.com!i<info at example.com%21i>"
_sip._tcp.example.com.
>From the above look up we can come to know that we can contact
example.comdomain in three ways
First using SIP over UDP protocol _sip._udp.example.com.
Second using SIP over TCP protocol _sip._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 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
"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")
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". 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.
So because we have the *"S" designation in the "flag" field, our next step
is to find the SRV record for the replacement*
#* host -t SRV _sip._udp.example.com*
_sip._udp.example.com SRV 5 100 5060 sip-udp01.example.com.
_sip._udp.example.com SRV 10 100 5060 sip-udp02.example.com.
We get two answers here so first we'll try 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*
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.
Thanks,
Basling.
2010/1/12 MÉSZÁROS Mihály <misi at niif.hu>
> Dear all!
>
> I have a question about SIP DNS based service location, and discovery
>
> start of example DNS zone file
>
> ============================================================================
> $TTL 60
> $ORIGIN atlanta.test.
> @ IN SOA a1.atlanta.test. root.a1.atlanta.test. (
> 2010011201 ; Serial
> 604800 ; Refresh
> 86400 ; Retry
> 2419200 ; Expire
> 604800 ) ; Negative Cache TTL
> ;
> @ IN NS a1
> @ IN NS a2
> a1 IN A
> a1 IN AAAA
> a2 IN A
> a2 IN AAAA
>
> ;; Priority Weight Port Target
> _sips._tcp IN SRV 10 0 5061 a1
> _sips._tcp IN SRV 20 0 5061 a2
> _sip._tcp IN SRV 10 0 5060 a1
> _sip._tcp IN SRV 20 0 5060 a2
> _sip._udp IN SRV 10 0 5060 a1
> _sip._udp IN SRV 20 0 5060 a2
>
>
> ;============================================================================
>
> The zone file above can continue in my example with two versions of NAPTR
> records.
>
> ;; order pref flags service
> regexp replacement
> @ IN NAPTR 10 50 "s" "SIPS+D2T"
> "" _sips._tcp
> @ IN NAPTR 20 50 "s" "SIP+D2T"
> "" _sip._tcp
> @ IN NAPTR 30 50 "s" "SIP+D2U"
> "" _sip._udp
>
> OR
>
> ;; order pref flags service
> regexp replacement
> @ IN NAPTR 10 50 "s" "SIPS+D2T"
> "!^(.*)$!_sips._tcp.\\1!" .
> @ IN NAPTR 20 50 "s" "SIP+D2T" "
> !^(.*)$!_sip._tcp.\\1!" .
> @ IN NAPTR 30 50 "s" "SIP+D2U" "
> !^(.*)$!_sip._udp.\\1!" .
>
> My questions are:
>
> - The second three NAPTR RR-s are valid?
> - Are the second RR-s equialent with the first three RR-s? If not, why?
>
> Can the regexp be not empty?
> rfc3263 section 4.1 says something but not clear for me that it speaking
> about the rfc3263 example or it is a general rule.
>
> These NAPTR records provide a mapping from a domain to the SRV record
> for contacting a server with the specific transport protocol in the
> NAPTR services field. *The resource record will contain an empty
> regular expression* and a replacement value, which is the SRV record
> for that particular transport protocol.
>
> I couldn't find a MUST or SHOLD about this behavior.
>
> Can any of you clarify this?
>
> If i am so lucky and my email find an expert, i hope i can ask he/she to
> clarify SIP+ NAPTR.
> For example can the SIP+D2X can be so complex like this? Is it valid? Or if
> not then where is problem with it?
>
> ;; order pref flags service regexp replacement
> @ 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!" .
>
>
> Many thanks!
> Any help or suggestion highly appreciated!
>
> Regards,
> Misi
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
--
Thanks and Regards,
-------------------------------------------
Baslingappa.B
Software Engineer
Bangalore-India
+91-9972832539
-------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100113/55c2501b/attachment-0002.html>
More information about the discussion
mailing list