[SIPForum-discussion] SIP NAPTR
MÉSZÁROS Mihály
misi at niif.hu
Fri Jan 15 06:05:40 UTC 2010
Hi Basling et al.,
Thank you for your answer!
I find the RFC snip too.
RFC3403
4.1 section
REPLACEMENT
This 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. If a record is
returned that has values for both fields then it is considered to
be in error and _SHOULD _be either ignored or an error returned.
Best regards,
Misi
>
>
> On Wed, Jan 13, 2010 at 1:05 PM, MÉSZÁROS Mihály <misi at niif.hu
> <mailto:misi at niif.hu>> wrote:
>
> 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
>> <mailto: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 <mailto:info at example.com%21i>"
>> _sip._tcp.example.com <http://tcp.example.com/>.
>>
> The last NAPTR is valid? I am confused.
>
> Please ignore the last NAPTR record .I is for email service.
>
>
> 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?
>
>
> U can not set both of them.If one is present other should not be there.
>
>
> "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?
>
> Sorry me to not clear about the main difference between order and
> preference.
>
>
> 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 <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/>.
>
> Only can fallback if the zone file seems like this?
>
> example.com <http://example.com/> NAPTR 10 10 "S" "SIP+D2U" ""
> _sip._udp.example.com <http://udp.example.com/>.
> example.com <http://example.com/> NAPTR 10 20 "S" "SIP+D2T" ""
> _sip._tcp.example.com <http://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 <http://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 <http://example.com/> with
> the above zone, if i am not wrong i will get in the end:
> _sip._tcp.example.com <http://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?
> SHOULD
>
>
>
> 1. Can please you point me on RFC where it is stated?
> Internal to office.Can not be exposed outside.
>
>
>
> 1. What happens if both are set, what has precedence?
> (replacement?)
> You should not set both.If they are set then your
> NAPTR response will be wrong and U can not make calls.
>
>
>
> 1. 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
>
>
>
>
> --
> 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/20100115/9a743f3e/attachment-0002.html>
More information about the discussion
mailing list