Problems with Extensions at Remote Location

General Help
1

I really need help identifying what’s wrong with our current setup and how to correct. At a high level, the extensions at our remote location can often not call each other, can’t call the main location, can’t access voicemail, and can’t make external calls. This is a fairly new install of Sangoma FreePBX at both locations.

Our main location is on the East coast and has two Sangoma Freepbx 100s. We have a location in Nevada, with approximately 15 users. The two sites connect via VPN over the internet.

Main location has a 100 MB Fiber, with a Fortigate between the fiber and the switch.
Satellite location has a dedicated point to point MW connection.

I’m including below pings between the sites, which are not good.

Thanks,
Karen

[root@freepbx ~]# ping 172.16.55.120
PING 172.16.55.120 (172.16.55.120) 56(84) bytes of data.
64 bytes from 172.16.55.120: icmp_seq=1 ttl=62 time=83.0 ms
64 bytes from 172.16.55.120: icmp_seq=2 ttl=62 time=82.9 ms
…
— 172.16.55.120 ping statistics —

15 packets transmitted, 2 received, 86% packet loss, time 14012ms

rtt min/avg/max/mdev = 82.955/82.980/83.005/0.025 ms

Ping from Nevada to Beverly:

Pinging pbx.nnnn.com [172.17.50.200] with 32 bytes of data:

Reply from 172.17.50.200: bytes=32 time=83ms TTL=63
Reply from 172.17.50.200: bytes=32 time=83ms TTL=63
Request timed out.
Request timed out.

Ping statistics for 172.17.50.200:

Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),

Approximate round trip times in milli-seconds:

Minimum = 83ms, Maximum = 83ms, Average = 83ms

2

Everything you described here tells us that the phones lost connection to the PBX.
Each phone that places a call to another phone is processing the call through the PBX.

It seems to me that this is a network issue rather than something related to your FreePBX configuration.

As you can see, if you have ping drops, then there’s either no stable internet connection or you have something wrong in your network setup.

Could also be, that VPN is having trouble negotiating a tunnel…

I’d suggest you re-searching how to troubleshoot network connectivity issues, and perhaps use WAN to LAN rules to allow SIP traffic from the remote locations instead of using VPN.

3

Apologies for the delay in responding on this. Thank you for responding. I’m pretty sure it’s a network issue as well. I have resources who will be working on this this coming Tuesday night.

At a high level, can you speak to whether the distance between sites should pose any issues?

What’s odd is that we are able to register remote extensions using Zoiper but not our Sangoma phones. (Any thoughts?).

4

We have phones connecting to servers with 10+ hours flight travel, I don’t think that’s the issue.

5

If the remote location does not have its own PBX and they are connecting over the VPN to the PBX then this sounds like a firewall/NAT (possible) with the VPN connection and how it is handling new requests from the phones.

So let me ask this, when this happens and the remote location starts to have these issues what is the current resolution? Are you rebooting something? If so, what and at which location?

6

Thanks PitzKey.

Your description of our set up is correct. Currently, we aren’t doing anything (when this happens) as it happens almost constantly. We plan to install a new firewall (same model as at our main location) tomorrow night; the hope is that this will correct the issue. The firewall at the remote site is old and has many complicated rules in it. My network admin is hesitant to make any changes to the current setup as it may break something in production. I’ll report back after then.

7

I’m not sure this has anything to do with the firewall a the remote location. Unless you are seeing the requests from the phones hitting the PBX and then the replies never making it back to the phones. Then you might have an issue with the firewall at the remote location.

If the phones are not hitting the PBX with their requests, are they getting to the firewall/router at the main location? Are they being dropped there? Because, again, it would be the firewall where the PBX is location in the main office, not the remote location.

Do you have any type of actual debugs of this to show any type of activity?

8

It’s also possible that the phones could be configured incorrectly. For example, if the addresses for the PBX in the phones are the External address (instead of the VPN server address) then this could be the normal functioning of a router timing out on a long connection. It could also be a bad “reply” address in the header which would work for a while and then quit.

I have no doubt that you’ve already checked that, but monitoring the network traffic and seeing what actual addresses are being used could bear some insights.

9

Blaze and cynjut - We moved the pbx to the dmz (bypassing the firewall) and now I’m seeing the remote stations are staying registered. However, I’m seeing 100% packet loss on reverse RTP traffic from remote stations.

Here’s a capture from this morning of a call showing these problems:

image
image1064×237 16.1 KB

Here is the stream analysis:
image

Where do I look for the cause of (or a pointer to) the packet loss? Thanks, Karen

10

I’m not sure what reverse RTP traffic is. Are the phones at the remote location having No Audio or One Way Audio issues now? If it is one way, which way is it? The user at the remote location can’t hear the other side of vice versa?

11

The phones at the remote location are having one way audio issues, with the rare successful two way audio.

I captured some test calls from the switch and a remote extension this morning.

Test 1: Call from HQ to remote location. Two way audio.
Test 2: Call from remote location to HQ. The caller has no audio; the called party has audio.
Test 3: Call from HQ to the remote location: The caller has no audio; the called party has audio.

We appear to have a port mismatch issue; sometimes the ports being returned to the switch are different than expected.

Monday%20testing
Monday%20testing1366×808 80.9 KB

In test 2, center image, the called party has audio, receiving packets for port 16682. The returned audio is going to port 35123 instead of expected port 51570.

The HQ side of the capture was captured on the switch with wireshark.

The switch traffic is not going through a firewall, on the HQ side.

12

OK, this looks to be more like an issue with the router/firewall at the remote location. I’m going to suggest something to try.

Take one or two phones, in the phones themselves change their SIP Port from 5060 to something unique. 5061, 5062 are fine. It won’t impact anything with the PBX it will just mean the PBX will send calls to the phone on those ports. Save the changes and have them re-register to the PBX.

Makes some test calls to those two phones, make some test calls from those two phones. See if the one way audio problem persists. If it does, the next step is to go and change the RTP Start Port (or what ever they call it) and do the same thing. Give them both unique RTP ports for the phone to work with.

Make the test calls again and see if it still persists.

13

I made the changes on two extensions at the remote site, restarted each extension and confirmed from the CLI that SIP SHOW PEERS shows the new ports.

Called from HQ to the remote extensions. In both cases, the first call to each extension had 2 way audio.

Then, I had each extension call me. In this case, the caller had one way audio (couldn’t hear me) but I could hear them.

Would this be on the remote firewall? Thanks Tom.

14

One other piece of information - I am working with Sangoma on this as well. This is what was said most recently:

The issue looks to be the same where the RTP port the 74.xx (remote) address is streaming to is different then what is being offered in the SIP INVITE. From the phones pcap, you see the one-way RTP as the PBX is not forwarding on the received RTP because its from a different port then what was offered.

15

That sounds alarmingly like SIP-ALG in action.

1 Like
16

Sigh; I’m having a hard time convincing my network resource to check the switches. It should just be a question of SSH’ing and typing the following, no?

SHOW IP NAT TRANSLATIONS
SHOW IP NAT STATISTICS

My co-worker is convinced it is a problem with the physical phones. We do not have a problem with soft phones - i.e., Zoiper.

17

The softphones would be on the data side of the network and the device it is on handling nat stuff. If your voice and data are handled on their subnets/vlans then your issue is on the voice network.

18

Please define what you mean by the voice network. My background is with a traditional PBX with PRIs and T1s.

19

I mean on your network, in the offices, you have all the Voice traffic on 192.168.1.0/24 and all your Data traffic on 192.168.2.0/24. If you have switches and need to use the same ports to move multiple subnets around do you have these tagged with VLANs?

My point is, Zoiper is a softphone and runs on a PC/mobile device. Those are generally connected to the data network in an office while the phone that’s on the desk is on the voice network. When people don’t have issues with their softphones and do with their phones it is generally because the softphones are on the data network and using their device’s NAT/network handling for what they need.

It also shows when the issue is more geared to how the voice network is laid out or its routing is handled.

20

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.