[SIPForum-discussion] UAs

Manpreet Singh msingh at ibasis.net
Fri Mar 3 16:14:16 UTC 2006


Sean
 
Based on the ENUM RFC 3761, if the "u" flag is present, the rule is the last
one and no more NAPTR queries can be performed. If there is no flag present,
thats when one can still issue a new NAPTR query, which would be more like
redirection of the first NAPTR query. So we cant do (1) as the "u" flag is
coming up. I have seen UAs doing SRV right after a NAPTR response and some
even doing simple A record lookup. The latter would not make sense all the
timer as the domain might be the true endpoint or proxy. So if we cant do
any more NAPTR queries, then what would be the right way to go about the URI
coming in the response. 
 
As far as why NAPTR is needed, how would one even get a URI for a E164
number is something NAPTR is used for. So first query gives the different
protocols the E164 can be reached at. So skipping first NAPTR would not
result in anything. Any suggestions?
 
Thanks
Manpreet

  _____  

From: Maddox, Sean (MVNSO Solutions Mgr) [mailto:sean.maddox at hp.com] 
Sent: Friday, March 03, 2006 1:03 AM
To: Manpreet Singh; Henning Schulzrinne; Klaus Darilion
Cc: discussion at sipforum.org
Subject: RE: [SIPForum-discussion] UAs


Manpreet,
 
The only thing I have found comes from section 6.2 of RFC 3824 (an
informational rfc) which you've probably read as well.  The way I read this
is that once you've  determined the AOR from the NAPTR regexp (from the
.e164.arpa request) you should be following the guidelines from RFC 3263 to
determine what to do next.  Given this RFC and your example:
 
    1.    Issue a NAPTR request against tele2.se.  Since the URI is
sip:information at tele2.se you'd be looking for the SIP+D2U service flag entry
which would have a replacement value of _sip._udp.tele2.se
        -    I don't know if the NAPTR request can be skipped and the
replacement value just assumed by the client, if this were the case why
require NAPTR in the first place?  Might it be "legal" for the NAPTR request
to return _sip._udp.tele3.se or some replacement pointing to some other
domain?
    2.    Issue a SRV request using the replacement value from #1
(_sip._udp.tele2.se), assume it returns just one value with a target of
sip-service.tele2.se
    3.    Issue an A type request using sip-service.tele2.se
 
If you just issue an A request against tele2.se I wouldn't think you'd get
very far.
 
Hope this helps.  If I've interpreted this incorrectly somebody please let
us know.
 
thx - sean


  _____  

From: Manpreet Singh [mailto:msingh at ibasis.net] 
Sent: Thursday, March 02, 2006 10:43 AM
To: Maddox, Sean (MVNSO Solutions Mgr); Henning Schulzrinne; Klaus Darilion
Cc: discussion at sipforum.org
Subject: RE: [SIPForum-discussion] UAs
Importance: High


Hi
 
Anything on this? Any input is appreciated. Different UAs have implemented
this differently ( some do SRV and some do A record for the domain) so not
sure what should be the right bahviour. I feel SRV shoul be done but then
its just my opinion.
 
 
Thanks
Manpreet

  _____  

From: Manpreet Singh 
Sent: Tuesday, February 28, 2006 6:52 AM
To: 'Maddox, Sean (MVNSO Solutions Mgr)'; Henning Schulzrinne; Klaus
Darilion
Cc: discussion at sipforum.org
Subject: RE: [SIPForum-discussion] UAs


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!"  .

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 list of servers and then send the
INVITE to those servers. My assumption is that the client would  do SRV
first because doing a A record lookup would not result in the actual
termination proxy or endpoint.
 
Correct me if I am wrong.
 
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 < <mailto:sean.maddox at hp.com> 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
<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
<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://
<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 <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:// <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
<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
<http://sipforum.org/mailman/listinfo/discussion>  

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20060303/8c101366/attachment-0001.html>


More information about the discussion mailing list