Reproduced in Chromebook too (after 5 times restarting ICE, the button gets disabled and can't do it any more).

Chromebook Daisy, 10323.21.0 / 65.0.3325.56

hbos@: Can you take a look?

I don't know if this is relevant to this issue, but I also see problems with createOffer(..., {iceRestart: true})

With a STUN-only config, initial connect and ice-restart work fine.

With a TURN config and iceTransportPolicy = 'relay', initial connect is ok, but ice-restarts from peer 1 do not succeed when peer 2 is restarted.

+deadbeef, hta: Do you know anything about this?

re #7: Does this concern a test case where both ends are restarted at the same time, or is it one restart, then another restart?

I don't know if we test ICE restart collision very well.

I think this is just an issue with the sample page. It enables the "Restart ICE" button when the state transitions from "completed" to "connected". But if you click the button quickly enough, you can trigger a restart while still in the "connected" state (from the last restart), and thus that transition won't occur.

Here's an issue filed against the webrtc/samples repository: https://github.com/webrtc/samples/issues/1036

Hi again,
Maybe I should open another issue for this?
I will first explain my findings before trying to come up with a test case to reproduce this.
Background:
A = client (regular chrome on ubuntu 16.04.3 LTS)
B = client (electron 1.7.13/ chromium on RPI3)
A and B both tested on same and different networks.

Issue:
A connects to B using signaling server + TURN (ok)
A opens datachannel, B gets ondatachannel event (ok)
---- At this point, the connection works for multiple hours ----
B is restarted, so back to initial internal state.
A fires 'oniceconnectionstatechange disconnected' (ok)
A fires 'oniceconnectionstatechange failed' (ok)
A does createOffer({iceRestart: true}) (manually)
B gets offer (with datachannel & generation 1) (ok)
B does not fire ondatachannel (not sure why? Is this due to the 'reboot' of B?)

now here is the confusing part:
A fires 'oniceconnectionstatechange connected' (ok)
A has rtcDataChannel.readyState == 'open' (?? B did not fire ondatachannel)

of course at this point, communication over rtcDataChannel does not work, but rtcDataChannel.send() does not raise any errors.

Before I dig further: is the iceRestart sequence allowed and correct, either during 'disconnected' or 'failed'?
Thanks!

When you say "B is restarted", do you mean an ICE restart, or a whole new PeerConnection? If it's the latter, then I think the SCTP association would need to be re-established, and a new data channel would need to be created. "ondatachannel" doesn't fire for B because A doesn't send another "open" message, because it was already sent successfully, and as far as A knows, it's talking to the same endpoint as before which still knows about the data channel.

In theory, you could establish a new SCTP association by changing the "a=sctp-port", but that's not implemented: https://cs.chromium.org/chromium/src/third_party/webrtc/media/sctp/sctptransport.cc?l=449&rcl=8058fbbd6bc09dd64b87a479d4028a0d8a2fed5b

So, I think the only workaround available right now would be modifying the SDP to reject the SCTP m= section (using a port of 0 on the m= line; "m=application 0"), then doing another offer/answer to re-negotiate it.

B is restarted = new PeerConnection(), as in a page refresh indeed.

However, there is no straightforward way for the user of the rtcDataChannel at 'A' that this has ever happened:
1. The ICE happily reconnects at A and B.
2. B ignores the 'old dataChannel' request and A keeps sending over the dataChannel, no errors. I think this should be reflected in the readyState.

I'll check if the 'old dataChannel' reconnects in case of a temporary network loss, and come back with the results here.

At this moment, I let 'A' create a 'new PeerConnection()' at any disconnect and this works fine, but ICE restarts are faster...