RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt

[Jonathan Rosenberg <[e-mail]>]

 

> -----Original Message-----
> From: David Yon [mailto:[e-mail]]
> Sent: Wednesday, December 13, 2000 4:26 PM
> To: [e-mail]
> Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
> 
> 
> Thanks everyone for the warm reception and feedback at the MMUSIC WG 
> meeting today.  While it is fresh in everyone's mind, I'd 
> like to collect a 
> laundry list of discussion items for the next version of the draft.
> 
> Jonathan suggested that we fold in all the 
> connection-oriented protocols 
> that we currently know about into the draft.  SSL, TLS, RTSP, 
> et al. 


SCTP (rfc2960), not RTSP.

> While 
> I wish I was an encyclopedia of existing network protocols, I'm not. 
> :-)  So if folks could chime in with their favorite 
> connection-oriented 
> protocols they would like to see listed, that would help me a 
> great deal.

I think if we have TLS (no need for a separate SSL identifier), TCP, and
SCTP, we are covered.

> 
> On that topic, apparently there is an ambiguity as to what is 
> meant by 
> "RTP/AVP-TCP".  If there are still issues to be hammered out 
> on how RTP/AVP 
> is transported over TCP, I would submit that it is not an issue to be 
> addressed by my draft.

rfc1890bis,
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt,
defines a default encapsulation format when none is defined. THis format is
simply to append each packet with a two byte length. There is a somewhat
annoying problem here, however.

The tcpmedia draft would depend on this mechanism as a normative reference.
Thus, it could not proceed to proposed until rfc1890bis goes to draft. At
the current pace, that should be sometime in 2005.

So, we have a few options. THe best one is to probably define a separate
"Generic transport of RTP over stream protocols", which is a one page
document that says "append each packet with a two byte length". Then, we can
progress that document alone to proposed along with the tcpmedia draft,
which would reference it.

The other encapsulation, defined by RTSP (rfc2326), is interesting. It
encapsulates the RTP stream within the same TCP connection that carries RTSP
messages. What is interesting about it is that we could conceivably do the
same for SIP; I think this is orthogonal to the SDP issue, but interesting
to consider. Might be a somewhat cleaner way to deal with firewalls and
NATs.

Note that RTSP calls the usage of TCP over the RTSP TCP connection
"RTP/AVP/TCP".


> I didn't hear any dissent on having "direction:both" be the 
> default value, 
> any objection?

I think that this is the most reasonable thing. Anything else would require
a different default in each direction, which is more confusing.


> 
> Brian Rosen spoke with me afterward and suggested that the 
> draft might be 
> unnecessarily biased towards TCP, whereas with some minor 
> rewording it 
> might expand in scope to all connection-oriented protocols 
> without any 
> additional complexity.  Brian if you could elaborate on this 
> a bit that 
> would be helpful.  I have a few reservations about it but I'd 
> like to hear 
> again what you are looking for so that I'm fully 
> understanding what you are 
> after.

I think the only issue is really the tokens to identify the protocols. The
action of "opening a connection" is common to all connection oriented
transports.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[e-mail]                     FAX:   [phone]
http://www.cs.columbia.edu/~jdrosen         PHONE: [phone]
http://www.dynamicsoft.com