Rtpengine run in debian docker in userspace, DTLS (server hello) response in wrong destination port cause webrtc failed

[Zhang vivid]

Application scenarios：
web browser --dtls--> opensips (+ rtpengine) --udp--> freeswitch
Both opensips and rtpengine run in their respective independent Docker containers and are on the same host.

opensips call rtpengine_answer, then trigger the ice and dtls negotiation
    UDP/TLS/RTP/SAVPF SDES-off ICE=force replace-origin DTLS=passive

The network environment is as follows:
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.26.153.110 netmask 255.255.255.0 broadcast 172.26.153.255
VIP: 172.26.153.29

10000-10199 of the VIP map to the public network xxx.xxx.20.187

after ICE flow, DTLS response in the wrong destination port

all the same, only change web browser to another network, everything is ok.

the docker-comose.yml as follows:

services:
  rtpengine1: 
    image: rtpengine-debian:mr13.3.1.4
    container_name: rtpengine1
    network_mode: host
    privileged: true 
    cap_add:
        - NET_ADMIN
        - NET_RAW
        - SYS_ADMIN
    command: [
      "/usr/bin/rtpengine",
      "--config-file=/etc/rtpengine/rtpengine1.conf",
      "--log-stderr",        
      "-f"                   
    ]
    volumes:
      - ./conf/rtpengine1.conf:/etc/rtpengine/rtpengine1.conf:ro
      - ./recordings/rtpengine1:/usr/local/audio_recording

the rtpengine1.conf as follows:
[rtpengine]
pidfile = /var/run/rtpengine1.pid
table = -1
interface = 172.26.153.29!xxx.xx.20.187
port-min = 10000
port-max = 10199
log-level = 7
log-facility = local7
listen-ng = 172.26.153.110:2223
num-threads = 4
silent-timeout = 600
timeout = 7200
final-timeout = 3600
offer-timeout = 60
delete-delay = 0
tos = 184
recording-dir = /usr/local/audio_recording
recording-method = proc
recording-format = eth
homer-id = 1
homer-ip = xx.xxx.xxx.xxx
homer-port = 9060
homer-protocol = udp
listen-http = 172.26.153.110:22223
#mr13.3.1.4 crash
#debug-srtp = true
log-srtp-keys = true
dtls-mtu=1200
#endpoint-learning=heuristic
#endpoint-learning=immediate
endpoint-learning=off
control-pmtu=want
no-fallback=true

1. I try different value of endpoint-learning, but still failed

2. I try mr13.3.1.4, mr11.5.1.34, the result are the same.

[Richard Fuchs]

This sounds like what has been discussed here: https://github.com/sipwise/rtpengine/issues/1996

The summarise: Generally ICE is in charge of determining an appropriate peer address and port, and if ICE converged on a different port, then DTLS responses would be sent to a different port as well.

This was different in older versions but was changed for technical reasons in https://github.com/sipwise/rtpengine/commit/533150630308b8182c157d3dc774421197555437

The recent patch https://github.com/sipwise/rtpengine/commit/271b3b152000f5bcf21c444daedfe2799b3ee5f6 restored the old behaviour. It's present in current master and 13.5, but not in 13.4 nor in 13.3. So you can try with a newer version and see if that makes a difference.

It's not a trivial patch but if it proves to be reliable, it may be a candidate for an eventual backport.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/a7d5c794-9f1d-4f09-a6e3-54f25fc3a431n%40googlegroups.com.

[Zhang vivid]

dear, I tried mr13.5,  It's working! Thank you for your kind help