W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2017

Re: Why is iceRestart just available in RTCOfferOptions?

From: Roman Shpount <roman@telurix.com>
Date: Mon, 27 Mar 2017 13:00:37 -0400
Message-ID: <CAD5OKxs8C4Eiyh=KdHVo52QyPf-a67d9Tfd4_pNe7g-V-Meb+A@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Mon, Mar 27, 2017 at 7:05 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2017-03-27 12:11 GMT+02:00 Iñaki Baz Castillo <ibc@aliax.net>:
> > I can't figure out any good rationale to not allow iceRestart in
> > createAnswer() (other than common/existing current usages).
>
> Well, indeed it seems that RFC 5245 states that "ICE restart" is just
> indicated within a new offer. Yet another WebRTC artificial constrain
> due the SDP O/A usage.
>
>
This is actually ICE design constraint. When ICE restart is initiated both
end points need to collect new set of candidates. When offer was sent after
ICE nomination was completed it already includes only the nominated
candidate, so ICE restart cannot be initiated from the answer. In order to
enable ICE restart initiated from an answer,. 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.

Regards,
_____________
Roman Shpount
Received on Monday, 27 March 2017 17:01:12 UTC

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