No Audio When Using MicroSIP (Works Over SIP Trunk)

Hello everyone,

I’m experiencing an issue with audio when making calls using MicroSIP. The call connects successfully, but there’s no audio in either direction. However, when I call over the SIP trunk, everything works perfectly — including audio.

The system is running on an Azure VM. In the Azure network settings, I’ve allowed both inbound and outbound traffic on:

  • Port 5060 (for SIP signaling)
  • Ports 10000–20000 (for RTP/media)

These rules are applied for any protocol.

Despite these settings, audio doesn’t work in MicroSIP. Here are my endpoints:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:4040

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0:5060
local_net=127.0.0.0/16
external_media_address={{ PUBLIC_IP }}
external_signaling_address={{ PUBLIC_IP }}

[transport-tcp-nat]
type=transport
protocol=tcp
bind=0.0.0.0
local_net=127.0.0.0/16
external_media_address={{ PUBLIC_IP }}
external_signaling_address={{ PUBLIC_IP }}

[telnyx]
type=endpoint
transport=transport-udp-nat
context=telnyx
disallow=all
allow=g722
allow=ulaw
allow=alaw
direct_media=no
aors=telnyx
outbound_auth=telnyx
; Configures the endpoint for incoming/outgoing calls and media handling

[telnyx]
type=identify
endpoint=telnyx
match=sip.telnyx.com

[6001]
type=endpoint
context=public
disallow=all
allow=g722
allow=ulaw
auth=6001
aors=6001
set_var=PROJECT_ID=108
transport=transport-tcp-nat
force_rport=yes
ice_support=yes
rewrite_contact=yes

[6001]
type=auth
auth_type=userpass
password=xxxxxxxxx
username=6001

[6001]
type=aor
max_contacts=10

and pjsip show transports displays this:

Transport:  tls_transport             tls      0      0  0.0.0.0:5061
Transport:  transport-tcp-nat         tcp      0      0  0.0.0.0:5060
Transport:  transport-udp             udp      0      0  0.0.0.0:4040
Transport:  transport-udp-nat         udp      0      0  0.0.0.0:5060
Transport:  wss_transport             wss      0      0  0.0.0.0:8089

Do you guys might have any idea of what it may be.
Any help or suggestions would be greatly appreciated!

You need to show an actual SIP trace using “pjsip set logger on” and examine the actual RTP traffic using “rtp set debug on”.

This is 99% of the time a Firewall issue, make sure that in your portal you have firewall policies in place to accept traffic trough port 10000-35000 udp as well as the 5060 udp. Not just on the server itself. Take Linode / Akamai for example even if you open ports tru your terminal you still need to open the ports via their Console in “firewall policies”

I don’t know if this is the best, but I’m getting a lot of spam debug messages from random pings
Working Sip Trunk:
Sip Message:


2025/07/11 15:58:54.458984 172.19.0.5:5060 -> 192.76.120.10:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.76.120.10;rport=5060;received=192.76.120.10;branch=z9hG4bKa5f4.055930d07857f17eadf3ad342a2aa0f2.0
Via: SIP/2.0/UDP 10.239.227.4:6000;rport=6000;received=10.239.227.4;branch=z9hG4bK0tvHvDXjy95DN
Record-Route: <sip:192.76.120.10;lr;r2=on;ftag=22KZZQB5KjB8Q>
Record-Route: <sip:10.255.0.1;lr;r2=on;ftag=22KZZQB5KjB8Q>
Call-ID: 2d59a42b-a3ff-4fcb-9fe8-1621d3d0fb49
From: "+351928024051" <sip:+351928024051@sip.telnyx.com>;tag=22KZZQB5KjB8Q
To: <sip:+351220600820@{PUBLIC IP}>;tag=58d36d9f-f2bf-4ebe-8f36-450e0b89f7e7
CSeq: 101570975 INVITE
Server: Asterisk PBX 18.24.3
Contact: <sip:{PUBLIC IP}:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, INFO
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length:   177

