Asterisk server audio issue for some networks

Asterisk Asterisk Support
1

I have configured the asterisk server for a calling. But the issue i am facing audio issue for some networks for some it works well tried every possible solution i can get but no outcome so trying to reach

2

On Friday 28 November 2025 at 21:54:29, Rushikesh-Zealconnec via Asterisk
Community wrote:

I have configured the asterisk server for a calling. But the issue i am
facing audio issue for some networks for some it works well tried every
possible solution i can get but no outcome so trying to reach

Based on the information you have given us, we have no idea what the problem
is.

We have no idea what your network setup is, whether you have routers / NAT /
double NAT between Asterisk and the endpoints, and not even what you mean by
“audio issue” (most likely are no audio, one-way audio, distorted audio,
delayed audio or intermittent audio, but those are just guesses).

Give us enough information to be able to reproduce your setup, and we might
have an idea regarding what’s wrong.

Start from stuff such as:

  • what operating system and version?
  • which version of Asterisk?
  • how was Asterisk installed (compiled from source, distribution package)?
  • what’s your network setup (routers, NAT)?
  • what are the endpoint devices (phones) making / receiving the calls?
  • what’s the simplest dialplan you can show us which displays the problem?
  • what is the problem?
  • what’s in the Invite to set up a call which shows the problem?
  • what’s in the 200 OK (SDP) for the same call?

Oh, and just as an aside, if you’ve “tried every possible solution” then it
clearly just doesn’t work :slight_smile:

Antony.

–
What do you call a dinosaur with only one eye? A Doyouthinkesaurus.

3

Hi,

Thanks for your reply. I’m sharing the detailed environment information as requested so the issue can be reproduced and analyzed properly.

System Information

  • Operating System: Ubuntu 24.04

  • Asterisk Version: Asterisk 20.17.0

  • Installation Method: Compiled from source

  • Hosting Environment: AWS EC2 instance inside a VPC

Network Setup

  • The Asterisk server is inside a VPC, so effectively it is behind NAT.

  • The server is accessed through an Application Load Balancer (ALB) for WSS signaling.

  • RTP media is expected to reach Asterisk directly (UDP).

  • No on-prem routers, only AWS networking.

  • Security group is open for SIP/WSS and RTP ranges.

Endpoints

  • The calling endpoint is a web browser (WebRTC).

  • The callee can be any SIP endpoint or device.

Transport Configuration

Running pjsip show transports returns:

Transport:  transport-tls   tls   0  0   0.0.0.0:5061
Transport:  transport-wss   wss   0  0   0.0.0.0:8089

Attaching some configuration files

ALB Public ip 3.7.67.101

Instance Public ip 13.204.248.46

rtp.conf

[general]
rtpstart=49152
rtpend=65535
externip=13.204.248.46
icesupport=yes
icesupportforce=yes
icesupportturnauto=yes
stunaddr=stun.l.google.com:19302
jbenable=yes
jbforce=yes
jbmaxsize=200
jbresyncthreshold=1000
external_media_address=13.204.248.46
external_signaling_address=3.7.67.101
localnet=10.0.0.0/8     ; Covers your 10.x.x.x internal IPs
localnet=172.17.0.0/12  ; Covers your 172.17.x.x Docker/internal IPs
;localnet=10.0.4.46/32
; Enable RTCP mux (combined RTP + RTCP)
rtcp_mux=yes
rtp_debug=yes

pjsip.conf

[webrtc]
stun_server=stun:stun.l.google.com:19302
turn_server=turn:13.204.248.46:3478?transport=udp
turn_username=zeal
turn_password=zeal123
[transport-tls]
type=transport
protocol=tls
method=tlsv1_2
bind=0.0.0.0:5061
verify_server=no
external_signaling_address=3.7.67.101
external_media_address=13.204.248.46
local_net=10.0.4.46/32
local_net=10.0.0.0/8
local_net=172.17.0.0/12
[transport-wss]
type=transport
protocol=wss
bind=0.0.0.0:8089
external_media_address=13.204.248.46
external_signaling_address=3.7.67.101
method=tlsv1_2
allow_reload=yes
;local_net=10.0.4.46/32
local_net=10.0.0.0/8
local_net=172.17.0.0/12

[webrtc-client]
type=endpoint
transport=transport-wss
context=internal
disallow=all
allow=g722
allow=opus
allow=ulaw
allow=alaw
aors=webrtc-client
auth=webrtc-client
webrtc=yes
ice_support=yes
use_avpf=yes
dtls_auto_generate_cert=yes
media_encryption=dtls
rtcp_mux=yes
force_rport=yes
rewrite_contact=yes
rtp_symmetric=yes
force_avp=no
direct_media=no
inband_progress=yes
rtp_keepalive=15

