No STUN server option after restart

[vlad-korniiaka-idt]

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:

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:

[rfuchs]

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.