Re: [MMUSIC] Another bundling proposal

While I do agree that legacy implementations will have issues with using the same port on multiple m= lines, the proposal does explicitly address multiplexing issues via the "kumquat payload format" (an RTP tunnel of sorts).  Describing the implications for RTP in the proposal is better rather than implicitly assuming a given de-multiplexing approach or the presence of RTP extensions (e.g. the capture RTP extensions Roni referred to in a previous post). 

Since the RTP tunnelling approach does require changes to lots of components in the system
(e.g. MCUs), it is not necessarily the easiest thing to deploy.  However, it does appear to obviate the need to declare individual SSRCs, which a number of the other proposals do not (e.g. if payload types are not required to unique among all m-lines, then if multiple media types are multiplexed then SSRC is the only remaining de-multiplex point, so SSRC declaration is required). 

Also, tunnelling proposals can be used to address some of the ICE performance issues as well.  There is really no intrinsic reason why those kind of proposals can't be used to allow multiple endpoints to share a TURN allocation, for example, removing TURN as a performance bottleneck without requiring Trickle ICE. 

> From: eckelcu@cisco.com
> To: worley@ariadne.com; mmusic@ietf.org
> Date: Fri, 22 Feb 2013 21:39:23 +0000
> Subject: Re: [MMUSIC] Another bundling proposal
> 
> Hi Dale,
> 
> Your proposal has some very nice properties; however, my concern with the overall approach is that I fear the initial offer will not be handled very well by typical pre-BUMDLE implementations. Due to the port being '9' and the connection address being 0.0.0.0, I would expect either:
> 1) a re-INVITE is needed for things to be renegotiated (best case)
> 2) the call fails (worst case)
> Of course other variations between the best and worst case could happen, but the odds of arriving at the worst case seem unacceptably high to me. That is just my 2 cents without actually testing anything to validate it. I'd like to hear what others think.
> 
> Cheers,
> Charles
> 
> 
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Dale R. Worley
> > Sent: Friday, February 22, 2013 1:06 PM
> > To: mmusic@ietf.org
> > Subject: [MMUSIC] Another bundling proposal
> > 
> > I've written an alternative bundling proposal which I think manages
> > the problems of bundling better.
> > 
> > A series of tutorial examples are here:
> > http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4
> > so it's easy to see how the proposal works.
> > 
> > Distinctive features of this proposal are:
> > 
> > - A separate m= line describes the bundled media, allowing unambiguous
> >   attribution of attributes to either the bundle or a constituent, and
> >   independent rejection of each constituent.
> > 
> > - Backward compatibility is achieved straightforwardly.
> > 
> > - Multiplexed media flows are attributed to their original constituent
> >   media descriptions without requiring each to be declared
> >   individually in the SDP.
> > 
> > - The multiplexed media flow is artificially given the media type
> >   "audio" to prevent rejection by SBCs.
> > 
> > - An encapsulating RTP format is used so demultiplexing can be done
> >   without coordinating payload types between media descriptions, and
> >   to ensure the bundled media description is rejected by
> >   non-supporting endpoints.
> > 
> > - Zero/non-zero ports and valid/null addresses are controlled to avoid
> >   duplicate port usage, and to ensure SBCs see exactly the media flows
> >   specified by the SDP.
> > 
> > 
> > 
> > Filename:	 draft-worley-sdp-bundle
> > Revision:	 02
> > Title:		 Kumquat: A Generic Bundle Mechanism for the Session
> > Description Protocol (SDP)
> > Creation date:	 2013-02-22
> > Group:		 Individual Submission
> > Number of pages: 27
> > URL:             http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-
> > 02.txt
> > Status:          http://datatracker.ietf.org/doc/draft-worley-sdp-bundle
> > Htmlized:        http://tools.ietf.org/html/draft-worley-sdp-bundle-02
> > Diff:            http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-02
> > 
> > Abstract:
> >    This document defines a generic bundle mechanism for the Session
> >    Description Protocol (SDP) by which the media described by a number
> >    of media descriptions ("m= lines") are multiplexed and transmitted
> >    over a single transport association.  The transport association is
> >    described by an additional media description, allowing SDP attributes
> >    to be applied to the aggregate, independently of attributes applied
> >    to the constituents.  In offer/answer usage, the bundle mechanism is
> >    backward compatible with SDP processors that do not understand the
> >    mechanism.  The mechanism is designed to be compatible with the
> >    limitations of the existing Internet infrastructure.
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic