Subject: Re: [clue] Consumer choosing subset of Captures from MCC

From: Robert Hansen <[email-masked]>
Date: Mon, 05 Jan 2015 18:12:40 +0000

I'm also good with the proposed change.

Rob

On 22/12/14 20:41, Paul Kyzivat wrote:
> (As individual) I support the proposed change.
>
>     Thanks,
>     Paul
>
> On 12/22/14 12:23 PM, Duckworth, Mark wrote:
>> We discussed this at the design team meeting last week.  See Rob’s email
>> from December 15.  The issue is we think the Provider should not be
>> required to honor a request in a Configure message to use only specific
>> Captures in an MCC.  Does the group agree with this proposed change?
>>
>> Current text in the framework:
>>
>> - The Consumer may or may not choose to receive all the indicated
>> Captures.  Therefore it can choose to receive a sub-set of Captures
>> indicated by the MCC.
>>
>> For example if the Consumer receives:
>>
>>          MCC1(VC1,VC2,VC3){attributes}
>>
>> A Consumer could choose all the Captures within a MCCs however if the
>> Consumer determines that it doesn't want VC3 it can return
>> MCC1(VC1,VC2).  If it wants all the individual Captures then it returns
>> only the MCC identity (i.e. MCC1).  If the MCC in the advertisement does
>> not reference any individual captures, then the Consumer cannot choose
>> what is included in the MCC, it is up to the Provider to decide.
>>
>> Proposed new text in the framework:
>>
>> - The Consumer may or may not request to receive all the indicated
>> Captures.  Therefore it can request to receive a sub-set of Captures
>> indicated by the MCC.
>>
>> For example if the Consumer receives an Advertisement with:
>>
>>          MCC1(VC1,VC2,VC3){attributes}
>>
>> A Consumer could choose all the Captures within the MCC, however if the
>> Consumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2)
>> in the Configure message. This is just a suggestion to the Provider.
>> The Provider MAY consider this suggestion when deciding which Captures
>> to include in the MCC Capture Encoding it sends to the Consumer. If the
>> Consumer wants all the individual Captures then it returns only the MCC
>> identity (i.e. MCC1).  If the MCC in the advertisement does not
>> reference any individual captures, then the Consumer cannot choose what
>> is included in the MCC, it is up to the Provider to decide.
>>
>> Another possibility is to add a new MCC attribute in the advertisement,
>> so the Provider can indicate whether or not it will accept requests
>> asking for only a subset of captures in an MCC.
>>
>> Mark
>>
>>
>>
>> _______________________________________________
>> 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: Tue, 06 Jan 2015 11:14:34 +1100

Looking from a user perspective I have trouble with this change. If the 
MP provider receives an MCC and gives the participants a chance to 
choose the contributing captures then the user will expect to receive 
their choice. There's no feedback that their choice isn't allowed other 
than the captures they don't want appear in their media stream. They'll 
probably try to do the "choose" procedure again figuring that they did 
something wrong in the first place.

So I don't support going from effectively a "MUST" to "a suggestion". I 
think the suggestion of adding an MCC attribute to indicate that a 
subset cannot be chosen is a more robust solution.

Regards, Christian

On 23/12/2014 4:23 AM, Duckworth, Mark wrote:
>
> We discussed this at the design team meeting last week.  See Rob’s 
> email from December 15.  The issue is we think the Provider should not 
> be required to honor a request in a Configure message to use only 
> specific Captures in an MCC. Does the group agree with this proposed 
> change?
>
> MCC1(VC1,VC2).  If it wants all the individual Captures then it 
> returns only the MCC identity (i.e. MCC1).  If the MCC in the 
> advertisement does not reference any individual captures, then the 
> Consumer cannot choose what is included in the MCC, it is up to the 
> Provider to decide.
>
> A Consumer could choose all the Captures within the MCC, however if 
> the Consumer determines that it doesn't want VC3 it can return 
> MCC1(VC1,VC2) in the Configure message. This is just a suggestion to 
> the Provider.  The Provider MAY consider this suggestion when deciding 
> which Captures to include in the MCC Capture Encoding it sends to the 
> Consumer. If the Consumer wants all the individual Captures then it 
> returns only the MCC identity (i.e. MCC1). If the MCC in the 
> advertisement does not reference any individual captures, then the 
> Consumer cannot choose what is included in the MCC, it is up to the 
> Provider to decide.
>
> Another possibility is to add a new MCC attribute in the 
> advertisement, so the Provider can indicate whether or not it will 
> accept requests asking for only a subset of captures in an MCC.
>
> Mark
>
>
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 06 Jan 2015 11:19:16 +1100

