W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

Re: Fwd: [rtcweb] Updated WG Last call for draft-ietf-rtcweb-stun-consent-freshness

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 20 Jun 2015 23:13:59 +1000
Message-ID: <CAHp8n2nru4DpO_8h-PA-wJmDtVZg3bnAQK=P0_XsGv_z-2Qk=w@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc <public-webrtc@w3.org>
On Sat, Jun 20, 2015 at 7:36 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 06/20/2015 02:56 AM, Silvia Pfeiffer wrote:
>>
>> Forwarding this from the IETF, because I am unclear what effect a ICE
>> update has on a Web application.
>>
>> Would the UA take care of ICE updates or would that get exposed on the
>> API level?
>> Would the RTCPeerConnection be pulled down when consent expires and
>> need to be re-established?
>
> Loss of consent on a track would lead to the PeerConnection's ICE state
> changing from "completed" to "disconnected". The description of the
> "disconnected" state says:
>
> "Liveness checks have failed for one or more components. This is more
> aggressive than failed, and may trigger intermittently (and resolve itself
> without action) on a flaky network."
>
> So the connection is NOT torn down - there's no promise that it won't start
> working again.
>
> One CAN do a new offer/answer to trigger an ICE restart in this case.
> Whether it helps or not depends, of course, on the cause of the disconnect.
>
>   pc.oniceconnectionstatechange = function() {
>      if (pc.iceConnectionState === 'disconnected') {
>         iAmInTrouble = true;
>         // See if it heals, then ICE restart
>         setTimeout(function() {
>              if (pc.iceConnectionState === 'disconnected' and iAmInTrouble)
> {
>              createOffer({iceRestart = true});
>              // negotiate - this won't affect existing tracks' state
>           }, 1000)
>      } else if (pc.iceConnectionState === 'connected') {
>          iAmInTrouble = false;
>      }
>   }
>
> Or something like that.... adjust timeouts to personal taste, add logic to
> deal with multiple connected/disconnected transitions within the timeout
> interval, abandon hope instead of renegotiating, collect statistics on how
> often things happen.... I think we need to let experience be gathered here.
>

Thanks, that was really helpful. It seems a bit complicated, but we'll
experiment with it.

Cheers,
Silvia.
Received on Saturday, 20 June 2015 13:14:47 UTC

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