search

w3c / ortc

ORTC Community Group specification repository (see W3C WebRTC for official standards track)
http://www.w3.org/community/ortc/
122 stars 42 forks source link

Restart method needed for the ICE Listener? #115

Closed aboba closed 10 years ago

aboba commented 10 years ago

At the ORTC CG meeting, the question was asked whether a restart method was needed for the ICE listener or not.

robin-raymond commented 10 years ago

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

robin-raymond commented 10 years ago 
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.
robin-raymond commented 10 years ago

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.

robin-raymond commented 10 years ago

$related https://github.com/openpeer/ortc/issues/93

aboba commented 10 years ago

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.

aboba commented 10 years ago

I believe that the resolution is to move restart() to the RTCIceTransportController, no?

aboba commented 10 years ago

I think we have convinced ourselves that we don't need (and can't use) a restart() method anywhere.