1457190 - ICE failure after switching roles

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect, P3)

Description

[sergio.miguel.inacio]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

Steps to reproduce:

In my webrtc project I not getting audio for all inbound calls, some of them don't get audio. Because the event iceConnectionState= connected never arrives. But In chrome I have audio for all the incoming calls

I'm using the asterisk 13.20 and the kamailio 4.4.6 version.

For signaling I have a server with a REST API to exchange the sip messages. In the javascript I using this webrtc-adapter https://www.npmjs.com/package/webrtc-adapter

Can anyone help me with this problem? Thank you in advance.

The flow in my javascript when I start the application and receive a call is the following:

1 - Execute GetUserMedia and save the stream received.
2 - Add the eventHandlers to the peerconnection
3 - Receive an offer (call), get the tracks from the localstream, and execute the addTrak of the peeConnection, to add the traks and the local stream to the peerConnection
4 - The user click a button to answer the call
5 - set remoteDescription of the received offer
6 - Create an answer without RTCOfferOptions
7 - setLocaldescription
8 - wait (using promises) until receive at least 2 candidates of the type srflx or until the Ice gathering is complete
9- When the Promise is resolved, an answer to the offer is sent to asterisk. The offer contains the sdp with the candidates (peerConnection.LocalDescription.sdp).
10 - After the answer been sent, I execute the play to the audio htmlElement. This element will have the property srcObject with the remote stream received in the event ontrack.

My configfuration of the peerConnection is the following:

var pcConfig: any = {
    'iceServers':
        [{urls: [
            "stun:stun4.l.google.com:19302"
        ]}],
        'rtcpMuxPolicy': 'negotiate'
}


Actual results:

I'am not getting audio

Using my app I get the following log from the firefox (about:webrtc): https://pastebin.com/mva43Qqx

This scenario also happens using the sipml5, here is the logs of the firefox (about:webrtc) using the sipml5: https://pastebin.com/VcR0912a

Another important information, is when the call is made from the sipml5 running in firefox to the x-lite phone I get audio. When the call I made from the x-lite to the sipnl5 running in firefox I don't get audio.


Expected results:

I should get audio

Comment 1

[Nils Ohlmeier [:drno]]

From the log:

(stun/INFO) STUN-CLIENT(srflx(IP4:172.30.161.79:55473/UDP|stun4.l.google.com:19302)): Received response; processing
 
