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: Harald Alvestrand <harald@alvestrand.no>
Date: Sat, 20 Jun 2015 11:36:03 +0200
Message-ID: <55853403.90603@alvestrand.no>
To: public-webrtc@w3.org
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.

> How can we deal with ICE updates without killing an existing video connection?
> Thanks,
> Silvia.
> ---------- Forwarded message ----------
> From: Ted Hardie <ted.ietf@gmail.com>
> Date: Mon, Jun 15, 2015 at 9:07 AM
> Subject: [rtcweb] Updated WG Last call for
> draft-ietf-rtcweb-stun-consent-freshness
> To: "rtcweb@ietf.org" <rtcweb@ietf.org>, Alissa Cooper
> <alissa@cooperw.in>, Cullen Jennings <fluffy@cisco.com>, Sean Turner
> <turners@ieca.com>
> The -14 of this draft is out now, with updates related to several of
> the external reviews.  Please re-review the document by June 29, 2015
> and provide comments.  Below is a link for your convenience,
> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/
> regards,
> Ted, Cullen, Sean
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
Received on Saturday, 20 June 2015 09:36:35 UTC

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