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

Re: What should happen to the ICE gathering state when iceTransports is changed?

From: Justin Uberti <juberti@google.com>
Date: Tue, 15 Jul 2014 10:04:08 -0700
Message-ID: <CAOJ7v-2jC9NXKnGRKzj2Z=uzi0EPVx44YeT4Sr-utu7yXiAi5A@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Right, I think that is the only sane result.

More generally, I wonder if iceTransports changes should always take effect
on the next ICE restart, meaning that even changes of relay->all during
gathering would have no effect until ICE restart occurs. One mode of
operation = less chance for apps to get it wrong.


On Mon, Jul 14, 2014 at 11:39 AM, Bernard Aboba <Bernard.Aboba@microsoft.com
> wrote:

> Link: http://lists.w3.org/Archives/Public/public-webrtc/2014Jun/0029.html
>
> Out of curiosity, what should happen if a more restrictive gathering
> policy is put in place before gathering is complete?
>
> The flow goes something like:
> - new PC({iceTransports: 'all'})
> - setRD(offer)
> - createAnswer
> - setLD(answer)
> - onicegatheringstatechange(gathering)
> - onicecandidate(relay1)
> - onicecandidate(relay2)
> - Possibility A: setConfiguration({iceTransports: 'relay'})
> - onicecandidate(null)
> - onicegatheringstatechange(complete)
> - Possbility B: setConfiguration({iceTransports: 'relay'})
>
>
> Personally, I like Option 3 for this as well (e.g. don't implement the new
> policy before the next ICE restart).
>
Received on Tuesday, 15 July 2014 17:04:56 UTC

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