Re: Which stream/transport does PC.oniceconnectionstatechange points to?

The relevant part of the spec is section 4.4.3, "RTCIceConnectionState 
Enum".


On 10/15/2014 12:44 PM, Iñaki Baz Castillo wrote:
> Usecase:
>
> PeerConnection in peer-A establishing two separate ICE/DTLS transports
> (audio and video) with peer-B (which supports rtcp-mux but does not
> support Bundle).
>
>
> - ICE procedures begin in peer-A.
>
> - At some point the ICE is completed in the audio transport.
>
> Q: Should PC fire oniceconnectionstatechange(connected)?

No. From the spec: "connected - The ICE Agent has found a usable 
connection FOR ALL COMPONENTS".
>
> - For some reason ICE is still not connected in the video transport.
>
> Q: Should PC later fire oniceconnectionstatechange(completed) due the
> ICE status in the audio transport?

No. As above it is only fired when it has found a connection FOR ALL 
COMPONETNS.
>
> - Later timeout or any other error happens in the video transport so
> its ICE procedures end with error.
>
> Q. Should P fire oniceconnectionstatechange(failed) or
> oniceconnectionstatechange(disconnected)?

See the description for "failed".
>
>
> I hope my questions are clear: Basically I mean that PeerConnection
> provides a "single and unique ICE status" while the fact it can deal
> with more than a single ICE transport.
>
I believe the descriptions are clear.

If we ever add transport objects to the spec (not in version 1.0!), we 
should expect to see events fired related to single connections, but in 
version 1.0, the RTCIceConnectionState refers to the aggregate state, 
not the state of individual transports.

Received on Wednesday, 15 October 2014 11:26:27 UTC