|Summary:||ASTERISK-20216: Bridged channels both have inbound RTP to Asterisk, but no RTP outbound from Asterisk|
|Reporter:||James Babiak (enki)||Labels:|
|Date Opened:||2012-08-12 00:17:42||Date Closed:||2012-10-30 16:34:50|
|Environment:||AstLinux 1.0.4, Dual core Atom D525 1.8. PBX has a public IP and connects to multiple SIP trunk providers. Remote soft phone is the Counterpath Bria Android application running on ICS.||Attachments:||( 0) example.pcap|
( 1) extension_configs.txt
( 2) sip_configs.txt
( 3) sip-debug.txt
|Description:||I'm having an unusual issue when trying to place external calls via my remote soft phone extension (cell phone on AT&T 3G). Long story short, while the SIP traffic is passed OK, and both endpoints send RTP traffic to the PBX, the PBX does not relay either RTP stream to the other endpoint or even recognize receipt of them. The sip trace looks fine, and I confirmed the receipt of RTP traffic via packet captures. However, when I run an rtp debug, I do not see any activity on the console. This is only affecting calls from remote extensions to external numbers (ie: extension 201 remote phone calling 8005551212). If I call a local extension (ie: 123) located behind the PBX (NAT'd), it works fine. If I call an extension on the PBX (ie: a meetme conf, IVR, etc.) it works fine. If I call the remote extension in question from a local extension, it works fine as well. But if I dial a number that will go out to an external SIP Trunk, I get no audio on either side. I've tried three different SIP ITSPs, with no difference. I've also tried every possible combination of UDP/TCP/TLS and RTP/SRTP with no difference. Additionally, I just recently upgraded my PBX from Asterisk 1.4, and this problem was not present on that version. It only manifested itself after the upgrade, which leads me to believe it's a bug inside of 1.8. |
The UA's sip.conf is setup properly, and clearly configured to stay in the media path (ie: directmedia=no, nat=yes). I've tried various codecs as well, including non-compatible combinations to even further force the PBX to transcode (ie: ulaw->g729, gsm->ulaw, etc.)
For simplicity's sake, here is a diagram of the connection:
Phone(10.124.255.176)---->AT&T 3G Public IP(18.104.22.168)---->PBX(22.214.171.124)---->SIP TRUNK(various public IPs)
The PBX receives the invite with the correct IN IP4 address of 126.96.36.199. It sends out a reply with it's own address of 188.8.131.52, which is where my phone is sending the RTP.
On the other leg of the call, to the ITSP, it sends out it's public IP, which the ITSP sends RTP to, and receives a valid address in response.
There is nothing in front of the PBX that would block/filter/modify packets.
Some additional information:
In the process of troubleshooting, I tried various different scenarios. In addition to the above mentioned UDP/TCP/TLS/RTP/SRTP options, I also changed up the dialplan. I tried a straight/simple Dial() without the various macros I normally use, but that had no effect. I also tried Answering the call first and then doing the Dial, with no effect. However, when I Answered the call then Playback'd a sound clip and then Dial'd the call, THAT worked, and I was able to receive and send RTP from the PBX. So it looks like as long as the PBX starts off sending RTP itself, it's fine. However, if it's dependant on the RTP from the two sides, it gets "confused" and doesn't pass it along. In fact, Asterisk itself doesn't seem to even recognize that RTP is being received from both parties (as evident in the rtp debug).
I spoke with various people on IRC #asterisk and no one had any ideas what was wrong. mjordan who also helped asked me to submit it here.
|Comments:||By: James Babiak (enki) 2012-08-12 00:21:10.998-0500|
Working on uploading a more complete pcap, but a snippet from a previous tcpdump showing the RTP traffic coming in from both endpoints but nothing being sent back out to them via the PBX:
20:11:12.488963 IP mobile-032-163-038-200.mycingular.net.14012 > pool-71-180-124-149.tampfl.fios.verizon.net.17554: UDP, length 172
20:11:12.493936 IP 184.108.40.206.16954 > pool-71-180-124-149.tampfl.fios.verizon.net.13516: UDP, length 172
By: Rusty Newton (rnewton) 2012-08-20 20:35:58.733-0500
Can't verify this is a bug yet. Can you provide a sanitized sip.conf, extensions.conf and another asterisk CLI (full) log but with VERBOSE and DEBUG messages of level 5 enabled?
By: Rusty Newton (rnewton) 2012-08-24 11:12:29.825-0500
James, remember to hit the "Enter Feedback" button once you get the VERBOSE and DEBUG level 5 log so that we'll see the update.
By: Rusty Newton (rnewton) 2012-09-19 20:44:16.309-0500
James, we have had no further response. Does this issue still exist and have you been able to get the additional debug requested?
By: Matt Jordan (mjordan) 2012-10-17 08:37:05.536-0500
I think we have enough information to go on at this point - sending it back and marking it as Open.
By: Joshua C. Colp (jcolp) 2012-10-30 14:57:54.061-0500
I've spent a few hours today trying to isolate this and reproduce it. I've tried setting up the same topology including soft phone running on my mobile and have had zero success reproducing it. I also had an idea of a change that may have caused this, but that did not pan out either based on your own testing discounting it. This is also a pretty normal scenario that nobody else has experienced, which makes me wonder if it's something environment specific. The fact that the packets aren't showing up in Asterisk but are in a packet capture is pretty bizarre... any case where the packets would be discarded before being logged by "rtp debug" also outputs a message. This makes me wonder if there's a firewall in play here that is wanting traffic to go out before letting inbound traffic in. This would also explain why having Asterisk send media before dialing works. I'll continue trying to isolate this for a bit longer, but a confirmation re: firewall would be nice.
By: Joshua C. Colp (jcolp) 2012-10-30 16:34:50.688-0500
Worked with reporter in real time, confirmed to be an iptables firewall issue.