No STUN server option after restart
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
Research direction
Reproduce by running rtpengine with the redis option, placing an ICE call, restarting the daemon, and diffing /proc/rtpengine/0/list before and after: the STUN flag is present before the restart and gone after, because the option is never written to the Redis store. Start in the code path that serialises per-stream call options into Redis and the counterpart that restores them at startup, since the STUN handling itself is fine — the flag is simply not persisted. Done when the post-restart list still shows STUN and the binding requests keep getting answered; expect to read around the session/stream state code first, as the issue names no files.
Written by the indexing model from the issue text.
Description
Hello!
We faced the issue related to session recovery.
The issue is that after restart there is no STUN option, as STUN option is not stored to Redis DB.
For calls without ICE-candidates there is no issue with the sound, as there is no STUN.
Tested at RTPEngine versions:
Version: 11.5.1.14+0~mr11.5.1.14 git-mr11.5.1-f880739a,
Version: 10.1.1.1
Reproduce steps:
- RTPEngine with Redis option:
redis = 127.0.0.1:1888/3 - Make a call with ICE-candidates (in our tests we called from UDP softphone to WSS device)
- Verify that there is a sound between devices.
- Verify that RTPEngine wrote to Redis DB
- Restart RTPEngine
- Sound will disappear in about 6 seconds.
What we have find out:
Before reboot (from /proc/rtpengine/0/list):
options: RTP PT-filter RTCP RTCP-mux DTLS STUN SSRC-tracking forward-RTCP forward-RTCP-FB
After reboot:
options: RTP PT-filter RTCP RTCP-mux DTLS SSRC-tracking forward-RTCP forward-RTCP-FB
As you see, STUN disappeared from options. We checked the info that is stored in Redis, and didn’t find any information about STUN.
And, after RTPEngine restart, we see “binding requests”, but RTPEngine knows nothing about them (please see attached screenshots):
15:53:29 - answer from RTPEngine
15:53:31 - no answer from RTPEngine
15:53:41.961601000 - RTPEngine stopped sending RTP to UDP device.
STUN:
In text:
No. \ Time \ Source \ Destination \ Protocol \ Len. \ Info
37101 \ 15:53:27 \ User \ RTPEngine \ STUN \ 142 \ Binding Request user: xHfrcEp4:cnH5
36910 \ 15:53:27 \ RTPEngine \ User \ STUN \ 198 \ Binding Success Response XOR-MAPPED-ADDRESS: RTPEngine:54473
37101 \ 15:53:29 \ User \ RTPEngine \ STUN \ 142 \ Binding Request user: xHfrcEp4:cnH5
36910 \ 15:53:29 \ RTPEngine \ User \ STUN \ 198 \ Binding Success Response XOR-MAPPED-ADDRESS: RTPEngine:54473
37101 \ 15:53:31 \ User \ RTPEngine \ STUN \ 142 \ Binding Request user: xHfrcEp4:cnH5
37101 \ 15:53:32 \ User \ RTPEngine \ STUN \ 142 \ Binding Request user: xHfrcEp4:cnH5
37101 \ 15:53:32 \ User \ RTPEngine \ STUN \ 142 \ Binding Request user: xHfrcEp4:cnH5
RTP:
- 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
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 2 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 2 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 2 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 2 days
All issues in sipwise/rtpengine
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
PerlDancer/Dancer2#1854 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
major/MySQLTuner-perl#1007 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
bioconda/bioconda-recipes#70187 ·
Maintainers usually reply within 2 days