Chrome browser DTLS fails after 15 seconds in long delay connections.

boks1971 commented 2 years ago

Your environment.

Version: v3.1.15
Browser: Version 97.0.4692.71 (Official Build) (arm64)
Other Information
- Happens when answering DTLSRole is webrtc.DTLSRoleClient (which is the default). When setting answering DTLSRole to webrtc.DTLSRoleServer via settings engine does not show the problem.
- Does not happen in Firefox 96.0.1 (64-bit)
- Does not happen in Safari Version 15.2 (17612.3.6.1.6)

What did you do?

Use Network Link Conditioner (NLC) in Mac OS (Monterey - version 12.1) to simulate long delay network.
Set both upstream and downstream delay of 1000 ms in NLC (this was reproducible even with 500 ms delay).
Use a Chrome client with just publishing audio (I used a slightly modified version of LiveKit JS SDK sample app).

What did you expect?

Stable streaming under long latency.

What happened?

After 15 seconds, Chrome gets an SSL_Read error and the peer connection state moves to failed.

Starting Chrome in debug logging mode, can see the following

[7163:83971:0117/101539.611376:WARNING:openssl_stream_adapter.cc(961)] OpenSSLStreamAdapter::Error(SSL_read, 1, 0
[7163:83971:0117/101539.611533:INFO:dtls_transport.cc(683)] DtlsTransport[0|1|_W]: Closed by remote with DTLS transport error, code=1
[7163:83971:0117/101539.611569:VERBOSE1:dtls_transport.cc(789)] DtlsTransport[0|1|_W]: set_writable to: 0
[7163:83971:0117/101539.611592:INFO:jsep_transport_controller.cc(1149)]  Transport 0 writability changed to 0
[7163:83971:0117/101539.611636:VERBOSE1:dtls_transport.cc(805)] DtlsTransport[0|1|__]: set_dtls_state from:2 to 4
[7163:83971:0117/101539.611693:INFO:channel.cc(563)] Channel not writable ({mid: 0, media_type: audio}
[7163:83971:0117/101539.611715:INFO:srtp_transport.cc(360)] The params in SRTP transport are reset.
[7163:47363:0117/101539.611900:INFO:peer_connection.cc(1814)] Changing IceConnectionState 3 => 5
[7163:47363:0117/101539.611926:INFO:peer_connection.cc(1833)] Changing standardized IceConnectionState 3 => 2
[7163:259:0117/101539.613295:ERROR:rtc_data_channel.cc(630)] DataChannel error: "Transport channel closed", code: 65535
[7163:259:0117/101539.613971:ERROR:rtc_data_channel.cc(630)] DataChannel error: "Transport channel closed", code: 65535

When this happens, audio from client stops. But, the STUN pings continue to happen and Pion is replying to those binding requests. ICEConnectionState on Chrome side does not go to failed.

Sean-Der commented 2 years ago

@boks1971 Are you changing this after the initial handshake? When you say audio from client stops were you publishing audio successfully?

Does this happen Chrome <-> Chrome? Try manually changing the setup: value before calling SetLocalDescription for the answering PeerConnection. I can help pull a jsfiddle together also if you don't have the time.

Would be great to compare behavior and maybe report upstream!

boks1971 commented 2 years ago

@Sean-Der . No, not changing it after initial handshake. I had it at Pion default which is DTLSRoleClient for answerer.

Yes, the audio was being published normally for 15 seconds and then it stops.

I have not tried Chrome <-> Chrome. I do not have a good set up for that.

Will try to spend more time on this later this week.

pion / webrtc