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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 14 Aug 2000 16:24:13 -0700

Yes, that was my suggestion. Just as there is a "udp" and "RTP/AVP" profile
we should create a "tcp" and "RTP/AVP-TCP" SDP profile. People seem to be
suggesting uses for both definitions.

Robert.

> -----Original Message-----
> From: David Yon [mailto:[email-masked]]
> Sent: Monday, August 14, 2000 8:38 PM
> To: Fairlie-Cuninghame, Robert; 'Christian Huitema'; 'Jonathan
> Rosenberg'
> Cc: [email-masked]
> Subject: RE: [SIP] SIP, SDP, and TCP-based media transport
> 
> 
> I just want to clarify that you are not suggesting that we go 
> solely with 
> the "TCP-AVP" nomenclature, yes?  Rather, you're suggesting 
> that we have 
> "TCP" (or some such that suggests raw TCP with no AVP) *and* a 
> "RTP/AVP-TCP" which implies RTP/AVP using TCP rather than UDP.
> 
> Have I got that right?
> 
> At 06:59 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote:
> 
> >I still beleive that both a tcp and a RTP/AVP-TCP SDP 
> profile will have
> >their uses. For instance, Henning just mentioned using reliable RTP
> >text/digit transport through TCP in another stream.
> >
> >Robert.
> 
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> [email-masked]
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Aug 2000 03:29:10 -0400

> suggesting uses for both definitions.

I agree as well. I am particularly interested in RTP/AVP-TCP for the
purposes of firewall traversal.

Answering some of the comments in other emails:

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

I want to be sure we are consistent about what the semantic is of values
we place inside of SDP. So, lets take a step back. For passive, both and
uni, we need to specify the port we are listening on. This port will
also be the source port of packets sent back to the host which initiated
the connection. For active connections, David wishes to indicate the
source port that will be used in the initial SYN packet. I'm still not
clear on why this is needed.

In any case, these are two different pieces of information, and as such,
should be conveyed in separate places. The m line is idea for the listen
port. In the case of active connections, I would propose this ALWAYS be
9. In this case, should a foolish firewall open up a hole to port 9, its
not a big deal. If active is in use, the a line could contain the source
port that will be used:

a=direction:active 9384

Christian writes:
> "both" is going to have funny results if there are one or 2 NATs on the
> path... You should not rely on comparing the binary values of ports or
> addresses. I thing that active/passive/uni provides a good match -- or
> active/passive/both, leaving it to the app to decide which connection is
> used for what purpose. 
> 

Good point on NAT. I have no problem combining both uni and both, and
allowing apps to decide how they distribute it. We would need to say
that implementations need to be prepared to receive packets on either
connection.

Sounds like we are nearing consensus. If thats the case, someone should
write up the 3 page I-D on the subject and we can move forward.

-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: David Yon <[email-masked]>
Date: Wed, 16 Aug 2000 10:26:19 -0400

>purposes of firewall traversal.

Would both "TCP" and "RTP/AVP-TCP" share the same a= line options?  Would 
they therefore be described in the same I-D or is there sufficiently more 
to say about RTP/AVP-TCP to warrant its own I-D?

>clear on why this is needed.

I talked about this earlier in the thread (substitute "port zero" in the 
mail for "PORT_ANY" or however you want to think about it):

http://lists.bell-labs.com/pipermail/sip/2000q3/001855.html

I don't know what to add to the above email---I thought I spelled it out 
fairly explicitly.

>not a big deal. If active is in use, the a line could contain the source

Urk, it's amazing how hard it is to wedge this functionality into SDP 
without having at least *one* distasteful workaround. :-)

The only thing I would add is that the direction:both should also be 
allowed to specify a source port if the UA deemed it necessary.

>that implementations need to be prepared to receive packets on either

So that leaves us with:

direction:active
direction:passive
direction:both

>write up the 3 page I-D on the subject and we can move forward.

Unless somebody else is already typing madly away on the I-D, I'd be happy 
to write it up since I'm the one to blame for this thread. :-)

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

---

From: David Yon <[email-masked]>
Date: Wed, 16 Aug 2000 10:28:47 -0400

>to say about RTP/AVP-TCP to warrant its own I-D?

I just wanted to clarify that by "a= line options" I meant the new 
"direction" attribute.  Obviously RTP/AVP-TCP has a slew of other a= 
options that are not necessarily applicable to just TCP.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Aug 2000 02:50:18 -0400

