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 17:03:55 -0400
Message-ID: <CAD5OKxsuNeGjQY0PBY6nqbOiVCVipi9Ve9JVfUxm7Ny6z3XCpw@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 4:53 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> > 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".
>

Yes, ICE is designed with offer/answer in mind. If it were designed for a
more flexible signaling scheme it could have been designed differently. All
I am saying that now, in order to support such more flexible scheme ICE
would have to be redesigned. This makes it different from things like codec
negotiation, which can be used with non offer-answer designs without major
changes.

Regards,
_____________
Roman Shpount
Received on Monday, 27 March 2017 21:04:29 UTC

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