(ice/ERR) ICE(PC:1524245864454000 (id=10737418249 url=http://wksms4/uAgentWeb_IS/Main.aspx)): peer (PC:1524245864454000 (id=10737418249 url=http://wksms4/uAgentWeb_IS/Main.aspx):default) pairing local trickle ICE candidate srflx(IP4:172.30.161.79:55473/UDP|stun4.l.google.com:19302)
 
(ice/INFO) ICE-PEER(PC:1524245864454000 (id=10737418249 url=http://wksms4/uAgentWeb_IS/Main.aspx):default): role conflict, both controlled
 
(ice/INFO) ICE-PEER(PC:1524245864454000 (id=10737418249 url=http://wksms4/uAgentWeb_IS/Main.aspx):default): detected role conflict. Switching to controlling
 
(ice/INFO) ICE(PC:1524245864454000 (id=10737418249 url=http://wksms4/uAgentWeb_IS/Main.aspx)): peer (PC:1524245864454000 (id=10737418249 url=http://wksms4/uAgentWeb_IS/Main.aspx):default) Trickle grace period is over; marking every component with only failed pairs as failed.
 
+++++++ END ++++++++

I'm wondering if need to do something after switching role to controlling?

Comment 2

[Nils Ohlmeier [:drno]]

As I said on the list already:

Since Asterisk is the offerer it needs to act as the controller for the ICE implementation. Which either:
- it does not do, which would be an Asterisk bug
- or it sends the role conflict response even though there is not conflict, again an Asterisk bug

Then as a workaround if you switch the offerer and answerer roles, by making Firefox the offerer my guess is the problem will disappear.

Comment 3

[Nils Ohlmeier [:drno]]

(In reply to Nils Ohlmeier [:drno] from comment #1)
> I'm wondering if need to do something after switching role to controlling?

Byron I'm wondering if switching role to controlling requires us to kick off new checks. What are your thoughts on that?

Comment 4

[Nils Ohlmeier [:drno]]

sergio, can you get us a PCAP also known as Wireshark trace of such a failed call please?

Comment 5

[Byron Campen [:bwc]]

(In reply to Nils Ohlmeier [:drno] from comment #3)
> (In reply to Nils Ohlmeier [:drno] from comment #1)
> > I'm wondering if need to do something after switching role to controlling?
> 
> Byron I'm wondering if switching role to controlling requires us to kick off
> new checks. What are your thoughts on that?

Yes, we would need to send new checks with USE-CANDIDATE. I don't think the INFO-level logging is going to tell us about individual checks though. We'd need to see the PCAP.

Comment 6

[sergio.miguel.inacio]

Attachment: xlite-sipml_without-audio.pcap

Comment 7

[sergio.miguel.inacio]

Attachment: sipml-xlite_with-audio.pcap

Comment 8

[sergio.miguel.inacio]

Hello,

Sorry about our delay.

we generated 2 new calls, here is the description of the scenarios and the configurations. The pcap files were attach to the bug.

X-Lite: 
  - IP address: 172.30.160.198:62750
  - Extension: 7100

Sipml5: 
  - IP address: 172.30.160.198:2597
  - Extension: 199

Asterisk (13.20.0) server: 10.2.185.32

Call scenarios
  - Sipml5 to X-Lite: file sipml-xlite_with-audio.pcap
  - X-Lite to Sipml5: xlite-sipml_without-audio.pcap


---------- sip.conf file ----------
[general]
directmedia = no
defaultexpiry = 480
tos_sip = 0x0
tos_audio = 0x0
tos_video = 0x0
tos_text = 0x0
pedantic = yes
legacy_useroption_parsing=yes
udpbindaddr=0.0.0.0:5060
realm=10.2.185.32
transport=udp,ws,wss

[7100]
type = friend
secret= xxxx
defaultuser = 7100
context = extensions
host = dynamic
directmedia = yes
qualify = yes
dtmfmode = rfc2833
nat = never
disallow = all
allow = alaw
call-limit = 2
busylevel = 1
session-timers = originate
session-expires = 90
session-minse = 90
session-refresher = uas

[7101]
type = friend
secret=xxxx
defaultuser = 7101
context = extensions
host = dynamic
directmedia = yes
qualify = yes
dtmfmode = rfc2833
nat = never
disallow = all
allow = alaw
call-limit = 2
busylevel = 1
session-timers = originate
session-expires = 90
session-minse = 90
session-refresher = uas

[199]
host = dynamic
secret = 199
context = extensions
type = friend
encryption = yes
avpf = yes
force_avp = yes
icesupport = yes
directmedia = no
disallow = all
allow = opus
allow = ulaw
dtlsenable = yes
dtlsverify = fingerprint
dtlscertfile = /etc/asterisk/keys/asterisk.pem
dtlscafile = /etc/asterisk/keys/ca.crt
dtlssetup = actpass
rtcp_mux = yes
---------- sip.conf file ----------

---------- rtp.conf file ----------
[general]
rtpstart=10000
rtpend=20000
stunaddr=stun4.l.google.com:19302
---------- rtp.conf file ----------

Comment 9

[Nils Ohlmeier [:drno]]

Thanks a lot for pcap's Sergio.

But I don't understand why this show everything in clear text. What we need is a pcap taken on the machine where the Firefox browser is running to see the initial ICE packets at the beginning of the RTCPeerConnection between Firefox and Asterisk.

Comment 10

[sergio.miguel.inacio]

Attachment: xlite-sipml_with-audio2.pcap

Comment 11

[sergio.miguel.inacio]

Attachment: xlite-sipml_with-audio2.html

Comment 12

[sergio.miguel.inacio]

Attachment: xlite-sipml_without-audio2.pcap

Comment 13

[sergio.miguel.inacio]

Attachment: xlite-sipml_without-audio2.html

Comment 14

[sergio.miguel.inacio]

Attachment: sipml-xlite_with-audio2.html

Comment 15

[sergio.miguel.inacio]

Attachment: sipml-xlite_with-audio2.pcap

Comment 16

[sergio.miguel.inacio]

Hi Nils,

Sorry about that.

Regarding this problem I have to add the following, when we make a call from the x-lite to the sipml5 and have audio the asterisk send the rtp to the local ip and not the public one. We are working on a private network and the chrome always chose the local ip.

We done another set of tests, here is the description of the tests

X-Lite: 
  - IP address: 10.10.0.57:56447
  - Extension: 7100

Sipml5: 
  - IP address: 10.10.0.57:50288
  - Extension: 199

Asterisk server: 10.2.185.32 | 10.2.198.68

Call scenarios
  1) Sipml5 to X-Lite: file sipml-xlite_with-audio2.pcap
  2) X-Lite to Sipml5: xlite-sipml_without-audio2.pcap
  3) (very rare: 1 out of 10 calls) X-Lite to Sipml5: xlite-sipml_with-audio2.pcap

1) Sipml5 to X-Lite with audio. Asterisk RTP packets debug:
Sent RTP packet to      10.10.0.57:57166 (type 08, seq 028707, ts 039304, len 000160)
Got  RTP packet from    10.10.0.57:64846 (type 109, seq 003590, ts 1037407858, len 000059)
Sent RTP packet to      10.10.0.57:57166 (type 08, seq 028708, ts 039464, len 000160)
Got  RTP packet from    10.10.0.57:64846 (type 109, seq 003591, ts 1037408818, len 000058)

2) X-Lite to Sipml5 without audio. Asterisk RTP packets debug:
Got  RTP packet from    10.10.0.57:64576 (type 08, seq 030321, ts 1292814200, len 000160)
Sent RTP packet to      62.28.32.2:64156 (via ICE) (type 107, seq 020932, ts 326688, len 000128)
Got  RTP packet from    10.10.0.57:64576 (type 08, seq 030322, ts 1292814360, len 000160)
Sent RTP packet to      62.28.32.2:64156 (via ICE) (type 107, seq 020933, ts 327648, len 000128)

3) X-Lite to Sipml5 with audio. Asterisk RTP packets debug:
Got  RTP packet from    10.10.0.57:56140 (type 08, seq 028663, ts 1293849976, len 000160)
Sent RTP packet to      10.10.0.57:49373 (via ICE) (type 107, seq 003513, ts 244416, len 000139)
Got  RTP packet from    10.10.0.57:49373 (type 107, seq 017266, ts 112580114, len 000045)
Sent RTP packet to      10.10.0.57:56140 (type 08, seq 018459, ts 040480, len 000160)

Comment 17

[sergio.miguel.inacio]

Hi Nils,

We after some additional research we sound the  following bug in the asterisk

https://issues.asterisk.org/jira/browse/ASTERISK-27646

So we update the asterisk to the 13.21 version, and using the sipml5. We get audio in the calls made by the x-lite to the sipml5.

Now we will execute some tests, using our code and check if everything is ok.

I will keep you posted

Best regards,
Sergio

Comment 18

[sergio.miguel.inacio]

Attachment: aboutWebrtc2CallsWithAndWithout.html

Comment 19

[sergio.miguel.inacio]

hi nils

so after update the asterisk, we are not getting role conflicts. And get the audio.

But we get a strange behaviour.

When using a vpn, the firefox after set the local description, the local canditates that I get have a public ip, a local ip from the network where my laptop is, and the local ip of the vpn. When I have these 3, the webrtc, select the 2 local, but the local ip from the network where my laptop is fail, but the local ip from the vpn does not, and I get audio.

Alghout, in the second call, I get 3 ips, a public one, a local ip from the network where my laptop is, and a ipv6 ip. And in this case I don't get any audio, because the local ip from the network where my laptop is fail, and the webrtc cannot resolve the ipv6.

I also use this sample https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

And in firefox I get the ipv6, the one that webrtc cannot resolve, but if I use the chrome I always get the ipv4 addresses.

I add the attach aboutWebrtc2CallsWithAndWithout

I am using the webrtc-adapter ( https://github.com/webrtc/adapter/blob/master/release/adapter.js )

Can you give me a little help?

Thanks in advance

Comment 20

[sergio.miguel.inacio]

I forgot to mention

192.168.10.182 this is the vpn ip

192.168.1.85 this is the local from the network where my laptop is

Comment 21

[sergio.miguel.inacio]

Hi Nills

This ticket can be closed.

The problem was in the version of the asterisk, and the second one was in my code.

Best regards,
Sérgio Silva