Re: [MMUSIC] Another bundling proposal

[Paul Kyzivat <[e-mail]>]

This is an interesting approach, though Bernard's comments need to be 
considered.

One observation is that this introduces a new level of multiplexing 
based on a special codec. While it can work, there is already a proposal 
on the table for multiplexing multiple RTP sessions on a single 5-tuple: 
draft-westerlund-avtcore-transport-multiplexing-04. ISTM that this new 
bundling proposal could be adapted to use that multiplexing technique.

Bernard already raised issues about port 9 and address 0.0.0.0. I'll add 
that when this is done for multiple m-lines we stand some chance of 
getting errors due to reusing the same transport address. AFAIK there is 
no particular reason to use port 9 in this case, so perhaps it would be 
safer to use a different non-zero port in each such line.

I had originally found little reason to pursue 
draft-westerlund-avtcore-transport-multiplexing-04, but now I start to 
think that this provides an answer to the problem of demuxing without 
having to specify SSRCs or restrict payload types. I think it could be 
used, rather than an RTP header extension, to specify capture-encodings 
for clue. (But it can't specify mapping to multiple capture-encodings.)

	Thanks,
	Paul

On 2/22/13 4:05 PM, Dale R. Worley wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>