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