Jitsi and Jigasi are installed on the same Server. The Server has 3 interfaces:
- ens3 (10.0.0.1)
- ens4 (192.0.2.1, 192.0.2.2)
- docker0 (172.17.0.1)
When a user enters a conference by dialing a phone number, there is no audio-communication to the SIP client.
The packet flow is as follows:
Asterisk -> Jigasi (192.0.2.1) -> (via loopback interface) -> Videobridge (192.0.2.2)
Jigasi logs:
2020-05-25 15:28:34.772 INFO: [1944] org.ice4j.ice.ConnectivityCheckClient.log() Pair validated: 10.0.0.1:12048/udp/host -> 192.0.2.2:10000/udp/host (audio.RTP). Local ufrag 8qbn01e960aikd
2020-05-25 15:28:34.792 INFO: [1944] org.ice4j.ice.ConnectivityCheckClient.log() Pair validated: 192.0.2.2:12048/udp/host -> 192.0.2.2:10000/udp/host (audio.RTP). Local ufrag 8qbn01e960aikd
2020-05-25 15:28:34.813 INFO: [1943] org.ice4j.ice.ConnectivityCheckClient.log() Pair validated: 192.0.2.1:12048/udp/host -> 192.0.2.2:10000/udp/host (audio.RTP). Local ufrag 8qbn01e960aikd
The Videobridge logs:
2020-05-25 15:28:34.793 INFO: [53] [confId=b38aa206fadf93a9 gid=ff258c conf_name=erik ufrag=h90s1e960aiir epId=1afcd3ca local_ufrag=h90s1e960aiir] ConnectivityCheckClient.processSuccessResponse#636: Pair validated: 192.0.2.2:10000/udp/host -> 10.0.0.1:12048/udp/host (stream-1afcd3ca.RTP).
2020-05-25 15:28:34.814 INFO: [53] [confId=b38aa206fadf93a9 gid=ff258c conf_name=erik ufrag=h90s1e960aiir epId=1afcd3ca local_ufrag=h90s1e960aiir] ConnectivityCheckClient.processSuccessResponse#636: Pair validated: 192.0.2.2:10000/udp/host -> 192.0.2.2:12048/udp/host (stream-1afcd3ca.RTP).
And then starts sending the Audio-Stream to the IP-Adress of the docker0-interface:
# tcpdump -i lo -nnp port 10000
15:28:34.839969 IP 10.0.0.1.12048 > 192.0.2.2.10000: UDP, length 122
15:28:34.840381 IP 10.0.0.1.12048 > 192.0.2.2.10000: UDP, length 112
15:28:34.849930 IP 192.0.2.2.10000 > 172.17.0.1.12048: UDP, length 85
15:28:34.851277 IP 192.0.2.2.10000 > 172.17.0.1.12048: UDP, length 358
15:28:34.855046 IP 192.0.2.2.10000 > 172.17.0.1.12048: UDP, length 166
15:28:34.855120 IP 192.0.2.2.10000 > 172.17.0.1.12048: UDP, length 29
15:28:34.855156 IP 192.0.2.2.10000 > 172.17.0.1.12048: UDP, length 25
Jigasi now of course complains:
2020-05-25 15:28:37.837 FINEST: [1927] org.ice4j.stack.Connector.run() received datagram packet - addr: /192.0.2.2 port: 10000
2020-05-25 15:28:37.837 FINEST: [1943] org.ice4j.stack.MessageProcessingTask.run() Dispatching a StunMessageEvent.
2020-05-25 15:28:37.837 FINEST: [1943] org.ice4j.stack.StunStack.handleMessageEvent() Received a message on 172.17.0.1:12048/udp of type:1
2020-05-25 15:28:37.837 FINEST: [1943] org.ice4j.stack.StunStack.handleMessageEvent() parsing request
2020-05-25 15:28:37.837 FINEST: [1943] org.ice4j.stack.StunStack.handleMessageEvent() existing transaction not found
2020-05-25 15:28:37.837 FINEST: [1943] org.ice4j.stack.StunStack.validateMessageIntegrity() Successfully verified msg integrity
The Videobridge itself is forced to use only the IP 192.0.2.2:
org.ice4j.ice.harvest.ALLOWED_ADDRESSES=192.0.2.2
org.ice4j.ice.harvest.ALLOWED_INTERFACES=ens4
Why does this happen and how can it be fixed?
Thanks in advance.