Closed minlp closed 4 months ago
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?
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.
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?
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 https://github.com/pion/dtls/pull/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 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.
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?
What did you expect?
In this situation, can successfully establish a connection with the server.