[SIPForum-discussion] UAs

Sun Mar 5 17:30:02 UTC 2006

Manpreet,

I believe you are correct in moving to an SRV request and not a
subsequent NAPTR request but I believe the "u" flag is terminal only to
the E164 to URI resolution process (E2U+anything including sip) and
doesn't prevent you, if necessary, from issuing future NAPTR requests if
the resolution process of the protocol specified in the URI requires it.
Once you have the URI you need to follow the resolution process(es) for
the protocol specified in the URI.  In the case of a sip URI the SIP
resolution process is covered by RFC 3263 and specifically for clients
in section 4 of that RFC.

I am basing this on section 4.1 of 3761 which states that 'In all cases,
the next step in the resolution process is to use the resolution
mechanism for each of the protocols, (specified by the URI schemes sip,
h323 and mailto) to know what node to contact for each'.  Given this,
and the selection of an E2U+sip record with a sip URI you then move on
to the SIP resolution process.

The first step in the SIP resolution process is selecting a transport
protocol (section 4.1 of RFC 3263) which says if the URI contains a
transport protocol it SHOULD be the transport protocol used.  If the URI
doesn't contain a transport protocol and the TARGET in the URI is not a
numeric IP address then the client should use NAPTR.

thx - sean 

________________________________

From: Manpreet Singh [mailto:msingh at ibasis.net] 
Sent: Saturday, March 04, 2006 12:16 PM
To: Richard Shockey
Cc: Maddox, Sean (MVNSO Solutions Mgr); Henning Schulzrinne; Klaus
Darilion; discussion at sipforum.org
Subject: RE: [SIPForum-discussion] UAs

Richard 

Thanks for the response. Yes I know about the reversed field, I think I
copied the example from 2916 instead. So I guess SRV is the right way to
go about it.

Just on the side note, is there any document available explaining the
reason as to why the fields were reveresed? I have tested severel Uas,
including cisco UA ( GWs and IPIP GWs) and they fail the call with new
implementation, which is E2U+SIP. If you can share any document
explaining why this change was done, I would really appreciate it

Thanks 
Manpreet 

-----Original Message----- 
From: Richard Shockey [mailto:Rich.Shockey at neustar.biz] 
Sent: Saturday, March 04, 2006 1:09 PM 
To: Manpreet Singh 
Cc: Maddox, Sean (MVNSO Solutions Mgr); Henning Schulzrinne; Klaus
Darilion; discussion at sipforum.org 
Subject: Re: [SIPForum-discussion] UAs 

Manpreet Singh wrote: 
> Sean 
>  
> True but these dont happen when using NAPTR for ENUM services. In the 
> example you gave, the "s" flag tells the client that the next lookup 
> is a SRV lookup. For ENUM response, most of the time in the 
> replacement string would carry a sip URI and the flag is "u". ( 
> terminal 
> ) Check the  example below: 
>  
> $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. 
> IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information at tele2.se!"     .

> IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information at tele2.se!"
. 

IN 3761 BTW the E2U and enumservice field is reversed 

as in E2U+sip 

> Now in the above example, would the UA be expected to do a SIP INVITE 
> to a A record of tele2.se or would be it do a SRV lookup for 
> _sip._udp.tele2.se. ( assuming it can only do UDP), receive a lost of 
> servers and then send the INVITE to those servers. My assumption is 
> that the client would so SRV first because doing a A record lookup 
> would not result in the actual termination proxy or endpoint. 
>  
> Correct me if I am wrong. 

That is correct. 
>  
> Thanks 
> Manpreet 
>  
> 
> ----------------------------------------------------------------------

> -- 
> *From:* Maddox, Sean (MVNSO Solutions Mgr) [mailto:sean.maddox at hp.com]

> *Sent:* Tuesday, February 28, 2006 1:33 AM 
> *To:* Manpreet Singh; Henning Schulzrinne; Klaus Darilion 
> *Cc:* discussion at sipforum.org 
> *Subject:* RE: [SIPForum-discussion] UAs 
> 
> Manpreet, 
> 
> My understanding is that the NAPTR response isn't a SIP URI but 
> instead should contain at least 3 records each of which identifies a 
> service (which itself defines both service & protocol) and an 
> associated target for that service.  Service in the context of SIP 
> NAPTR records means either SIP (non-secure) or SIPS (secure) while 
> protocol in this context means TCP, UDP or SCTP.  The combination of 
> protocol and service being represented by the DNS response as SIP+D2U 
> (SIP over UDP), SIP+D2T (SIP over TCP), SIPS+D2T (secure SIP over TLS 
> over TCP) and SIP+D2S (SIP over SCTP).  The SIP client processes these

> NAPTR records with an order of preference for selection of SIPS+D2T 
> (secure & reliable transport), 
> SIP+D2T (un-secure & reliable) and finally SIP+D2U (un-secure & 
> un-reliable).  The replacement value associated with each NAPTR record

> identifies the value to issue the SRV DNS request against. 
> 
>  From RFC 3263, the NAPTR response might contain the following values:

> 
>    ;          order pref flags service      regexp  replacement 
>       IN NAPTR 50   50  "s"  "SIPS+D2T"     ""
_sips._tcp.example.com. 
>       IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com 
>       IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.

> 
> The client is supposed to first choose a service and then issues a DNS

> SRV request using the replacement value (for example 
> _sips._tcp.example.com) which in turn would yield a target of 
> something to the effect of sips-service.example.com and a port.  If a 
> numeric IP address is returned instead then the client uses the 
> address, if no port is returned then the default is assumed.  If a 
> non-numeric value is returned the client should issue a DNS A or AAAA 
> request against the target value to resolve it. 
> 
> That is at least the way I read, and re-read, things. 
> 
> Thx - Sean 
> 
> *Sean P. Maddox* <_sean.maddox at hp.com_ <mailto:sean.maddox at hp.com>> IP

> Communications Solutions Manager - HP Americas Mobility, Voice & 
> Network Solutions The Hewlett-Packard Company 
> +1 817.898.0218 
> sip:sean.maddox at hp.com 
> 
> As always, please let me know if you prefer not to receive these 
> emails from me. For more information regarding Hewlett-Packard's 
> policy or to obtain contact information, please see our privacy
statement at: 
> http://thenew.hp.com/country/us/eng/privacy_intent.html 
> 
> ----------------------------------------------------------------------

> -- 
> *From:* discussion-bounces at sipforum.org 
> [mailto:discussion-bounces at sipforum.org] *On Behalf Of *Manpreet Singh

> *Sent:* Monday, February 27, 2006 10:39 PM 
> *To:* Henning Schulzrinne; Klaus Darilion 
> *Cc:* discussion at sipforum.org 
> *Subject:* RE: [SIPForum-discussion] UAs 
> *Importance:* High 
> 
> Hi 
> 
> I have a question regarding the NAPTR implementation. For a NAPTR 
> response which is a SIP URI, is the UA meant to do a simple A record 
> lookup and initiate a request or should be really doing a SRV lookup 
> and then follow the A record lookup. I have seen different UAs 
> behaving differently ( some do SRV first and some do A record lookup )

> so was curious as to what would be right behaviour/implementation. 
> 
> If not in spec then is it purely on the discretion of a UA 
> implementation? I would usually expect a host portion to be a domain 
> in the response ( eg bob at abc.com ) which would host proxies, hence SRV

> would make sense. Opinions/suggestions?? 
> 
> Thanks 
> Manpreet 
> 
> -----Original Message----- 
> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu] 
> Sent: Monday, February 27, 2006 9:37 PM 
> To: Klaus Darilion 
> Cc: discussion at sipforum.org 
> Subject: [SIPForum-discussion] UAs 
> 
> The list is quite helpful. I'm trying to flesh out the list at http://

> www.cs.columbia.edu/sip/ua.html with additional data on modern (3261),

> actively-maintained client, i.e., you would want to recommend to a 
> friend new to SIP. It would be helpful if those who have used (or 
> written) clients can provide information about their UA, such as 
> 
> - SIP features: TCP, TLS, NAPTR 
> - audio codecs, including RFC 2833 support 
> - video codecs 
> - presence - basic? rich? XCAP? 
> - license 
> - any additional remarks such as restrictions or particular features 
> 
> I'm focusing on UAs that can be configured for any proxy, not just 
> those that are part of a service. 
> 
> Thanks. 
> 
> On Feb 27, 2006, at 6:04 AM, Klaus Darilion wrote: 
> 
>  > Bill Nash wrote: 
>  >> <mailto:discussion at sipforum.org> Hi! 
>  >> I am beginner for softphone applications. I want to implement a  
> >> simple softphone between two PC (end-to-end) with SIP using C++  >>

> language on Linux. I need some advice about tutorial, API and  >> 
> whatever you want to say about  it. 
>  > 
>  > 
>  > Hi Bill! 
>  > 
>  > First, I would not write a new SIP phone, but extend existing SIP  
> > phones. You can find a list of free sip phones at: http://  > 
> www.pernau.at/kd/voip/bookmarks-sip-phones.html 
>  > 
>  > If you really want to write a new SIP phone, check out the existing

> > SIP stacks: 
>  > http://www.pernau.at/kd/voip/bookmarks-sip-stacks.html 
>  > 
>  > regards 
>  > klaus 
>  > _______________________________________________ 
>  > discussion mailing list 
>  > discussion at sipforum.org 
>  > http://sipforum.org/mailman/listinfo/discussion 
> 
> _______________________________________________ 
> discussion mailing list 
> discussion at sipforum.org 
> http://sipforum.org/mailman/listinfo/discussion 
> 
> 
> ----------------------------------------------------------------------

> -- 
> 
> _______________________________________________ 
> discussion mailing list 
> discussion at sipforum.org 
> http://sipforum.org/mailman/listinfo/discussion 

-- 

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 
46000 Center Oak Plaza  -   Sterling, VA  20166 
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com 
ENUM +87810-13313-31331 
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 
Fax: +1 815.333.1237 
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz> 
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20060305/641f6a2a/attachment-0001.html>