v=0
o=- 1752224848 1752224851 IN IP4 172.19.0.5
s=Asterisk
c=IN IP4 172.19.0.5
t=0 0
m=audio 18388 RTP/AVP 9
a=rtpmap:9 G722/8000
a=ptime:20
a=maxptime:140
a=sendrecv

Sent RTP packet to 50.114.147.11:19398 (type 09, seq 027731, ts 001920, len 000080)
Sent RTP packet to 50.114.147.11:19398 (type 09, seq 027732, ts 002000, len 000080)
Got RTP packet from 50.114.147.11:19398 (type 09, seq 008460, ts 285280, len 000080)
Got RTP packet from 50.114.147.11:19398 (type 09, seq 008461, ts 285360, len 000080)

Microsip:
Sip Message:

2025/07/11 16:00:20.627877 172.19.0.5:5060 -> 62.28.235.114:64091
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.11.0.14:64091;rport=64091;received=62.28.235.114;branch=z9hG4bKPjab59e4a8cb8442058b15b53ce13db4ee;alias
Call-ID: b176b711c7334011ab76a75ebefa5e71
From: "6002" <sip:6001@135.236.108.143>;tag=718fa44e96ee4e218c59e4263f75c835
To: <sip:100@135.236.108.143>;tag=a5636aae-4fca-4c37-a694-04da943f2311
CSeq: 10293 INVITE
Server: Asterisk PBX 18.24.3
Contact: <sip:135.236.108.143:5060;transport=TCP>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, INFO
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   455

v=0
o=- 3961242020 3961242022 IN IP4 172.19.0.5
s=Asterisk
c=IN IP4 172.19.0.5
t=0 0
m=audio 15226 RTP/AVP 9 101
a=ice-ufrag:1e3342364953290138fdab4a73571605
a=ice-pwd:57652b5f08bc82864ced91dc65fa7d3f
a=candidate:Hac130005 1 UDP 2130706431 172.19.0.5 15226 typ host
a=candidate:Hac130005 2 UDP 2130706430 172.19.0.5 15227 typ host
a=rtpmap:9 G722/8000
a=ptime:20
a=maxptime:140
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Sent RTP packet to 10.10.92.94:4032 (type 09, seq 013178, ts 000080, len 000080)
Sent RTP packet to 10.10.92.94:4032 (type 09, seq 013179, ts 000160, len 000080)

What’s strange is that I’ve tested both MicroSIP and Linphone across different networks. So I’m assuming it’s not a firewall problem.

The SDP does not contain the public IP address. It could be because it’s not actually configured to do that (the configuration is not the actual configuration), or due to having multiple transports. You could examine the transport using “pjsip show transport” and see.

Always Firewall Nando you need to examine further.(deeper)!

This address isn’t on the internet, but you are asking it to send media to an address that is:

