W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: New spec: Restarting ICE

From: Justin Uberti <juberti@google.com>
Date: Sun, 10 Jun 2012 19:02:08 -0400
Message-ID: <CAOJ7v-1NrwtaA++oS4nZU9p_UWVn0VWje6fs4g=r_oY3Q_usNQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
On Sun, Jun 10, 2012 at 6:16 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 06/10/2012 04:20 PM, Cullen Jennings wrote:
>> I think we need to look at how constrains get merged form one call to the
>> next. If the browser remembers any previous constrains in the
>> peerConnectionObject, this might mean the next call that passes in
>> constraints needs to remember set { "restarts":false } to clear the
>> previous value.
>> I suspect something like this could be made to work but a few more
>> details are needed on constraints.
> Is there such a concept as "next call" in a PeerConnection?
> With "serial forking" by using PRANSWER, I take it we can have a
> PeerConnection pointing at multiple endpoints, but I have been making the
> assumption that once you enter the "closed" state, there is no way back.
> If you want to remember constraints on a next call, just create a new
> PeerConnection object and apply the constraints you want to it.

I also don't see why a set of constraints passed to createOffer (where this
ICE restart constraint would be applied) would have any lifetime other than
the specific createOffer call.
Received on Sunday, 10 June 2012 23:02:57 UTC

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