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

["Parthasarathi R" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Parthasarathi R
> Sent: Wednesday, July 03, 2013 10:02 PM
> To: 'Christer Holmberg'; 'Mo Zanaty (mzanaty)'; 'Paul Kyzivat'
> Cc: [e-mail]
> Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map
> received data to m- line?
> 
> 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
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Christer Holmberg
> > Sent: Wednesday, July 03, 2013 12:57 PM
> > To: Mo Zanaty (mzanaty); Paul Kyzivat
> > Cc: [e-mail]
> > 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.
> >
> > 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:[e-mail]]
> > Lähetetty: 3. heinäkuuta 2013 8:07
> > Vastaanottaja: Paul Kyzivat
> > Kopio: Christer Holmberg; [e-mail]
> > Aihe: 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:mmusic-
> [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
> > >>
> > >
> > >
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic