- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 27 Mar 2017 22:53:18 +0200
- To: Roman Shpount <roman@telurix.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
2017-03-27 22:44 GMT+02:00 Roman Shpount <roman@telurix.com>: > I mean after ICE nomination completes, end points release unused candidates > and keep only the single candidate which was nominated. If an offer is sent > after the end of ICE nomination, it contains only a single a=candidate line. > When ICE is restarted, the candidates are collected again. When answerer > receives the offer it will be missing the candidates needed for ICE restart > since offering side did not collect them. Thanks understood. Now imagine that the offerer is a ICE-Lite server which just adds its local host candidates into the offer and re-offer. The answerer (a browser) would have no problem in performing a ICE restart within pc.createAnswer(). And ICE-Lite does exist, even in RFC 5245. Anyhow, yes, even the ICE-Lite endpoint may release unused host candidates before sending a re-offer so the browser wouldn't have all the options to perform ICE restart. But: > it would be required to notify the offerer that new set of ICE candidates should be collected and provide a way to send it back to the answerer. This will require a major ICE redesign which will go beyond just offer/answer. Well, that's the problem of relying on SDP O/A for *everything*, and this is clearly influenced by the SIP protocol. This kind of limitations should not apply in WebRTC land. There are over 1000 ways to tell the endpoint "please, collect candidates and offer them to me". Thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Monday, 27 March 2017 20:54:12 UTC