Subject: [SIP] SIP, SDP, and TCP-based media transport

From: David Yon <[email-masked]>
Date: Wed, 26 Jul 2000 10:31:51 -0400

Attached is an informal discussion of various approaches to solving the 
SDP/TCP problem.  Any comments are welcome.  If there is general agreement 
I'd be happy to collaborate on or submit a formal I-D.

With FOGLAMPS under way, and T.38 Annex D already finalized, this problem 
needs to be solved as soon as possible.  While this may be more of an SDP 
issue than a SIP issue, this problem is directly relevant to SIP which is 
why I've posted this here.  If anyone has suggestions for additional and/or 
more appropriate forums please let me know.

----

		SIP, SDP, and TCP-based media transport
		=======================================
	
The Session Description Protocol currently only describes a small set of 
protocols that are used for media transport, the most common being RTP and 
UDP.  A significant omission in SDP is a way to specify TCP as the 
transport protocol.  Since SIP uses SDP to describe the media used in the 
session being initiated, there is currently no way to use SIP to set up 
sessions that use TCP connections for media transport.

Annex D of the T.38 spec recommends that a protocol identifier of "TCP" be 
added to SDP.  While this allows SDP to describe that the media transport 
will use TCP as the network protocol, it only tells half the story.  The 
major difference between RTP/UDP and TCP is that connection setup is 
asymmetric---one side must be the initiator and the other must be the 
listener.  Only specifying that the network protocol is TCP omits this 
important piece of information.

The remainder of this document discusses ways that the direction of the TCP 
connection setup could be conveyed in SDP.

Specification By Inference
--------------------------

One approach is to leave the decision to the endpoints, and just assume 
that if they can agree on a media transport that they'll implicitly know 
how to correctly set up the connection.  For example, a transport type of 
"t38" over TCP might imply that the caller always initiates the connection 
and the callee accepts the connection.

The problem is that it doesn't scale.  It requires that SIP ALP's stay 
current on an ever-growing list of transport types and hard-code their 
connection heuristics.

Mapping to SIP Call Flow
------------------------

Another approach is to standardize on mapping the SIP call direction to the 
connection of the TCP setup.  I.e., specify in the SIP RFC that the UA that 
does the INVITE is the one that accepts the TCP connection from the UA that 
does the OK.

The problem with this is that it imposes an arbitrary restriction upon a 
wide range of applications and topologies.  The transport may involve a 
legacy protocol that cares about the direction of the TCP setup, and it may 
not always map to the direction of the call flow.

The other problem is that it resolves the issue only for SIP, leaving the 
problem to be solved again and again for other protocols that also use SDP.

First-Specified/First-Served
----------------------------

One could specify that the first UA to offer up an SDP message is 
implicitly offering to accept the TCP connection.  This maps somewhat to 
how SDP works on UDP-based transports, where by specifying a port number 
the UA is announcing that the port is now available to accept a media stream.

This technique would certainly work when the topology allows the UA sending 
the INVITE to accept the TCP connection.  But if the topology requires that 
it be the UA sending the OK, then you run into the problem of 
underspecifying the session type.  Most sessions signalled in SIP are 
described by the SDP being sent in the INVITE.  I.e., is this an audio 
call?  an audio/video call?  a T.38 fax call?  This question can be 
answered by inspecting the SDP in the INVITE.  Not sending this information 
may deprive downstream SIP proxies of critical information required to 
select the correct media gateway.

Port Zero
---------

Another twist that would leave SDP syntax unchanged would be to establish 
the convention that an SDP message specifying zero for the port and TCP for 
a transport is the UA that will initiate the TCP connection.  It would be 
up to the other UA to supply a valid port that will accept this connection.

One problem is that this limits the flexibility of the network 
topology.  Many TCP protocols have a well-known port at which they will 
accept connections, and it may be desirable to always use that port number 
for the accept (not the least of which is ease of dumb-firewall 
administration).  If this is the case, specifying port zero for the 
initiator means that the acceptor may not have sufficient information to 
correlate an incoming connection with a SIP session.

TCP/S and TCP/C
---------------

The most explicit way to fully describe TCP-based transport is to add two 
new SDP protocol descriptors: TCP/S and TCP/C (any better suggestions for 
nomenclature?).  The UA that will accept the connection specifies TCP/S 
along with the port number it will be accepting on.  The UA that will 
initiate the connection specifies TCP/C along with the port number to which 
it has bound the outgoing socket.

This approach has numerous advantages.  The SDP messages convey *exactly* 
what will be occurring for media transport, and SIP ALP's will be able to 
Do The Right Thing(tm) for TCP-based transports with a minimum of extra 
complexity.  TCP-based servers can continue to use fixed port numbers for 
incoming connections if that is desirable.  At the same time, connections 
can be mapped to sessions without using additional signaling in the media 
transport itself.  Even dumb firewalls can easily be configured to pass 
this type of traffic (although NAT's remain a problem).

SSL/S and SSL/C?
----------------

Any reason to add these to the list?  One could argue that this belongs in 
the description of the upper-layer protocol.  On the other hand, it's 
common enough that it may warrant being added to the list of well-known SDP 
transports.  Comments?

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]

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

