Asterisk 16.4 & WebRTC = no audio

Hello there,

we’ve just tried our fist webrtc test with Asterisk 16.4.0
The endpoints get registered well and it’s able to send calls without problems … but without audio.

This is the Asterisk CLI:

    -- Executing [600@entrantes:1] Answer("PJSIP/webrtc_test-000005e5", "") in new stack
    -- Executing [600@entrantes:2] Playback("PJSIP/webrtc_test-000005e5", "demo-congrats") in new stack
    -- <PJSIP/webrtc_test-000005e5> Playing 'demo-congrats.slin16' (language 'en')

Nothing wrong there.

The http.conf:

[general]
enabled=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/letsencrypt/archive/xxxxxxxxx.com/cert1.pem
tlsprivatekey=/etc/letsencrypt/archive/xxxxxxxxx.com/cert1.pem

The rtp.conf:

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

The pjsip.conf:

[webrtc_test]
type=aor
max_contacts=1
remove_existing=yes
[webrtc_test]
type=auth
auth_type=userpass
username=webrtc_test
password=xxxxxxxxxxxxx
[webrtc_test]
type=endpoint
aors=webrtc_test
auth=webrtc_test
use_avpf=yes
media_encryption=dtls
dtls_ca_file=/etc/letsencrypt/archive/xxxxxxxxxxx.com/cert1.pem
dtls_cert_file=/etc/letsencrypt/archive/xxxxxxxxxx.com/cert1.pem
dtls_verify=fingerprint
dtls_setup=actpass
ice_support=yes
media_use_received_transport=yes
rtcp_mux=yes
context=entrantes
disallow=all
allow=opus

The RTP log:

[2020-04-16 13:54:28] VERBOSE[32020][C-00000267] res_rtp_asterisk.c: Sent RTP packet to      88.5.35.95:64260 (type 111, seq 007662, ts 000960, len 000070)
[2020-04-16 13:54:28] VERBOSE[32020][C-00000267] res_rtp_asterisk.c: Sent RTP packet to      88.5.35.95:64260 (type 111, seq 007663, ts 001920, len 000069)
[2020-04-16 13:54:28] VERBOSE[32020][C-00000267] res_rtp_asterisk.c: Sent RTP packet to      88.5.35.95:64260 (type 111, seq 007664, ts 002880, len 000070)
[2020-04-16 13:54:28] VERBOSE[32020][C-00000267] res_rtp_asterisk.c: Sent RTP packet to      88.5.35.95:64260 (type 111, seq 007665, ts 003840, len 000070)

And here the SIP debug of the INVITE:

INVITE sip:600@xxxxxxxxxxxxx.com:5080 SIP/2.0
Via: SIP/2.0/WSS e365p8cqo4oi.invalid;branch=z9hG4bK1952616
Max-Forwards: 69
To: <sip:600@xxxxxxxxxxxxx.com:5080>
From: "test" <sip:webrtc_test@xxxxxxxxxxxx.com:5080>;tag=n666jbbb7v
Call-ID: bfjavj2i62c5vhf2772n
CSeq: 7177 INVITE
Contact: <sip:9p80dn3f@e365p8cqo4oi.invalid;transport=ws;ob>
Content-Type: application/sdp
Session-Expires: 90
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,ice,replaces,outbound
User-Agent: JsSIP 3.3.11
Content-Length: 7339
v=0
o=- 4448799088798269464 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS eOAgk0Cy4UQ2OpJqYPUQelJJ0gmOpknKzAIJ
m=audio 55579 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 88.5.35.95
a=rtcp:55580 IN IP4 88.5.35.95
a=candidate:2322976989 1 tcp 1518280447 192.168.1.71 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:2322976989 2 tcp 1518280446 192.168.1.71 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:3304467501 1 udp 2122260223 192.168.1.71 55579 typ host generation 0 network-id 1 network-cost 10
a=candidate:3304467501 2 udp 2122260222 192.168.1.71 55580 typ host generation 0 network-id 1 network-cost 10
a=candidate:853956089 1 udp 1686052607 88.5.35.95 55579 typ srflx raddr 192.168.1.71 rport 55579 generation 0 network-id 1 network-cost 10
a=candidate:853956089 2 udp 1686052606 88.5.35.95 55580 typ srflx raddr 192.168.1.71 rport 55580 generation 0 network-id 1 network-cost 10
a=ice-ufrag:hpgo
a=ice-pwd:mkC6lujrLiRR2LegFyKbllxf
a=ice-options:trickle
a=fingerprint:sha-256 DA:DA:13:4C:08:8C:06:9F:DC:C7:C8:4C:E8:3D:F5:8F:22:C4:E3:27:C1:D1:F6:77:0A:62:DF:66:EB:55:B3:86
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:eOAgk0Cy4UQ2OpJqYPUQelJJ0gmOpknKzAIJ c5c57d91-351c-4170-b73a-9bccef52f9b3
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1

Looks like an ICE problem but the setup look all ok.
¿Any ideas?

Thanks !!!
Richi

The full SIP trace is needed, as well as information about the network layout. It appears ICE is not succeeding, so it can’t find a route for traffic.

Thanks for your help Joshua :wink:

Asterisk is behind a pfSense. It using a local ip 192.168.0.110 and a external IP.
The certificate is based in a domain.
Over pjsip using UDP in the same server we don’t have nat problems.
Chrome is been used in a laptop with a local IP 192.168.1.71 and a external ip 88.5.35.95

Here is a complete SIP trace of the invite:

[2020-04-16 14:38:11] VERBOSE[8862] res_pjsip_logger.c: <--- Received SIP request (7891 bytes) from WSS:88.5.35.95:61295 --->
INVITE sip:600@xxxxxxxxxx.com SIP/2.0
Via: SIP/2.0/WSS e365p8cqo4oi.invalid;branch=z9hG4bK7243745
Max-Forwards: 69
To: <sip:600@xxxxxxxxxx.com>
From: "test" <sip:webrtc_test@xxxxxxxxxx.com>;tag=p0fupjtu1v
Call-ID: l0s84789a8bpku2pe1kq
CSeq: 165 INVITE
Contact: <sip:po58lb6d@e365p8cqo4oi.invalid;transport=ws;ob>
Content-Type: application/sdp
Session-Expires: 90
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,ice,replaces,outbound
User-Agent: JsSIP 3.3.11
Content-Length: 7344

v=0
o=- 7454254421304841860 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2
m=audio 53624 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 88.5.35.95
a=rtcp:53625 IN IP4 88.5.35.95
a=candidate:3304467501 1 udp 2122260223 192.168.1.71 53624 typ host generation 0 network-id 1 network-cost 10
a=candidate:3304467501 2 udp 2122260222 192.168.1.71 53625 typ host generation 0 network-id 1 network-cost 10
a=candidate:2322976989 1 tcp 1518280447 192.168.1.71 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:2322976989 2 tcp 1518280446 192.168.1.71 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:853956089 1 udp 1686052607 88.5.35.95 53624 typ srflx raddr 192.168.1.71 rport 53624 generation 0 network-id 1 network-cost 10
a=candidate:853956089 2 udp 1686052606 88.5.35.95 53625 typ srflx raddr 192.168.1.71 rport 53625 generation 0 network-id 1 network-cost 10
a=ice-ufrag:OKCN
a=ice-pwd:RSCjC9ieFfqAYua/oAXHfmrU
a=ice-options:trickle
a=fingerprint:sha-256 AC:87:27:6E:2D:49:20:A2:35:29:58:2B:E9:0D:4A:BD:A1:2F:F3:A6:2A:AF:15:B4:BF:21:ED:0C:41:70:3F:D2
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2 fab0f177-8e17-41d2-8710-46a5207be8e7
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:4235530459 cname:dB5v5mqOdF4yQ3NQ
a=ssrc:4235530459 msid:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2 fab0f177-8e17-41d2-8710-46a5207be8e7
a=ssrc:4235530459 mslabel:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2
a=ssrc:4235530459 label:fab0f177-8e17-41d2-8710-46a5207be8e7
m=video 53626 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
c=IN IP4 88.5.35.95
a=rtcp:53628 IN IP4 88.5.35.95
a=candidate:3304467501 1 udp 2122260223 192.168.1.71 53626 typ host generation 0 network-id 1 network-cost 10
a=candidate:3304467501 2 udp 2122260222 192.168.1.71 53628 typ host generation 0 network-id 1 network-cost 10
a=candidate:2322976989 1 tcp 1518280447 192.168.1.71 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:2322976989 2 tcp 1518280446 192.168.1.71 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:853956089 1 udp 1686052607 88.5.35.95 53626 typ srflx raddr 192.168.1.71 rport 53626 generation 0 network-id 1 network-cost 10
a=candidate:853956089 2 udp 1686052606 88.5.35.95 53628 typ srflx raddr 192.168.1.71 rport 53628 generation 0 network-id 1 network-cost 10
a=ice-ufrag:OKCN
a=ice-pwd:RSCjC9ieFfqAYua/oAXHfmrU
a=ice-options:trickle
a=fingerprint:sha-256 AC:87:27:6E:2D:49:20:A2:35:29:58:2B:E9:0D:4A:BD:A1:2F:F3:A6:2A:AF:15:B4:BF:21:ED:0C:41:70:3F:D2
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2 6b150087-1df6-469d-b734-27399e7e0316
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=ssrc-group:FID 1189404513 2550184438
a=ssrc:1189404513 cname:dB5v5mqOdF4yQ3NQ
a=ssrc:1189404513 msid:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2 6b150087-1df6-469d-b734-27399e7e0316
a=ssrc:1189404513 mslabel:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2
a=ssrc:1189404513 label:6b150087-1df6-469d-b734-27399e7e0316
a=ssrc:2550184438 cname:dB5v5mqOdF4yQ3NQ
a=ssrc:2550184438 msid:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2 6b150087-1df6-469d-b734-27399e7e0316
a=ssrc:2550184438 mslabel:ggGSNU8I61oOHDViO3oZbGPeO0iUTRE4vqI2
a=ssrc:2550184438 label:6b150087-1df6-469d-b734-27399e7e0316

This is the same call in the Chrome side:

SIP/2.0 200 OK
Via: SIP/2.0/WSS e365p8cqo4oi.invalid;rport=61295;received=88.5.35.95;branch=z9hG4bK8997391
Call-ID: l0s842bl5qol918493s1
From: "test" <sip:webrtc_test@xxxxxxxxx.com>;tag=keohj6aaif
To: <sip:600@xxxxxxxxx.com>;tag=c0d232aa-7d05-4519-82c8-ce47e9376d08
CSeq: 1871 INVITE
Server: Asterisk
Contact: <sip:192.168.0.110:8089;transport=ws>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 90;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:  1746

v=0
o=- 144756409 4 IN IP4 192.168.0.110
s=Asterisk
c=IN IP4 192.168.0.110
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1
m=audio 19512 UDP/TLS/RTP/SAVPF 8 0 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 BC:E7:43:42:CD:8C:FF:04:E1:79:AA:94:15:71:6B:E2:4A:1F:C5:FC:74:A4:18:41:52:38:EE:86:38:26:D5:41
a=ice-ufrag:730864c073be134968dc90f7550d2fa2
a=ice-pwd:6c3d0b5f0d5a9f1a135b6bf52509c2b9
a=candidate:Hc0a8006e 1 UDP 2130706431 192.168.0.110 19512 typ host
a=candidate:S5aa02db3 1 UDP 1694498815 xx.xx.xx.xx 27437 typ srflx raddr 192.168.0.110 rport 19512
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:1785668518 cname:c4f017a6-64a2-406c-8c6d-bd7f7c3d4fd7
a=msid:6f6c8f19-7b8b-4817-8a84-dae4143270b7 c4c5a240-54fb-4d25-bdd5-9692e65387eb
a=rtcp-fb:* transport-cc
a=mid:0
m=video 19512 UDP/TLS/RTP/SAVPF 102 96
a=connection:new
a=setup:active
a=fingerprint:SHA-256 BC:E7:43:42:CD:8C:FF:04:E1:79:AA:94:15:71:6B:E2:4A:1F:C5:FC:74:A4:18:41:52:38:EE:86:38:26:D5:41
a=ice-ufrag:730864c073be134968dc90f7550d2fa2
a=ice-pwd:6c3d0b5f0d5a9f1a135b6bf52509c2b9
a=rtpmap:102 H264/90000
a=fmtp:102 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:317370228 cname:a40485db-9478-450b-a0a9-57d1c839e9bc
a=msid:6f6c8f19-7b8b-4817-8a84-dae4143270b7 5d698a4c-4ba2-4437-86fa-40ba8b568539
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* nack
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=mid:1

Thank you again :wink:

I meant the entire SIP trace for the call. ICE works by exchanging candidates (IP address/port) which can be used for communicating. You have to see both sides to understand what the possibilities are, and then based on that further isolate things down. You could also do a Wireshark capture of the traffic and look for STUN packets to see if any are going out or coming in. At least one candidate has to be viable for media to flow.

Looks like there is one candidate in both side with the correct IP:

ASTERISK SIDE:
a=candidate:853956089 1 udp 1686052607 88.5.35.95 53624 typ srflx raddr 192.168.1.71 rport 53624 generation 0 network-id 1 network-cost 10

CHROME SIDE (xx.xx.xx.xx has our external Asterisk IP)
a=candidate:S5aa02db3 1 UDP 1694498815 xx.xx.xx.xx 27437 typ srflx raddr 192.168.0.110 rport 19512

Yes, looks that there is traffic from Asterisk to Chrome

We’re missing something … but not sure what :frowning:

That would mean it’s not getting a response from Chrome, so you’d need to investigate outside of Asterisk or enable port forwarding in the firewall and configure rtp.conf to also place your public IP address in the ICE candidates as a host candidate.

Sorry, I forgot to tell you that this test is just a prompt in Asterisk. So the sound is going just from Asterisk to Chrome. That’s why the direction is only from Asterisk to Chrome

That doesn’t matter, STUN traffic has to go bidirectionally to consider it a viable path.

Ok, understood. So … do you think the problem is Chrome --> Asterisk direction?.
In rtp.con we just added the candidates:

[general]
rtpstart=10000
rtpend=20000
rtpchecksums=no
dtmftimeout=3000
rtcpinterval=5000
;strictrtp=yes esto funciona pjsip pero no webrtc
strictrtp=no
icesupport=yes
stunaddr=stun.l.google.com:19302

[ice_host_candidates]
192.168.0.110 => xx.xx.xx.xx

But still no audio :frowning:

Based on the packet capture you provided, I did not see responses to the STUN messages so either Chrome isn’t getting the STUN requests or its responses are being blocked.

Thanks for that.
We’ll investigate that further and we’ll update this ticket with the result

:wink:

It’s solved now.
It was smth as stupid as the codecs.

We had this in pjsip.conf --> allow=alaw,ulaw,h263,h264,vp8
After changing it to --> allow=opus,alaw
… it works !!

I’m leaving here the complete setup in case it helps to someone in the future:

RTP

[general]
rtpstart=10000
rtpend=20000
rtpchecksums=no
dtmftimeout=3000
rtcpinterval=5000
strictrtp=no
icesupport=yes
stunaddr=stun.l.google.com:19302
[ice_host_candidates]
192.168.0.110 => xx.xx.xx.xx (public ip)

PJSIP

[wss]
type=transport
protocol=wss
bind=0.0.0.0
async_operations=1
allow_reload=yes
symmetric_transport=no

[webrtc_test]
type=aor
max_contacts=1
remove_existing=yes
[webrtc_test]
type=auth
auth_type=userpass
username=webrtc_test
password=xxxxxxxxxxx
[webrtc_test]
type=endpoint
aors=webrtc_test
auth=webrtc_test
dtls_ca_file=/etc/letsencrypt/archive/xxxxxxxxxx.com/cert1.pem
dtls_cert_file=/etc/letsencrypt/archive/xxxxxxxxxx.com/cert1.pem
rtp_symmetric=yes
force_rport=yes
webrtc=yes
context=entrantes
disallow=all
allow=opus,alaw
transport=wss

Thanks Joshua for your help with this issue :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.