No audio before first DTMF event

I’m working on an Asterisk app called dev. When users call the extension 1000, they are routed into the dev app with the following dialplan:

exten = 1000,1,NoOp()
same = n,Answer()
same = n,Stasis(dev)
same = n,Wait(1)

In the dev app, a new bridge is created, and the inbound channel is added to the bridge. The app starts recording the bridge and plays audio, after which the caller can input DTMF and speak.

The issue is as follows:

• For some users (e.g., user A), everything works fine, and the inbound audio is recorded correctly.

• However, for other users, their voice isn’t recorded—Asterisk shows a warning indicating “recorder no sound.”

• Strangely, once the user presses any DTMF key, the audio begins working, and everything records as expected from that point.

Troubleshooting Done:

• I used Wireshark to check the RTP and SIP packets, and all the packets are arriving at the PBX as expected.

• I can even play back the audio in Wireshark, confirming that it’s being transmitted.

• All packets are using the G.711 PCMU codec, and I’ve ensured that ulaw is allowed in Asterisk.

Why does this happen, and how can I fix the issue where audio is only properly recorded after the user presses a DTMF key? Thanks

Is the audio actually being read by Asterisk (rtp set debug on will show it)? What does a debug log show[1]?

[1] Collecting Debug Information - Asterisk Documentation

Got  RTP packet from    **SIP server IP**:18110 (type 00, seq 061108, ts 1917881338, len 000160)
Got  RTP packet from    **SIP server IP**:18110 (type 00, seq 061108, ts 1917881338, len 000160)
Sent RTP packet to      127.0.0.1:9908 (type 00, seq 020896, ts 103200, len 000160)
Sent RTP packet to      127.0.0.1:9908 (type 00, seq 020896, ts 103200, len 000160)
[2024-09-23 17:07:48] WARNING[3409078]: app.c:1941 __ast_play_and_record: No audio available on Recorder/ARI-000002c9;1??
[2024-09-23 17:07:48] WARNING[3409078]: app.c:1941 __ast_play_and_record: No audio available on Recorder/ARI-000002c9;1??

I see there are len 160 package come in, and the external media forward to 127.0.0.1:9908. I used wireshark to get the package on port 9908, the 160 len is empty.

So, what I know:

  • RTP package come in normally
  • after ARI external media, the package is empty

What does external media have to do with this? You didn’t mention that in the initial post here.

You need to be extremely specific with what you are doing in ARI and how things are connected and such.

In the dev ARI app, an ‘external media channel’ is created to route audio to an external audio server on port 9908.

That’s not specific enough. How you are using ARI matters, so showing the actual requests/responses and operations is needed.

  • Answer the inbound call (inboundChannel)
  • Create a snoopChannel (which point to the inboundChannel)
  • Create a ‘external media channel’
    (external media channel only pass the audio from snoopChannel to port 9908)

This is my code. I think I typo, it should be snoopChannel.externalMedia
Is this the problem? If yes, why some of the users will work fine?

inboundChannel.externalMedia({
  app: 'externalMedia',
  external_host: `127.0.0.1:9908`,
  format: 'ulaw',
  variables: {
    call_SID: call_SID,
    inOut: 'in',
  },
});

Thanks

Creating channels doesn’t say what you are doing WITH those channels, or how they are being connected or bridged. The state of them when things occur.

For example if you gave an actual full log of the interactions and events (instead of me getting details bit by bit by asking you), it might be immediately obvious to me or someone else what is going on.

I apologize as I am still new to Asterisk. Currently, the only log message I see is a warning stating ‘recorder no sound’ in /var/log/asterisk/messages.

I tried enabling pjsip set logger on, but there are no additional errors or warnings. When using rtp set debug on, it only shows that Asterisk is receiving 160-byte packets and forwarding them to port 9908.

Is there a logging method available that can provide more detailed information about the state of the channels, such as how they are connected or bridged? Or do you suggest I add more logging within the ARI app to monitor the channel states?

Thanks

The “ari set debug on” CLI command will show the events and HTTP requests/responses in modern versions. A core debug[1] is also generally a good idea.

[1] Collecting Debug Information - Asterisk Documentation

Here is the full log of ari debug all on

This log only include one call only,
and at the end of the call, PBX popup WARNING[4054298]: app.c:1941 __ast_play_and_record: No audio available on Recorder/

fullLog.txt (187.3 KB)

What version of Asterisk is this?

Your log file also does not include debug level log for Asterisk itself, which would have provided RTP level and other debugging as well.

I am using Asterisk 18 :smiling_face_with_tear:
Which version should I updgrade to? Will current ARI not work after I upgrade?

Asterisk 18 isn’t a specific version. There have been over 24 releases of 18. I asked because the ARI debug didn’t include the HTTP requests, which would seem to indicate it’s an older version of Asterisk. As I stated also, your debug log file doesn’t include the core debug (from the docs site documentation) alongside the ARI debug.

core show version
Asterisk 18.10.0~dfsg+~cs6.10.40431411-2 built by nobody @ buildd.debian.org on a unknown running Linux on 2022-02-12 18:24:51 UTC

Okay, it’s a Debian build. Uninstall the package and build Asterisk from scratch and try.

And as you can see at the end of that thread:

So, I would try uninstalling/removing the package and using Asterisk as we ship it.

core show version
Asterisk 21.4.3 built by root @ dev on a x86_64 running Linux on 2024-10-02 08:05:56 UTC

I upgraded to Asterisk 21 which is not debian build, but the behavior didn’t improve. The same issue seems to be occurring.

I’ve gathered new logs after the upgrade and uploaded them in the Google log in below.

core_log_asterisk21

In line 2197, there are ‘No audio available on Recorder’ warning.

In line 2321, caller clicked the first time DTMF. After that, audio become normal.

Thanks

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