Everything is working and I didnt get any error in console. Also, I can able to call from browser and status changing to InCall but the only issue is I could not hear the audio from browser?
Is it normal ? Could someone please help me
Thanks
-- Contact webrtc_client/sips:webrtc_client@xxxxx:50605;transport=ws;rtcweb-breaker=no is now Unknown.
== Endpoint webrtc_client is now Reachable
== Setting global variable ‘SIPDOMAIN’ to ‘xxxx’
== DTLS ECDH initialized (automatic), faster PFS enabled
– Executing [200@default:1] Answer(“PJSIP/webrtc_client-00000000”, “”) in new stack
> 0x7ffab402c7f0 – Strict RTP learning after remote address set to: 122.174.231.175:60011
– Executing [200@default:2] Playback(“PJSIP/webrtc_client-00000000”, “”/var/lib/asterisk/sounds/en/demo-congrats"") in new stack
– <PJSIP/webrtc_client-00000000> Playing ‘/var/lib/asterisk/sounds/en/demo-congrats.slin16’ (language ‘en’)
> 0x7ffab402c7f0 – Strict RTP learning after ICE completion
– Executing [200@default:3] Hangup(“PJSIP/webrtc_client-00000000”, “”) in new stack
== Spawn extension (default, 200, 3) exited non-zero on ‘PJSIP/webrtc_client-00000000’
From the Asterisk CLI enable rtp debug and see where the packets are being sent and make sure they are being sent to the appropriate address. You can use the following commands to enable/disable rtp debug:
CLI> rtp set debug on
CLI> rtp set debug off
Also increase the debug level and enable sip tracing for your channel driver in Asterisk. Then post the results here for the call in question. See Collecting Debug Information on the wiki for how to enable more debugging and sip tracing.
It seems packets are sent to my IP address. please take a look on logs
*CLI> core set verbose 5
Console verbose was 3 and is now 5.
*CLI> core set debug 5
Core debug was OFF and is now 5.
*CLI> module reload logger
Module ‘logger’ reloaded successfully.
*CLI> Asterisk Queue Logger restarted
== WebSocket connection from ‘122.164.218.255:51353’ for protocol ‘sip’ accepted using version ‘13’
– Added contact ‘sips:webrtc_client@122.164.218.255:51353;transport=ws;rtcweb-breaker=no’ to AOR ‘webrtc_client’ with expiration of 200 seconds
– Contact webrtc_client/sips:webrtc_client@122.164.218.255:51353;transport=ws;rtcweb-breaker=no is now Unknown.
== Setting global variable ‘SIPDOMAIN’ to ‘asterisk.org’
== DTLS ECDH initialized (automatic), faster PFS enabled
– Executing [200@default:1] Answer(“PJSIP/webrtc_client-00000001”, “”) in new stack
– Executing [200@default:2] Playback(“PJSIP/webrtc_client-00000001”, “demo-congrats”) in new stack
Sent RTP packet to 122.164.218.255:53847 (type 111, seq 003393, ts 000096, len 000070)
– <PJSIP/webrtc_client-00000001> Playing ‘demo-congrats.slin16’ (language ‘en’)
Sent RTP packet to 122.164.218.255:53847 (type 111, seq 003394, ts 001056, len 000069)
Sent RTP packet to 122.164.218.255:53847 (type 111, seq 003395, ts 002016, len 000070)
Sent RTP packet to 122.164.218.255:53847 (type 111, seq 003396, ts 002976, len 000070)
Sent RTP packet to 122.164.218.255:53847 (type 111, seq 003397, ts 003936, len 000070)
So if Asterisk is sending out the rtp packets and they are going to the right (negotiated/expected) place (ip:port) then the next step is to figure out if they are getting to the browser hosted machine.
The easiest way to do this is is to use something like wireshark and get a packet capture.
Before that I’d double check, and rule out the obvious. For instance make sure the sound on the system is not muted and turned up to a sufficient level. Make sure too the browser itself is not muting the audio (tab mute for instance). Are you expecting the sound to come out a speaker, but headphones are plugged in? etc… Somewhat silly I know but sometimes it’s easy to overlook the obvious
Actually I just learned that if rtp debug is on then if ICE is negotiated then in it will say something along the lines of “(via ICE)” in the output. As this is not shown in your log then chances are ICE negotiation failed, thus DTLS didn’t get negotiated.
WebRTC requires ICE, DTLS, and SRTP. You can’t disable it. They are foundational aspects. If you are planning to use WebRTC in any capacity you need to learn the basics of them including how to debug and understand what is going on. WebRTC can, and WILL, fail to work like you’re seeing.