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

[Paul Kyzivat <[e-mail]>]

On 6/29/13 8:50 AM, Colin Perkins wrote:
> Christer,
>
> On 25 Jun 2013, at 12:16, Christer Holmberg wrote:
>> 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 :)
>
> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care.

I just replied elsewhere on this.
My opinion turns out to be the exact opposite of yours: we need to 
support multiple algorithms, and that all applications should care.

I won't repeat the stuff about multiple algorithms.

I will repeat what I have said about the need for being able to associate:

There must have been *some* reason that two m-lines were used, rather 
than just one. Each m-line heads a media section of the SDP that 
contains a bunch of declarations. Something must be different in those 
two media sections, or else a single media section would have been 
enough. Presumably whatever it is that is different is intended to 
affect how received packets are processed or interpreted. (If not, again 
there is no need for it to be there.) If you can't associate the packet 
with the m-line, then you don't know which of the multiple 
interpretations to apply to the packet.

Maybe there is some exception to this, though I haven't come up with 
anything. If there is, then I hope someone will call it out. If so, then 
the constraint can be tightened.

	Thanks,
	Paul