Subject: [MMUSIC] ICE restart in RFC 5245bis and ICE SIP/SDP usage draft

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Jul 2014 14:47:20 -0700

RFC 5245 Section 9.1.1.1 (see below) deals with ICE restarts.

In checking for revisions of this material in draft-ietf-mmusic-rfc5245bis
and draft-ietf-mmusic-ice-sip-sdp, I noticed that material on
ICE restart was included in the ICE SIP/SDP usage draft, but not
in RFC 5245bis.

This seems a bit odd to me, because not all of the material in
Section 9.1.1.1 of the ICE SIP/SDP usage draft is dependent on SIP.
For an implementer of WebRTC (where signaling is out of scope), this
might raise questions about the applicability of some of the paragraphs.
For example, by including this material only in the SIP/SDP usage
draft, are we saying that the requirement that the agent change
the ice-pwd and ice-ufrag to restart ICE only applies to SIP?

================ RFC 5245 Section 9.1.1.1 ============

9.1.1.1.  ICE Restarts

   An agent MAY restart ICE processing for an existing media stream.  An
   ICE restart, as the name implies, will cause all previous states of
   ICE processing to be flushed and checks to start anew.  The only
   difference between an ICE restart and a brand new media session is
   that, during the restart, media can continue to be sent to the
   previously validated pair.

   An agent MUST restart ICE for a media stream if:

   o  The offer is being generated for the purposes of changing the
      target of the media stream.  In other words, if an agent wants to
      generate an updated offer that, had ICE not been in use, would
      result in a new value for the destination of a media component.

   o  An agent is changing its implementation level.  This typically
      only happens in third party call control use cases, where the
      entity performing the signaling is not the entity receiving the
      media, and it has changed the target of media mid-session to
      another entity that has a different ICE implementation.

   These rules imply that setting the IP address in the c line to
   0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
   MUST NOT utilize this mechanism for call hold, and instead MUST use
   a=inactive and a=sendonly as described in [RFC3264].

   To restart ICE, an agent MUST change both the ice-pwd and the ice-
   ufrag for the media stream in an offer.  Note that it is permissible
   to use a session-level attribute in one offer, but to provide the
   same ice-pwd or ice-ufrag as a media-level attribute in a subsequent
   offer.  This is not a change in password, just a change in its
   representation, and does not cause an ICE restart.

   An agent sets the rest of the fields in the SDP for this media stream
   as it would in an initial offer of this media stream (see
   Section 4.3).  Consequently, the set of candidates MAY include some,
   none, or all of the previous candidates for that stream and MAY
   include a totally new set of candidates gathered as described in
   Section 4.1.1.

---

From: Ari Keränen <[email-masked]>
Date: Tue, 15 Jul 2014 22:08:00 +0000

Hi Bernard,

> the ice-pwd and ice-ufrag to restart ICE only applies to SIP?

Good catch. It was not the intention to remove this kind of details from the ICE spec with the split. Will need to have a closer look on which parts should go to which spec. Regarding this section, I think the change of ice-pwd and -ufrag applies to other protocols too and should be mentioned in the main spec. Anything else in particular to consider?

Cheers,
Ari

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 16 Jul 2014 00:52:56 +0200

2014-07-16 0:08 GMT+02:00 Ari Keränen <[email-masked]>:
> I think the change of ice-pwd and -ufrag applies to other protocols

Why should the ufrag and pwd change upon ICE restart? I mean: is there
a real reason for that?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 16:04:44 -0700

> Why should the ufrag and pwd change upon ICE restart? I mean: is there

Yes, it's a signal to a peer that a restart is happening.  Ostensibly,
it's actually unnecessary, but as a practical matter, you gotta do it.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Jul 2014 16:42:41 -0700

Ari said: 
"Anything else in particular to consider?"
[BA] Does the MUST restart guidance apply more generally?  For example, whether a restart is always required when changing the target of the media stream or the implementation level.   Also, the guidance on the set of candidates (some, none or all of  the previous candidates or a new set) doesn't seem specific to SIP.

---

From: Ari Keränen <[email-masked]>
Date: Thu, 17 Jul 2014 21:38:04 +0300

On 16/07/14 02:42, Bernard Aboba wrote:
> [BA] Does the MUST restart guidance apply more generally?  For example,
> whether a restart is always required when changing the target of the
> media stream or the implementation level.   Also, the guidance on the
> set of candidates (some, none or all of the previous candidates or a new
> set) doesn't seem specific to SIP.

Regarding the media stream target and "implementation level", since 
these may not even apply to many non-SIP protocols, I would say that it 
should not be in the main spec. However, probably we should state here 
that the protocol using ICE needs to define when/if a restart is really 
required.

If you want to proxy your protocol to a SIP environment, doing the same 
thing that SIP does regarding restarts is probably a MUST.

The candidate guidance (last sentence of section 9.1.1.1 in RFC5245) 
seems to me generic enough to stay here as such.

Sounds like a good way forward?

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Thu, 17 Jul 2014 21:40:37 +0300

> it's actually unnecessary, but as a practical matter, you gotta do it.

I think it makes sense to keep this behavior (for better 
interoperability with SIP environments, backward compatibility, etc.) 
unless there is a good reason not to do it.

Cheers,
Ari