Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

I started this issue, so I'll make my case again.

There must be a reason to have multiple m-lines in the bundle. (If there 
isn't, leave them out, and then maybe you won't need bundle at all.)

I assert that in all cases that reason can't be realized without being 
able to associate packets with the corresponding m-line.

The exception to this are those packets that deal only with those 
aspects of the bundle that are common. The most obvious example of this 
is ICE. But if *all* packets are common to all the m-lines then there is 
no reason for the bundle.

	Thanks,
	Paul

On 6/25/13 7:16 AM, Christer Holmberg wrote:
> Hi,
>
> There has been some discussions about whether BUNDLE should mandate that
> users are mandated to *always* (no matter what transport protocols are
> used in the BUNDLE group) have a mechanism to map received data to an m-
> line, or whether it from a generic BUNDLE perspective should be optional
> – IF there would be cases where it’s not needed.
>
> We haven’t had that much discussion about it yet, so I will not ask a
> DECISION question at this point, but I would really like to get some
> input from people who have opinions about this :)
>
> Note that this issue is NOT about HOW to map data to m- lines (there
> will be a separate question about how to map RTP to m- lines etc), or
> whether we should allow usage of the same PT value (for the same codec
> configuration) in multiple m- lines, but more about a general rule.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>