-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chrome browser DTLS fails after 15 seconds in long delay connections. #2089
Comments
@boks1971 Are you changing this after the initial handshake? When you say Does this happen Would be great to compare behavior and maybe report upstream! |
@Sean-Der . No, not changing it after initial handshake. I had it at Pion default which is 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. |
Fixes pion/webrtc#2089 When a retranmission from the remote side arrives after the handshake is complete, the `finish` routine puts it back into retransmit loop. With Chrome, this fails after 15 seconds. Firefox does not error out though.
Fixes pion/webrtc#2089 When a retranmission from the remote side arrives after the handshake is complete, the `finish` routine puts it back into retransmit loop. With Chrome, this fails after 15 seconds. Firefox does not error out though.
Fixes pion/webrtc#2089 When a retranmission from the remote side arrives after the handshake is complete, the `finish` routine puts it back into retransmit loop. With Chrome, this fails after 15 seconds. Firefox does not error out though.
Fixes pion/webrtc#2089 When a retranmission from the remote side arrives after the handshake is complete, the `finish` routine puts it back into retransmit loop. With Chrome, this fails after 15 seconds. Firefox does not error out though. Testing: --------- - Tested with Firefox and Chrome with long delay (500 ms up and down) in network link conditioner. - Tested the above with no introduced delays too. - Added test for slow server.
Fixes pion/webrtc#2089 When a retranmission from the remote side arrives after the handshake is complete, the `finish` routine puts it back into retransmit loop. With Chrome, this fails after 15 seconds. Firefox does not error out though. Testing: --------- - Tested with Firefox and Chrome with long delay (500 ms up and down) in network link conditioner. - Tested the above with no introduced delays too. - Added test for slow server.
Fixes pion/webrtc#2089 When a retranmission from the remote side arrives after the handshake is complete, the `finish` routine puts it back into retransmit loop. With Chrome, this fails after 15 seconds. Firefox does not error out though. Testing: --------- - Tested with Firefox and Chrome with long delay (500 ms up and down) in network link conditioner. - Tested the above with no introduced delays too. - Added test for slow server.
Your environment.
webrtc.DTLSRoleClient
(which is the default). When setting answering DTLSRole towebrtc.DTLSRoleServer
via settings engine does not show the problem.What did you do?
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
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
.The text was updated successfully, but these errors were encountered: