Subject: [Sip] moving UDP support out of the core SIP document

From: Rohan Mahy <[email-masked]>
Date: Wed, 23 Oct 2002 11:02:12 -0700

Hello Everyone,

I wanted to share some thoughts that I had about removing UDP from the 
core SIP document when we go to draft standard. We are probably at 
least one year away from going to Draft Standard. I hope that during 
this time most implementations will support RFC3261, and therefore 
support TCP.  In addition, it is quite likely that when moving to Draft 
Standard that the IESG will REQUIRE TLS support on SIP User Agents. 
This would ensure a ubiquitous hop-by-hop channel security mechanism, 
but which requires a reliable transport (TCP or SCTP).

Obviously UDP is still very attractive in wireless networks (due to RTT 
issues) and in other typically private networks with well-understood 
delay and loss characteristics. To make most implementations simpler 
however, I am proposing that we make unreliable transports (UDP and 
DCCP) of SIP optional in User Agents, and that we put the UDP-specific 
mechanism (ex: much of the complication of the transaction layer for 
handling retransmissions) in a separate Draft Standard document.  It is 
very likely that if we did this there would also be a baseline security 
mechanism for UDP as well (probably some profile of IPsec).  The net 
effect is that SIP User Agents could also talk to each other using TCP 
or TLS+TCP, and that User Agents with a strong preference for UDP would 
have a consistent security mechanism.  Proxies would still support both 
transports, so you could easily communicate between a TCP-only User 
Agent, and as User Agent which prefers UDP without requiring the User 
Agent to switch over to TCP.

I welcome your discussion and comments on this idea.

thanks,
-rohan

_______________________________________________
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: "Victor Paulsamy" <[email-masked]>
Date: Wed, 23 Oct 2002 11:23:19 -0700

If SIP is "truly" independent of underlying transport protocols, wouldn't it
be appropriate to make all transports "optional"?

Regards,

--victor

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Rohan
> Mahy
> Sent: Wednesday, October 23, 2002 11:02 AM
> To: [email-masked]
> Subject: [Sip] moving UDP support out of the core SIP document
>
>
> Hello Everyone,
>

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 23 Oct 2002 12:02:47 -0700

Hi Victor,

Having no default transport does not encourage interoperability which 
is a major goal of Internet protocols.

thanks,
-rohan

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 24 Oct 2002 10:27:08 -0500

Rohan Mahy wrote:
> core SIP document when we go to draft standard. 
[...]
> handling retransmissions) in a separate Draft Standard document.  

Making UDP optional is fine, but I think it should stay in the core
SIP specification.  Over the years, the SIP state machines for
INVITE and non-INVITE transactions have evolved keeping multiple
transports in mind.  The sourrounding text and the FSM figures
(Figure 5, 6, 7, and 8 in rfc3261) at this point in time are well
specified and, I beleive, well understood by the SIP community in
general.

Divorcing UDP transport from the core spec to another RFC raises other
questions:

   1/ Since proxies are optional in SIP and a UA can initiate
      a session directly with its peer, will a UDP-only UA
      insert a "Require: udp" in the request?

   2/ Issues such as reassembly, UDP response growing
      larger than the request, etc. still remain.

If it is a choice between deprecating UDP entirely or moving it to
another RFC, I would choose the latter.  But so long as we tacitly
support UDP, it would be nice to have it in the base document (maybe
degrade it to a MAY instead of a SHOULD).

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216