I tried searching before, but everything I find has a solution that does not apply. I’m basically getting the dreaded “incoming calls get dropped after 30 seconds”. I can do outgoing fine.
Setup is fairly basic, Internet connection -> Ubiquiti EdgeRouter doing nat -> LAN
My Freepbx install (fresh install as of yesterday) resides on the lan, and is dual homed, with it’s second NIC handling the SIP phones (Cisco SPA 5xx).
I’ve configured my public IP under sip settings, and opened/forwarded ports 10000-20000 udp to my Freepbx box (not sure it’s needed).
Can anyone recommend troubleshooting steps, or logs I could provide to help finding the culprit? I looked at the PJSIP logs, but it simply appears to send a BYE, no reason given.
I’m aware that 30 seconds is the RTP timeout, but changing it to 45 seconds doesn’t appear to make the drops happen at 45 seconds, they still drop at 30 seconds.
I feel dumb, it shouldn’t be that hard! Thanks in advance.
A call from one extension to another stays up for at least a minute.
You have disabled SIP ALG in the router.
Direct Media for the trunk is set to No (the default).
On a failing call, audio flows normally in both directions until the call drops.
If you still have trouble, at the Asterisk command line, type pjsip set logger on
make a failing call until it drops, paste the Asterisk log for the call (which will now include the SIP traffic) at pastebin.freepbx.org and post a link here.
As requested:
I have just made a 5 minute call to another extension, and this stays up. Audio flows both ways.
I can confirm SIP alg is disabled on the Edgerouter:
admin@EdgeRouter8:~$ show configuration commands | grep sip
set system conntrack modules sip disable
DirectMedia is set to No on the trunk.
Audio flows both ways on all calls, even the dropped ones.
Any way to tell the logger to only log one extension? The pjsip log is interleaved with SIP messages from other non active extensions. (pastebin to follow in a few minutes)
The important thing to log is the trunk (I assume that it’s SIP – if you’re on a PRI that’s another ball game). You can do pjsip set logger host 1.2.3.4
(replace 1.2.3.4 with the IP address of the trunking provider).
However, ~35 seconds of log should contain at most one OPTIONS to each extension and the response. It shouldn’t be a huge amount of data.
Some info:
18191234567 is the SIP phone number I’m calling (sanitized)
8197654321 is my cell phone that I’m using to call the number above (sanitized)
1.1.1.1 is my internet IP address (sanitized)
192.168.2.10 is the Cisco phone IP connected to freepbx. Extension is 456706 (sanitized)
192.168.192.8 is the freepbx box. Packets from internet get natted to this IP for udp 10000-20000
Hopefully my search and replace were precise enough they didn’t cause collateral damage.
The 200 OK to Fongo / Fibernetics does contain your correct public IP in the contact header, but you aren’t receiving their ACKs and are re-transmitting the 200 until it times out. We know that they got the 200, otherwise they wouldn’t know where to send the audio you are hearing.
My guess is that the ACKs are coming from a different public IP (because of the multiple VIAs and Record-Route headers) and your router is blocking them. Can you capture traffic on the WAN interface of the router and see whether the ACKs are present? If so, forwarding UDP port 5060 from their IP addresses to 192.168.192.8 should be a fix.
OK, so capture traffic on the router WAN interface and see what they are sending for the ACK.
If you see nothing, confirm that the 200 OK that was sent out is properly intact.
Also, confirm that the router WAN interface has your public IP address – possibly your modem is actually a gateway doing NAT.
It’s possible that I missed something important in the log you posted. Could you temporarily shut down the PBX, configure one of the SPA phones to register directly to Fibernetics and see whether that has the same issue?
If you have any other trunking providers, do they have the same trouble?
I tried capturing on the WAN interface, but there are no ACKs coming in at all. I also confirmed that the tcpdump on the router is getting packets before they are firewalled, so I should see everything.
Out of desperation, I setup my trunk as SIP instead of PJSIP (and added 5160 where I had 5060), and boom, it just worked. I’m even more confused… The one thing I noticed is sip allows me to use a “registration string” in the Incoming tab for the trunk. A few posts online suggest the required string is:
In pjsip, when you have Registration Send, the default equivalent values are: Username:Secret@SIP Server/Contact User
If Contact User is left blank, it defaults to Username.
There are several Advanced settings to modify these, but if you left those blank, your registration should be identical to what you have with chan_sip. You can compare the REGISTER requests to see if the same info actually gets sent.
If you don’t mind, could you please post a log (with the same info as you posted previously) for a chan_sip incoming call? Possibly, there is a bug in pjsip that is worth reporting, or there is a required pjsip setting that will be obvious from the comparison.
To enable SIP logging with chan_sip, use sip set debug on
IMO the key difference is that the 200 OK sent by chan_sip has Contact: <sip:[email protected]:5160>
but pjsip has Contact: <sip:1.1.1.1:5060>
I’m reasonably certain that the latter is valid SIP for this situation and believe that a bug in Sippy (at Fibernetics) is preventing it from getting parsed, so the ACK is not sent out.
If you’re willing to try pjsip again, please set Contact User to 18191234567 (of course, use your actual number) and retest. (You won’t need to forward any ports, since we now know that the ACK comes from the same IP that the 200 OK was sent to.)
Actually, Contact User has been set to the proper number all along!! Is it not being “honored” by PJSIP?
At this point, unless there’s a clear benefit to use PJSIP, I’d be happy to just use chan_sip. Of course, if I can help troubleshoot an issue in freepbx/asterisk itself, I’m happy to try more things!
This is really embarrassing: This exact subject was discussed about 8 months ago, I participated and totally forgot about it:
I had some suggestions in the penultimate post in that thread, but it appears that the OP did not follow up.
It’s past 02:00 here and I need to get to bed, but will look in the morning to see if any updates may have fixed this. What Asterisk version are you running?
I’ve pretty much accepted the fact that I am either missing something not so obvious, or that there is a bug in the combination of PJSIP and how my provider handles my calls. chan_sip works, I’ll stop scratching my head and just use it.
Still willing to try other things if people have ideas, but I won’t cry over it if I can’t get it to work.