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

[Paul Kyzivat <[e-mail]>]

On 7/3/13 7:38 AM, Christer Holmberg wrote:
>
> Hi,
> I guess one advantage with 4 m- lines is that, if the remote endpoint
> does not support BUNDLE, it will allow to have a separate 5-tuple for
> each thumbnail stream, without having to send a "fallack" offer.
> When both endpoints do support BUNDLE it makes little sense, but when
> thinking about it I really wonder if there is a reason to forbid it.

Yes, perhaps it is an interesting case to consider.
I think there is still an issue, but maybe it needs to be refined.

ISTM that *if* there is a subset of bundled media-sections that are 
indistinguishable other than by position or the address-info that will 
become common when the bundle is accepted, then it is only necessary 
that there be a way to associate a media packet to the subset, not to an 
individual m-line within that subset. (This is because being able to do 
so would not yield any useful information.)

Unfortunately, trying to turn that into clear text in the draft will be 
a challenge. :-(

The point I am trying to make about this is that when there is something 
*different* about the media sections, then only by associating media 
packets to m-lines is is possible to associate that other info with the 
packet. For instance, suppose each of the bundled m-lines has an 
associated a=label attribute. Then it is necessary to be able to 
associate a packet to an m-line in order to know which label applies to 
it, and that can impact what application level processing is done.

	Thanks,
	Paul

> Regards,
> Christer
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Mo Zanaty (mzanaty) [[e-mail]]
> *To:* Paul Kyzivat [[e-mail]]
> *CC:* Christer Holmberg [[e-mail]];
> [e-mail] [[e-mail]]
> *Subject:* RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism
> to map received data to m- line?
> To clarify, I have no plan to use or abuse Plan A. The implementations
> I'm most interested in are all closer to Plan B. However, I'm aware of
> widely deployed implementations (from other vendors) which are closer to
> Plan A in general, and specifically for the thumbnail example below (one
> m-line per thumbnail, all with the same port/PT). While I personally
> would not chose this, I see no reason to forbid it, because I recognize
> it is just personal preference.
>
> Mo
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Tuesday, July 02, 2013 6:40 PM
> To: Mo Zanaty (mzanaty)
> Cc: Christer Holmberg; [e-mail]
> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to
> map received data to m- line?
>
> On 7/2/13 4:33 PM, Mo Zanaty (mzanaty) wrote:
>>> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever.
>>
>> It seems you both want to mandate this (Plan B). Why? I see no reason for bundle to pick a plan. Let the plan wars rage outside bundle.
>
> So you want to use plan A *without* the association, so that the *only*
> purpose of the extra m-lines is to denote the number of flows?
>
> How would the receiver know if an incoming packet was associated with
> one of the flows defined by the m-lines?
>
> How would the receiver know if each ssrc should be treated as a
> different flow, or if appid should be used to define flows?
>
> I think you abuse plan A. Its different with plan B or No Plan. There
> you still need the ability to associate packets to m-lines, but that
> isn't sufficient to map them to flows. It is assumed that "extra"
> information, learned by different means, is used to sort out the flows.
>
>          Thanks,
>          Paul
>
>> Mo
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Tuesday, July 02, 2013 4:00 PM
>> To: Christer Holmberg
>> Cc: Mo Zanaty (mzanaty); [e-mail]
>> Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
>>
>> +1
>> (Except that I *am* Paul)
>>
>> On 7/2/13 2:30 PM, Christer Holmberg wrote:
>>> Hi,
>>>
>>> I am not Paul, but just to verify that I understand his issue, the question is:
>>>
>>> Why do you need 4 m- lines for the thumbnails, when you could use 1 m- line?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> -----Alkuperäinen viesti-----
>>> Lähettäjä: [e-mail] [mailto:[e-mail]] Puolesta Mo Zanaty (mzanaty)
>>> Lähetetty: 2. heinäkuuta 2013 19:09
>>> Vastaanottaja: Paul Kyzivat
>>> Kopio: [e-mail]
>>> Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
>>>
>>> An attempt at "an answer that makes sense". (Just snippets, not full SDP.)
>>>
>>> m=video 10000 RTP/SAVPF 96
>>> a=rtpmap:96 H264/90000
>>> a=fmtp:96 profile-level-id=42001F <--- HD 720p30 main speaker
>>>
>>> m=video 10000 RTP/SAVPF 97
>>> a=rtpmap:97 H264/90000
>>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>>>
>>> m=video 10000 RTP/SAVPF 97
>>> a=rtpmap:97 H264/90000
>>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>>>
>>> m=video 10000 RTP/SAVPF 97
>>> a=rtpmap:97 H264/90000
>>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>>>
>>> m=video 10000 RTP/SAVPF 97
>>> a=rtpmap:97 H264/90000
>>> a=fmtp:97 profile-level-id=42000C <--- SD 240p15 thumbnail a=recvonly
>>>
>>> No need to map thumbnail packets to specific m-lines, so reuse of PT=97 is fine. Just render the last 4 thumbnail sources received (in addition to the main speaker).
>>>
>>> You could mandate that PT must be unique to allow unique mapping.
>>>
>>> You could mandate that multiple m-lines of thumbnails must be combined into a single m-line with a=ssrc/max-ssrc/multiple-render/whatever.
>>>
>>> Which do you want to mandate and why?
>>>
>>> Cheers,
>>> Mo
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[e-mail]]
>>> Sent: Tuesday, July 02, 2013 10:06 AM
>>> To: Mo Zanaty (mzanaty)
>>> Cc: [e-mail]
>>> Subject: 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Paul Kyzivat
>>>> Sent: Saturday, June 29, 2013 12:12 PM
>>>> To: [e-mail]
>>>> 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
>>>> [e-mail]
>>>>https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>>https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>