[MMUSIC] draft-ietf-mmusic-rtsp-nat: ICE restart fails, then what?

[Magnus Westerlund <[e-mail]>]

WG,

I received a comment in the doc shepherd preparation from Flemming. I
need some feedback on this.

This is in regards to ICE restart.

One initiate an ICE restart when having an existing promoted and
used candidate pair. So RFC 5245 is clear that you continue to use the
candidate pair while restarting, but it is not clear that you will
continue to use it if an ICE restart fails.

My intuition would be to keep on using the candidate pair if it still
works. But, if one looks at 8.1.2 and applies that to a restart the
result is different. I mean the following text:

   o  If the state of the check list is Failed, ICE has not been able to
      complete for this media stream.  The correct behavior depends on
      the state of the check lists for other media streams:

      *  If all check lists are Failed, ICE processing overall is
         considered to be in the Failed state, and the agent SHOULD
         consider the session a failure, SHOULD NOT restart ICE, and the
         controlling agent SHOULD terminate the entire session.

Thus, one should terminate the session. I think there is possibility
that there should be a bit more room for attempting rectifying actions.

Thus my current proposal for Section 6.12 of draft-ietf-mmmusic-rtsp-nat
is the following:

   If the RTSP session is in playing state at the time of sending the
   SETUP request requiring ICE restart, then the ICE connectivity checks
   SHALL use Regular nomination.  Any ongoing media delivery continues
   on the previously nominated candidate pairs until the new pairs have
   been nominated for the individual candidate.  Once the nomination of
   the new candidate pair has completed, all unused candidates may be
   released.  If the ICE processing fails and no new candidate pairs are
   promoted for use, then one MAY continue to use the previously
   nominated candidate pairs while they still function.  If they have
   appear to fail to transport media packets anymore then the client can
   select between two actions.  First, if it has any actions available
   that might make ICE work, like trying another STUN/TURN server or
   change the transport parameters it modifies the session, and if ICE
   is still to be used restart ICE.  If the client is unable to modify
   the ICE parameters, it MUST NOT restart the ICE processing, and
   SHOULD terminate the RTSP session.


Have I missed anything about this interaction with ICE?

Any issues with what I propose?

Thanks

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------