---

From: David Yon <[email-masked]>
Date: Mon, 31 Jul 2000 10:43:06 -0400

Wow, not a single reply or comment.  Is there no interest/opinion 
at all on this subject?  Have I raised this subject in an inappropriate 
forum?  Does this duplicate work in other places that I've missed?  Should 
I take silence for agreement or is disagreement so strong that folks can 
hardly bring themselves to speak? :-)

         Any comments or suggestions appreciated.

At 10:31 AM 7/26/00 -0400, David Yon wrote:
>why I've posted this here.  If anyone has suggestions for additional 
>and/or more appropriate forums please let me know.
>

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 31 Jul 2000 16:59:48 -0400

David,

Here's a few comments.

You say in your intro that "A significant omission in SDP is a way to
specify TCP as the transport protocol."  Well, there is. There just
isn't a way for proxies to figure out a priori which party will connect
actively and which will accept the connection. This means (as I think
you also mention) that SIP with SDP *can* be used to set up TCP based
sessions only they have their own private arrangement about who gets to
be active/passive.

I agree with your views that having a separate TCP connection for each
direction is unsatisfying. You list some options for how to include in
the signaling an indication as to who will be active in the connection
setup. The one I like the best is the idea of using a port number of 0
to mean the other guy gets to be passive and choose a port number to
listen to and then tell the initiating party about it. I don't
understand your comments about flexibility on this one.

An alternative would be to use SDP attributes, e.g.

  m=chat 5678 TCP
  a=connection:passive

but it seems kind of pointless to use an attribute when there's a port
number begging to be overloaded ;-)

--
Anders Kristensen

---

From: David Yon <[email-masked]>
Date: Mon, 31 Jul 2000 17:26:28 -0400

Thanks for taking the time to read/comment!  More discussion below...

>sessions only they have their own private arrangement about who gets to

         Well yes, the "TCP" identifier was just recently added, at the 
impetus of T.38 Annex D if I'm not mistaken.  So you can indeed specify a 
TCP transport, but as you say, right now the connection direction is left 
out of the SDP.  It's my position that this doesn't scale, especially for 
SIP ALP's.  Much better that it be explicit.

>understand your comments about flexibility on this one.

         The problem with port zero is that it forces a server to use 
dynamic port assignments.  There are many cases where you want a TCP server 
to be sitting listening on a single port for incoming connections (indeed, 
this is the norm for most TCP-based services).  Assuming this topology, how 
is the server able to correlate an incoming connection to the original SIP 
caller?  In normal SIP/SDP, both sides specify an Address/Port pair, 
forming a unique four-tuple which identifies the session.  If you force the 
client-side port to be zero, you lose a critical piece of information 
necessary for the client to determine which party just connected.

         For example, let's say you have a server at 10.2.3.4 listening on 
port 2392, and it just got two SIP calls back-to-back which specify that 
two different parties want to set up a session with that server.  The twist 
is that the two different parties are at the same IP address of 63.5.4.3 
(could be a shared server, could be a NAT with a SIP ALP).  So now you have 
two four-tuples outstanding:

Caller A:       { 63.5.4.3, 0 }, { 10.2.3.4, 2392 }
Caller B:       { 63.5.4.3, 0 }, { 10.2.3.4, 2392 }

         When the server at 10.2.3.4 gets a connection on port 2392 from 
63.5.4.3, is it Caller A or Caller B?  We don't know, and that's the 
problem I'm talking about.

>number begging to be overloaded ;-)

         My problem here is that it forces ALP's down into the attribute 
line to be able to determine the connection direction.  Having TCP/S and 
TCP/C (or equivalent) means that the "m=" line is all the ALP needs to inspect.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
[email-masked]

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 31 Jul 2000 18:26:36 -0400

David Yon wrote:
> impetus of T.38 Annex D if I'm not mistaken.

Does that mean I've been using "TCP" as the transport illegally for
nearly two years now? Good grief.

  So you can indeed specify a
> necessary for the client to determine which party just connected.

OK, so if I understand you right you want to allow a UAC to be the
active part in setting up the TCP connection while at the same time
specifying which local TCP port it will be using in an initial INVITE,
but without actually connecting before receiving the 2xx specifying the
host/port to connect to, right?  I believe not all programming
environments (think Java) will actually allow allocating a local port
without connecting, although it sounds like a reasonable thing to do.

On the whole it doesn't sound like this is much of a problem in
practice, but if it is my preference would be for using an SDP m= level
attribute over TCP/C TCP/S transport specifiers. Looks better, IMHO.

--
Anders Kristensen