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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2013 10:05:30 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Saturday, June 29, 2013 12:12 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 2 Jul 2013 16:09:01 +0000

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:[email-masked]] 
Sent: Tuesday, July 02, 2013 10:06 AM
To: Mo Zanaty (mzanaty)
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Jul 2013 18:30:26 +0000

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ä: [email-masked] [mailto:[email-masked]] Puolesta Mo Zanaty (mzanaty)
Lähetetty: 2. heinäkuuta 2013 19:09
Vastaanottaja: Paul Kyzivat
Kopio: [email-masked]
Aihe: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

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

 

Cheers,
Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2013 10:06 AM
To: Mo Zanaty (mzanaty)
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

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

>>> 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 :)
>>
> 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 
> anything. If there is, then I hope someone will call it out. If so, 
> then the constraint can be tightened.
>
> 	Thanks,
> 	Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2013 16:00:06 -0400

+1
(Except that I *am* Paul)

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 2 Jul 2013 20:33:02 +0000

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

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2013 4:00 PM
To: Christer Holmberg
Cc: Mo Zanaty (mzanaty); [email-masked]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

+1

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Jul 2013 18:40:07 -0400

> 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

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 3 Jul 2013 05:06:32 +0000

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:[email-masked]] 
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; [email-masked]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Jul 2013 07:26:34 +0000

Hi Mo,

I think what you are saying is that you want to have one thumbnail flow per m- line. So far so good.

And, WITHOUT BUNDLE, you would be able to demux the flows based on the 5-tuple (as each m- line would have a unique address:port). So far go good.

But, in your example, WITH BUNDLE, all 4 m- lines share the same 5-tuple, so if you want to demux the streams you need to have SOME other mechanism than the 5-tuple. Will you demux based on SSRC?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
Lähetetty: 3. heinäkuuta 2013 8:07
Vastaanottaja: Paul Kyzivat
Kopio: Christer Holmberg; [email-masked]
Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; [email-masked]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

> 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

>>>>> 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 :)
>>>>
>>> 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.
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Jul 2013 11:38:00 +0000

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.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Mo Zanaty (mzanaty) [[email-masked]]
To: Paul Kyzivat [[email-masked]]
CC: Christer Holmberg [[email-masked]]; [email-masked] [[email-masked]]
Subject: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; [email-masked]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

        Thanks,
        Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 3 Jul 2013 22:01:42 +0530

Hi all,

In case BUNDLE, the same type of “m” lines shall be diffentiated by SDP
label attribute? I'm asking this question as I heard that SSRC in RTP is not
created to differentiate RTP session.

In fact in SIPREC, the label attribute is used to differentiate the two
different "m" line of the same type.

Thanks
Partha

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Wednesday, July 03, 2013 12:57 PM
> To: Mo Zanaty (mzanaty); Paul Kyzivat
> Cc: [email-masked]
> And, WITHOUT BUNDLE, you would be able to demux the flows based on the
> 5-tuple (as each m- line would have a unique address:port). So far go
> good.
> 
> But, in your example, WITH BUNDLE, all 4 m- lines share the same 5-
> tuple, so if you want to demux the streams you need to have SOME other
> mechanism than the 5-tuple. Will you demux based on SSRC?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 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
> 
> >> 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.
> 
> >> 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 multiple m-lines of thumbnails must be
> combined into a single m-line with a=ssrc/max-ssrc/multiple-
> render/whatever.
> >>
> >>> 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.
> >>
> >> 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.
> >> 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
> >>>
> >>>>> 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.
> >>>>>
> >>>> 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.
> >>>

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 3 Jul 2013 22:50:21 +0530

Hi Christer,

Sorry, label attribute shall be used to distinguish in application layer
only and not on RTP layer demux as label is not possible to be pushed in the
RTP session.

AFAIK, the proposal to use SSRC or CNAME for distinguishing the RTP streams
are discussed in SIPREC but both are not selected.

Thanks
Partha

> Behalf Of Parthasarathi R
> Sent: Wednesday, July 03, 2013 10:02 PM
> To: 'Christer Holmberg'; 'Mo Zanaty (mzanaty)'; 'Paul Kyzivat'
> Cc: [email-masked]
> > Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to
> map
> > received data to m- line?
> >
> > Hi Mo,
> >
> > I think what you are saying is that you want to have one thumbnail
> flow
> > per m- line. So far so good.
> >
> > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism
> to
> > map received data to m- line?
> >
> > > Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate
> mechanism
> > to map received data to m- line?
> > >
> > > +1
> > >> Why do you need 4 m- lines for the thumbnails, when you could use
> 1
> > m- line?
> > >>
> > >> Regards,
> > >>
> > >> Christer
> > >>
> > >> Lähettäjä: [email-masked] [mailto:mmusic-
> [email-masked]]
> > >> Puolesta Mo Zanaty (mzanaty)
> > >> 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.)
> > >>
> > >> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism
> to
> > map received data to m- line?
> > >>
> > >>> Behalf Of Paul Kyzivat
> > >>> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism
> to
> > map received data to m- line?
> > >>>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 3 Jul 2013 18:17:13 +0000

Hi Christer,

If by "demux" you mean classify as separate RTP streams, then yes, that is always by SSRC (regardless of SDP).

If by "demux" you mean map to unique SDP m-lines for unique context of other attributes, that unique context is not always necessary for all apps, hence why I prefer not mandating this.

I think you worded it well: "if you want to demux the streams you need to have SOME other mechanism". Emphasis on "if" (when demux refers to mapping to unique SDP m-lines). This would be fine to mandate if you include the "if".

Cheers,
Mo

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, July 03, 2013 3:27 AM
To: Mo Zanaty (mzanaty); Paul Kyzivat
Cc: [email-masked]
Subject: VS: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Hi Mo,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
Lähetetty: 3. heinäkuuta 2013 8:07
Vastaanottaja: Paul Kyzivat
Kopio: Christer Holmberg; [email-masked]
Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; [email-masked]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Jul 2013 07:10:34 +0000

Hi,

I meant mapping to unique m- line :)

Regards,

Christer

-----Original Message-----
From: Mo Zanaty (mzanaty) [[email-masked]]
To: Christer Holmberg [[email-masked]]; Paul Kyzivat [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?
Hi Christer,

Cheers,
Mo

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, July 03, 2013 3:27 AM
To: Mo Zanaty (mzanaty); Paul Kyzivat
Cc: [email-masked]
Subject: VS: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Hi Mo,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Mo Zanaty (mzanaty) [mailto:[email-masked]]
Lähetetty: 3. heinäkuuta 2013 8:07
Vastaanottaja: Paul Kyzivat
Kopio: Christer Holmberg; [email-masked]
Aihe: RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

Mo

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, July 02, 2013 6:40 PM
To: Mo Zanaty (mzanaty)
Cc: Christer Holmberg; [email-masked]
Subject: Re: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Jul 2013 14:59:29 -0400

> 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) wh…

Since there currently is no BUNDLE, I don't know how you can say an 
implementation is closer to any of the plans. Instead, you can only 
hypothesize on how such an application might use any of the bundling 
schemes if it became available.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Jul 2013 15:13:12 -0400

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)
>
> *From:* Mo Zanaty (mzanaty) [[email-masked]]
> *To:* Paul Kyzivat [[email-masked]]
> *CC:* Christer Holmberg [[email-masked]];
> [email-masked] [[email-masked]]
> *Subject:* RE: VS: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism
> 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
>
>>>> 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.
>>>
>>> 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
>>>>