Assistance Needed with Asterisk Audio Routing for Speech-to-Text and Text-to-Speech Application

Hi Support Team,

I’m developing an Asterisk-based application that receives audio from a caller, processes it through a Speech-to-Text engine, and sends back generated audio from a Text-to-Speech engine.

I’ve read several posts and Asterisk documentation on this topic but still can’t get it to work correctly.

Current Implementation:

I’m using a Mixing Bridge with three channels: a PJSIP channel, an out_external_media channel, and an in_external_media channel.

  • out_external_media channel: This operates on port 9000, where another server captures the audio and saves it as a WAV file. This part works well—I can hear the caller’s audio clearly in the saved file.

  • in_external_media channel: This operates on port 9001, where another server generates audio and sends it back over port 9001. However, this part does not work—the caller doesn’t hear any audio. (All ports are open on the firewall, so I don’t believe this is a firewall issue. In a previous configuration, I did hear white noise on the caller side, so audio can pass in this direction.)

Asterisk Configuration Files:

/etc/asterisk/extensions.conf

[general]
static=yes
writeprotect=no
clearglobalvars=no

[from-trunk]
; Handle incoming calls from the trunk and route to ARI app
exten => s,1,NoOp(Incoming call to ARI app)
 same => n,Stasis(hello-world)   ; ARI app name as defined in your Python app
 same => n,Hangup()              ; Ensure proper call cleanup

/etc/asterisk/rtp.conf

[general]
rtpstart=10000
rtpend=40000
jitterbuffer=yes
maxjitterbuffer=100
maxjitterinterps=10

/etc/asterisk/pjsip.conf

[transport-ws]
type = transport
protocol = ws
bind = 0.0.0.0:5060 ; Port for WebSocket connection

[transport-udp]
type=transport
protocol=udp ;udp,tcp,tls,ws,wss,flow
bind=0.0.0.0

[siptrunk]
type=endpoint
transport=transport-udp
context=from-trunk
disallow=all
allow=ulaw
aors=siptrunk_aor

[siptrunk_aor]
type=aor
contact=sip:72.1.46.10

[siptrunk_auth]
type=auth
auth_type=userpass
username=640671
password=****

[siptrunk_registration]
type=registration
outbound_auth=siptrunk_auth
server_uri=sip:72.1.46.10
client_uri=sip:640671@72.1.46.10
retry_interval=60

[siptrunk_identify]
type=identify
endpoint=siptrunk
match=72.1.46.10

/etc/asterisk/http.conf

[general]
enabled = yes
bindaddr = 0.0.0.0
bindport = 8088

[ws]
enabled = yes
bindaddr = 0.0.0.0
bindport = 8088

[ari]
enabled = yes

Could you please help identify any misconfigurations or suggest solutions for getting audio output to work on the in_external_media channel? Thanks for your assistance!

Is your server sending RTP packets in the correct interval to Asterisk?

Sending every 20ms - is it the correct one?

I’m suspecting that something is wrong with the connection between the channels

Here are the high level diagram of the architecture

There is no snoop channels at all.
Receiving audio from Asterisk works well, just sending back audio is not working for me - i.e. the caller doesn’t hear the audio

Best Regards
Arkadi

On Fri, 1 Nov 2024 at 20:58 Carlos.Escalona00 via Asterisk Community <notifications@asterisk.discoursemail.com> wrote:

Carlos.Escalona00
November 1

Is your server sending RTP packets in the correct interval to Asterisk?


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

I face a simillar issue when the duration of the audio being injected is less than 5sec. Audio of 10 sec goes fine. What is the duration of audio that you are injecting ?

I have a service that generates 20ms rot packets and send them to Asterisk in an infinite loop.

On Sat, 2 Nov 2024 at 7:37 Sandeep via Asterisk Community <notifications@asterisk.discoursemail.com> wrote:

Sandeep
November 2

I face a simillar issue when the duration of the audio being injected is less than 5sec. Audio of 10 sec goes fine. What is the duration of audio that you are injecting ?


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

Try sending a 10 sec wave file - 160 bytes chunks, sent every 20ms. Check if caller hears the audio.

Thank @Sandeep

Unfortunately, I still can’t hear the audio on the caller’s side. I’m sending audio every 20ms in 160-byte chunks (172 bytes with a 12-byte header). I’ve also muted the PJSIP channel, so audio isn’t being sent from the PJSIP to the bridge.

One odd thing is that in the Asterisk CLI, I see the following log:

Sent RTP packet to 127.0.0.1:9001 (type 00, seq 012804, ts 1003360, len 000160)

It appears as though the audio is going in the opposite direction (from PJSIP to the external channel).

Here are my channels and bridges:

core show channels
Channel                                                          Location                         State   Application(Data)             
UnicastRTP/127.0.0.1:9001-0x55d9ac7bc560                         s@default:1                      Up      Stasis(hello-world)           
Snoop/1730987233.346-0000000f                                    s@default:1                      Up      Stasis(hello-world)           
PJSIP/siptrunk-00000035                                          s@from-trunk:2                   Up      Stasis(hello-world)      

bridge show all
Bridge-ID                            Chans Type            Technology      Duration
f1625f10-1c9f-43e6-8b3e-64b933b6581d     3 stasis          softmix         00:00:35

 bridge show f1625f10-1c9f-43e6-8b3e-64b933b6581d
Id: f1625f10-1c9f-43e6-8b3e-64b933b6581d
Type: stasis
Technology: softmix
Subclass: stasis
Creator: Stasis
Name: 
Video-Mode: talker
Video-Source-Id: 
Num-Channels: 3
Num-Active: 3
Duration: 00:00:43
Channel: PJSIP/siptrunk-00000035
Channel: UnicastRTP/127.0.0.1:9001-0x55d9ac7bc560
Channel: Snoop/1730987233.346-0000000f

@jcolp can you help with that?

BR,
Arkadi

Please don’t tag me, if I have anything of value to add to posts or can provide help then I’ll do so. I don’t have anything to add to this right now.

2 Likes