[SIPForum-discussion] UAs
Maddox, Sean (MVNSO Solutions Mgr)
sean.maddox at hp.com
Fri Mar 3 06:03:23 UTC 2006
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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20060303/87dd0077/attachment-0001.html>
More information about the discussion
mailing list