Outbound RTP stream missing

Asterisk Asterisk SIP
1

Hi community! Asterisk noob here. I’ve got an inbound sip trunk and an outbound sip trunk. I am receiving the call on inbound001 doing some JSON lookups to an external app, then sending the call to outbound001. Signaling seems ok, I see INVITEs, 100/183s, 200 OKs and ACKs both in packet caps on Wireshark as well as debug in asterisk. I even see media coming from inbound001 and outbound001 IP addresses. But nothing coming from the Asterisk itself. Debug shows channels join “simple_bridge’ basic-bridge”. I have packet caps available if anyone wants to help dive in on this one! Main diff I seen on successful vs failure is the inbound call on failure:
inbound001 --INVITE (SDP) -->Asterisk
inbound001 <–100 Trying — Asterisk
inbound001 <–183 Session In Progress(SDP) — Asterisk
inbound001 <–200 OK (SDP) — Asterisk
inbound001 --ACK --> Asterisk

on a successful call, signaling flow looks identical, except the inbound001 carrier begins sending RTP after Asterisk sends it’s 183 and that seems to kick everything off in all directions (inbound both ways and outbound both ways):
inbound001 --INVITE (SDP)–>Asterisk
inbound001 <–100 Trying — Asterisk
inbound001 <–183 Session In Progress(SDP)— Asterisk
inbound001 – RTP --> Asterisk
inbound001 <-- RTP – Asterisk
inbound001 <–200 OK (SDP) — Asterisk
inbound001 <-- RTP – Asterisk
inbound001 --ACK --> Asterisk
inbound001 – RTP --> Asterisk

I’m running Asterisk 16.1.1 on CentOS Linux release 7.6.1810 (Core). Currently, this is a no NAT asterisk server directly connected to a coax provider business internet connection. There is also no firewall in front of it at the moment (just trying to remove complexities for the time being).

Thanks in advance!

2

What is the output of “rtp set debug on” for a failure case? If you bump up the debug level in Asterisk (debug in logger.conf to console, and core set debug 9 on console) does anything stand out?

3

Hey jcolp. Thanks for the reply.

I am thinking I have a firewall-cmd issue at the moment. If I add a rich rule specifying just the source, audio works fine 100% of the time. If I remove that rich-rule, i’m back to hit and miss. I ran the debug and log levels you recommended
and absolutely zero audio packets show up on the console. =(

It shows that that it’s learning the remote address as well as putting the 2 call legs together as well as putting them in bridge:

0x7f1d1000cae0 – Strict RTP learning after remote address set to: 192.30.165.76:16128

Peer audio RTP is at port 192.30.165.76:16128

0x7f1dbc007cf0 – Strict RTP learning after remote address set to: 74.120.93.70:17868

Peer audio RTP is at port 74.120.93.70:17868

– SIP/outbound001-0000001d is making progress passing it to SIP/inbound001-0000001c

– SIP/outbound001-0000001d answered SIP/inbound001-0000001c

– Channel SIP/outbound001-0000001d joined ‘simple_bridge’ basic-bridge

– Channel SIP/inbound001-0000001c joined ‘simple_bridge’ basic-bridge

And shows them leaving the bridge when hung up (or times out after 5 or 10 seconds)

<------------>

– Channel SIP/outbound001-0000001d left ‘simple_bridge’ basic-bridge

– Channel SIP/inbound001-0000001c left ‘simple_bridge’ basic-bridge

As far as firewalld/firewall-cmd goes, I’ve got:

Automatic helpers set to ‘yes’

SIP helper enabled:

#firewall-cmd --get-helpers

Q.931 RAS amanda ftp h323 irc netbios-ns pptp proto-gre sane sip snmp tftp

During a call it appears the helpers are working as they are “expecting” connections from the correct media IP addresses:

cat /proc/net/nf_conntrack_expect | grep -v sport=5060 | grep -v dport=53 | grep -v dport=22

156 l3proto = 2 proto=17 src=108.61.23.201 dst=50.209.143.189 sport=0 dport=16299 sip/audio

155 l3proto = 2 proto=17 src=192.30.165.76 dst=50.209.143.189 sport=0 dport=15139 sip/audio

155 l3proto = 2 proto=17 src=50.209.143.189 dst=192.30.165.76 sport=0 dport=16888 sip/audio

155 l3proto = 2 proto=17 src=50.209.143.189 dst=192.30.165.76 sport=0 dport=16889 sip/audio

156 l3proto = 2 proto=17 src=108.61.23.201 dst=50.209.143.189 sport=0 dport=16298 sip/audio

155 l3proto = 2 proto=17 src=192.30.165.76 dst=50.209.143.189 sport=0 dport=15138 sip/audio

4

I’ve never used the SIP helper or firewalld, so I can’t really help in that regard. If it is blocking things though - or modifying the SIP signaling - then that would be bad. Have you tried disabling the SIP helper?

5

I’m running tests now. I’ve forwarded all ports that Asterisk is using 10000-20000 and it seems to be working so far. I’ve got to make some toll free and alas calls. It seems our carrier is doing some least cost routing on our outbound
calls / termination. Depending on the area code, the media addresses end up all over the place.