I have set up a simple webrtc demo as follows:
webrtc client running on Firefox browser V57 using SIP.JS (192.168.1.211)
asterisk server running 15.1.2 and usng chan_sip.(192.168.1.92)
IP deskphone (192.168.1.121)
All components are running on the same LAN. Both the phone and the webrtc client register successfully on the asterisk box. Nat is set to “NO” on the asterisk server.
My demo works fine and reliably for calls going from the webrtc client to the deskphone - calls are setup and I get audio both ways.
However calls to the webrtc client from the deskphone are not so good. Most of the time I get no audio at all however sometimes I get audio both ways (never one way) and I have been able to compare the behaviour of Asterisk for the working and non working cases.
In summary, asterisk in most cases picks the ICE candidate (3) i.e. the WAN address to send the audio to, however in some cases ( 3 out of 10 ) it will decide to use the ICE candidate(2) and everything works.
a=candidate:0 1 UDP 2122252543 172.25.183.97 51967 typ host
a=candidate:2 1 UDP 2122187007 192.168.1.211 51968 typ host
a=candidate:4 1 TCP 2105524479 172.25.183.97 9 typ host tcptype active
a=candidate:5 1 TCP 2105458943 192.168.1.211 9 typ host tcptype active
a=candidate:3 1 UDP 1685987327 18.104.22.168 61715 typ srflx raddr 192.168.1.211 rport 51968
How does it decide which ICE candidate to use ? There are the ones that are offered in the SIP 200 OK to the INVITE.
In the working case I always get this in the RTP debug output
– Strict RTP switching to RTP target address 192.168.1.211:51968 as source
– Strict RTP learning complete - Locking on source address 192.168.1.211:51968
In the non-working this is not present.
I have noticed that if I delay in answering the call at the webrtc client, I have a better chance of getting it set up correctly but I am not entirely sure about that.
I have asterisk and browser logs for both working and non-working situations if required.
I would be grateful for any suggestions.