There was no sound on the call

Asterisk Asterisk SIP
#1

When I dialed the phone from the web page, I was able to make a successful call, but neither party could hear the voice. The log appears as follows:

[Dec 12 16:25:18] DEBUG[32285][C-0000001f]: audiohook.c:309 audiohook_read_frame_both: Failed to get 160 samples from read factory 0x390f3c8
[Dec 12 16:25:18] DEBUG[32285][C-0000001f]: audiohook.c:272 audiohook_read_frame_both: Read factory 0x390f3c8 and write factory 0x390fe08 both fail to provide 160 samples.

I hope I can solve this problem but I don’t know how to solve it. Right

#2

Is it a SIP call? Are you or the remote sides behind NAT? If SIP have you done a packet capture or used “rtp set debug on” to see if media is flowing?

#3

I used sipml5 on the web side to dial another linephone client, which is on the same LAN as the asterisk service.After the call, I tried to listen to the recording. I could hear the sound in the recording.The following is the log I showed using “RTP set debug on”.

Connected to Asterisk certified/13.21-cert4 currently running on asterisk13-ceert (pid = 99399)
[Dec 12 19:37:54] ERROR[100669]: tcptls.c:695 handle_tcptls_connection: Problem setting up ssl connection: error:00000001:lib(0):func(0):reason(1), Internal SSL error
[Dec 12 19:37:54] WARNING[100669]: tcptls.c:782 handle_tcptls_connection: FILE * open failed!
== WebSocket connection from ‘192.168.1.88:64237’ for protocol ‘sip’ accepted using version ‘13’
– Registered SIP ‘698000099’ at 192.168.1.88:64237
== DTLS ECDH initialized (automatic), faster PFS enabled
== DTLS ECDH initialized (automatic), faster PFS enabled
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
[Dec 12 19:37:57] NOTICE[100670][C-00000008]: chan_sip.c:10405 process_sdp: Received SAVPF profle in audio offer but AVPF is not enabled, enabling: audio 61497 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
– Executing [9003@test:1] Macro(“SIP/698000099-00000010”, “startrecord”)
– Executing [s@macro-startrecord:1] NoOp(“SIP/698000099-00000010”, “开始录音”)
– Executing [s@macro-startrecord:2] Set(“SIP/698000099-00000010”, “PATH=/appdata/record/2019/12/12”)
– Executing [s@macro-startrecord:3] Set(“SIP/698000099-00000010”, “CALLFILENAME=1576150677.122-698000099-s”)
– Executing [s@macro-startrecord:4] MixMonitor(“SIP/698000099-00000010”, “/appdata/record/2019/12/12/1576150677.122-698000099-s.wav,b”)
== Begin MixMonitor Recording SIP/698000099-00000010
– Executing [s@macro-startrecord:5] Set(“SIP/698000099-00000010”, “app_filepath=/appdata/record/2019/12/12/1576150677.122-698000099-s.wav”)
– Executing [s@macro-startrecord:6] Set(“SIP/698000099-00000010”, “CDR(filepath)=/appdata/record/2019/12/12/1576150677.122-698000099-s.wav”)
– Executing [9003@test:2] Dial(“SIP/698000099-00000010”, “SIP/9003,120”)
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
– Called SIP/9003
– SIP/9003-00000011 is ringing
– SIP/9003-00000011 is ringing
– Registered SIP ‘698000099’ at 192.168.1.88:63851
– SIP/9003-00000011 answered SIP/698000099-00000010
– Channel SIP/9003-00000011 joined ‘simple_bridge’ basic-bridge <98b2d9d7-eec0-41b6-a450-8e37bbf1ff2a>
– Channel SIP/698000099-00000010 joined ‘simple_bridge’ basic-bridge <98b2d9d7-eec0-41b6-a450-8e37bbf1ff2a>
[Dec 12 19:38:00] WARNING[100678][C-00000008]: res_rtp_asterisk.c:2612 __rtp_recvfrom: PJ ICE Rx error status code: 370400 ‘Bad Request’.
[Dec 12 19:38:00] WARNING[100678][C-00000008]: res_rtp_asterisk.c:2612 __rtp_recvfrom: PJ ICE Rx error status code: 370400 ‘Bad Request’.
[Dec 12 19:38:00] WARNING[100678][C-00000008]: res_rtp_asterisk.c:2612 __rtp_recvfrom: PJ ICE Rx error status code: 370400 ‘Bad Request’.
[Dec 12 19:38:00] WARNING[100678][C-00000008]: res_rtp_asterisk.c:2612 __rtp_recvfrom: PJ ICE Rx error status code: 370400 ‘Bad Request’.
[Dec 12 19:38:01] DEBUG[100678][C-00000008]: res_rtp_asterisk.c:5525 ast_rtp_read: RTP NAT: Got audio from other end. Now sending to address 192.168.1.205:7076
Got RTP packet from 192.168.1.205:7076 (type 00, seq 000004, ts 005760, len 000160)
Sent RTP packet to 192.168.1.88:61497 (type 00, seq 003774, ts 005760, len 000160)
Got RTP packet from 192.168.1.205:7076 (type 00, seq 000005, ts 005920, len 000160)
Sent RTP packet to 192.168.1.88:61497 (type 00, seq 003775, ts 005920, len 000160)
Got RTP packet from 192.168.1.205:7076 (type 00, seq 000006, ts 006080, len 000160)
Got RTP packet from 192.168.1.205:7076 (type 00, seq 000007, ts 006240, len 000160)
Sent RTP packet to 192.168.1.88:61497 (type 00, seq 003776, ts 006080, len 000160)
Sent RTP packet to 192.168.1.88:61497 (type 00, seq 003777, ts 006240, len 000160)
Got RTP packet from 192.168.1.205:7076 (type 00, seq 000008, ts 006400, len 000160)
Sent RTP packet to 192.168.1.88:61497 (type 00, seq 003778, ts 006400, len 000160)
Got RTP packet from 192.168.1.205:7076 (type 00, seq 000009, ts 006560, len 00016

#4

Ah, you are using WebRTC. You didn’t mention that originally and this changes things. I’d highly suggest using the latest mainline 13 release, and also ensuring you are building Asterisk using bundled PJSIP[1]. I would also suggest breaking down the scenario to just debugging the WebRTC part initially.

If you plan on deploying WebRTC at all I would also suggest learning about ICE/STUN/DTLS-SRTP, as these are fundamental aspects of WebRTC. When things go wrong these are what you have to dig into and investigate.

[1] https://blogs.asterisk.org/2016/03/16/asterisk-13-8-0-now-easier-pjsip-install-method/

#5

Thanks, but the problem I have now is that I was able to use webRTC to make phone calls normally before this.Now if you do not use webRTC, you can make a normal phone call. After using webRTC, you can dial normally to answer the phone, but the two sides cannot hear each other’s voice after putting through the phone.I’ve seen the recordings, there’s sound in there

#6

Thank you. The problem has been solved. It’s the problem of self-signed SSL certificates

#7

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