This is incomplete. It may well need to include both 192.168/16 and 10/8, or subsets of them, although you really need to explain where your network 10 address fits in. (I’ve never seen such a wide range around 127.0.0.0. I have a feeling it already knows 127.0.0.1 and I don’t know the status of the rest of 127.0/16

I’ve fixed that, and now the RTP debug shows it’s sending traffic to my public IP, but I still can’t receive any media.

Endpoints

[transport-tcp-nat]
type=transport
protocol=tcp
bind=0.0.0.0
local_net=127.0.0.0/16
external_media_address={PUBLIC_IP}
external_signaling_address={PUBLIC_IP}

[6001]
type=endpoint
context=public
disallow=all
allow=g722
allow=ulaw
allow=alaw
auth=6001
aors=6001
set_var=PROJECT_ID=108
transport=transport-tcp-nat
ice_support=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no

[6001]
type=auth
auth_type=userpass
password=xxxxxxxxx
username=6001

[6001]
type=aor
max_contacts=10

SIP Debug

INVITE sip:100@{PUBLIC_IP};transport=tcp SIP/2.0
Via: SIP/2.0/TCP {MY PUBLIC IP}:63684;rport;branch=z9hG4bKPja305065d1b3e4201adb8c431c32a91b6;alias
Max-Forwards: 70
From: "6001" <sip:6001@{SERVER PUBLIC_IP}>;tag=5f4f83a397244b838eaf69424dcef9d1
To: <sip:100@{SERVER PUBLIC_IP}>
Contact: <sip:6001@{MY PUBLIC IP}:63684;transport=TCP;ob>
Call-ID: 37638dea4a04483ebad9ba53d7d83256
CSeq: 23296 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: MicroSIP/3.21.6
Authorization: Digest username="6001", realm="asterisk", nonce="1752511012/f597da3dea81f57f7082936a90ab7cb8", uri="sip:100@{SERVER PUBLIC_IP};transport=tcp", response="edd2802a5a09680bb0d5c46357c9a783", algorithm=MD5, cnonce="c4ac712028594a47a05fdd713256be35", opaque="20105dc030444e02", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length:   745

v=0
o=- 3961503412 3961503412 IN IP4 {MY PUBLIC IP}
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4002 RTP/AVP 8 0 9 96 97 98 99 100 101 102 103
c=IN IP4 {MY PUBLIC IP}
b=TIAS:64000
a=rtcp:4003 IN IP4 {MY PUBLIC IP}
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 G7221/16000
a=fmtp:96 bitrate=24000
a=rtpmap:97 G7221/16000
a=fmtp:97 bitrate=32000
a=rtpmap:98 G7221/32000
a=fmtp:98 bitrate=48000
a=rtpmap:99 G7221/32000
a=fmtp:99 bitrate=24000
a=rtpmap:100 G7221/32000
a=fmtp:100 bitrate=32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:102 telephone-event/16000
a=fmtp:102 0-16
a=rtpmap:103 telephone-event/32000
a=fmtp:103 0-16
a=ssrc:829259614 cname:1e3863ca3ea33c5a

RTP Debug

Sent RTP packet to      {MY PUBLIC IP}:4002 (type 09, seq 000612, ts 000080, len 000080)

and as far as my iptables rules go I have this
IPtables Rules

Chain FORWARD (policy DROP 7 packets, 2622 bytes)
  61M   35G DOCKER-ISOLATION-STAGE-1  0    --  *      *       0.0.0.0/0            0.0.0.0/0
  61M   35G DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0
  30M   19G ACCEPT     0    --  *      br-aeab3c66b5ee  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
73023   47M DOCKER     0    --  *      br-aeab3c66b5ee  0.0.0.0/0            0.0.0.0/0
  31M   17G ACCEPT     0    --  br-aeab3c66b5ee !br-aeab3c66b5ee  0.0.0.0/0            0.0.0.0/0

Chain DOCKER (2 references)
   86  4464 ACCEPT     6    --  !br-aeab3c66b5ee br-aeab3c66b5ee  0.0.0.0/0            172.19.0.5           tcp dpt:5060
 2487 1852K ACCEPT     17   --  !br-aeab3c66b5ee br-aeab3c66b5ee  0.0.0.0/0            172.19.0.5           udp dpt:5060

I’ve fixed the issue where RTP packets were not being sent to my public IP, but it’s still not working.
Sent RTP packet to {MY PUBLIC IP}:4002 (type 09, seq 000612, ts 000080, len 000080)

Asterisk is not receiving media. You provided redacted logs for the SDP from the remote side, but not for Asterisk. Asterisk is sending media to what is provided in the SDP, which may or may not be correct if the remote side is behind NAT.

I don’t have any further comments, aside from my past comment and that if Asterisk is providing the correct IP in its SDP, then the problem is outside of Asterisk.

Place local_net=172.19.0.0/16 seem to do the trick

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