Subject: [clue] provider should be able to bypass SDP O/A state in some cases

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 11 Nov 2014 13:30:06 -0800

Hello all,
In the protocol draft, it seems to me the provider state machine requires the provider to initiate an SDP offer/answer even when it is not necessary or desirable to do so.  Suppose the provider is in ESTABLISHED state, and then receives a new CONF message.  Provider goes to CONF RESPONSE state.  Suppose the provider sends a successful CONF RESPONSE back to the consumer.  Now according to the state diagram and the text in section 6.1, the provider initiates an SDP O/A.  But in this case I think SDP O/A is not required, because nothing in the SDP should change from the previous O/A, is that right?  If not, then what in SDP should change?

If the SDP O/A is not desired in this case, then maybe when in ESTABLISHED receiving CONF should go to  a different state similar to CONF RESPONSE but which does not lead to O/A.  This is related also to my previous question about handling a configure error after ESTABLISHED state.

What do you think?

Mark

---

From: Christian Groves <[email-masked]>
Date: Wed, 12 Nov 2014 15:52:00 +1100

Hello Mark,

I think in general the SDP O/A states should be separate from the CLUE 
states. The SDP O/A for the CLUE controlled streams could be sent before 
the ADVERTISEMENT. The linkage only comes about when both the CaptureIDs 
and their associated EncodingIDs are communicated. It gets complicated 
then because some media may be established and others not established. 
The established state would have to be expanded to address these 
possibilities.

In order to simplify things perhaps we should not have any "SDP O/A" / 
"ESTABLISHED" state in the CLUE protocol document? So rather than having 
these states we have a state "Waiting for additional CONF" which 
transitions back to the CONF RESPONSE state.

Regards, Christian

On 12/11/2014 8:30 AM, Duckworth, Mark wrote:
>
> Hello all,
>
> In the protocol draft, it seems to me the provider state machine 
> requires the provider to initiate an SDP offer/answer even when it is 
> not necessary or desirable to do so.  Suppose the provider is in 
> ESTABLISHED state, and then receives a new CONF message.  Provider 
> goes to CONF RESPONSE state.  Suppose the provider sends a successful 
> CONF RESPONSE back to the consumer.  Now according to the state 
> diagram and the text in section 6.1, the provider initiates an SDP 
> O/A. But in this case I think SDP O/A is not required, because nothing 
> in the SDP should change from the previous O/A, is that right?  If 
> not, then what in SDP should change?
>
> If the SDP O/A is not desired in this case, then maybe when in 
> ESTABLISHED receiving CONF should go to  a different state similar to 
> CONF RESPONSE but which does not lead to O/A.  This is related also to 
> my previous question about handling a configure error after 
> ESTABLISHED state.
>
> What do you think?
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 12 Nov 2014 22:15:49 +0100

Hello Mark,

please see in-line my comments ([SPR]).

> If the SDP O/A is not desired in this case, then maybe when in ESTABLISHED receiving CONF should go to  a different state similar to CONF RESPONSE but which does not lead to O/A.  This is related a…

[SPR] We gave for granted that a new CONFIGURE triggers a new O/A phase. If this is not the case, we definitely have to think of a state machine modification in-line with what you are suggesting.

Simon

> Mark

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 12 Nov 2014 22:25:11 +0100

Hello Christian,

please see my comments in-line ([SPR]).

> Hello Mark,
> 
> I think in general the SDP O/A states should be separate from the CLUE states. The SDP O/A for the CLUE controlled streams could be sent before the ADVERTISEMENT. The linkage only comes about when both the CaptureIDs and their associated EncodingIDs are communicated. It gets complicated then because some media may be established and others not established. The established state would have to be expanded to address these possibilities.

[SPR] If you recall my last presentation at IETF90 in Toronto, SDP-CLUE synchronization is actually one of the hot topics we have to tackle.

> In order to simplify things perhaps we should not have any "SDP O/A" / "ESTABLISHED" state in the CLUE protocol document? So rather than having these states we have a state "Waiting for additional CONF" which transitions back to the CONF RESPONSE state.

[SPR] We put the "SDP O/A" state there as a place-holder for the above mentioned CLUE-SDP synchronization procedure. From the protocol's perspective, there is a bi-directional link to the O/A phase: when you are in a CLUE state which requires that you start a new O/A phase, you call something like 'createOffer()' and then you wait for an SDP-triggered event which is raised as soon as the O/A phase is completed (in much the same way as the WebRTC browser's API does with the underlying JSEP state machine).
What's your feeling about this?

Cheers,

Simon

                     					       _\\|//_
                           				      ( O-O )

---

From: Christian Groves <[email-masked]>
Date: Thu, 13 Nov 2014 11:41:31 +1100

Hello Simon, all,

SDP-CLUE interaction is something we have to address but I'm not 
convinced that we have to go to the level of specifying a detailed state 
machine for this. From a CLUE protocol draft perspective we can model 
inputs at a higher level rather than linking to specific SDP O/A events. 
Really the key criteria is for a Configure whether encoding information 
has been received.

We have the signalling draft that specifies CLUE interwork with SDP O/A. 
It seems to me that we'd have an overlap in the procedures if we go into 
detail about SDP O/A in the protocol draft. Do we gain much by going to 
this detail?

Regards, Christian

On 13/11/2014 8:25 AM, Simon Pietro Romano wrote:
>> I think in general the SDP O/A states should be separate from the 
>> CLUE states. The SDP O/A for the CLUE controlled streams could be 
>> sent before the ADVERTISEMENT. The linkage only comes about when both 
>> the CaptureIDs and their associated EncodingIDs are communicated. It 
>> gets complicated then because some media may be established and 
>> others not established. The established state would have to be 
>> expanded to address these possibilities.
>
> [SPR] If you recall my last presentation at IETF90 in Toronto, 
> SDP-CLUE synchronization is actually one of the hot topics we have to 
> tackle.
>
>> In order to simplify things perhaps we should not have any "SDP O/A" 
>> / "ESTABLISHED" state in the CLUE protocol document? So rather than 
>> having these states we have a state "Waiting for additional CONF" 
>> which transitions back to the CONF RESPONSE state.
>
> [SPR] We put the "SDP O/A" state there as a place-holder for the above 
> mentioned CLUE-SDP synchronization procedure. From the protocol's 
> perspective, there is a bi-directional link to the O/A phase: when you 
> are in a CLUE state which requires that you start a new O/A phase, you 
> call something like 'createOffer()' and then you wait for an 
> SDP-triggered event which is raised as soon as the O/A phase is 
> completed (in much the same way as the WebRTC browser's API does with 
> the underlying JSEP state machine).
>>> requires the provider to initiate an SDP offer/answer even when it 
>>> is not necessary or desirable to do so.  Suppose the provider is in 
>>> goes to CONF RESPONSE state.  Suppose the provider sends a 
>>> successful CONF RESPONSE back to the consumer.  Now according to the 
>>> state diagram and the text in section 6.1, the provider initiates an 
>>> SDP O/A. But in this case I think SDP O/A is not required, because 
>>> nothing in the SDP should change from the previous O/A, is that 
>>> right?  If not, then what in SDP should change?
>>>
>>> ESTABLISHED receiving CONF should go to  a different state similar 
>>> to CONF RESPONSE but which does not lead to O/A.  This is related 
>>> also to my previous question about handling a configure error after 
>>> ESTABLISHED state.
>>>
>>> What do you think?
>>>
>>> Mark
>>>
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>  e-mail: [email-masked] <mailto:[email-masked]>
>