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

Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology?

The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan.

Mo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Saturday, June 29, 2013 12:12 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic