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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Aug 2000 00:50:12 -0400

This thread never reached any conclusion; there was a lot of discussion
and it would be nice to come to consensus.

Summary so far:

1. Seems there is consensus that we would like to be able to have a
single TCP connection for bidirectional media. The case of two
unidirectional tcp connections is easy and pretty much supported with
the current SDP model.

2. It was proposed that the INVITE could contain a port number even if
the UAC was going to open the connection to the UAS; this port would
indicate the source port used in the open. This was motivated by the
desire for the UAS to have a single server port, and thus distinguish
incoming tcp connections from different UACs on the same machine by the
source port.

I have a problem with including the source port in the outgoing request.
As Anders pointed out, this requires allocating a source port before a
connection is setup, which is going to be impossible in certain systems.

It would also be useful to allow both sides to try to connect, in the
case where one is behind a firewall, the result is that one of the
connection attempts will work and then that can be used. If both
connect, we could define a precedence rule for dropping one.

So, my proposal would be:

1. m line format stays as is
2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP
3. the port number in the m line refers to the port it is listening on
for connections; this may be meaningless dependending on the next thing
4. we define a new attribute, tcp, with values of:
   active: the port number is meaningless and the UA sending this SDP
wishes to open the connection to the remote side
   passive: please open a connection to this port
   both: we should both try to open connections; the one opened to the
highest remote port takes precedence if both succeed. If the ports are
the same, the highest IP address.
   uni: we should both open tcp connections, and use both, each being
unidirectional (at least for RTP, RTCP would be sent back over the same
TCP connection I suppose)

I don't like using port zero since this overloads the meaning of port
zero defined by SIP (refusal of a stream).

Comments?

-Jonathan R.

David Yon wrote:
> 
> 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

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

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

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 09 Aug 2000 10:57:08 +0200

Works for me, although in 2. I'd prefer using the token TCP rather than
AVP-TCP. This really has nothing to do with any Audio Video Profile.
Unlike for RTP-over-UDP we're not aiming to tell the peer that this
connection is carrying a certain type of traffic. It just means we're
establishing a TCP connection, right?

Cheers,
Anders

---

From: David Yon <[email-masked]>
Date: Wed, 09 Aug 2000 06:27:34 -0400

I have more commentary as well, but this is an easy one: I also object to 
the AVP-TCP token for the same reason.  Adding "AVP" certainly doesn't add 
any useful information (there *is* no Audio-Video Profile for raw TCP of 
which I'm aware), and in fact is misleading since the likelihood that you 
will be using TCP to transport audio or video is quite remote.

More commentary will be forthcoming once the morning brain fog clears a bit...

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

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 09 Aug 2000 14:44:19 +0200

David Yon wrote:
> While I understand the concern, omitting the ability to specify the port
> because of the brain-damage in certain programming languages is a bit
> self-defeating.  I'm not ready to give up on that feature yet, especially
> when bind-before-connect *is* available in most environments.
> 
> Note that I'm not advocating that the UA be *forced* to specify an
> origination port (see my discussion down below).  But the designers of a
> system should be allowed to make this choice for themselves, knowing that
> there are tradeoffs in both directions.

The only problem I see in allowing a UAC to include a port number in the
m= line whilst using a=tcp:active attribute is that since people don't
want to use port 0 it is not clear whether the port number is meant to
be meaningful or not. This can be solved by specifying the special
uac-local-port-is-not-specified port to be 9. It will seem odd to
everyone who doesn't know that 9 happens to be the assigned port for the
Unix 'null' service, though.  I think we can safely assume that to be
most people.

> As I mentioned in another email: AVP is meaningless at best, misleading at
> worst.  If we are going to specify the direction in an attribute, let's
> just use the "TCP" token that was defined for us by the T.38 Annex D work.

Not that we really needed the ITU to grant us the right to use "TCP" as
a transport specifier in SDP.

> re: using an attribute.  Do we really want to require that SIP ALP's forage
> into the attributes in order to do their job?

Of course we do. The parameter mechanism is there to allow us to add
extra info to m= lines or to otherwise qualify them. We could try and
encode all this info info into the trnsport specifier but that's totally
pointless.

--
Anders Kristensen

---

From: David Yon <[email-masked]>
Date: Wed, 09 Aug 2000 07:40:34 -0400

>and it would be nice to come to consensus.

Thanks for picking up this thread again, I was waiting for the dust to 
settle from the IETF meeting before doing another ping to the list.

>unidirectional tcp connections is easy and pretty much supported with

Yes.

Note that you might want something like this for RTP-over-TCP, but that's a 
different subject, and it seems like you would want use a special token for 
that.

>wishes to open the connection to the remote side

What if we were to define a port that is the equivalent of PORT_ANY? (which 
unfortunately is usually zero---and yes---I know there's no PORT_ANY in 
most socket headers :-) )  The UA wishing to be the active side of the 
connect can specify a port if possible, or by specifying PORT_ANY it 
denotes that it does not know from which port it will be originating the 
connect.

The SIP version of PORT_ANY could be 9 (discard, as Robert suggests), or 
maybe 65535.

re: using an attribute.  Do we really want to require that SIP ALP's forage 
into the attributes in order to do their job?  The reason I had originally 
suggested that we have several TCP tokens (in this case we could have 
TCP/BOTH, TCP/ACTIVE, TCP/PASSIVE, and TCP/UNI) was so that a SIP ALP would 
have everything it needed to know on the m= line.  I'm not stuck on either 
approach, but I wanted to make sure we understood the ramifications of each 
side.

>the same, the highest IP address.

"both" opens up a race condition if both succeed.  What if the "winning 
ticket" (highest port/address) gets connected later due to packet 
loss?  I.e., late enough that the other connection has already has some 
data in the pipe?

>TCP connection I suppose)

I don't see when this would ever be used except for RTP-over-TCP, in which 
case you probably want a unique token for that.  But my objection to this 
is not all that strong.

>zero defined by SIP (refusal of a stream).

I agree, and it's unfortunate that it's in conflict with the natural desire 
to use PORT_ANY (0) for the purposes I list earlier.

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

---

From: David Yon <[email-masked]>
Date: Wed, 09 Aug 2000 09:23:18 -0400

>Unix 'null' service, though.  I think we can safely assume that to be

Well yes, we're agreeing.  Although you snipped it out of your reply, I 
suggested the same thing: either port 9 or port 65535 as the equivalent of 
"I don't know what port I'm using".  I agree that port 0 in SIP already has 
other connotations and that it would be bad to overload it.

>a transport specifier in SDP.

Didn't mean to infer anything of the sort.  I was just pointing out that 
TCP was there already, regardless of who put it there.

>encode all this info info into the trnsport specifier but that's totally

Yes, but I have three issues:

         1) A SIP ALP shouldn't need to have an in-depth knowledge of
            the media beyond that which is necessary to route it.  I.e.,
            a SIP ALP shouldn't need to know anything about the G.xxx
            codecs in order to do its job of firewall/NAT management.

         2) It seems like in other usage models, the m= line contains
            network endpoint data, and the a= line contains more detailed
            information about the media that will be flowing.  The
            current proposal blurs this separation.  I'll admit that
            TCP connection setup is a grey area in terms of media
            properties vs network properties, but I'm leaning towards
            the latter.

         3) If I'm remembering correctly, the m= line has a very simple,
            fixed format, whereas the a= line is much more open and
            extensible.  If a SIP ALP can get its routing information
            from the m= line it will reduce complexity.

If someone can point out existing media descriptions that would require a 
SIP ALP to have intimate knowledge of the a= line in order to manipulate a 
NAT/firewall, I'd be interested to hear it.  Barring that we will be the 
first to extend SDP such that this is required.

I'll also add that this is not a rapidly growing set of attributes we're 
talking about.  I.e., unlike codec technology and the AVP profiles, it 
doesn't seem like there will be a lot of new things to say about TCP 
connection setup in the future.

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

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Aug 2000 17:32:01 +0200

> first to extend SDP such that this is required.

Check draft-ietf-mmusic-sdp-srcfilter-00.txt. The author proposes
an extension to the a=line which allows to specify source addresses.

Jiri

-- 
Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
--
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Aug 2000 11:37:32 -0400

Jonathan Rosenberg wrote:

> connection is setup, which is going to be impossible in certain systems.

I assume you mean the port number specified in bind()? You're saying
that 

s = socket()
bind(s, ...)
connect(s, ...)

does not work on some systems?

> 2. instead of AVP, its a new parameter which indicates TCP: AVP-TCP

AVP makes sense iff the next layer is RTP, uses RTP profile (RFC
1890bis) payload types and the encapsulation is using the 2-byte message
delineation mechanism. Thus, this may be true for some TCP connections,
but not others.

> the same, the highest IP address.

This being the two two numbers/IP addresses advertised in SDP, i.e.,
this should not require any additional socket calls to find out.

> zero defined by SIP (refusal of a stream).

Seems like a reasonable solution. Adding some explanatory detail as to
the socket API calls involved may prevent confusion as to what's meant.
As for the preconditions draft, having a table spelling out the
allowable combinations of active/passive/both/uni may be useful.

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

---

From: David Yon <[email-masked]>
Date: Wed, 09 Aug 2000 12:39:49 -0400

>an extension to the a=line which allows to specify source addresses.

Fair enough, although based on a quick reading of the I-D, it would appear 
that a simple SIP ALP would not actually be required to understand the a= 
line described in the draft.  A *smart* SIP ALP could use it as an 
optimization (i.e., configure the firewall to filter the source addresses), 
but a simple SIP ALP could opt to let the UA do it, which is what happens 
anyway if there is no ALP in the path.

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