Subject: [clue] Sending a configure

From: Christian Groves <[email-masked]>
Date: Thu, 13 Dec 2012 11:20:44 +1100

Hello,

Section 9 of the framework states:
" The consumer is able to change its configuration of the provider's
    encodings any number of times during the call, either in response to
    a new capture advertisement from the provider or autonomously. The
    consumer need not send a new configure message to the provider when
    it receives a new capture advertisement from the provider unless the
    contents of the new capture advertisement cause the consumer's
    current configure message to become invalid."

 From the text I don't think its 100% clear what is meant by "or 
autonomously". Does this relates to the signalling of CLUE i.e. sending 
a Configure message? Does it relate to sending a new SDP O/A? Changing 
the what RTP it sends autonomously?

If we're only talking about sending a Configure message I would propose 
that we change the first sentence to say:
"Once the consumer has received an advertisement it may change its 
configuration of the provider's encodings any number of times during the 
call by sending a new configure message."

Regards, Christian

---

From: Andy Pepperell <[email-masked]>
Date: Thu, 13 Dec 2012 10:46:09 +0000

Hi Christian,

The intent behind the use of "autonomously" there was just to re-iterate
that this wouldn't be necessarily a consumer's "response" to the provider's
advertisement, but more that even in the absence of any changed state on
the provider there might be reasons for a new configure message from the
consumer. This wasn't intended to refer to any SIP O/A changes, but more
for things like the user of the consumer system choosing, say, to no longer
want to view a presentation video stream or to receive a set of switched
loudest speaker captures rather than pre-composed video streams from the
provider (even if the provider offers both throughout).

Your wording proposal does sound like a useful clarification I think,
though it may also be worth continuing to make clear that the configure
isn't strictly a response to the advertisement from the provider.

Regards,

Andy

On Thu, Dec 13, 2012 at 12:20 AM, Christian Groves <
[email-masked]> wrote:

> autonomously". Does this relates to the signalling of CLUE i.e. sending a
> Configure message? Does it relate to sending a new SDP O/A? Changing the
> what RTP it sends autonomously?
>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Dec 2012 09:13:42 +1100

Hello Andy,

How does the following sound?
"Once the consumer has received an advertisement it may change its 
configuration of the provider's encodings any number of times during the 
call independent of subsequent advertisements by sending a new configure 
message."

Regards, Christian

On 13/12/2012 9:46 PM, Andy Pepperell wrote:
> Hi Christian,
>
> The intent behind the use of "autonomously" there was just to 
> re-iterate that this wouldn't be necessarily a consumer's "response" 
> to the provider's advertisement, but more that even in the absence of 
> any changed state on the provider there might be reasons for a new 
> configure message from the consumer. This wasn't intended to refer to 
> any SIP O/A changes, but more for things like the user of the consumer 
> system choosing, say, to no longer want to view a presentation video 
> stream or to receive a set of switched loudest speaker captures rather 
> than pre-composed video streams from the provider (even if the 
> provider offers both throughout).
>
> though it may also be worth continuing to make clear that the 
> configure isn't strictly a response to the advertisement from the 
> provider.
>
> Regards,
>
> Andy
>
>
> On Thu, Dec 13, 2012 at 12:20 AM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello,
>
>     autonomously". Does this relates to the signalling of CLUE i.e.
>     sending a Configure message? Does it relate to sending a new SDP
>     O/A? Changing the what RTP it sends autonomously?
>
>     If we're only talking about sending a Configure message I would
>     propose that we change the first sentence to say:
>     configuration of the provider's encodings any number of times
>     during the call by sending a new configure message."
>
>     Regards, Christian
>     _______________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2012 18:10:41 -0500

> call independent of subsequent advertisements by sending a new configure

I find "independent of subsequent advertisements" a bit confusing. It 
might imply that it is appropriate to keep ordering from an old menu 
after a new menu has been published. As we discussed at the interim in 
SJ, that *may* work, but probably isn't guaranteed. So how about:

"Once the consumer has received an advertisement it may change its 
configuration of the provider's encodings any number of times while the 
advertisement remains current by sending a new configure message."

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Dec 2012 10:31:39 +1100

Hello Paul,

Adding "remains current" may imply that an Advertisement may expire 
which I don't think they do? It also may cause confusion with the 
subsequent sentence indicating that even after receiving a new 
advertisement the consumer doesn't have to send a configure.

Perhaps my original wording proposal is enough?

Regards, Christian

On 14/12/2012 10:10 AM, Paul Kyzivat wrote:
> configuration of the provider's encodings any number of times while 
> the advertisement remains current by sending a new configure message."
>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2012 18:53:38 -0500

On 12/13/12 6:31 PM, Christian Groves wrote:
> which I don't think they do?

They can be superseded, after which they are no longer current.
But I make up that terminology, and will be happy if you have something 
better.

> It also may cause confusion with the

You weren't at the interim. There was a lot of discussion of this.

*My* understanding of this is that:

- each advertisement will be uniquely identified (e.g. version#)

- a config must identify the advertisement it responds to

- a config *may* be rejected if the advertisement it references
   is not the most recent one. (But it need not be if the advertiser
   remembers enough to process it.)

- a new advertisement may imply that some previously advertised
   captures are no longer available, or have differing properties.
   If the most recently received config references captures that
   are no longer available, then they may no longer be transmitted.
   So it may be expedient to send a new config after receiving a
   new advertisement that impacts some previously configured captures.
   But one is not *obligated* to do this.

Making a rule that you MUST send a new config after receiving a new 
advertisement doesn't really help, because there will still be a window 
when the old config might be invalid.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Dec 2012 11:19:02 +1100

Hello Paul,

Please see my response below.

Regards, Christian

On 14/12/2012 10:53 AM, Paul Kyzivat wrote:
> But I make up that terminology, and will be happy if you have 
> something better.

[CNG] Yes I agree. Sending a new Advertisement replaces the old one.

> advertisement doesn't really help, because there will still be a 
> window when the old config might be invalid.

[CNG] Er, I wasn't proposing that you MUST send a new config. I was just 
pointing out that we were discussing the first sentence of a paragraph. 
There was a second sentence also to consider. I wasn't at the interim 
and I take it many people on the list also weren't there. I'm trying to 
work through the framework clarify potential issues. It would be good 
these sorts of discussions found there way into the document.