- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Sat, 14 Feb 2015 23:05:42 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
- CC: "robin.raymond@hookflash.com" <robin.raymond@hookflash.com>
Robin said: "Solutions: (a) Before a full "disconnect" of an IceTransport, start testing still viable back-up candidates mutually. This would allow 3G/4G IPv6 failover to have a reasonable chance of success without a full restart (and a faster response time before full disconnect where the application layer needs to be involved). (b) When interfaces come back-up (e.g. Wifi becomes available), temporarily re-gather the reflexive and TURN candidates if those candidates would have higher priority than other candidates active within any of the attached IceTransports. (c) Do nothing and expect "restart" to solve this issue." [BA] From an API perspective, would Option (a) be a use case for calling iceTransport.start() again with a previously used iceGatherer? Option (b) seems like it would involve continuous nomination (e.g. iceTransport.state is never "completed"). Some of the required protocol changes are discussed here: https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit#heading=h.qf9e6tbxwkrn
Received on Saturday, 14 February 2015 23:06:13 UTC