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

[David Yon <[e-mail]>]

Finally getting a chance to spin a new version of the draft...

At 04:00 AM 12/14/00 -0500, Jonathan Rosenberg wrote:


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

The problem with SCTP is that it allows each endpoint to be comprised of 
multiple IP addresses, which:

         (a) is not possible to express in SDP, and
         (b) the draft in question does nothing to remedy

While I appreciate the notion that we want to cover as many protocols as we 
can in this draft, it's looking to me like expressing SCTP in SDP requires 
its own draft which then references this one.

The alternative is that we just live with the fact that this draft will not 
address the problem of SCTP endpoints have multiple IP addresses.


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

Anyone have an opinion on these options?  Do we want to just have this 
draft reference RTSP?  Or does anyone care about RFC1890bis enough to draft 
the one-pager that Jonathan mentions?  I'm not enough of a RTP expert to 
qualify.



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

Given the possible inclusion of SCTP in the draft, I'm going to scrub most 
of the references to TCP out of it and just talk about "connection setup" 
in the abstract.  It also begs the question of title, I propose renaming 
the draft as follows:

Connection-Oriented Media Transport in SDP
  <draft-ietf-mmusic-sdp-comedia-01.txt>

Any comments?


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


David Yon
Chief Technical Officer
Dialout.Net, Inc.
[e-mail]