Read MC Media Consumer below.

Christian

On 6/01/2015 11:14 AM, Christian Groves wrote:
> Looking from a user perspective I have trouble with this change. If 
> the MP provider receives an MCC and gives the participants a chance to 
> their choice. There's no feedback that their choice isn't allowed 
> other than the captures they don't want appear in their media stream. 
> They'll probably try to do the "choose" procedure again figuring that 
> they did something wrong in the first place.
>
> So I don't support going from effectively a "MUST" to "a suggestion". 
> I think the suggestion of adding an MCC attribute to indicate that a 
>> email from December 15.  The issue is we think the Provider should 
>> not be required to honor a request in a Configure message to use only 
>> the Provider.  The Provider MAY consider this suggestion when 
>> deciding which Captures to include in the MCC Capture Encoding it 
>> sends to the Consumer. If the Consumer wants all the individual 
>> Captures then it returns only the MCC identity (i.e. MCC1). If the 
>> MCC in the advertisement does not reference any individual captures, 
>> then the Consumer cannot choose what is included in the MCC, it is up 
>> to the Provider to decide.
>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 8 Jan 2015 14:35:00 -0800

I see Paul and Rob agreeing with the proposal that says the Provider should not be required to honor a request in a Configure message to use only specific Captures in an MCC.  Christian prefers to add an attribute the Provider can set, telling the Consumer whether or not it will accept such requests.

Either way is okay with me.

Any further discussion?  How do we choose which way to go?

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Monday, January 05, 2015 7:15 PM
> To: [email-masked]
> Subject: Re: [clue] Consumer choosing subset of Captures from MCC
> 
> > We discussed this at the design team meeting last week.  See Rob's

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Jan 2015 11:55:30 -0500

> Either way is okay with me.

The main thing is not to force the provider to accept such subsetting, 
since it could prevent important implementation approaches.

But then there needs to be clarification of what is to happen when a new 
source is being added to the MCC by the provider. If the consumer has 
selected a subset, does that mean it won't get the new source until it 
receives a new advertisement that mentions it and the consumer has 
updated the config to select it?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 12 Jan 2015 16:31:30 +1100

I agree its important not to force the provider to accept subsetting, 
that's why I think its important for the consumer to know whether the 
provider allows it or not. An MCC attribute would allow this.

If a new source is added I would think it is handled like any other 
capture. The provider advertises it and if the consumer wants it then it 
should send a configure.

Regards, Christian

On 10/01/2015 3:55 AM, Paul Kyzivat wrote:
>> I see Paul and Rob agreeing with the proposal that says the Provider 
>> should not be required to honor a request in a Configure message to 
>> use only specific Captures in an MCC.  Christian prefers to add an 
>> attribute the Provider can set, telling the Consumer whether or not 
>> it will accept such requests.
>>
> But then there needs to be clarification of what is to happen when a 
> new source is being added to the MCC by the provider. If the consumer 
> has selected a subset, does that mean it won't get the new source 
> until it receives a new advertisement that mentions it and the 
> consumer has updated the config to select it?
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jan 2015 09:52:27 -0500

> capture. The provider advertises it and if the consumer wants it then it

The problem here is timeliness. If you don't subset then you see the new 
source immediately. If you subset, then you miss the new source until 
you see the advertisement and configure it.

I suppose one way to deal with that would be for the subset to be 
specified by listing those sources you *don't* want to receive.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 12 Jan 2015 08:46:26 -0800

Inline, my responses to Christian and Paul.
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, January 12, 2015 9:52 AM
> To: [email-masked]

[Duckworth, Mark] I suspect the group will not object to adding an attribute,
so I will make a specific proposal to add text for this, in a separate email.

> you see the advertisement and configure it.

[Duckworth, Mark] I agree with Christian, and I don't see timeliness as
a problem here.  If the Consumer asks for something specific, then that is
what it gets, with no new additions, until it specifically changes
what it asks for with another configure message.

> not
> deciding