RE: Issue 115: Restart method needed for the ICE Listener?

The full text from RFC 5245 Section 9.1.1.1 is:

   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.

[BA] Would it be useful to work through an example, such as changing the target of the media stream (e.g. interface switch)?  

In general, I agree that you can't just call restart() on the ICE Transport and assume that all objects utilizing it (e.g. DTLS transport object, sender/receiver objects) will not be affected. 
________________________________________


>From Robin Raymond:

https://tools.ietf.org/html/rfc5245#section-9.1.1.1

http://tools.ietf.org/html/draft-petithuguenin-mmusic-ice-sip-sdp-01#section-9.1.1

Important info about restarts...

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.

ICE restarts aren't just changing ufrag/password for ICE. Nor it is just flushing the candidate checks. Because it's redirecting to a new target, this implies that a restart needs to perform a full DTLS exchange to the new target after establishing connectivity.

This you can't just have a "restart" method on the Ice listener. You actually need to have brand new IceListeners, IceTransports and DTLS transport objects. Seems to me the simpler thing is to do nothing and let those who need to perform this kind of restart stop existing objects, create brand new objects, and insert the object into the list at the right spot for the ice transport controller.

Received on Tuesday, 1 July 2014 21:25:58 UTC