Subject: [SIP] Transports again

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Mon, 12 Jun 2000 22:02:14 +0100

Hi Folks,
  If one can specify a transport other than UDP using a transport-parameter,
then why does one HAVE TO support UDP in the first place?

It looks like the bis draft now means that one MUST support it, even if
only for an initial negotiation.

Within enterprise environments, I can imagine providing a system which
only supports TCP. No retransmit support, and using SSL/TLS for security
for ALL session setups.

I've been trying to see under what circumstances this is a problem.
Of course, if I plug in a UA that only supports UDP, then certainly
there's no success. However...this is not going to work anyway where
we want to use SSL/TLS (in current implementations, at least).

The new requirement for UDP support "come hell or high water" seems to make
the current discussion on transport-parameter negotiation moot. You have
to support UDP, so the initial negotiation will be done using UDP, so it's
expensive to change to TCP - setting up all calls this way ends up with
message exchanges worthy of H.323.

UDP is a fine transport, and SIP's efficient support for reliable exchanges
using UDP is one of its beauties, but making it MANDATORY for every
implementation is not a good move, IMHO.
-- 
[email-masked] -- +44 1794 833666
-------------------------------------------------------------
Herewith a pointless waste of a few lines, stating that
Roke Manor Research Limited is NOT responsible for my rantings
and that they would very much like people to sue me rather than
them if this email contains racist or sexist comments, please.
Also, I can't do anything; only our lawyers can, so speak to them.
Oh, and by the way, if our I.T. department has so mangled our
email system that this has been misdirected, beware that having
read this far, your eyes are about to fall out from reading
this highly sensitive information, unless you immediately
forget that this ever darkened your mailbox. Do it now.
-------------------------------------------------------------

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 12 Jun 2000 16:21:21 -0500

"Conroy, Lawrence (SMTP)" wrote:
> 
> Hi Folks,
>   If one can specify a transport other than UDP using a 
> transport-parameter, then why does one HAVE TO support UDP in the 
> first place?

So that two UACs can talk to each other without involoving a UDP->TCP
proxy.  In other words, if UDP is the de-facto standard that all SIP
entities MUST support, then any entity can talk with any other one.  If 
on the other hand, a UAC supports only UDP, then it can only talk to 
other UACs who support UDP.  It cannot talk to a UAC that only supports 
TCP without necessarily involving a proxy that does UDP->TCP con- 
version.
[...]
> UDP is a fine transport, and SIP's efficient support for reliable 
> exchanges using UDP is one of its beauties, but making it MANDATORY 
> for every implementation is not a good move, IMHO.

I belive most SIP implementations support UDP anyway.  I also believe
that under the new bis draft, UACs MUST support UDP and MAY support
TCP; proxies on the other hand MUST support both UDP and TCP.  

I am not sure how the new requirements of support SCTP, etc. will affect
the proxy.

Regards,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
IN Architecture and Internet Software Group
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 12 Jun 2000 22:56:08 +0100

>I am not sure how the new requirements of support SCTP, etc. will affect
To which I reply
I agree that most SIP implementations support UDP.
I understand from your comment that, if one has a TCP-only UA, it's
non-standard. This is stronger than the original SHOULD for UDP support.
If one wants to use a UDP-only UA in an enterprise with a set of TCP-only
UAs then one has to go through a proxy - this was always the case and I'd
expect to have such a beast even where the vast majority of UAs use TCP.

The difference now is that the TCP-only UAs are non-standard.
                                                 ^^^^^^^^^^^^
-- 
All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd pay me for them"    |
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---

From: Igor Slepchin <[email-masked]>
Date: Mon, 12 Jun 2000 17:54:41 -0400

"Conroy, Lawrence (SMTP)" wrote:
> You have

This isn't the case: there is no requirement for the protocol of initial
transaction in SIP. If you know that the callee supports TCP, SCTP,
pigeon carriers etc. (by examining callee's SRV record or by any other
means), you are free to use that protocol for initial transaction. The
requirement to implement UDP ensures that there is always a common
protocol for communication.

If a particular implementation/network configuration/PINT wants to use
TCP only due to any reason (security considerations, inline contents
etc), it is free to publish TCP as the preferred (or the only) protocol
in its SRV records or SIP URLs. If it still receives a UDP request, it
can either reject it or redirect with transport=tcp in the Contact.

---
Igor Slepchin

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2000 18:06:11 -0400

> The difference now is that the TCP-only UAs are non-standard.

Yes, that's intentional. The last thing I want to happen is that you and
I both buy a SIP gadget, with a nice "Powered by SIP" logo pasted on the
box, we plug them in and we can't communicate. Internet protocol
implementations should always have a minimal way to communicate with
each other to be standards-compliant. That is a common theme for all
implementation aspects, from transport to security mechanisms. The
effort in supporting both is minimal. The only time it would conceivably
matter is for embedded systems - they would have a problem supporting
TCP, not UDP. Yes, you may spend a few hours extra building UDP logic
into your software. Standards compliance has its cost.

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

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 12 Jun 2000 23:33:44 +0100

>into your software. Standards compliance has its cost.

Hmm... embedded systems may well have as hard a time supporting the
retransmit-logic and storage implied by SIP-over-UDP - That software
is not *yet* available completely off the shelf, whilst TCP stacks are.
It's not the development time that's a problem here - it's the size and
application processing requirements of the eventual product.

I've realised that it may be my misunderstanding of the word SHOULD.
I had thought that this could be translated as "you had better do this
unless you have a good reason for doing otherwise".

If I buy a "Powered by SIP" (apologies if this is someone's trademark :)
device, then I would expect it to talk over UDP, unless it states that
it only talks over TCP. I just believe that a TCP-only device should be
a valid sub-set - but any such product had better state that it supports
only this sub-set. Isn't that the sense of SHOULD?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 12 Jun 2000 22:51:29 -0400

> application processing requirements of the eventual product.

Speaking from personal experience, with a lab that has developed a stack
for both networking and SIP: TCP would have been far more complex than
the trivial retransmit timer in SIP. For us, that's as much a code space
problem as a development time problem.

> If I buy a "Powered by SIP" (apologies if this is someone's trademark :)

It should be, with a nice logo to go along with it :-)

> only this sub-set. Isn't that the sense of SHOULD?

My perception is that items crucial for basic interoperability are
labeled MUST, while those more on the margins can be SHOULD.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2000 23:45:02 -0400

> labeled MUST, while those more on the margins can be SHOULD.

SHOULD means an implementation can not do it and still be compliant.

As has been pointed out, you can still build your network which always
uses TCP/TLS when talking to each other. No UDP under normal conditions.
But, you just need to be prepared for that UDP call from someone elses
phone.

-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