Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt

From: "Roni Even" <[email-masked]>
Date: Thu, 20 Oct 2016 20:12:15 +0300

Hi Christian,
This goes back to the point that Jonathan made about the need for capture
id. The major reason is to be able to use the spatial information of the
media capture currently switched by the MCC, in the composed case we are not
sure if the spatial information is relevant at all 
Roni

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, September 27, 2016 9:01 AM
> To: [email-masked]
> Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt
> 
> Hello Mark,
> 
> What about the switched composed case where the endpoint switches
> between composed captures? We should probably explicitly mention this as
> its discussed in the framework.
> 
> Regards, Christian
> 
> 
> On 27/09/2016 7:56 AM, Duckworth, Mark wrote:
> > Hi Jonathan and Roni,
> >
> > I thought some more about the MCC composed case, where there are two
> or more MCs in the MCC. I think trying to use this CaptureID RTP Header
and
> SDES item has problems for that case, so maybe it is better to just drop
it. I
> agree with Jonathan that "I'm not sure how useful the constituent capture
ID
> is for composed MCCs".
> >
> > The problem I see is about associating the original contributing
CaptureIDs
> to SSRC/CSRC values. When using the RTP header extension, we are
> associating one contributing original CaptureID with the SSRC of the MCC
> stream. This is different than associating the captureID to a CSRC that
might
> appear in the same RTP packet. This works well for the switched case (as
> opposed to composed) because it is direct and doesn't rely on any CSRC.
> Some topologies might not even be using CSRCs.
> >
> > If we also use this SDES item to map CaptureIDs to CSRCs that appear
> within an MCC packet, that is a different sort of mapping. Those CSRC
values
> would be associated with the original constituent MCs, not the MCC. So we
> would be using this captureID mapping mechanism to map it to two different
> types of things. That doesn't seem right to me. It gets more complicated
if
> the composed case happens to include only one CSRC at some point, then
> what do you map the CaptureID to? The CSRC value, or the SSRC value, or
> both?
> >
> > So anyway, now I'm proposing this mechanism can be used only for the
> switched MCC case. This is closer to how the rtp mapping document is
> already written.
> >
> > I still will have some small suggestions for clarifying text in the
document. I
> can send that later, after the group agrees whether or not to support the
> composed case with this, or just the pure switched case.
> >
> > Mark
> >
> >> -----Original Message-----
> >> From: Jonathan Lennox [mailto:[email-masked]]
> >> Sent: Wednesday, September 21, 2016 11:32 AM
> >> To: Duckworth, Mark <[email-masked]>
> >> Cc: Roni Even <[email-masked]>; Paul Kyzivat
> >> <[email-masked]>; [email-masked]
> >> Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt
> >>
> >> Hi, Mark -
> >>
> >> These seem like good changes to me.  Sorry, I'd lost track of our
> >> previous discussion.
> >>
> >> I'm not sure how useful the constituent capture ID is for composed
> >> MCCs, as opposed to switched ones, since the geometry information is
> >> only going to be meaningful for switched MCCs.  But it's still useful
> >> informationally, and putting it in the CSRCs' SDESes is the right thing
to
> do.
> >>
> >> If you could suggest text that'd be great.
> >>
> >>> On Sep 14, 2016, at 1:03 PM, Duckworth, Mark
> >> <[email-masked]> wrote:
> >>> Hi Roni,
> >>>
> >>> I agree the parts about mapping ssrc/csrc to m-lines and CLUE
> >>> encodings is described in other RTP documents and CLUE signaling
> >>> document. So I am
> >> okay
> >>> with that part.
> >>>
> >>> However, I think some information about the meaning and usage of the
> >> Capture
> >>> ID SDES item and RTP Header is missing.
> >>>
> >>> 1. Capture ID SDES and RTP Header is intended to be used only for
> >>> constituent captures within an MCC.
> >>>    1.a - I previously suggested changing the name to "MCC
> >>> Constituent Capture ID", and Jonathan agreed. I still think this is a
good
> idea.
> >>>
> >>> 2. An MCC can include more than 1 constituent capture at a time. The
> >> Capture
> >>> ID SDES item is intended to be used for any number of simultaneous
> >>> constituent captures. This means it can be used for the composed
> >>> case as well as the pure switching case. The document implies (to
> >>> me) it can be
> >> used
> >>> only for the switching case.
> >>>
> >>> 3. For the composed case, the RTP Header extension is not used,
> >>> because
> >> that
> >>> won't map the capture ID to CSRC values. Instead, for the composed
> >>> case, only the RTCP SDES mechanism can be used to map the Capture ID
> >>> to
> >> values
> >>> that appear in the MCC packets' CSRC list. This allows the media
> >>> consumer
> >> to
> >>> identify the original media captures that are composed into the MCC.
> >>>
> >>> I think Jonathan agreed to all this on the list
> >>>
> >> https://mailarchive.ietf.org/arch/msg/clue/qFfSNIzFuNtqqlGbxx1W5dXLik
> >> 4
> >>> If you agree, I could suggest specific changes to the document to
> >>> make this clear.
> >>>
> >>> Mark
> >>>
> >>>> -----Original Message-----
> >>>> From: Roni Even [mailto:[email-masked]]
> >>>> Sent: Wednesday, September 14, 2016 12:19 PM
> >>>> To: Duckworth, Mark <[email-masked]>; 'Paul Kyzivat'
> >>>> <[email-masked]>
> >>>> Cc: 'Jonathan Lennox' <[email-masked]>; [email-masked]
> >>>> Subject: RE: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt
> >>>>
> >>>> Hi Mark,
> >>>> The reason we took the information out because it is described in
> >>>> other documents like the RTP topologies for SSRC/CSRC or the CLUE
> >>>> signaling document for the SDP mapping. We reference these
> >>>> documents and did
> >> not
> >>>> see
> >>>> any need to repeat information
> >>>>
> >>>> Roni
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Duckworth, Mark [mailto:[email-masked]]
> >>>>> Sent: Tuesday, September 13, 2016 1:07 AM
> >>>>> To: Roni Even; 'Paul Kyzivat'
> >>>>> Cc: 'Jonathan Lennox'; [email-masked]
> >>>>> Subject: RE: [clue] I-D Action: draft-ietf-clue-rtp-mapping-08.txt
> >>>>>
> >>>>> I'm also concerned we are losing some important information in
> >>>>> this
> >>> recent
> >>>>> change. I found the old section 5 "Application to CLUE Media
> >>>> Requirements"
> >>>>> particularly useful.
> >>>>>
> >>>>> For me, the most important information in the RTP mapping
> document
> >>>>> is how to associate all these different things with each other:
> >>>>> - SSRC/CSRC
> >>>>> - SDP m-line (which is a CLUE encoding)
> >>>>> - Clue capture ID for directly configured media captures (MC or
> >>>>> MCC)
> >>>>> - Clue capture ID for constituents of MCC (for both switched and
> >>> composed
> >>>>> cases)
> >>>>>
> >>>>> I went back to old email here:
> >>>>>
> >> https://mailarchive.ietf.org/arch/msg/clue/qFfSNIzFuNtqqlGbxx1W5dXLik
> >> 4
> >>>>> I'm not sure anymore if the RTP mapping document clearly describes
> >>>>> the different cases discussed in that email. I think it should,
> >>>>> and I
> >>> thought
> >>>> it
> >>>>> did, but I'm not so sure anymore.
> >>>>>
> >>>>> I think this part is not at all clear (from the referenced email):
> >>>>>
> >>>>>> Mechanism 2: Use RTP/RTCP CaptureID SDES item, conveyed in RTCP
> >> and
> >>>>> RTP
> >>>>> header extension as described in clue-rtp-mapping section 6.  This
> >>>>> gives
> >>> a
> >>>>> direct mapping between an ssrc value and a captureID.  This
> >>>>> mechanism
> >> is
> >>>>> intended to be used only for Clue media captures that are
> >>>>> constituents
> >>> of
> >>>> an
> >>>>> MCC.  This could apply to an MCC that is switched or composed.
> >>>>>> For the case of a "switching mixer", the ssrc value in RTP
> >>>>>> packets
> >>> stays
> >>>>> the same over time for a given m line and CLUE encoding.  This is
> >>>>> true
> >>> for
> >>>>> single MC encoded directly, and also for an MCC.  For an MCC, the
> >>>>> ssrc
> >>>> value
> >>>>> associated with the MCC captureID stays constant.  But the
> >>>>> value(s) in
> >>> RTP
> >>>>> CSRC field change as switching occurs.  So the MID SDES item maps
> >>>>> to a constant ssrc value even when switching occurs.  The
> >>>>> CaptureID SDES
> >> item
> >>>>> (conveyed in RTCP) maps the MCC constituent capture IDs to the
> >>>>> values
> >>>> that
> >>>>> appear in RTP CSRC field.  These mappings don't change, but the
> >>>>> media provider should send the mapping information whenever an
> >>>>> individual
> >> MC
> >>>> is
> >>>>> switched into an MCC for the first time.  The CaptureID RTP header
> >>>> extension
> >>>>> does not apply for this case, it can be conveyed only in RTCP.
> >>>>>
> >>>>> I think it would help if we took some information from that old
> >>>>> email
> >>> and
> >>>>> added it into RTP mapping doc. Or can anybody show me how it
> >>>>> really is clear already, or if the old email is actually mistaken?
> >>>>>
> >>>>> Mark
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: clue [mailto:[email-masked]] On Behalf Of Roni Even
> >>>>>> Sent: Sunday, September 11, 2016 2:08 PM
> >>>>>> To: 'Paul Kyzivat' <[email-masked]>; [email-masked]
> >>>>>> Cc: 'Jonathan Lennox' <[email-masked]>
> >>>>>> Subject: Re: [clue] I-D Action:
> >>>>>> draft-ietf-clue-rtp-mapping-08.txt
> >>>>>>
> >>>>>> Paul,
> >>>>>> The issue of static and dynamic mapping was reflecting the
> >>>>>> discussion between Jonathan Lennox and me. It was based on the
> >>>>>> different
> >>>> supported
> >>>>>> topologies and after talking with Colin Perkins it was clear that
> >>>>>> it
> >>> was
> >>>>>> confusing terminology and there was need to have it in this
> >>>>>> document
> >>>> and
> >>>>>> just reference the AVTcore topologies supported by CLUE.
> >>>>>> We tried to make the document simpler and this is the result
> >>>>>>
> >>>>>> Roni
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: clue [mailto:[email-masked]] On Behalf Of Paul
> >>>>>>> Kyzivat
> >>>>>>> Sent: Tuesday, September 06, 2016 10:11 PM
> >>>>>>> To: [email-masked]
> >>>>>>> Subject: Re: [clue] I-D Action:
> >>>>>>> draft-ietf-clue-rtp-mapping-08.txt
> >>>>>>>
> >>>>>>> Roni & Jonathan,
> >>>>>>>
> >>>>>>> On 9/2/16 12:32 PM, Paul Kyzivat wrote:
> >>>>>>>
> >>>>>>>> Thanks for the context. In my first reading of the diffs it
> >>> appeared
> >>>>>>>> to me that significant functionality had been dropped. But I
> >>>>>>>> will
> >>>> read
> >>>>>>>> it again. Maybe I just misunderstood.
> >>>>>>> OK, I read it again. Now I can be more specific about what is
> >>>> bothering
> >>>>>> me.
> >>>>>>> (Note that I'm discussing changes between -07 and -08. So it is
> >>>>> necessary
> >>>>>> to
> >>>>>>> have both in front of you (or the diff) to make sense of these
> >>>>> comments.)
> >>>>>>> * Section 3:
> >>>>>>>
> >>>>>>> The change from -07 removes the discussion of there being two
> >>>>>>> major RTP/RTCP behaviors. Does that mean we have lost one or
> >>>>>>> both of
> >>>> these?
> >>>>>>> * Section 4:
> >>>>>>>
> >>>>>>> Here again two distinct behaviors were previously broken out,
> >>>>>>> and
> >>> that
> >>>>> has
> >>>>>>> now been removed. I thought those alternatives were important.
> >> Have
> >>>>> we
> >>>>>>> lost one of those?
> >>>>>>>
> >>>>>>> And then we have also lost:
> >>>>>>>
> >>>>>>>     In either of the above two cases, the MCU/Mixer may create an
> >>>>>>>     advertisement with a virtual room capture scene (i.e., with
> >>>> Multiple
> >>>>>>>     Content Captures).
> >>>>>>>
> >>>>>>>     isAlternately the MCU/Mixer can relay all the capture scenes
> >>> from
> >>>>> all
> >>>>>>>     advertisements to all consumers.  This means that the
> >>>> advertisement
> >>>>>>>     will include multiple capture scenes, each representing a
> >>> separate
> >>>>>>>     TelePresence room with its own coordinate system.
> >>>>>>>
> >>>>>>> While this will remain true even if it is not mentioned, I
> >>>>>>> thought
> >>> it
> >>>>> was
> >>>>>> an
> >>>>>>> important conceptual difference that was worth highlighting,
> >>>>>>> since
> >>> one
> >>>>> or
> >>>>>>> the other may not occur to some readers.
> >>>>>>>
> >>>>>>> * Sections 4.3 & 4.4 (in -7):
> >>>>>>>
> >>>>>>> These two sections (Static Mapping and Dynamic Mapping) were
> >>>>>>> elaborations of the stuff I mentioned above. So my same
> >>>>>>> questions
> >>>> apply.
> >>>>>>> This distinction was a *big deal*, with some participants
> >>> implementing
> >>>>> one
> >>>>>>> and some the other in their video conferencing products.
> >>>>>>>
> >>>>>>> * Sections 4.2 and 5 (in -7):
> >>>>>>>
> >>>>>>> I guess you all decided we no longer needed to carry the history
> >>>>>>> of
> >>>> how
> >>>>> we
> >>>>>>> got where we ended up. It disturbs me to lose this history, but
> >>>>>>> I
> >>>>>> understand it
> >>>>>>> can be distracting. So I reluctantly accept this.
> >>>>>>>
> >>>>>>> 	Thanks,
> >>>>>>> 	Paul
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> clue mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://www.ietf.org/mailman/listinfo/clue
> >>>>>> _______________________________________________
> >>>>>> clue mailing list
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/clue
> >
> >
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue