PJSIP: no audio on bridge between trunks

Hello there,

I have the following setup:

WebAPP <----> twilio PJSIP Trunk <----> Asterisk 16_16 <----> Cisco Gateway <----> PSTN

Anybody at the PSTN can call to my phone number, the cisco gateway answer the call and transfer it to my asterisk. Asterisk answer the call and transfer it to twilio PJSIP Trunk. My users answer the call from a web application connected to the twilio service. Everything on this scenario works properly.

My Problem is when I try to call from the WebAPP to a PSTN number, any RTP that comes from Twilio arrives to Asterisk but are not sent to cisco. The weird part is that every RTP that came from the PSTN through cisco, asterisk and then twilio arrives to the webApp.

When I receive the call from twilio, I just modify the default contexts in order to add an “Answer(500)” before the “Dial()”.

I’ll really appreciate any clue about it.

Best regards,

Carlos

This URL gives you a google document with the configurations and the call log:

After check logs and network packets captures, I noticed that the RTP packets comming from Twilio arrives to asterisk but asterisk is not using them… I don’t know why.

Do they show up when “rtp set debug on” is done? Do you have a firewall in place on the system? A packet capture occurs before firewall.

I’m capturing the packages using tcpdump at the same asterisk. Inside the pcap file are the RTP packets that came from twilio… in that way a firewall is discarted.

Executing “rtp set debug on” I only can see the following all the time:

[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Got RTP packet from 172.24.1.31:46154 (type 00, seq 046554, ts 684855816, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.108:17234 (type 00, seq 002302, ts 684855816, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Got RTP packet from 172.24.1.31:46154 (type 00, seq 046555, ts 684855976, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.108:17234 (type 00, seq 002303, ts 684855976, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Got RTP packet from 172.24.1.31:46154 (type 00, seq 046556, ts 684856136, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.108:17234 (type 00, seq 002304, ts 684856136, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Got RTP packet from 172.24.1.31:46154 (type 00, seq 046557, ts 684856296, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.108:17234 (type 00, seq 002305, ts 684856296, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Got RTP packet from 172.24.1.31:46154 (type 00, seq 046558, ts 684856456, len 000160)
[2023-09-21 18:08:41] VERBOSE[27217][C-0000001f] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.108:17234 (type 00, seq 002306, ts 684856456, len 000160)

172.24.1.31 is my cisco gateway
3.122.181.108 is the twilio media server

As you can see, I only can send RTP to twilio, but asterisk is not receiving RTP packages from twilio.

And is there a firewall on the system blocking the RTP packets from Twilio?

There is not firewall blocking from Twilio 'cause I receive the RTP packets at the asterisk’s network interface:

But, as you see in logs… Asterisk is ignoring them :cry:

[2023-09-21 18:44:09] VERBOSE[28342][C-00000011] pbx.c: Executing [6@ext-trunk:4] Playback(“PJSIP/freshCaller-00000004”, “silence/1”) in new stack
[2023-09-21 18:44:09] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021193, ts 000160, len 000160)
[2023-09-21 18:44:09] VERBOSE[28342][C-00000011] file.c: <PJSIP/freshCaller-00000004> Playing ‘silence/1.gsm’ (language ‘es’)
[2023-09-21 18:44:09] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021194, ts 000320, len 000160)
[2023-09-21 18:44:09] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021195, ts 000480, len 000160)
[2023-09-21 18:44:09] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021196, ts 000640, len 000160)
[2023-09-21 18:44:10] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021197, ts 000800, len 000160)
[2023-09-21 18:44:10] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021198, ts 000960, len 000160)
[2023-09-21 18:44:10] VERBOSE[28342][C-00000011] res_rtp_asterisk.c: Sent RTP packet to 3.122.181.74:16756 (type 00, seq 021199, ts 001120, len 000160)

Thanks for your attention.

Best regards,

Carlos

That packet capture is BEFORE any firewall on the system. Is there a firewall on the system itself using something like iptables?

iptables and firewalld are disabled on this system.

I can give you pcap and asterisk log if you wish…

You should check with iptables -L to make sure there are no rules, as far as I know you can NOT disable iptables on Linux, without either compiling a kernel without, or making sure the modules required for iptables, does not load. Whatever you do with systemctl or similar, is usually just loading some predefined rules, or a daemon handling the rules.

Thanks to all for your responses…

As I said before… there is not firewall rules on this server:

image

After a lot of reading, I found something wear with the PCAP files… please, check the RTP port that the Remote SDP configures:

After that… my asterisk start to send RTP packets to that IP on that PORT:

Nevertheless, when my asterisk sends his own SDP, please, check the port:

image

Finally when the Twilio media server start to send RTP, send the RTP to a different Port:

Is asterisk ignoring the incoming RTP packages because arrives to the wrong port?

PD: The LAN IP Address of this asterisk is 192.168.19.17.

Yes, the port given in SDP is where RTP has to be sent to. Asterisk is listening on that port for it.

It COULD be a broken NAT implementation, changing the port on the outgoing SDP, but not correctly rewriting the port on the actual UDP packets. Would not be the first time a broken NAT implementation makes SIP calls fail.

@Chano… could you please guide to me in order to know how to confirm or discard this “broken NAT implementation”?

I only can manage the Asterisk side of this scenario.

Thanks in advance.

Capture packets either side of router and make sure that they have the correct transformations made. Broken NAT is anything that is done wrongly in the name of NAT, not something for which there is one single test.

Ok… I’ll ask to my ISP to make a network capture on the UTM (they rent me the UTM). I also asked for support at twilio.

After asked for twilio support. They confirmed that they are seeing the same port numbers. I guess that they haven’t a clue about where is the problem :S

Ok… apparently Twilio scaled my case to an upper support level. They shared the PCAP file for an example call and noticed that the SDP information that they receives is different of the information that my asterisk is sending.

I’m asking to get access to the Fortigate at the border of my lan, apparently it enables by default soming called SIP-ALG

https://docs.fortinet.com/document/fortigate/6.2.15/cookbook/000809/sip-pinholes

“apparently it enables by default soming called SIP-ALG”

My advice to anyone encountering a router which has a SIP ALG (Application
Layer Gateway, sometimes known for incomprehensible reasons as a “SIP helper”)
is to turn it off and leave it off.

I have never come across any situation where turning it on makes life better,
and I’ve seen many where it actively introduces problems such as you’re
seeing.

Antony.

@Pooh thanks for the advice. I’ll disable SIP ALG.

I’ve had mixed experiences with SIP ALG/Helper implementations. Sometimes you’d want it to be on, other times you’d like it to be off… My suggestion if our customers have problems that could be related to NAT manipulation, is to to flip it to the opposite of whatever it’s at currently, as that’s usually the setting they need. :wink:

1 Like