Having issues with Asterisk 18 and WebRTC

[Daniel_B]

So, we started with a very basic configuration. 2 PJSIP endpoints (snom phones) (500 and 501) and 2 PJSIP endpoints for WebRTC (510 and 520) using sipML5. Our configuration is:

pjsip.conf

[global]
    type=global
    user_agent=ASIPBX-18.0.1
    default_outbound_endpoint=dpma_endpoint
    endpoint_identifier_order=ip,username,anonymous,header,auth_username
    default_outbound_endpoint=dpma_endpoint

[0.0.0.0-udp]
    type=transport
    protocol=udp
    bind=0.0.0.0:5060
    allow_reload=no
    tos=cs3
    cos=3

[transport_wss]
    type=transport
    bind=0.0.0.0
    protocol=wss


[500]
    type=endpoint
    aors=500
    auth=500-auth
    tos_audio=ef
    tos_video=af41
    cos_audio=5
    cos_video=4
    allow=ulaw,alaw,gsm,g726,g722
    context=from-internal
    callerid=test 500 <500>
    dtmf_mode=rfc4733
    direct_media=yes
    aggregate_mwi=yes
    use_avpf=no
    rtcp_mux=no
    max_audio_streams=1
    max_video_streams=1
    bundle=no
    ice_support=no
    media_use_received_transport=no
    trust_id_inbound=yes
    media_encryption=no
    timers=yes
    timers_min_se=90
    media_encryption_optimistic=no
    refer_blind_progress=yes
    refer_blind_progress=yes
    send_pai=yes
    rtp_symmetric=yes
    rewrite_contact=yes
    force_rport=yes
    language=it
    one_touch_recording=on
    record_on_feature=apprecord
    record_off_feature=apprecord
    language=it

[505]
    type=endpoint
    aors=505
    auth=505-auth
    tos_audio=ef
    tos_video=af41
    cos_audio=5
    cos_video=4
    allow=ulaw,alaw,gsm,g726,g722
    context=from-internal
    callerid=Prova asistar <505>
    dtmf_mode=rfc4733
    direct_media=yes
    aggregate_mwi=yes
    use_avpf=no
    rtcp_mux=no
    max_audio_streams=1
    max_video_streams=1
    bundle=no
    ice_support=no
    media_use_received_transport=no
    trust_id_inbound=yes
    media_encryption=no
    timers=yes
    timers_min_se=90
    media_encryption_optimistic=no
    refer_blind_progress=yes
    refer_blind_progress=yes
    send_pai=yes
    rtp_symmetric=yes
    rewrite_contact=yes
    force_rport=yes
    language=it
    one_touch_recording=on
    record_on_feature=apprecord
    record_off_feature=apprecord
    language=it

[510]
    type=endpoint
    aors=510
    auth=510-auth
    webrtc=yes
    disallow=all
    allow=ulaw
    context=from-internal

[520]
    type=endpoint
    aors=520
    auth=520-auth
    webrtc=yes
    disallow=all
    allow=ulaw
    context=from-internal

[500]
type=aor
max_contacts=1
remove_existing=yes
maximum_expiration=7200
minimum_expiration=60
qualify_frequency=60

[505]
type=aor
max_contacts=1
remove_existing=yes
maximum_expiration=7200
minimum_expiration=60
qualify_frequency=60

[510]
type=aor
max_contacts=1
remove_existing=yes
maximum_expiration=7200
minimum_expiration=60
qualify_frequency=60

[520]
type=aor
max_contacts=1
remove_existing=yes
maximum_expiration=7200
minimum_expiration=60
qualify_frequency=60

[500-auth]
type=auth
auth_type=userpass
password=psw
username=500

[505-auth]
type=auth
auth_type=userpass
password=psw
username=505

[510-auth]
type=auth
auth_type=userpass
password=psw
username=510

[520-auth]
type=auth
auth_type=userpass
password=psw
username=520

and for the dialplan we have:
extensions.conf

    exten => _5XX,1,Set(CHANNEL(language)=it)
    exten => _5XX,n,Dial(PJSIP/${EXTEN},35,tT)

    exten => 900,1,Playback(demo-congrats)

Now, if we call between the two snom phones everything seems fine. I then try to connect to sipML5 from a PC from the same LAN as asterisk using the following settings:

and it connects correctly, I can easily dial a PJSIP Endpoint and have it ring, or dial 900 and get the demo message playback. So far everything OK.
The issues start when I try to connect with my mobile phone, using 4G. It connects normally, without issues but when I try to dial it takes about 2 minutes for the SIP INVITE to reach asterisk, but then it works correctly with audio.
Now, if someone else in the office tries to do the same thing, they’ll connect, dial, wait about 2 minutes and they’ll have no audio, we are all using different ISPs, the only one that seems to work is TIM.
One fix I’ve found for this long time to dial is to set [] into the ICE Servers on sipML5, but when I do that then I’ll have no audio at all.

