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 193.200.155.171 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.
STUN packets are sent back and forth with viable candidates being ones that allow bidirectional traffic. The priority is communicated in the candidate lines (the big long number like 2122252543) and the one with the highest priority is used. I posted this on another recent thread but if you are deploying WebRTC you really need to learn the underlying foundation of it and the technologies in use. It can, and will, stop working or not work in certain cases. It’s not a plug and play solution.
If for some reason, and I don’t understand why yet, the higher priority candidates are not available, will Asterisk use the last candidate in the list of candidates it has. My asterisk server definitely cannot communicate with the 193 address yet it starts transmitting RTP packets to it.
It depends, if the ICE negotiation completely fails it might try some other address in the SDP if it’s valid. Otherwise it uses what the ICE negotiation has told it to use.
I attach a wireshark screenshot of the STUN interaction between asterisk .92 and webrtc client .211 for a working and non-working call.
The trace from packet no 63 to 3857 is the trace I got for a WORKING call and it has an error reported (Role Conflict) in that trace. Also there is much more STUN activity on a call for the WORKING case (21 packets) exchanged including a BINDING Indication packet from asterisk to the webrtc client.
Whereas a call where the audio was NOT working did not have this error and only 4 packets associated with the STUN interaction.
Joshua, I had a look at that issue and I don’t that is my issue, however, it prompted me to increase the pjproject logging level and see what asterisk was thinking during the ICE process. I got two log files attached and it shows the asterisk/ICE negotiation process with pjproject debugging turned up for a working and not-working case.
In the working case the response from the webtrc client to the initial STUN binding request is a “Role Conflict”. Asterisk then changes the STUN message from ICE-CONTROLLED to ICE-CONTROLLING and everything happens. It nominates the best candidate i.e. the first in the list ( the LAN connection), cancels any other candidate selection activity and away we go. All good.
In the failed case, the webrtc doesn’t give a “Role Conflict” error - so only one STUN message is sent
and the STUN process succeeds. The process reports the check as successful but then does not proceed to use that candidate.
From what I have read over the past few days on ICE the initiator of the call is normally the CONTROLLING party in the ICE process but that may not be true always. However, what I don’t understand is why the WEBRTC client objects to the STUN message sometimes and not others.
Thank you for your help so far. I appreciate any further insight you might have on this.
[Feb 5 13:03:30] DEBUG[26135][C-00000001] pjproject: icess0x7fc4f401dc58 .Check 0: [1] 192.168.1.92:18472–>192.168.1.211:60643 (not nominated): connectivity check SUCCESS
[Feb 5 13:03:30] DEBUG[26135][C-00000001] pjproject: icess0x7fc4f401dc58 .Check 0: [1] 192.168.1.92:18472–>192.168.1.211:60643: state changed from In Progress to Succeeded
[Feb 5 13:03:30] DEBUG[26135][C-00000001] pjproject: icess0x7fc4f401dc58 .Check 0 is successful
The patch also includes the ASTERISK-23026 fix (https://issues.asterisk.org/jira/browse/ASTERISK-23026) as we noticed that from time to time (often, actually), there would be no audio in DTLS-SRTP calls. We found out the problem to be with ICE, actually, and specifically in a conflict between Asterisk and browsers on CONTROLLING/CONTROLLED roles. That patch forces a specific behaviour and so has not been completely accepted in that discussion, but it fixed the problem for us and so we thought we’d integrate it as well.
That said, this patch is obviously not meant to be considered for integration within the Asterisk main code as it is, but rather as a testbed for people to play with. Feedback on whether or not it works for people would definitely help find a concrete solution to the Asterisk DTLS issues. We have been trying this in the field (and in some production environments as well) and it seems to work fine, although we experienced some occasional force closes within the DTLS code that we wanted to investigate: more testing from people interested in the functionality would definitely help making this investigation easier.
Also, another user experienced exactly the same issue as myself.
**Yuriy Gorlichenko added a comment - 30/Jun/14 6:33 AM - edited**
_I have one more trouble with this patch. It happens when I do call from webphone (sipml5 or jssip) to some endpoint (softphone). 8 times of 10 Ihave no audio. _ at rtp log I see only traffic from softphone to asterisk, and to softphone from asterisk. At the start of session I see that one rtp packet sends fron webphone (via ICE), then i see Probation passed - setting RTP source address to : And then I see only rtp from and to softphone. As I say - It happens not always. Sometimes I have 2 ways rtp packets. (random Lucky???) ICE enabled and stun configured at rtp.conf
It mentions that the patch is not meant for integration with “Asterisk main code” - does that mean that a fix for 23026 may not be in the Asterisk version 15.1.2 .
