No procedure for the ICE failed state

[lgrahl]

Do we need a procedure for the ICE failed state?

It should at least trigger closing all data channels abruptly (similar to RTCPeerConnection.close). I'm pretty sure there's also something to be done for media tracks. What can survive an ICE restart before we dive into discussing a procedure?

• Could a data channel survive an ICE restart? From my perspective: Yes, if the SCTP association does not time out. So, data channels can be left open until the SCTP association is dead (or the user closes the channel or the peer connection). But there is no guarantee that the SCTP association will survive.
• Can a media track survive an ICE restart? I'm guessing yes?

If it turns out that we don't need to do anything in case we move into the failed state, should we at least mention that the failed state is recoverable and all associated data transports and media may survive it but it depends on the individual transport?

[fippo]

failed is recoverable by an ICE restart, closing data channels or stopping media seems wrong

[lgrahl]

@fippo Agree. Edited my initial posting as there are some open questions.

We also may want to add tests for that case. At least for data channels, I don't remember having seen any for the failed state.

[lgrahl]

Bumping this one. At least for data channels, it's currently undefined whether or not the SCTP association is supposed to survive which makes ICE restarts unreliable for data channel applications.

[aboba]

An SCTP association (or a TCP or QUIC connection, for that matter) should not terminate immediately when ICE enters the "failed" state, since an ICE restart could restore the ICE virtual connection. By default, retransmission timers will fire and the RTO estimate will increase until potentially the association limits will be reached. When ICE enters the "connected" state again, if the selected pair changes, an implementation might want to reset the RTT estimate, but that is a potential implementation decision.

[lgrahl]

To not ABORT due to ICE failed is logical (although not well-defined). But the question is what happens when ICE recovers but the SCTP association already failed.

[aboba]

If the SCTP association fails, then RTCSctpTransport.state will transition to closed and a statechange event will be fired. I would also expect a close event to fire on the RTCDataChannel. If the ICE restart subsequently succeeds, then it would be necessary to establish another SCTP association and bring up another data channel.

Would calling pc.createDataChannel() cause that to happen?

[lgrahl]

JSEP sec 5.11:

  *  If no valid SCTP association exists, prepare to initiate a SCTP
     association over the associated ICE component and DTLS
     connection, using the local SCTP port value from the local
     description, and the remote SCTP port value from the remote
     description, as described in [I-D.ietf-mmusic-sctp-sdp],
     Section 10.2.

Not sure the terminology applies 100% but I'm somewhat certain we can interpret the case that the SCTP association closed as no SCTP association exists.

Since all data channels are closed, I assume the application would have to create at least one new data channel because otherwise SCTP would not be negotiated for the ICE restart. So, yes, I think your assumption is correct.

But this brings us back to the original topic. I think we should clarify these things in an ICE failed procedure. This would define what should happen in such a case and thus automatically clarifies what should not happen (e.g. abort the SCTP association or close any data channels).

[juberti]

I don't think anything should happen automatically in an ICE failed situation. The app can stop things if it wants to, but given that an ICE restart might bring things back to life, we shouldn't do anything automatically.

[aboba]

@juberti Agreed.

@lgrahl Have you seen implementations that do things automatically (like closing SCTP associations) when ICE fails? This is really more of a protocol implementation issue, but just trying to understand whether this is an interop issue.

[lgrahl]

Have you seen implementations that do things automatically (like closing SCTP associations) when ICE fails?

Haven't seen any browser that closes in case of ICE failed but I haven't tested whether anyone (re)starts the SCTP association. So, perhaps this is not an issue at all. I believe a clarification in the form of "ICE moving into the failed state does not affect any of the upper layer transports" would be helpful since I can't imagine being the only person wondering.

[fippo]

for media: do we need something in jsep or rtp-usage saying there are no timeouts such as the ones described in https://tools.ietf.org/html/rfc3550#section-6.3.5?