W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2014

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 15 Oct 2014 13:25:51 +0200
Message-ID: <543E59BF.1050501@alvestrand.no>
To: public-webrtc@w3.org
The relevant part of the spec is section 4.4.3, "RTCIceConnectionState 

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 
> - 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 
> - 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC