Subject: RE: FW: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying next transport upon failure

From: "Paul D.Smith" <[email-masked]>
Date: Wed, 6 Oct 2004 09:20:08 +0100

Jonathan,

Thanks for the clarification regarding the use of NAPTR records.

Just so that we are 100% clear on the other cases, can you first confirm
that
an implementation is allowed to pick any transport it prefers, look for an 
SRV record and if one is found, use that transport?  And as per the NAPTR
example, if that transport fails, then no further transports are tried?

But if no SRV records were found for the chosen transport, another transport
may be chosen until either SRV records are found, or there are no further
transports to try.

And finally the final case of no SRV records.  In this case the transport to
use is UDP for SIP: URIs and TLS (over TCP) for SIPS: URIs.  Agreed?

Thanks,
Paul D Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked] 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 29 September 2004 07:38
To: SIP Public Folder (E-mail)
Subject: Re: FW: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915:
trying next transport upon failure

Thanks for prodding me to answer this.

I agree this is confusing. RFC 3261 seems to refer to the notion that 
you can change transports on different attempts (end of 8.1.2). However, 
RFC 3263 would seem to indicate that the NAPTR result would be a single 
service, and therefore, a single transport.

The correct behavior is the latter. That is, the NAPTR processing will 
select a single transport, and that's what gets used. Previously, we 
were allowing attempts across transports because we were combining 
addresses from different SRV records and merging them. This was deemed a 
no-no by the DNS folks, due to the operational issues with comparing 
preference values across records.

Once we eliminated this merging, the updated procedures in RFC 3263 
effectively resulted in selection of a single transport, but this wasn't 
  made fully consistent with RFC 3261. I've logged a bug against 3261 to 
clarify (http://bugs.sipit.net/sipwg/show_bug.cgi?id=760).

Thanks,
Jonathan R.

Paul D.Smith wrote:

> Jonathan,
> 
> Can I please ask you to comment on the discussion Brett and I have been
> having
> via the WG regarding the use of NAPTR records?
> 
> The question is whether the use of multiple transports, indicated by
> multiple
> NAPTR records, SRV records or client support for multiple transports
should
> be attempted or not.
> 
> I can see an advantage to defining, say "TLS preferred over TCP over UDP"
> but
> this would only be useful under the "just try one transport" idea if the
> client only supported one of the less preferred options.
> 
> However the "try all in order" idea allows for, for example, a separate
TLS
> connection server to be preferred but for TCP to be acceptable (possibly
> with
> some restrictions imposed through other means) if the TLS server is
> unavailable.
> 
> So what is the intended processing?  Also in either case, would you like
to 
> raise a bugzilla report to ensure this is clarified in a future release of
> the
> specification?
> 
> Thanks,
> Paul D Smith
> Network Protocols Group 
> Data Connection Ltd (DCL)
> Tel: +44 20 8366 1177  Email: [email-masked] 
> Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com
> 
> 
> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: 17 September 2004 18:31
> To: SIP Public Folder (E-mail)
> Subject: RE: [Sip-implementors] RE: [Sip] rfc3263 and rfc2915: trying
> next transport upon failure
> 
> 
> Hi Jonathan,
> 
> Do you agree with Paul's interpretation 
> concerning advancement to the next transport
> (next NAPTR record or set of SRV records)?
> 
> My interpretation was that advancing
> between transports has been removed.
> 
> There are likely good reasons for and
> against advancing between transports.
> I am just trying to understand what
> rfc3263, rfc2915, and rfc3261 indicate
> or should have indicated.
> 
> Thanks in advance,
> Brett Tate
> 
> 
> 
>>RFC3263, section 4.1, contains the following text
>>
>> If no NAPTR records are found, the client 
>> constructs SRV queries for those transport 
>> protocols it supports, and does a query for 
>> each.  Queries are done using the service 
>> identifier "_sip" for SIP URIs and "_sips" 
>> for SIPS URIs.  A particular transport is 
>> supported if the query is successful.  The 
>> client MAY use any transport protocol it 
>> desires which is supported by the server.
>>
>>This means that potentially the set of 
>>SRV records covers multiple protocols in 
>>the case that no NAPTR records are returned.
> 
> 
> I interpret the text as indicating that one
> transport should be selected instead of
> potentially combining the multiple sets of
> srv records.
> 
> 
>>It therefore seems only sensible to me 
>>that if multiple transports are indicated 
>>by NAPTR records, that they too should be 
>>tried, in the order indicated by the NAPTR 
>>records.
> 
> 
> Hopefully there would have been a statement 
> indicating when to advance to the next NAPTR
> record.  Or there could have been a statement
> indicating the combining of all the SRV records
> for each NAPTR record.
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip