Re: [clue] CLUE and Simulcast

Hi Christian,
Inline
Roni

> -----Original Message-----
> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves
> Sent: 24 October, 2014 4:59 AM
> To: clue@ietf.org
> Subject: Re: [clue] CLUE and Simulcast - ticket #47
> 
> Hello Roni,
> 
> Supporting draft-westerlund-avtcore-rtp-simulcast-04
> <http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04>
> seems like the most straight forward approach as it keeps things at the
> encoding level, which is really where simulcast belongs.
> 
> For a CLUE based solution I don't think we need to revert to MCCs. The
purpose
> of simulcast is to provide different encoding options for a particular
media
> stream. A media provider can Advertise a MC with multiple encoding groups.
A
> media consumer if it wants to receive multiple encodings for the same MC
can
> simply choose multiple capture encodings e.g. MC1/Encoding1 MC1/Encoding2
> etc.
[Roni Even] How does the media consumer know that these are alternatives of
a simulcast stream and know how many can be used at the same time. You also
lose here the option of the total BW that is an encoding group attribute.
All these means that we need some changes to CLUE and we can look at what
will make the best solution using MCs or MMCs.
Still the question is if we say that we will use the SDP based solution even
though it is not a WG draft, having it as a normative reference will delay
the publication of the CLUE draft

> 
> Regards, Christian
> 
> On 22/10/2014 8:00 AM, Roni Even wrote:
> >
> > Hi,
> >
> > During our weekly design team meeting we discussed simulcast support
> > in CLUE.
> >
> > Here is my take on the options, my description may not be accurate and
> > the purpose here is to continue the discussion allowing us to have a
> > better view of the options.
> >
> > Looking at the state of simulcast support in other WGs, there is an
> > individual draft
> > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04
> > that being discussed. The proposed solution is based on the unified
> > plan where all encoded streams composing alternatives of a simulcast
> > stream are in the same m-line. The alternatives are described using an
> > SDP media level attribute "a=simulcast". This attribute is not defined
> > for SDP session level.
> >
> > The first question we had is if we should base CLUE simulcast support
> > on this individual draft based on CLUE timeline or try to define a
> > different multicast solution at the CLUE protocol level.
> >
> > If we base our solution on the avtcore-rtp-simulcast-04 document the
> > advertisement will include an individual encoding that will relate to
> > optional multiple simulcast encoding and the configure will select
> > such encoding. The actual number of different stream that will compose
> > the simulcast stream will be negotiated using Offer/Answer as
> > described in the above document. The risk here is that this is an
> > individual draft and we may need to review the CLUE support if it
> > changes. The advantage is that we will have simulcast the same for
> > CLUE and non-CLUE systems.
> >
> > The other option for simulcast support in the CLUE protocol can be
> > based on having separate Media Capture for each of the different
> > simulcast encoding and use MCC to compose the simulcast alternatives.
> > We will need some way to escribe that this MCC is for simulcast
> > description and to provide the actual allowed individual encodes
> > combinations for the Configuration by the consumer.
> >
> > Thanks
> >
> > Roni
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org
> > https://www.ietf.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue