Browser Phone with asterisk 16 and vps

[rickygm]

hi , I have been trying for a couple of days to get the webrtc client to work, but I can't get audio when the call is answered, I have tried different configurations, I don't think so because I have the asterisk directly with public ip, I paste the log of a call.

 DTLS ECDH initialized (automatic), faster PFS enabled
    -- Executing [2006@llamadas-inter:1] NoOp("PJSIP/2007-00000004", "WEBRTC1") in new stack
    -- Executing [2006@llamadas-inter:2] NoOp("PJSIP/2007-00000004", "Protocolo TLS = 1") in new stack
    -- Executing [2006@llamadas-inter:3] Dial("PJSIP/2007-00000004", "PJSIP/2006/sip:9g6j2g7b@186.77.205.68:59817;transport=ws,30,tT") in new stack
    -- Called PJSIP/2006/sip:9g6j2g7b@186.77.205.68:59817;transport=ws
  == DTLS ECDH initialized (automatic), faster PFS enabled
    -- PJSIP/2006-00000005 is ringing
    -- PJSIP/2006-00000005 answered PJSIP/2007-00000004
    -- Channel PJSIP/2006-00000005 joined 'simple_bridge' basic-bridge <d51d6553-4217-4960-a7b3-2f0b772343b5>
    -- Channel PJSIP/2007-00000004 joined 'simple_bridge' basic-bridge <d51d6553-4217-4960-a7b3-2f0b772343b5>
    -- Channel PJSIP/2006-00000005 left 'simple_bridge' basic-bridge <d51d6553-4217-4960-a7b3-2f0b772343b5>
    -- Channel PJSIP/2007-00000004 left 'simple_bridge' basic-bridge <d51d6553-4217-4960-a7b3-2f0b772343b5>
  == Spawn extension (llamadas-inter, 2006, 3) exited non-zero on 'PJSIP/2007-00000004'
  == DTLS ECDH initialized (automatic), faster PFS enabled
    -- Executing [2007@llamadas-inter:1] NoOp("PJSIP/2006-00000006", "WEBRTC") in new stack
    -- Executing [2007@llamadas-inter:2] NoOp("PJSIP/2006-00000006", "Protocolo TLS = 1") in new stack
    -- Executing [2007@llamadas-inter:3] Dial("PJSIP/2006-00000006", "PJSIP/2007/sip:unvk8qp6@186.77.205.68:65008;transport=ws,30,tT") in new stack
    -- Called PJSIP/2007/sip:unvk8qp6@186.77.205.68:65008;transport=ws
  == DTLS ECDH initialized (automatic), faster PFS enabled
    -- PJSIP/2007-00000007 is ringing

my http.conf

[general]
enabled=yes
enablestatic=yes
bindaddr=0.0.0.0
bindport=8088
prefix=
sessionlimit=1000
session_inactivity=30000
session_keep_alive=15000
tlsenable=yes
tlsbindaddr=0.0.0.0:8089 
tlscertfile=/etc/letsencrypt/live/sip.domain.com/fullchain.pem 
tlsprivatekey=/etc/letsencrypt/live/sip.domain.com/privkey.pem
redirect=/ /static/index.html

rtp.conf

[general]
rtpstart=10000
rtpend=20000
rtpchecksums=no
dtmftimeout=3000
rtcpinterval=5000
strictrtp=no
probation=4
icesupport=yes
stunaddr=stun.l.google.com:19302

Firewall port is open , 8088 , 8089 , 10000:20000 , 5060

is there anything to do inside browser phone?

[InnovateAsterisk]

Normally audio issues are related to ICE configurations, because with WSS, the connections are TCP, and generally able to traverse nat networks. This means even if your NAT configurations are not correct, WSS can often work, but then audio will fail as it uses UDP.

While it is true that having Asterisk directly bound to a live IP address helps, its also not necessary, and if you describe your nat layout to asterisk, audio will flow normally. This is, of course, if ICE negotiations complete correctly. By default, the sipjs code will include the google stun address, and it cannot be take out or nulled.

I would say your first steps would be to check that a regular SIP hardware phone or software phone works correctly over UDP (5060).

[rickygm]

Hi.

yes, my extensions with udp/tls work very well, even behind nat, inside and outside my network, but webrtc does not work for me.

user webrtc =====> to user webrtc no audio user webrtc =====> to user softphone/hardwarephone no audio

do you want me to share my config?

on the other hand your project is excellent, and more because it brings xmpp support.

[InnovateAsterisk]

As a simple test, can a webrtc extension dial into Asterisk and hear something like MusicOnHold, or Echo ?

[rickygm]

Hi , I have no audio, but only with webrtc, other audio between extensions or gsm gateway works fine, I paste the log of a call to voicemail.

https://pastebin.com/rxqXd71Y

I added the signaling on the transports, but it is not necessary because it is not behind a nat, but I put it to rule it out.

my transports

[udp-transport] type=transport async_operations=1 external_media_address=23.227.X.X external_signaling_address=23.227.X.X protocol=udp bind=0.0.0.0 allow_reload=no symmetric_transport=no local_net=192.168.30.0/24

[0.0.0.0-wss] type=transport protocol=wss bind=0.0.0.0:5080 external_media_address=23.227.X.X external_signaling_address=23.227.X.X allow_reload=yes tos=cs3 cos=3 local_net=192.168.30.0/24 symmetric_transport=no

any ideas or advice is welcome!

[InnovateAsterisk]

I added the signaling on the transports, but it is not necessary because it is not behind a nat, but I put it to rule it out.

Correct, if Asterisk is directly bound to a live IP address, this is not necessary - but in your config you are specifying a nat network:

external_media_address=23.227.X.X
external_signaling_address=23.227.X.X

local_net=192.168.30.0/24

Just to be clear, the only time Asterisk is really exposed to a live IP address is when the actual live IP is assigned to the NIC. When you type ifconfig on the terminal what does it output? If eth0 is set to a 192.168.30.X ip, then your Asterisk box is behind a nat network.

This topic can be confusing because cloud providers do offer what they will call a "live" ip address or "dedicated" ip address, but often its just a 1:1 nat ip. (This is what I use at AWS, for my testing a demo services)

So, If you are 1:1 natted, then you will need to do the following in the rtp.conf:

[general]
rtpstart=10000
rtpend=20000
rtcpinterval = 5000
stunaddr=stun.l.google.com:19302

[ice_host_candidates]
192.168.30.X => 23.227.X.X

On the last line 192.168.30.X => 23.227.X.X you will need to map the vps eth0 ip address to the "live" vps ip address.

Also note: we are using stun.l.google.com:19302 as a stun server. And also that the firewall needs to have UDP ports 10000 to 20000 open for inbound connections.

Now let's look at the pjsip.conf

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

These are the only setting that you would need to specify. You don't need to specify a bind port (remember it comes in via the http service. I believe the rest of the settings are ignored if you specify protocol=wss. WebRTC uses ICE to negotiate DTLS, so the rtp.conf will play the most important role here.

You have not shared you endpoint, but from what I have seen there a a few things here that can help with firewalls etc:

[webrtc_client]
type=endpoint
aors=webrtc_client
auth=webrtc_client
dtls_auto_generate_cert=yes
webrtc=yes
; Setting webrtc=yes is a shortcut for setting the following options:
; use_avpf=yes
; media_encryption=dtls
; dtls_verify=fingerprint
; dtls_setup=actpass
; ice_support=yes
; media_use_received_transport=yes
; rtcp_mux=yes
context=default
disallow=all
allow=opus,ulaw

; I use the following to help tricky client firewalls.
force_rport=yes
rtp_symmetric=yes
rtp_timeout=60

Once you have checked these, open Wireshark on your local PC, and trace your activity. It will be encrypted, but its not important what's inside the packet, only the source and destination etc.

Then on the Asterisk box, go to the CLI, and enable RTP debug on > rtp set debug on

Finally, there is one other consideration:

Codec: Typically in WebRTC, the opus codec is used. ULAW can also be used, but opus significantly improves call quality. I see you offer opus, and the OK accepts opus as the first codec, and ulaw as a backup. To double check that the opus codec is correctly in stalled on the server, fire up a hardware phone, like a yealink etc, and set the only codec option to opus, and make sure you get audio. It's possible that opus is corrupt - have had this before more than once... its very frustrating.

Once you have tested, and de-bugged the solution with something simple like music on hold, you will be able to call each other. Remember that, WebRTC via Asterisk cannot exit the media path, or provide a proxied end-to-end call, as it it just not built that way - it would have established the DTLS connection already via ICE, and so the "2nd leg" of the call would fail. Media always flows through Asterisk with WebRTC, and it acts as a Back-to-back user agent.