We then tried installing a TURN server (coTURN, to be precise), setting it both in the rtp.conf file and the ICE Servers in sipML5, this allows other mobile ISPs to receive audio when calling a snom phone, but when we try to call from a snom phone to a sipML5 endpoint, the calls ends always in a NOANSWER status, even if we accept the call on sipML5.
And still it always takes a few minutes before we get the SIP INVITE on Asterisk.

Now, I’ve been thinking for a while, the long time to dial a call could be because sipML5 is “looking” for a way to put the browser and asterisk in communication and only when it finds this “route”, the INVITE will be sent, but if it is so I have no idea how to fix it. I can’t understand if it’s a configuration issue, firewall issue or something else.
For the audio problem I’ve noticed that while RTP packets are sent to the sipML5 there is no RTP connection from sipML5 to Asterisk.

If you need more info, let me know

[jcolp]

There are steps on a blog post I wrote[1] which cover some things to look into. In your case it’s probably ICE, in which case you have to look at all the addresses being attempted and see if logically at least one should work.

I should also add that if you are deploying WebRTC you really have to learn the underlying technologies - RTP, ICE, STUN, TURN, the browser side - because figuring out things when they go wrong can take a ton of time and investigation.

[1] https://www.asterisk.org/webrtc-asterisk-goes-wrong/

[a4business]

Hi Daniel,
I’ve faced with the same issue recently, it took me a day or so to found a solution.
My problem was is Sipml5 was doing ICE Gathering with timeout 20s (!!) for every candidate I have on my PC ( it includes VPN, LAN, WAN, Wifi … ) . - I could see it from chrome debug console
and it was a pain . on PC with only one NIC and ip it was fast for the same sipml5 account.

then I took sipjs , it had the same issue, but allowed me to tune it a little.

I’ve confgiured coTurn on the same host when asterisk with credentials ( TURN requires it )
First - it allows me to decrease Gathering timeout to 2000ms ,
second - I could change iceTransportPolicy to “relay” only. (ICE agent only considers media relay candidates when evaluating candidates - https://developer.mozilla.org/en-US/docs/Web/API/RTCConfiguration/iceTransportPolicy )

it made the sipjs to accept or send INVITE instantly , with two way voice all the time.

Final initialization of sipjs was :

 userAgent = new SIP.UA({
			  uri: ...
			  transportOptions: {
			      wsServers: [ 'wss://' + serverip + ':8443/ws' ],
			      maxReconnectionAttempts: 999,
			      reconnectionTimeout: 3,
			      keepAliveInterval: 5,
			      traceSip: false
			  },    
			  turnServers: [ { urls:"stun:" + serverip + ":19302" },
				  	 { urls: "turn:" + serverip + ":19302?transport=udp",
					 	 username: "turn",
					  	 password: "****",
					  	 credential: "****"
			  }],
			  sessionDescriptionHandlerFactoryOptions: {
			    peerConnectionOptions: {
		              iceCheckingTimeout:2000,
			          rtcConfiguration:{
				         iceTransportPolicy: "relay",
			             iceServers:
					        [
					          {
					            urls: "turn:" + serverip + ":19302?transport=udp",
						        username: "turn",
							password: "secured",
						        credential: "secured"
					            
					          }
					        ]
			      }
			    }
			  }
           
		});

If anyone could tell me how to configure the sipml5 the same way - it would be nice.

[Daniel_B]

Hi @jcolp, thank you for the answer. You were right, the issue was at ICE, most of the IPs it finds are local instead of public so when a remote client tries to generate a call we waste a lot of time working through the wrong ICE candidates, I’ll have to see what I can do about that, but from what I’ve read it’s protocol related.

I should also add that if you are deploying WebRTC you really have to learn the underlying technologies - RTP, ICE, STUN, TURN, the browser side - because figuring out things when they go wrong can take a ton of time and investigation.

You’re completely right, I just know the basics now but I’m probably have to read more on that

[Daniel_B]

Hi @a4business, thank you! I’m going to try and build an easy page with sipjs with your suggestion and see if it works also for us!

If anyone could tell me how to configure the sipml5 the same way - it would be nice.

Looks like you can, there’s an hack you can do to change the ICE gathering timeout, check out this commit[1] or this issue[2], might have some pointers for you. I haven’t had the chance to test it so far

[1]Added ICE Gathering timeout hack · DoubangoTelecom/sipml5@a1fae10 · GitHub
[2]Calling from web browser takes long time · Issue #313 · DoubangoTelecom/sipml5 · GitHub

[a4business]

Thanks, Daniel .
Thank you for pointers, the hack mentioned there will cancel gathering when specified timeout reached.
in sipjs , I aso do it, by specify iceCheckingTimeout , but no audio in most of cases.
Only iceTransportPolicy = relay with a workign TURN server configured helps, so it looks for a relay srflx (A server reflexive candidate), and then only cancel iceGathering/
What would be great - is to have ability to specify peerConnectionOptions in sipml5.