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.
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.
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.
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.
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.
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
ā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.
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.
