Re: Unclear specification

On 2014-06-16 09:26, Adam Bergkvist wrote:
> On 2014-06-13 10:38, Blessing Pascal wrote:
>> In 4.3.1 in the definition of the procedures after an ICE event it is
>> unclear if the "ICE connection state" at article 2 is the same as
>> "iceConnectionState" at article 3 (marked red below)
>>
>>  1.
>>
>>     If the |RTCPeerConnection| ice gathering state
>>
>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-ice-gathering-state>
>>
>>     is |new| and the ICE transports setting
>>
>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#ice-transports-setting>
>>     is not set to |none|, the user agent /MUST/ queue a task to start
>>     gathering ICE addresses and set the ice gathering state
>>
>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-ice-gathering-state>
>>
>>     to |gathering|.
>>
>>  2.
>>
>>     If the ICE Agent has found one or more candidate pairs for each
>>     MediaStreamTrack that forms a valid connection, the ICE connection
>>     state is changed to "connected".
>>
>>  3.
>>
>>     When the ICE Agent finishes checking all candidate pairs, if at
>>     least one connection has been found for each MediaStreamTrack, the
>>     iceConnectionStateis changed to "completed"; else the
>>     iceConnectionState is changed to "failed".
>
> They are the same. (And should be formatted the same.)

For some reason we handle the PeerConnection states (signaling, 
gathering and ice connection) differently than, for example, the 
DataChannel readyState where we reference the readyState attribute 
directly. With the PeerConnection states we talk about an "ice 
connection state" that changes value, and the iceConnectionState 
attribute then returns this value. It would be more consistent (with 
other specs) to reference the attribute values directly for the 
PeerConnection states as well.

/Adam

Received on Tuesday, 17 June 2014 07:46:42 UTC