No Audio for remote extensions

I’ve just rolled out all of our remote extensions that are now connecting and registering with our PBX. We have no audio in either direction.

  • Our PBX is hosted in our main office, i have the in built firewall enabled and then it goes through a USG Pro which is forwarding all ports to our PBX.
  • On the remote extensions, they have all ports allowed to the external PBX.
  • I have NAT enabled at both ends with the external IP of the PBX being used.
  • I’ve double checked the correct ports are open.

I’m not sure what next steps to take. Here is a snapshot of a call;

[2020-02-10 10:02:54] VERBOSE[12066] chan_sip.c: --- (9 headers 0 lines) ---
[2020-02-10 10:02:54] VERBOSE[12066] chan_sip.c: Really destroying SIP dialog '[email protected]:5160' Method: OPTIONS
[2020-02-10 10:02:54] VERBOSE[12066] chan_sip.c: Retransmitting #2 (NAT) to
OPTIONS sip:[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK430ca9d9;rport
Max-Forwards: 70
From: "Unknown" <sip:[email protected]:5160>;tag=as10607e18
To: <sip:[email protected]:5060;transport=UDP>
Contact: <sip:[email protected]:5160>
Call-ID: [email protected]:5160
User-Agent: FPBX-
Date: Mon, 10 Feb 2020 10:02:52 GMT
Supported: replaces, timer
Content-Length: 0

Using sngrep (it’s a great tool, wish i knew about it before). i have the following;

[ ] 426  INVITE     [email protected] [email protected] 8     REMOTE_EXT_IP:26571     Internal_PBX_IP:5160     IN CALL

I’m guessing i shouldnt have the internal PBX IP in the destination and it should be the pbx external IP?

I believe you’re correct there. I think the issue is in the routing, not in the firewall. How are IP Addresses/Hosts communicated across your locations? I think that it’s safe to assume that the remote endpoints are incorrectly being pointed to [email protected] and that they should be pointed to the IP Address and/or FQDN of your PBX.

I’m also getting the following on a remote extension invite, is the internal IP of the pbx at our head office.

xFrom: <sip:[email protected]>;tag=3d5eaebc-d4ad-4cb9-95bf-8ddc128b7835

How are IP Addresses/Hosts communicated across your locations?

I’m not sure what you mean by this?

Under SIP Settings i have;
External Address: the correct external IP for the pbx
Local Networks: (do i need to add the local IPs ranges of remote sites?)

Strangely, the following now works;

  • External calls inbound to any extension, local or remote
  • Calls from remote handsets to local handsets

What doesn’t work is;

  • Calls remote extension to a remote extension.

There are a few checks to ensure that the audio works in remote extensions.

  1. Ensure NAT is enabled on the trunk details
  2. Ensure NAT is enabled on the extension/user
  3. Ensure that the RTP port(s) under the Advanced SIP Settings are open on your firewall

We have since changed this and now have the remote extensions using the OpenVPN. They connect fine and register, we can hear audio but get cut off at 30 seconds. I guess this is the RTP traffic not getting through.

I thought it would just tunnel that traffic through to the pbx and so wouldn’t be an issue other ports being opened.

The local IP of the VPN clients is added the local networks - do i need to disable NAT anywhere else? I can’t get access to SSH at the moment so can’t produce the logs

Is NAT enabled in the trunk? I had it where it would cut off and some calls would be one way audio due to not having NAT enabled for the trunk.

I can’t see any options for NAT at the trunk level. I’ve been digging around and now have SSH access. Looking at a call, i get the below at 32 seconds.

BYE sip:[email protected]:5060;transport=UDP SIP/2.0
xVia: SIP/2.0/UDP External_IP:5060;rport;branch=z9hG4bKPj5faf3ddc-6515-4f7c-b263-241f07e9a35a
xFrom: <sip:[email protected]>;tag=65eff96d-a5ca-4d15-a4b4-b1d7819eff2a
xTo: "1260" <sip:[email protected]>;tag=1b279428810a094
xCall-ID: [email protected]
xCSeq: 29899 BYE
xMax-Forwards: 70
xUser-Agent: FPBX-
xContent-Length:  0

I’m not sure the external IP should be there, strange as there are lots of SDP 200 OK before with the correct internal IP.

if you’re getting cut off after 30 seconds, check the UDP timeout on your router/firewall

I’ve already looked at that, on the USG Pros theres both UDP Other and UDP stream. I set both to 50 seconds and still got cut off at 32.

Would things like that effect it, as the remote extensions are VPN’d in? I thought they would only communicate via the internal (VPN) network of 10.8.0.* but as posted above, the 2nd line contains the external IP address.

NAT wise;
NAT = No
IP Config Override = External IP

A reminder of the route our traffic takes. PBX > PBX Firewall > USG PRO > Remote Firewall > Remote Extension. The remote extensions VPN into the the PBX. In my (simple) mind, so long as the VPN connection is live all data should be passed through that tunnel and i should have any other issues. Other than the provisioning data, does any other traffic get sent outside of the tunnel?

Try changing NAT to Yes

But surely it wouldn’t be needed as phones are on a 10. range connecting to the pbx on 10. range through a VPN tunnel?

I’ve tried it anyway and i still get cut off at 32 seconds on a outbound call only.

EDIT: This is any outbound call, either to an external DDI or another remote extension.

Is this just a problem with remote extensions? All local extensions work with no issues?

That was correct.

We have since ditched the VPN. Remote extensions connect fine.

  • They can receive external calls and they work fine.
  • They can dial out for external calls and they work fine.
  • They have no audio when a remote extension calls another remote extension, or forwards a external call to another remote extension.

I always though no audio was a NAT/Firewall issue, but this can’t be the case is external calls are working fine.

I think it would still help to see a packet capture of a remote ext to remote ext call. I agree that it might not be a nat/firewall issue based on what we know so far, but it still might lead to some clues. In this case, I wouldn’t filter for only sip since it could help to see any rtp packets involved.

1 Like

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