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

From: "Paul D.Smith" <[email-masked]>
Date: Mon, 27 Sep 2004 13:28:18 +0100

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.

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 Sep 2004 02:37:49 -0400

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.

-- 
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