DTLS: last handshake flight cannot be retransmitted in rtpengine
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 28/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c
- Domain
- audio-video-rtc, networking
Research direction
Read the linked pion/dtls issue #479 first for what the DTLS RFC expects from a server whose final flight is lost, then find where rtpengine drives the OpenSSL DTLS handshake as a server and where the last flight (the SSL3_MT_NEWSESSION_TICKET message) is sent. Reproduce with an openssl DTLS client against rtpengine with ~30% loss on the server-to-client path. Done means the cached last flight is resent when the client retransmits its final message and the handshake completes under that loss; run the existing DTLS tests to confirm no regression.
Written by the indexing model from the issue text.
Description
rtpengine version the issue has been seen with
No response
Used distribution and its version
No response
Linux kernel version used
No response
CPU architecture issue was seen on (see uname -m)
None
Expected behaviour you didn't see
As a DTLS server, RTP engine should retransmit the last flight to client if the last flight is lost on network.
Unexpected behaviour you saw
As a DTLS server, RTP engine does not retransmit the last flight to client if the last flight is lost on network.
That will cause DTLS handshake failure.
Steps to reproduce the problem
Use an openssl as client, build DTLS connection with RTP engine, and set packet lost to 30% from RTP engine to client.
sometimes, DTLS handshake cannot be built correctly.
Additional program output to the terminal or logs illustrating the issue
Same issue with detailed description: https://github.com/pion/dtls/issues/479
Anything else?
It is easily to fix this issue, RTPengine cache the last flight (type == SSL3_MT_NEWSESSION_TICKET) before sending to client, if client re-sends the last DTLS message to RTP engine, RTP engine can retransmit the cached last flight to client.
- Dominant language
- Perl
- Stars
- 992
- Forks
- 459
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sipwise/rtpengine
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 3 days
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 3 days
-
HTTP/WS worker threads spin forever in `__websocket_write_done()` (`sched_yield` loop) — 100% CPU with `--listen-http`Possibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 15/100
sipwise/rtpengine#2197 · 1 comment ·
Maintainers usually reply within 3 days
-
Kernel NULL pointer dereference in target_put() during target deletionPossibly taken A pull request linked to this issue is open or already merged. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 38/100
sipwise/rtpengine#2190 · 1 comment ·
Maintainers usually reply within 3 days
-
Calls using a third logical interface are silently never written to Redis (breaks keyspace-notification HA)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sipwise/rtpengine#2181 · 4 comments ·
Maintainers usually reply within 3 days
All issues in sipwise/rtpengine
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
bioconda/bioconda-recipes#70187 ·
Maintainers usually reply within 2 days
-
documentation Needs Triage
Difficulty 1/5 Under an hour Newbie friendliness 93/100
Maintainers usually reply within 1 day
-
Proposed Text EditsOpen
Difficulty 1/5 Under an hour Newbie friendliness 82/100
curl/everything-curl#658 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
PDLPorters/pdl#561 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
objectionary/eolang.sty#197 ·
Maintainers usually reply within 1 day