Do you want a SIP trace or from the Asterisk
Do you want a SIP trace or from the Asterisk
You can do both.
SIP trace (UDP ports 5060 to 20000): https://pastebin.com/6US15DkR
Related section of Asterisk full log: https://pastebin.com/GHsJDexu
Looks like you don’t have your PBX setup for the fact it’s behind NAT. You’re sending private IP details to your provider in the SDP.
o=- 1343252156 1343252156 IN IP4 192.168.0.96
c=IN IP4 192.168.0.96
m=audio 19840 RTP/AVP 0 8 3 111 9 101
Is that a technical or just a privacy issue?
Could it be the cause for lacking audio?
Yeah. Without the public address, there’s no way for the receiver to establish the RTP session back to your private network.
Well, you can also see the PBX’ public IP in the trace (220.127.116.11). BTW the SBC’s address is 18.104.22.168.
What is more: This setup worked for >18 months - at least for normal calls from and to external parties.
But I am open to reconfigure the FreePBX in order to eliminate all private IPs.
I searched the entire Web GUI for the private IP, but couldn’t find it apart from the System Admin > Network Settings section, where it is shown as DHCP-assigned IP address. I’m quite sure that I mustn’t change this IP address to reflect the PBX’ public IP.
/etc directory recursively for the private IP address, the only matches are the files res_digium_phone_general.conf and res_digium_phone_devices.conf .
Any ideas, where to eliminate the private IP?
And what changed to make it suddenly stop working? Did you do updates? Add custom code?
Yeah, tried to make Call Forwarding work. Finally no changes were required for the Diversion header, so I activated the VM’s old state (I had a VM snapshot created prior to the Call Forwarding investigation). The RTP transmission on forwarded calls worked for three test calls, then there was no audio.
So I investigated that, but when I didn’t find a solution I activated the VM’s old state again.
Since then, also normal calls from and to external parties do not have audio.
The Packet Capture showed that RTP is transferred only from the PBX to the SBC. No RTP traffic from the SBC to the PBX!
I analysed the captured data (captured between the PBX’ public IP and the SBC) and it is sure that the transmitted RTP data contains speech (you can replay the test text I feeded).
With an external firewall, even with a 1:1 NAT, you need to configure the driver, the trunks, and the extensions with the correct NAT settings.
There are settings for PJ-SIP and Chan-SIP in the Advanced settings that need to be correct. The external address (for example) needs to be set correctly with the routable address that the rest of the world will see as the “most outside”. Any other local addresses will need to be configured so that the server knows what is a local (non-NAT) address so that the proper headers will be created.
In general, if you have a pfSense firewall in front of everything, this setup should be used. The extensions on your local network (including any VPN networks you might have) can be set to “NAT=no” in the extension configuration, although setting it to “Yes” might work - in the Extension config, there are several options there that you can use. Check them and see which one works best in your network config.
So, the Chan-SIP and PJ-SIP settings in the Advanced Options needs to be set correctly - probably “Yes”. The extension configs need to have NAT=Yes if they are outside the local network. Make sure you address entries are correct - the outside most router (the one visible to the world) needs to be the “external” address and your local address needs to be identified in the driver config.
As Vodafone provided us a Test SBC some months ago, I configured the pfSense and FreePBX to connect to it.
The result is that RTP is transmitted without issues and the participants can hear each other.
The conslusion is that Vodafone has to fix the productive SBC - maybe a port reset, system restart or whatsoever will fix the issue.
As soon as RTP will be transmitted again for normal calls, I will be able to investigate the RTP transmission for Forwrded Calls issue agian.
Just to return to initial question: what is the proper way in FreePBX to add configuration to a context? I was trying to add an execution of an agi script when DND codes are dialed (*78, *79, *76) in order to add these events in a DB table without success, but I think that there are many more examples of interesting things to do.
This has been explained. Custom dialplan should go into _custom.conf files so you can hook into them. However, include statements in the dialplan will only look at the included contexts if the is no match already in the current context which really these days isn’t going to happen. That is why using the custom includes that exist where labeled as “legacy leftovers”.
If you need to override the dialplan contexts then you need to use the override.conf file but you need to do the whole context not just what you want to add. So if you want to change the DND code actions you need to override the app-dnd-on, etc contexts.
To amplify Tom’s post:
/etc/asterisk/extensions_override_freepbx.conf (I think).
Look for /etc/asterisk/extension*.conf from the console to get the exact filenames.
A really good explanation of extending the context framework can be found in @lgaetz article
Haaaa, speech is being transmitted again. Vodafone has a filter on the SBC and this filter was rejecting all RTP packets from and to our PBX.
They needed only 10 days to find out their own filter and disable it. Meanwhile the whole company couldn’t use the PBX.
Today I have to party, but the initial issue will be investigated soon.
So this thread deals about lacking RTP transmission in this scenario:
External caller (e.g. mobile device) A -> calls PBX extension B -> diverted to external number (e.g. mobile device) C.
The diversion is configured at FreePBX Web GUI > Applications > Extensions > MyExtension EDIT > Find Me / Follow Me > Destinations: Misc. Destinations: MyMobile
The call is diverted to C, and C’s display sees the correct CID (i.e. A’s CID), so everything regarding SIP is OKAY.
But C cannot speak to A and vice versa. RTP transmission is NOT OKAY. Actually the SIP trace shows that it is not being initiated at all.
Somebody working with Asterisk servers (with chan_sip, not PJSIP!) had a look at the SIP trace and told me that the reason would be that the FreePBX’ local IP address is shown in the INVITE request block and that it should be the public IP address.
I researched that the configuration page for the public IP address in FreePBX Web GUI is located here:
FreePBX Web GUI > Settings > General SIP Settings > NAT Settings > External Address or alternatively here:
FreePBX Web GUI > Settings > Chan PJSIP Settings > 0.0.0.0 (udp) > External IP Address
First, I configured the external IP address at General SIP Settings. I had only to hit the button Detect Network Settings and the field was popultaed with the correct public IP address.
Result: Normal calls from external callers cannot be taken anymore. You take your VoIP phone’s handset, but the caller’s device keeps ringing and ringing.
I did research on how to configure correctly the PBX’ external IP address in a PJSIP setup, but didn’t find the solution.
Does anybody know if the public IP address has to be configured at multiple locations in a FreePBX system?
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.