I hope someone can help me troubleshooting my PBX. I have several PBX Instances behind NAT which are working pretty fine.
But now I installed my first PBX which is on a hosted Server with a public IP.
NAT is set to “no” I think thats the right way
My Clients are Softphones behind NAT (PhoneSuite) and most of the stuff is working finde.
Only on Outgoing calls I have some problems.
On Outgoing or local calls when I use these features at the Initiator side I can’t
-Hold these calls (nothing happens but the Audio goes away)
Cant transfer these calls (nothing happens but the Audio goes aways)
Calls End after 30 Minutes
Sometimes one way Audio on Inbound calls
The phone rings after trying to redirect a incoming call to another participant
I think there are some Problems with sending/receiving re-Invites
So we could say its a Firewall/NAT Problem on the Client side. BUT. I configured the VPN Server on the FreePBX and connected the Clients over VPN - same problem
Next I tried another SIP Client (ZOIPER) - everything working fine
But I don’t think its a PhoneSuite Problem because:
I connected PhoneSuite directly to an PBX (same local Network) and over a VPN Software to another FreePBX (this one is behind NAT) - Working fine
I hope someone can help me troubleshooting this.
Thank you
Additional Informations:
When i do “asterisk -rvvvv” and put a call on hold, nothing happens there. When i put a inbound call on hold which is working the Log shows stuff
As far as I know, hosted VMs are generally behind some sort of NAT device. Yo can check if yours is by going into the freepbx console and issuing ifconfig -a command. If you see a private IP listed instead of your public IP, then your VM is behind a NAT device.
Though I can’t explain your VPN experience (which could be a separate issue), everything else (so far) is consistent with a SIP ALG causing the trouble.
On the Client end, confirm that the re-invite for hold is being sent to the correct IP address and port. At the PBX, confirm that you are capturing traffic ahead of the FreePBX firewall. sngrep and tcpdump are ahead of the firewall, but Asterisk chan_sip debug and pjsip logger are after the firewall.
At the client end: ISP? Modem make/model? Is modem a ‘gateway’ (has more than one Ethernet port)? If so, is it in bridge mode? Separate router/firewall, if any? Any SIP ALG in either device? If so, have you tried turning them off? Any other VoIP-related settings?
The VPN was directly to the PBX (freepbx own VPN server)calls are working over it. So SIP Alg is disabled but shouldn’t make problems when the call goes over a VPN
A trace on the client shows that the INVITE is getting send to the VPN IP of the PBX. But a trace on the PBX shows no INVITE…
Can you post packet captures from both sides of the VPN tunnel? This should start from the initial INVITE to set up the call (or earlier) and continue through the failing re-invite to put the call on hold (or later). At the client end, you should see retries of the failing re-invite, since it is receiving no response.
Put both .pcap or .pcapng files into a .tgz file and attach it to your post.
The only difference between a Trace of a running HOLD and a not working one
On the Client side the reInvite goes out to the PBX.
But Wireshark says. So I think theres something wrong with the telephony Software, looks like it’s sending out defect INVITE Packages right?
P-Key-Flags: resolution=“31x13”, keys=“4”
What does it mean? Because its marked blue in Wireshark
The INVITE Packets are passing the Client Network Interface → LAN Interface of the Firewall → WAN Interface of the Firewall.
But they aren’t shown in a WAN Trace on my PBX, the BYE Packets are still shown when I end the call
Click on #842 (the complete INVITE) and expand
Session Initiation Protocol
Message Header
Message Body
Session Description Protocol
and post a screenshot. That will show what is taking so many bytes.
I haven’t read the full thread, so this problem may have been mitigated, but this is about the one situation where nat=no is wrong! The chan_sip nat parameter enables certain workarounds that are necessary when Asterisk is outside NAT, its peers are inside NAT, and the peers are not compensating for the existence of NAT. It is not relevant for when Asterisk is inside NAT and has peers outside. Asterisk has certain heuristics which will detect that can detect peer inside NAT and automatically enable the workarounds, so, in most cases, the default should work. Specifying no turns off these heuristics.
