I promise you I’ve read every thread here about this and still cannot figure it out.
Like most people with the problem, I have my PBX and local extensions here in my office and two remote extensions.
The remote extensions are able to register and both place and receive calls. The problem is that outbound calls from the remote extensions drop after 30 seconds. Inbound calls from the office to the remote extensions continue on until one end hangs up.
These are PJSIP extensions and the console shows the correct public IPs for the remote extensions. All ports are properly forwarded through my firewall to my PBX (presumably).
Like all the other threads, I believe this to be an RTP issue, though changing multiple settings had no effect on call duration.
I’d like to be able to filter the pjsip logger to only show those specific IPs because I’m getting flooded with data from all my (internal) extensions and it’s too much to filter out. Can that be done? Previous instructions (pjsip set logger host x.x.x.x) on how to do that didn’t seem to filter anything.
I’ve disabled SIP and H.323 conntrack modules on my end (I run Unifi gear) and the same on one of my extensions (it’s at my house; also using Unifi gear), which had no effect.
I’m at my wit’s end here and I don’t know what else to check.
For this case, I’d actually include all UDP traffic, not just 5060. That way we can see RTP traffic, or a lack of it, which could be relevant. For ex:
tcpdump -s0 -w/tmp/capture.pcap -C50 udp and host ip.phone.is.registering.from
Alternatively, you can omit the " and host ip.phone.is.registering.from" part, and just apply a filter when viewing the file, but it might include too much in the trace, that you wouldn’t want to share.
Once you have the pcap, it can be read with an app like Wireshark, where we can filter things as needed to see the call and its associated rtp traffic that we want. If you share one, you’ll want to let us know the numbers of the parties involved, so we can find the right call.
You might also want to see if there are any SIP ALG options on your Unifi devices, and disable them if they are enabled. I’m sure if it’s relevant to your models, but SIP ALG does come up for some unifi related products.
Look in the logs for a message about RTP packet failure about the time if the failure. If that’s not it, then the problem is a router dropping the NAT connection after 30 seconds. The router may not be yours… SIP “Helpers” on remote routers can screw you up like this too.
Ok, so I did a capture for two calls: one for my call to the remote extension to have them call me back and a second for the call back to me (that lasted 31 seconds).
There are 3690 packets, but I’m not entirely sure what I should be looking for.
The most common source of maligned packet are SIP Helpers such as SIP-ALG. Generally speaking, we recommend against using SIP helpers because they cause unpredictable changes to the packets that cause all sorts of weird problems.
As a test, I set up a laptop on a VPN (L2TP) connection back to my office and installed a softphone on it.
I’m still getting dropped after 30 seconds, but the trace for this connection was WAY shorter (41 packets vs the 3700 on the first trace), despite the procedure being the same:
Start trace
Call remote phone for quick call
Have remote phone call back
Drop after 30 seconds.
The second trace, however, shows RTP traffic whereas the first does not.
I’m still not sure how to read the logs, so I don’t know if that’s meaningful information.
There are tools that can help you, including sngrep.
Wireshark should also be able to decompress the trace for you. Look for places where the addresses don’t make any sense (like a 192.168.0.1 going out into the WAN).
Also, the /var/log/asterisk/full file can tell you a lot without having to dig through a SIP debug.
Confirm that Rewrite Contact for the failing extension is set to Yes.
If that’s not your issue, at the Asterisk command prompt, type pjsip set logger on
have the remote call in, paste the relevant section of the Asterisk log at https://pastebin.freepbx.org and post the link here.
Rewrite is enabled for the extensions in question and I can see both on the console and the pcap traces that it is referencing the correct (their external) IPs.
Setting the logger on only serves to flood me with data from all my extensions (of which I have many) and it ends up just being noise.
Can I filter the logger to show ONLY that extension’s info?
Thanks everyone for all your help. It is very much appreciated.
In regards to getting the call data from the pcap file, here’s what I typically do, assuming you’re using Wireshark. Others may have better methods.
-First look for the INVITE of the call leg that we want to examine. In this case, I’d start by looking for the INVITE that is sent from the PBX to the remote phone, assuming you called out to it from a local phone. Go up to the Telephony menu(next to File, Edit, View, etc), and select VOIP calls to see a filtered list
-On the VoIP Calls window, select the call and click Prepare Filter. This should filter out the packets we need in the main window. You should see the INVITE/BYE transactions with a bunch of RTP packets in between. The RTP packets should be flowing both ways between the source and destination IPs.
This would be for a typical call, and you’d be seeing lots of RTP packets for every second of the call. For your case, I’d look to see if this is not happening. There might be a lot of time that passes between the BYE and the RTP packet that is listed before it. Or you might not see RTP flowing in both directions at some point. It’s hard to say what you’ll see at this point, but that’s what I usually look at first. Another tip could be to get a trace of a local to local call that doesn’t have this problem, so you can see what a normal call looks like for comparison.
Having said that, I’d also still try to get others what they need if it helps them troubleshoot this in other ways. Seeing the full asterisk logs with inline packet captures can be really messy, as you’re experiencing. But it can still be really helpful to see asterisk activity around the sip traffic. As for the file to search through, you should be able to see all that stuff in /var/log/asterisk/full
I don’t work on FreePBX so I don’t know where this could be configured, but in pjsip.conf if the “debug” option is set to yes then SIP traffic is always output disregarding the specific host filter.
According to my first trace, there are no RTP packets in any of the 3700 packets. There are RTCP packets, and with the exception of one, they’re all in pairs with the outbound (from the pbx) packet being fine and the inbound packet being malformed.
For my 2nd trace (data being passed over a VPN), there are far fewer packets over the same time frame but I do see RTP packets:
What is the actual call experience like? Are most of the cases where calls sound fine in both directions, and get a hangup at the 30 second mark? Or, is there a time where it’s only one way audio(can’t hear the remote phone) before the hangup. Also, have you checked Unifi documentation/support to see if there are any sip related options to look at?
Call audio is flawless in both direction. The cutoff only occurs when dialing outbound from the remote extensions and is always at 30 seconds. Inbound calls to the remote extensions last until either end hangs up.
I’ve checked with Ubiquiti and had them on my router and they can see no blocked traffic in any direction. Any SIP-related options have been checked and disabled (SIP Conntrack is the only one)
