@Antonito This is absolutely amazing work, your PRs are the best I have seen in months. Gives me the energy to get back into it :)

I think we could make the test a lot simpler.

• Create two PeerConnections and connect them.
• Send one RTP packet
• Create a new PeerConnection and generate an offer, and send it to one of the PeerConnections in the first flow.
• Send one RTP packet

I think that gets us the coverage we need and keeps the LoC low still? Push back if I am wrong!

@Antonito This is absolutely amazing work, your PRs are the best I have seen in months. Gives me the energy to get back into it :)

I think we could make the test a lot simpler.

• Create two PeerConnections and connect them.
• Send one RTP packet
• Create a new PeerConnection and generate an offer, and send it to one of the PeerConnections in the first flow.
• Send one RTP packet

I think that gets us the coverage we need and keeps the LoC low still? Push back if I am wrong!

So, I tried to rewrite the unit test in a simpler way, and it uncovered several problems. I'm not sure if there are caused by the DTLS restart or were already there (I'm thinking the later, for most of them).

• Sending a single RTP packet doesn't trigger an OnTrack event on the other peer. Sending two in a row doesn't either, but sending 1 / waiting a few ms / sendign another one works.
• When ran multiple times in a row, the test sometimes logs pc ERROR: 2021年06月28日 13:30:33 Incoming unhandled RTP ssrc(1595441956), OnTrack will not be fired. single media section has an explicit SSRC. I initially thought this was a difference in behavior with the test I already pushed (since with your method, the first peer connection doesn't go to disconnected or failed before the other one connects), but turns out it's also happening with this one – I just had lucky runs. It doesn't seem to be a race condition, tsan didn't detect anything.
• I found out weird behaviors with DataChannels
  • I added a call to CreateDataChannel, behavior unchanged (as expected)
  • I then set an empty OnDataChannel callback -> this causes the test to sometimes hang (again I'm not doing anything more with DataChannels here)
  • I then tried to send data from ClientB and read with ClientA1 and ClientA2, sometime it hangs, but when it doesn't:
    • As expected, ClientA1 can read
    • After ClientA2 connects, ClientB tries to send data – which causes a io: read/write on closed pipe error log
    • ClientA2 can't read, since ClientB can't send anything (this is most likely an issue with DTLS restart)

I rewrote the unit test without pion/transport, and split it in two very similar tests, for debugging purpose:

• TestPeerConnection_DTLS_Restart_MediaOnly
• TestPeerConnection_DTLS_Restart_MediaAndDataChannel

Before merging, we should only keep TestPeerConnection_DTLS_Restart_MediaAndDataChannel.

SCTP restart is now implemented and DataChannels are re-opened, if needed.

There seems to be some kind of race condition, but I really don't think it's related to the stuff this PR modifies – I think the unit tests just show an already existing problem.
It's what I was describing above, and now have a bit more validation of what's really happening.

The TestPeerConnection_DTLS_Restart_MediaOnly behaves correctly, in go test. To make it work with tsan, I had to add an extra:

I think this is a consequence of the first point I was developing in my previous message (about RTP packets).

TestPeerConnection_DTLS_Restart_MediaAndDataChannel behaves correctly with go test, but hangs with tsan. I also tried to add a few extra RTP packets, but it doesn't change any thing. Somehow, the hang seems to be caused by the simple fact of calling CreateDataChannel and OnDataChannel.