Subject: [SIP] Re: Picky SIP bis draft comment

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2000 09:38:05 -0400

Billy Biggs wrote:
> 
>   Hi,
> 
>   I noticed you added SCTP and TLS to the transport URL parameter.  On
> page 19, when describing URL parameters, you don't mention them at all.
> 
>   This should be updated to say something like:
> 
>   "The transport parameter determines the transport mechanism to be used
>    for communications.  SIP is currently defined to operate over TCP,
>    UDP, SCTP, and TLS, although others are possible."

Thanks for catching this; fixed (with slightly different wording).

> 
>   One problem with this is that transport unfortunately isn't a list.
> So, I guess if you support all of them, you have to publish each
> transport you support as a seperate URL.  Correct?

Interesting point. A list would be more convenient, particularly when
the URL is included on a web page. For Contact, enumeration will
probably do, except that this won't work when Record-Route is used - the
rules only allow to copy one Contact entry and the UAC has no clue which
of the transport parameters might be appropriate for the last proxy
before the Contact header address. Unfortunately, a list is not
backward-compatible. I suppose we could define a new parameters, say,
transports, which allows a list and deprecate the old version.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2000 09:39:50 -0400

As a follow-up comment, this whole issue could be avoided if we could
rely on DNS SRV. It seems far better to store transport availability in
DNS rather than trying to update URLs on web pages...
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Billy Biggs <[email-masked]>
Date: Mon, 12 Jun 2000 11:04:59 -0400

> DNS rather than trying to update URLs on web pages...

  I'm not sure I follow.  You're suggesting that if we could rely on DNS
SRV records, then we could announce URLs without specifying transport,
and have the remote end use DNS to query what transports we support?

  That doesn't work very well with clients on machines that don't have
access to their DNS entries, or to cases where many SIP clients (with
seperate transport capabilities) are running on one machine...

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2000 11:24:12 -0400

> DNS rather than trying to update URLs on web pages...

I agree. I think we should keep transport as listing a single transport,
which represents the "preferred" mechanism, but still allow for others
discovered as a result of DNS and/or simply trying other transports to
see what happens.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2000 12:23:35 -0400

> and have the remote end use DNS to query what transports we support?

That would be one model that works some of the time.

> seperate transport capabilities) are running on one machine...

Yes, but the alternative of changing dozens of web pages and an untold
number of address book entries is probably higher. In the end, I'd
imagine we end up with a hybrid system, where SRV is used for servers
(where you typically wouldn't have a bunch running on the same system,
at least not under the same externally visible name) and URL parameters
for specifying the "favorite" transport and, like Jonathan said,
try-others-if-necessary approach.

To conclude this item: Unless somebody speaks up, the single-transport
mechanism stays as is, rather than complicating things.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs