Re: Why is iceRestart just available in RTCOfferOptions?

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