Subject: [MMUSIC] Proposed Resolution on comedia and comedia-fix

From: Joerg Ott <[email-masked]>
Date: Fri, 14 Feb 2003 14:27:53 +0100

David, Jonathan,

We have reviewed the entire discussion again and have come to few concrete
proposals how we would like to proceed on this issue.  First of all, there
is merit in the current comedia proposal to proceed (quickly), but there is
also value in Jonathan's comments and observations.

What we would like to do is:

1.  Proceed using David's comedia-04 draft as a basis.

2.  Remove the entire discussion of, and attributes for, source IP
     addresses.  As there is no general way to determine when an IP
     addresss can be trusted, we believe its use is worthless, if not
     risky.

3.  Include discussion of the security consideration Jonathan raised
     into the revision to comedia-04.

4.  Include something like the eid: attribute as an optional indicator.
     We need to consider if a unique random indentifier is appropriate, or
     if an application specific identifier (e.g. RTP SSRC) might be better.

5.  Do not follow the comedia-fix idea of sending the eid: as the
     first couple of bytes over any TCP connection.  We believe this
     is going to cause problems with existing protocols and protocol
     implementations which do not natively send this information.

     Where necessary, for example when multiplexing several application
     layer connections into a single transport layer connection, the higher
     layer protocol must obviously already provide some framing structure.
     It is expected that such a structure can be used to tag the individual
     application layer connections and correlate them via the eid:.  In such
     a case, or if the application layer protocol supports flow identifiers,
     this can also be used for single-hop TCP connections. If the transport
     protocol supports additional identifiers they might also be used.

     Obviously, this requires writing up further details. Specific use of,
     or formats for, the eid: per application layer protocol might need to
     be defined.

     It is hoped that this will solve the connection re-use issue for
     certain applications while allowing other applications to continue
     unmodified.

6.  Port re-use on servers should preferably be dealt with on a per
     application basis.  The eid: will be useful for this purpose if
     an application protocol supports referencing it in some fashion.
     There is no need to generally break backwards compatibility with
     arbitrary protocols.

7.  The revised comedia document needs to specify that if eid: is included,
     it MUST be used by the application protocol. If the eid: is not
     present, then identifying incoming connections can only work on a
     receiver port basis (with all the negative implications identified by
     comedia-fix -- which should be included in a note).  New application
     protocol to be used with comedia should incorporate the necessary
     behavior.

Comments?

Cheers,
Colin and Joerg

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: David Yon <[email-masked]>
Date: Fri, 14 Feb 2003 09:47:46 -0500

I disagree with #2, but so be it.  At this rate, all future IETF protocols 
are going to have use divining rods to determine where to send packets, 
since IP addresses are being banned because of NATs (insert half-smiley).

I agree with your proposal for eid:, but per the recent RTSP discussion I 
propose that eid be made its own draft, as it is arguably not intrinsic to 
connection-oriented media and therefore does not belong in comedia.  I have 
no problem with comedia referencing an externally-documented eid mechanism 
and applying the appropriate MUSTs listed below.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 16 Feb 2003 23:24:31 -0500

I agree with the proposal. Some followup on eid below.

David Yon wrote:
> I disagree with #2, but so be it.  At this rate, all future IETF 
> protocols are going to have use divining rods to determine where to send 
> packets, since IP addresses are being banned because of NATs (insert 
> half-smiley).

Just source addresses.

> 
> I agree with your proposal for eid:, but per the recent RTSP discussion 
> I propose that eid be made its own draft, as it is arguably not 
> intrinsic to connection-oriented media and therefore does not belong in 
> comedia.  I have no problem with comedia referencing an 
> externally-documented eid mechanism and applying the appropriate MUSTs 
> listed below.

At this point, I would actually agree with David here. If the way that 
eid is done is application specific anyway (I concede that sending it as 
the first bytes is not optimal and is better done application specific), 
then its encoding in SDP may as well be application specific too. The 
use of a separate draft would be primarily to outline the concept, I 
suppose. However, I don't see a need for comedia to have a dependency on it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com