Subject: [clue] maxgroupbandwidth clarification?

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 26 Nov 2014 08:17:09 -0800

Hi Christian,
Maybe we should have some clarification about maxgroupbandwidth, but I think the simulcast question really has no bearing on it.  Use of maxgroupbandwidth, and relation to SDP, should be the same whether we do CLUE protocol level simulcast or not.
Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, November 25, 2014 7:25 PM
> To: [email-masked]
> Subject: Re: [clue] Consensus call: remove clue-specific simulcast
> 
> I'm OK with removing list with Rob's clarification below. As a result
> we'll need to revisit some of the examples. Also as I raised, we should
> provide some clarification on the use of maxbandwidth as a result.
> 
> Regards, Christian
> 
> 
> On 25/11/2014 9:09 PM, Robert Hansen (rohanse2) wrote:
> > YES, I support removing this.
> >
> > (specifically, removing the maxCaptureEncodings element and mandating
> that a capture can be mapped to at most one encoding).
> >
> > Rob
> >
> > -----Original Message-----
> > From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> > Sent: 24 November 2014 22:07
> > To: CLUE
> > Subject: [clue] Consensus call: remove clue-specific simulcast
> >
> > During the Honululu meeting we had consensus to remove the clue-
> specific simulcast mechanism (via configuring the same capture with two or
> more encodings). The expectation is that, in lieu of this clue will rely on an
> SDP mechanism for negotiating simulcast within a single m-line. (The mmusic
> wg adopted draft-westerlund-avtcore-rtp-simulcast-04 as a wg item at this
> meeting.)
> >
> > This message brings that question to the list for confirmation.
> >
> > Please indicate if you support removal of the clue-specific simulcast
> > mechanism: YES/NO.
> >
> > If you indicate NO, please provide a detailed reason why not.
> >
> > 	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

---

From: Christian Groves <[email-masked]>
Date: Thu, 27 Nov 2014 14:33:37 +1100

Hello Mark,

I agree in general. A specific case I was thinking about was that 
previously with the CLUE simulcast if additional encodings (say for 
other media) were added to the group, the maxgroupbandwidth would apply 
to all the encodings. Moving simulcast to SDP would allow a "simulcast" 
maxbandwidth to be assigned (via SDP) as well as the overall CLUE 
encoding group maxbandwidth. This would prevent the simulcast media from 
dominating the bandwidth where other encodings are involved.

Regards, Christian