-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
As a client, the handling of DTLS exceptions leads to a failure in connecting to the server #2629
Comments
Hi @minlp - I haven't tested the revised code but it looks plausible. Can you confirm it fixes the issue in your case? If so, can you kindly open a PR on pion/dtls so we can review in more detail and run the CI tests? |
It can solve my problem, as I haven't encountered any DTLS handshake failures after making local modifications. I will open a pull request on pion/dtls. |
but I can't push my branch to pion/dtls, can you give me the relevant permissions? @adriancable |
Hi @minlp - you don’t/can’t push to this repo. You fork pion/dtls, push changes to your fork, then create a PR on pion/dtls repo based on the fork. Then me (or one of the other pion maintainers) will take it from there. |
This was fixed with the merging of pion/dtls#600 |
Your environment.
What happened?
When connecting to the WebRTC media server, there are occasional issues with streaming failure. Upon analyzing the captured packets, it appears that the failure is due to DTLS handshake failure.
Based on the analysis of the captured packets, when packet sequence number 10766 is received and there is no "server hello" and "hello verify request" in the current cache, it results in an internal error being returned. In this case, can the fullPullMap method be modified as follows?Based on the highlighted section in the image, the packets for "server hello," "certificate," "server key exchange," "certificate request," and "server hello done" are split into two packets (packet sequence numbers 10766 and 10830). In a normal network scenario, packet 10830 should be received before packet 10766. However, due to network latency, packet 10766 arrived first, causing the client to handle it abnormally and return an internal error. This abnormal handling resulted in an overall disruption in the process.
What did you expect?
In this situation, can successfully establish a connection with the server.
The text was updated successfully, but these errors were encountered: