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.4.0 : Friday, 17 January 2020 19:17:59 UTC