search

sipwise / rtpengine

The Sipwise media proxy for Kamailio
GNU General Public License v3.0
765 stars 362 forks source link

No STUN server option after restart #1767

Open vlad-korniiaka-idt opened 7 months ago

vlad-korniiaka-idt commented 7 months ago

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:

  1. RTPEngine with Redis option: redis = 127.0.0.1:1888/3
  2. Make a call with ICE-candidates (in our tests we called from UDP softphone to WSS device)
  3. Verify that there is a sound between devices.
  4. Verify that RTPEngine wrote to Redis DB
  5. Restart RTPEngine
  6. 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: image (11)

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: image (10)

rfuchs commented 7 months ago

ICE state isn't currently stored into Redis, so this is actually expected not to work.

ICE state could be stored into Redis (and then restored from it) if implemented. Although ICE is often used in combination with SRTP-DTLS, and trying to get DTLS state in and back out of Redis is an entirely different problem.