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.
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 18.104.22.168
(replace 22.214.171.124 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.
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)
126.96.36.199 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:[email protected] 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:188.8.131.52: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.)
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.