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

On 6/30/13 11:32 PM, Mo Zanaty (mzanaty) wrote:
> 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.

I'm going to keep asking this question until I get an answer that makes 
sense:

Please explain to me a meaningful situation when there are multiple 
m-lines in a bundle and there is insufficient information to associate 
each packet with an m-line.

The *point* of plan A is that there be an m-line per "flow", and that 
the offerer is enumerating the flows. So clearly it knows the mapping. 
If the answerer isn't capable of doing the same mapping, then the use of 
plan A has failed.

The part that I want to be normative is that an O/A is not valid unless 
the mapping is possible with the information in the O/A, and that the 
offerer and the answerer would agree about the mapping of each packet. I 
don't care if they actually do the mapping, though if they are doing any 
sensible processing then they will be doing something *equivalent* to 
the mapping.

	Thanks,
	Paul

> 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
>