> I don't know what to add to the above email---I thought I spelled it out

The difficulty here is that you are choosing to modify one of the
fundamental RTP design choices. RTP uses dynamic ports explicitly
because you might have multiple sessions on the same host; thats why
there is no well known RTP port. Your problem is arising since you want
to discard this decision, use a single port for RTP, and demux based on
source IP address AND source port. Demuxing based on source address and
port info seems mightily dangerous, particulary in the presence of NATs
which routinely modify exactly these things.

I guess your assumption is that if the media streams are always on a
well known port, we can convince firewall admins to allow inbound
connections to that port. I'm doubtful that this would really happen.

-Jonathan R.

---

From: David Yon <[email-masked]>
Date: Thu, 17 Aug 2000 10:38:17 -0400

>fundamental RTP design choices. RTP uses dynamic ports explicitly

Since the TCP transport protocol I have in mind is not RTP, I am doing no 
such thing.

>which routinely modify exactly these things.

Once you have a NAT, the source port is the least of your problems, since 
the source IP address is also munged.  This is where SIP ALPs come into 
play, and there's no reason why even a basic SIP ALP can't handle both 
address and port translation.

>connections to that port. I'm doubtful that this would really happen.

Your guess is incorrect.  The reason (among several) to have fixed ports on 
the "passive" side is not to convince firewall admins to allow inbound 
connections to that port, but rather to convince the hyper-paranoid 
firewall admins to allow *outbound* connections to that port.  The topology 
is that the UA advertising "passive" is not behind a firewall, which allows 
UAs which *are* behind a firewall to (a) not require inbound connections, 
and (b) only have a single outbound port open.  Asking an admin to open an 
outbound port on 2392 (for example) so that users can make use of a 
well-defined SIP-based service is a lot different than asking "gee, can you 
open ports 6000-8000?"

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Aug 2000 23:00:17 -0400

> Since the TCP transport protocol I have in mind is not RTP, I am doing no

Right. I keep forgetting you aren't interested in RTP. I am clearly
thinking along RTP lines.

> well-defined SIP-based service is a lot different than asking "gee, can you

These kinds of things have been hashed out endlessly on various IETF
mailing lists. It all comes down to this: designing protocols to meet
assumed policies of firewall administrators is a dangerous game. These
policies change all the time, and what works today may not work
tomorrow. 

-Jonathan R.

---

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

>policies change all the time, and what works today may not work

At a philosophical level I agree that tap-dancing around firewalls is bound 
to get your toes stubbed eventually.  Nevertheless, I still believe that my 
original assertion is true: reducing the footprint of the firewall pinhole 
tends to reduce the friction through the firewall.  It's self-defeating to 
pass up an opportunity to gain some ground on the problem with the argument 
of "you may win the battle, but you'll never win the war."

And like I said, firewalls are but one reason to allow SDP to describe 
TCP-based services that accept on a fixed port (interoperability with 
legacy TCP-based protocols comes to mind).  It just seems like allowing 
(ALLOWING, *not* requiring) the initiator of the TCP connection to announce 
the source port is a potentially useful addition that isn't in the category 
of undue complexity in the protocol.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Aug 2000 11:03:17 -0400

> of undue complexity in the protocol.

So long as its not mandatory, I can live with that. So, is the proposal
made previously

> not a big deal. If active is in use, the a line could contain the source

OK? If so, lets declare this done, get an I-D written, and move forward
here.

-Jonathan R.

---

From: David Yon <[email-masked]>
Date: Fri, 18 Aug 2000 13:32:36 -0400

>OK? If so, lets declare this done, get an I-D written, and move forward

Yes, fine by me.  I'll assume since nobody else stepped up to the plate 
that I've got the token on the I-D.

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

---

From: David Yon <[email-masked]>
Date: Tue, 29 Aug 2000 11:52:48 -0400

Ok, I've got an I-D available, any and all comments welcome:

ftp://ftp.dialout.net/drafts/draft-ietf-sip-sdp-tcpmedia-00.txt

I'm an admitted newbie to the whole I-D process, but based on my readings 
at www.ietf.org this needs to be submitted under the auspices of the SIP 
WG.  Can I just mail it to the [email-masked] address or are 
there other considerations to be dealt with first?

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