Asterisk 16.1 WebRTC configuration not working when calling web client (other way is ok)


#1

I’m setting up Asterisk to work with web clients (sipML js library) and native softphone clients. The problem is calling a web client , in which case I can’t hear anything (in any direction). If a web client calls a native client, everything is ok.

Web Client Configuration

The configuration of a web client is as follows (I’m using realtime, so the configuration is in a table, so I’m reporting column_name: value , without using the .conf syntax):

Table ps_aors:

id: 503 max_contacts: 1 remove_existing: yes

Table ps_auths:

id: 503 auth_type: userpass password: ******* username: 503

Table ps_endpoints:

id: 503 transport: wss-transport aors: 503 auth: 503 context: default disallow: all allow: ulaw, opus direct_media: no ice_support: yes identify_by: username use_avpf: yes media_encryption: dtls dtls_verify: fingerprint dtls_setup: actpass media_use_received_transport: yes rtcp_mux: yes dtls_auto_generate_cert: yes

Native Client Configuration

The configuration of a native client is as follows:

Table ps_aors:

id: 500 max_contacts: 1 remove_existing: yes

Table ps_auths:

id: 500 auth_type: userpass password: ******* username: 500

Table ps_endpoints:

id: 500 transport: transport-udp aors: 500 auth: 500 context: default disallow: all allow: ulaw, opus direct_media: no ice_support: yes dtls_auto_generate_cert: no

The two transports in pjsip.conf are:

[transport-udp] type=transport protocol=udp bind=0.0.0.0

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

My Hypothesis

I think the problem is with ICE support. I activated SIP and RTP debug on Asterisk, and when 500 (native) calls 503 (web) I don’t see the (via ICE) message, while it is there if 503 calls 500. I’m reporting the bug traces below; they are from two different calls, I hope that’s ok.

SIP debug trace for call 500 -> 503

https://pastebin.com/CjX0hnWf

RTP debug trace for call 500 -> 503

... Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011030, ts 067040, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011031, ts 067200, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006845, ts 067360, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011032, ts 067360, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006846, ts 067520, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011033, ts 067520, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006847, ts 067680, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011034, ts 067680, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006848, ts 067840, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011035, ts 067840, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006849, ts 068000, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006850, ts 068160, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011036, ts 068000, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011037, ts 068160, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006851, ts 068320, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011038, ts 068320, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006852, ts 068480, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011039, ts 068480, len 000160) Got RTP packet from 10.20.67.50:4022 (type 00, seq 006853, ts 068640, len 000160) Sent RTP packet to 10.20.102.93:48976 (type 00, seq 011040, ts 068640, len 000160) ...


#2

Yes, it appears as though the ICE negotiation failed but you’d need to dig into packet captures to see what was being done, and also look at the browser to see if it gives a reason.

If you don’t have the knowledge to do so then deploying WebRTC may not be for you - it requires understanding of a lot of technology, or the ability to learn some of it, because when it fails (and it will) there’s a lot of moving pieces involved to determine what is going on. It’s not something that can be easily solved by someone on a forum because it requires digging deep into things - and problems can be hard for others to duplicate because every different part can alter the result.


#3

BTW I’m usign the SipML client. Indeed the console says that “ICE failed, add a TURN server”. The fact is that my clients and server are all on the same local network. I’m attaching screenshots of the page about:webrtc.


#4


#5

about:webrtc html --> https://pastebin.com/LcN6LXBd


#6

Asterisk did not provide ICE, why that is I do not know. It’s likely your configuration in some way. If you weren’t yourself able to notice that based on the SDP, then you need to gain those skills if you wish to use WebRTC.


#7

All clients have ice_support = yes (in the ps_endpoints table). In rtp.conf I have icesupport = yes. If there is any other configuration to look at, please let me know.

Thank you for your help!

(BTW, regarding the comments about my inexperience in this topic, I fail to see their purpose; I don’t know how else am I supposed to learn if not by doing, asking here, and studying the few resources I can find)


#8

WebRTC itself is built on different technology - STUN, TURN, ICE, DTLS-SRTP, SDP. Those are things you need to read about and understand. They are defined in RFCs and specifications. From a browser perspective you have to look at the different ways they provide to debug WebRTC handling on their end. Forums and such are great if you have specific targeted questions.

SDP itself is how WebRTC is negotatiated and communicated, so it is very important to have a solid understanding of it if putting WebRTC into any sort of production environment.

I bring this up because I’ve seen numerous people roll out WebRTC into production without having any understanding of it, and when it goes wrong they are helpless to debug or understand what is going on. Unlike SIP phones which are much more defined and comparatively simple, WebRTC is very complex and a black box in some ways (the browser) so there’s more responsibility on the deployer.

As for your problem have you double checked which endpoint is being used? Have you used the CLI command to make sure that the configuration is being read properly? Have you tried using the “webrtc” option which ensures the endpoint is configured properly for WebRTC?