Re: Restarting ICE

It seems that we don't have a controversy here.
Conclusions:

- Name of constraint is "IceRestart"
- Constraint can only be applied to CreateOffer

Adam, can you get that into the spec for the next release?

On 04/04/2013 09:06 PM, Justin Uberti wrote:
>
>
>
> On Wed, Apr 3, 2013 at 11:09 PM, Adam Bergkvist 
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     On 2013-04-04 07:13, Harald Alvestrand wrote:
>
>         On 04/04/2013 01:23 AM, Justin Uberti wrote:
>
>             Nitpick: I propose it be called "IceRestart", for
>             consistency with the
>             existing "IceTransports".
>
>
>         Works for me. It's also consistent with the pattern that
>         constraints are
>         nouns, not verbs.
>
>
>     I think this is pretty uncontroversial, since it was a while since
>     we decided to do ice restart via "new
>     credentials"/setLocalDescription(), and the spec incomplete on
>     this matter at the moment.
>
>     Detail to pin down: is this constraint valid for both
>     createOffer() and createAnswer()?
>
>
> I don't think it needs to be (or should be) specified to createAnswer. 
> If you receive an offer with changed ICE credentials, you MUST 
> generate changed ICE credentials in the answer 
> (http://tools.ietf.org/html/rfc5245#section-9.2.1.1).
>
>
>     Thought: ICE restart is obviously a consequence of setting a
>     description with new ICE credentials, but is that the only reason
>     why you would have new credentials? I mean, should the constraint
>     actually be called something like "GenerateNewIceCredentials" and
>     ICE restart is only a consequence of setting the new description?
>
>
> Yes. Also from 9.2.1.1 <http://9.2.1.1>:
>
>     If the offer contained a change in the a=ice-ufrag or a=ice-pwd
>     attributes compared to the previous SDP from the peer, it indicates
>     that ICE is restarting for this media stream.
>