[webrtc-client]
type=aor
max_contacts=50
remove_existing=yes

[webrtc-client]
type=auth
auth_type=userpass
username=zeal
password=zeal123

extension.conf

[outgoing]

exten => _X.,1,NoOp(Outbound — PROVIDER header REQUIRED)

    ; --- Read provider header ---
    same => n,Set(PROVIDER=${TOLOWER(${PJSIP_HEADER(read,PROVIDER)})})

    ; Reject call if provider header missing
    same => n,GotoIf($["${PROVIDER}" = ""]?reject,1)

    ; --- Only add + in front, no stripping ---
    same => n,Set(DIALNUM=+${EXTEN})

    ; --- Routing based on provider ---
    same => n,GotoIf($["${PROVIDER}"="ringover"]?ringover,1)
    same => n,GotoIf($["${PROVIDER}"="acefone"]?acefone,1)
    same => n,GotoIf($["${PROVIDER}"="didlogic"]?didlogic,1)

    ; Unknown provider -> reject
    same => n,Goto(reject,1)

;==========================================
; RINGOVER ROUTE
;==========================================
exten => ringover,1,NoOp(PROVIDER=ringover)
    same => n,Set(CALL_NAME=${PJSIP_HEADER(read,X-Call-Name)})
    same => n,ExecIf($["${CALL_NAME}"=""]?Set(CALL_NAME=${CALLERID(num)}))
    same => n,Set(CALLFILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${CALL_NAME}-${DIALNUM})
    same => n,Set(RECDIR=/var/spool/asterisk/monitor)
    same => n,ExecIf(!${STAT(e,${RECDIR})}?System(mkdir -p ${RECDIR} && chown asterisk:asterisk ${RECDIR}))
    same => n,MixMonitor(${RECDIR}/${CALLFILENAME}.wav,,/usr/local/bin/ast_postrec.sh ${RECDIR}/${CALLFILENAME}.wav)
    same => n,Dial(PJSIP/${DIALNUM}@ringover-outbound,60)
    same => n,StopMixMonitor()
    same => n,Hangup()

;==========================================
; ACEFONE ROUTE
;==========================================
exten => acefone,1,NoOp(PROVIDER=acefone)
    same => n,Set(CALL_NAME=${PJSIP_HEADER(read,X-Call-Name)})
    same => n,ExecIf($["${CALL_NAME}"=""]?Set(CALL_NAME=${CALLERID(num)}))
    same => n,Set(CALLFILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${CALL_NAME}-${DIALNUM})
    same => n,Set(RECDIR=/var/spool/asterisk/monitor)
    same => n,ExecIf(!${STAT(e,${RECDIR})}?System(mkdir -p ${RECDIR} && chown asterisk:asterisk ${RECDIR}))
    same => n,MixMonitor(${RECDIR}/${CALLFILENAME}.wav,,/usr/local/bin/ast_postrec.sh ${RECDIR}/${CALLFILENAME}.wav)
    same => n,Dial(PJSIP/${DIALNUM}@acefone-outbound,60)
    same => n,StopMixMonitor()
    same => n,Hangup()

