in local network i can make inbound and outbound calls without any issues and my freepbx is behind nat all nessary ports are opened in linux and router the issue is when i try to make inbound call from outside the local network it connect but both sides cant hear each other.
what is the cause of this issue and how I can solve it. side note some calls works fine when I contact from outside the network.
Mis-configuration of NAT or firewalls, including not providing the correct external media address when you are behind NAT.
i checked my router NAT config and firewall port forwarding and I see all is working fine.
i have tried 3 diffrent router all gave me the same result.
i 've used tools to make sure external ports are open.
i see ports 10000:20000 are closed.
I am using webrtc to make calls in local network it works perfectly without any issues but from the internet no voice.
i tested the calls outside the network with client to site vpn and it worked well. but this is not practical for our use case.
for webrtc media i used google stun server :stun.l.google.com:19302
side note this project is in the UAE which as i khow have some restriction on voip calls.
Did you configure the correct external IP address in Asterisk SIP Settings? Do you have more than one internet uplink? Have you already tried packet inspection
I checked my external public IP in asterisk sip settings which is the same static public IP from my ISP. I didn’t try packet inspection. how to do so? what might be the issue?
Log in to the FPBX shell and run tcpdump -i eth0 -s0 -w pcap.pcap . Make a call from outside your network and pick up. After a few seconds, hang up and stop packet capturing. Download the pcap file via WinSCP or FileZilla and then inspect it. If you need help with inspecting this file, let me know.
I’ve included a snapshot of the pcap which was captured while making an outbound call from external network tcpdump -i eth0 -s0 -w pcap.pcap was running in freepbx server.
To help you, I need the whole context.
Go to Telephony → VoIP Calls → Select call → Follow Sequence.
Make a screenshot and post it here.
On the previous and new screenshot, I can see that this call is initiated from a local address 192.168.0.10. Are you sure that when you were making this test call, you were outside your network? Do you have any VPN configuration on the endpoint you used for making this test call? If not, what is this device with this IP address? This call flow looks completely fine.
on my network there is a freepbx17 server and GSM gateway which has the sim card the used for outbound call during capture of packets while using webrtc from external network. the call ring and after accepted it started for about 30 sec then auto terminated without any audio for both side.
so one side is webrtc client connected remotely without any vpn to freepbx and that freepbx is on the same network of a gsm gateway.
the other side is a real phone used to receive the call.
server IP: 192.168.0.10
gateway IP:192.168.0.161
@mxmMarcin you are correct the call flow has no issue. when I changed RTP port range (10000:20000) to (50000:60000) I can make audible calls with little to no issue. i wounder if there a better range to follow!. i also updated this from linux firewall, router firewall and the gateway itself.
I am still testing and I hope all issue will be solved.
I also need to make sure that is config in the responsive firewall is correct.
What kind of router do you have? Maybe this router catches all RTP packets reaching the WAN interface on the standard port range, which is 10000 - 20000?
I am using a Unifi Dream router
port forwarding all ports as I can’t find the DMZ option.
i still facing some issues as some calls are open with voice and some with no audio at all
As other have stated, this is almost certainly a NAT issue.
You should be allowing UDP port range 10000-20000 to pass through the router with no port address translation. There should be no need to be playing around with those port ranges on the firewall imo.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.