;==========================================
; DIDLOGIC ROUTE
;==========================================
exten => didlogic,1,NoOp(PROVIDER=didlogic)
    same => n,Set(CALL_NAME=${PJSIP_HEADER(read,X-Call-Name)})
    same => n,ExecIf($["${CALL_NAME}"=""]?Set(CALL_NAME=${CALLERID(num)}))
    same => n,Set(CALLFILENAME=${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${CALL_NAME}-${DIALNUM})
    same => n,Set(RECDIR=/var/spool/asterisk/monitor)
    same => n,ExecIf(!${STAT(e,${RECDIR})}?System(mkdir -p ${RECDIR} && chown asterisk:asterisk ${RECDIR}))
    same => n,MixMonitor(${RECDIR}/${CALLFILENAME}.wav,,/usr/local/bin/ast_postrec.sh ${RECDIR}/${CALLFILENAME}.wav)
    same => n,Dial(PJSIP/${DIALNUM}@didlogic-outbound,60)
    same => n,StopMixMonitor()
    same => n,Hangup()

;==========================================
; REJECT CALL
;==========================================
exten => reject,1,NoOp(Rejecting call — missing or invalid PROVIDER header)
    same => n,Hangup(403)

[internal]
; Route any dialed digits (PSTN) to outgoing context (so WebRTC can call external numbers)
exten => _X.,1,Progress()                          ; Early media for WebRTC
same => n,NoOp(Internal -> Outgoing for ${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)                ; Delegate to correct Dial syntax

sip.conf

[general]
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
canreinvite=no
directrtpsetup=yes
rtcachefriends=yes
rtupdate=yes

turnserver.conf


listening-port=3478
tls-listening-port=5349

# Authentication
fingerprint
lt-cred-mech
user=zeal:zeal123
realm=test.apis.platform.zealconnect.com

# Certificates (Let’s Encrypt)
cert=/etc/letsencrypt/live/test.apis.platform.zealconnect.com/fullchain.pem
pkey=/etc/letsencrypt/live/test.apis.platform.zealconnect.com/privkey.pem

# Network config
listening-ip=13.204.248.46
external-ip=13.204.248.46

# Security
no-loopback-peers
no-multicast-peers

# WebRTC optimizations
no-tcp-relay
# Enable detailed logs for debugging
#log-file=/var/log/coturn.log
verbose

SIP INVITE For successfull call with audio

INVITE sip:919503617645@test.apis.platform.zealconnect.com SIP/2.0
Via: SIP/2.0/WSS e898us5cub1c.invalid;branch=z9hG4bK5757376
To: <sip:919503617645@test.apis.platform.zealconnect.com>
From: <sip:webrtc-client@test.apis.platform.zealconnect.com>;tag=o635je1s0v
CSeq: 2 INVITE
Call-ID: cm3f223vu33ki6tkacm5
Max-Forwards: 70
Authorization: Digest algorithm=MD5, username="zeal", realm="asterisk", nonce="1764393874/488a3265effb7c8a24c23669631c569a", uri="sip:919503617645@test.apis.platform.zealconnect.com", response="e833ff2fa9ab3da86a990f010758038c", opaque="0bd4d9e21fef08c3", qop=auth, cnonce="121o9neia7h8", nc=00000001
X-Call-Name: call_1764393872191_bookingId_B5MCHQ%232121982_userName_Yogesh
Provider: didlogic
Contact: <sip:klpvkatr@e898us5cub1c.invalid;transport=ws;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIP.js/0.21.1
Content-Type: application/sdp
Content-Length: 1684

v=0
o=- 68966385922436228 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS d41b11c0-d491-4254-8595-c037c7422be2
m=audio 57852 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
c=IN IP4 103.122.147.87
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1509968982 1 udp 2122260223 192.168.0.112 57852 typ host generation 0 network-id 1 network-cost 10
a=candidate:4115311976 1 udp 1686052607 103.122.147.87 57852 typ srflx raddr 192.168.0.112 rport 57852 generation 0 network-id 1 network-cost 10
a=candidate:617590478 1 tcp 1518280447 192.168.0.112 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=ice-ufrag:5mLf
a=ice-pwd:zkkauaW8Hq8i5487zbVcHt+H
a=ice-options:trickle
a=fingerprint:sha-256 EC:FD:2B:DF:A9:24:2D:EC:5C:18:F9:EE:A2:3D:1E:95:50:91:F0:9F:CA:C8:E0:30:94:BC:A6:DC:FC:84:9D:EB
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=sendrecv
a=msid:d41b11c0-d491-4254-8595-c037c7422be2 c54eaaeb-6f30-4416-b107-25baea3c0487
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:3991767025 cname:hFcBBqZceGklgC/j
a=ssrc:3991767025 msid:d41b11c0-d491-4254-8595-c037c7422be2 c54eaaeb-6f30-4416-b107-25baea3c0487

Sat Nov 29 2025

SIP Invite for No Audio

INVITE sip:919503617645@test.apis.platform.zealconnect.com SIP/2.0
Via: SIP/2.0/WSS 1n6k34b9igl1.invalid;branch=z9hG4bK6914971
To: <sip:919503617645@test.apis.platform.zealconnect.com>
From: <sip:webrtc-client@test.apis.platform.zealconnect.com>;tag=mndbekm5du
CSeq: 2 INVITE
Call-ID: 8oml5eul58l7991rad9t
Max-Forwards: 70
Authorization: Digest algorithm=MD5, username="zeal", realm="asterisk", nonce="1764394025/c5d0cd3dfb1be8ec09f92eb952d98ee2", uri="sip:919503617645@test.apis.platform.zealconnect.com", response="fc29584fdb07c3bb7decd27a1838d3b9", opaque="0968de920aac0106", qop=auth, cnonce="k8lnuh4nlocb", nc=00000001
X-Call-Name: call_1764394022220_bookingId_B5MCHQ%232121982_userName_Yogesh
Provider: didlogic
Contact: <sip:nkhk0d58@1n6k34b9igl1.invalid;transport=ws;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIP.js/0.21.1
Content-Type: application/sdp
Content-Length: 1686

v=0
o=- 808260024115289567 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS 55889580-68e5-442c-8787-ddb5c860f121
m=audio 60953 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
c=IN IP4 106.220.87.69
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:2199416557 1 udp 2122260223 10.224.133.187 57140 typ host generation 0 network-id 1 network-cost 10
a=candidate:365955124 1 udp 1686052607 106.220.87.69 60953 typ srflx raddr 10.224.133.187 rport 57140 generation 0 network-id 1 network-cost 10
a=candidate:2108865145 1 tcp 1518280447 10.224.133.187 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=ice-ufrag:9Oz8
a=ice-pwd:v8D4nqd9dU7IC5rcsej5yjBZ
a=ice-options:trickle
a=fingerprint:sha-256 04:99:18:E9:F0:DE:DE:79:CA:DC:D0:15:2F:4C:21:73:EF:05:E6:71:5A:E9:AA:5F:4D:0E:45:FE:F2:53:BB:C2
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=sendrecv
a=msid:55889580-68e5-442c-8787-ddb5c860f121 5db86613-ad4a-42da-92bb-80421748b9cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:3622835805 cname:ZHKszSql5SV2c0Sx
a=ssrc:3622835805 msid:55889580-68e5-442c-8787-ddb5c860f121 5db86613-ad4a-42da-92bb-80421748b9cc

audio.txt (77.1 KB)

no audio.txt (77.2 KB)

No audio for sip calls
4

If any one knows how to fix it please help

5

You said that the server was in an AWS VPC and that all of the on prem locations have “AWS Networking not routers”

This sort of implies that all of the on-prem locations also have AWS VPC and so everything is one giant happy network where it can all communicate with each other without going through a NAT.

And yet you are digging around in 8 year old posts that talk about NAT issues which kind of implies that you have stuff going through a NAT.

You also lump “any SIP endpoint” which is wrong. There are great variations in SIP endpoints both soft phones and desk phones.

Fundamentally let’s please review some basic networking 101

An AWS VPC cloud is used in 2 ways:

  1. To group AWS virtual servers located at AWS into one network out in the cloud, which is accessed by the usual method of public IPs translated to the private numbers in the VPC

  2. To create a bunch of private VPCs all over the place and tie them together using these methods:

Network-to-Amazon VPC connectivity options - Amazon Virtual Private Cloud Connectivity Options

Your post implies you’re going with #2. However, there’s lots of options with #2

One fundamental problem with VPNs is that they have overhead. Which means there’s an MTU change when going through them. Some SIP phone firmware respects this and pays attention to it other firmware ignores it and thus will get trashed when going through a VPN. Note that TCP SIP connections Just Work through a VPN because the TCP/IP stack knows about MTU changes and accounts for them. But, audio uses UDP and so the application now has to know about MTU changes and handle them.

You say this works on some networks and not on others. Well, are all these networks using the same exact mechanism of connectivity in the document link network to network VPC connectivity options? I would bet that there’s a correlation between specific types of VPC connectivity that works and certain that does not.

One of the hugest and biggest lies that Cloud providers repeatedly tell customers like you is, you can be dumb as a box of rocks about wide area network connectivity and the cloud provider will “do all the work for you that’s why cloud is better because any cheap idiot you get off the street can setup a cloud server while it takes a specialized expensive IT tech that understands WAN networking to do on premise”

Well, sir, you are that idiot that does not understand WANS or TCP/IP who bought into that line of baloney from AWS and fell for it hook line and sinker. And now, your lack of knowledge is pulling your pants down.

You need to understand one thing. Cloud providers are liars. Cloud is NOT easier. Nor is it cheaper. And if you want to put together a network of VoIP that works, cloud or otherwise - you need to learn this stuff and not fob it off on someone else.

Noe of this is impossible for you. You can do what the rest of the gurus do and hit the books and learn this stuff. Or you can choose to keep being stupid and assume Cloud Solves Everything.

SOME of your sites are working, SOME are not. Dig into the sites and extensively document all the networking and endpoints used, then compare them all. You’re going to find differences between the WAN networking and applications used with the working sites and the broken sites. Start studying everything involved in those differences. I’ve already given you a good lead to investigate. Learn this stuff. And quit with trying to pay people for knowledge you should know to do your job.

1 Like
6

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