One Way Audio Over VPN Issue

FreePBX Endpoints
1

Hi All, I am having a “One Way Audio Issue Over VPN” and can’t seem to determine the fix. I’ve followed some of the other posts but they did not resolve my issue.

FreePBX is running on 192.168.1.0/24. PJSIP extensions 101 and 105 on that network function great together. I then moved ext 105 over to 192.168.9.0/24, which is a wireguard VPN. On the VPN side, I can hear audio from ext 101 and incoming/outbound calls… However, they cannot hear me. I did a TCPDUMP on the FreePBX server and VPN router, and it appears packets are making their way back and forth. Not seeing anything that sticks out there. Both sides are running Edgerouters and SIP ALG is disabled on both.

I have added the VPN network to: SETTINGS, ASTERISK SIP SETTINGS, LOCAL NETWORKS. Both 192.168.1.0/24 and 192.168.9.0/24 are there. I also added the VPN network as a LOCAL NETWORK in Firewall.

Under ext 105 pjsip settings I did turn OFF Direct Media.

**EDIT: I have done an echo test, after the instructions complete I talk and nothing happens. I move the phone back over to the main network and can hear the audio…

I did reboot the server each time I mad a config change.

What else could I look at to diagnose this?

Thank you!

Jason

2

It sounds like there is some NAT involved, but your description is too vague to tell. Please describe all the network elements in the system, with example private addresses for each. Phone make/model? Can you ping the phone from a shell prompt on the PBX?

On the FreePBX server, do you see RTP packets arriving from the remote phone? If so, does the destination address and port match what got sent out in the SDP in the 200 OK response to the incoming INVITE?

3

Sometimes, you need to enable NAT for the extensions that are on the VPN, for example with zoiper. I know it is not your situation, but give it a try.

4

I am able to ping the phone from the PBX.

What commands are best to use to catch RTP? I’m not seeing that with TCPDUMP? But here’s the snippet from TCPDUMP on both sides.

**I replaced my FQDN with “xxxxxxxx”. But I am certain that the FQDN is resolving to 192.168.1.4, which is my FREEPBX server. And a traceroute shows it is traversing over the VPN correctly. My phone at ext 105 is at IP 192.168.9.126

On VPN SIDE:

18:38:47.960975 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: INVITE sip:*[email protected] SIP/2.0
18:38:48.019288 IP pbx.xxxxxxxx.com.sip > 192.168.9.126.sip: SIP: SIP/2.0 401 Unauthorized
18:38:48.022414 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: ACK sip:*[email protected] SIP/2.0
18:38:48.026504 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: INVITE sip:*[email protected] SIP/2.0
18:38:48.100817 IP pbx.xxxxxxxx.com.sip > 192.168.9.126.sip: SIP: SIP/2.0 100 Trying
18:38:48.105269 IP pbx.xxxxxxxx.com.sip > 192.168.9.126.sip: SIP: SIP/2.0 200 OK
18:38:48.114132 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: ACK sip:192.168.1.4:5060 SIP/2.0
18:38:48.165985 IP 192.168.9.126.5004 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.189313 IP 192.168.9.126.5004 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.207475 IP 192.168.9.126.5004 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.225769 IP 192.168.9.126.5004 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.248547 IP 192.168.9.126.5004 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.266540 IP 192.168.9.126.5004 > pbx.xxxxxxxx.com.12446: UDP, length 172

ON FREEPBX SIDE:

18:38:47.987943 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: INVITE sip:*[email protected] SIP/2.0
18:38:47.988840 IP pbx.xxxxxxxx.com.sip > 192.168.9.126.sip: SIP: SIP/2.0 401 Unauthorized
18:38:48.042213 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: ACK sip:*[email protected] SIP/2.0
18:38:48.056182 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: INVITE sip:*[email protected] SIP/2.0
18:38:48.057897 IP pbx.xxxxxxxx.com.sip > 192.168.9.126.sip: SIP: SIP/2.0 100 Trying
18:38:48.062138 IP pbx.xxxxxxxx.com.sip > 192.168.9.126.sip: SIP: SIP/2.0 200 OK
18:38:48.135376 IP 192.168.9.126.sip > pbx.xxxxxxxx.com.sip: SIP: ACK sip:192.168.1.4:5060 SIP/2.0
18:38:48.191475 IP 192.168.9.126.avt-profile-1 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.208586 IP 192.168.9.126.avt-profile-1 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.222709 IP pbx.xxxxxxxx.com.12446 > 192.168.9.126.avt-profile-1: UDP, length 172
18:38:48.226426 IP 192.168.9.126.avt-profile-1 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.242566 IP pbx.xxxxxxxx.com.12446 > 192.168.9.126.avt-profile-1: UDP, length 172
18:38:48.251829 IP 192.168.9.126.avt-profile-1 > pbx.xxxxxxxx.com.12446: UDP, length 172
18:38:48.262645 IP pbx.xxxxxxxx.com.12446 > 192.168.9.126.avt-profile-1: UDP, length 172
18:38:48.267665 IP 192.168.9.126.avt-profile-1 > pbx.xxxxxxxx.com.12446: UDP, length 172

So I do find it strange that the FREEPBX side that “avt-profile-1” starts to be added during the echo test instructions. I stopped the capture after a couple seconds of the instructions.

The phone is a Grandstream DP752 base station with a DP730 DECT phone.

5

Where do you toggle this? Under ext 105 I’m not seeing this in the settings? I did look under Advanced tab.

6

That setting only shows for chan_sip extensions. For pjsip extensions make sure the setting “rewrite contact” is enabled for the extension.

7

Rewrite Contact was already set to YES for this extension.

8

This is not an issue. tcpdump, by default, attempts to translate port numbers to the corresponding name, e.g. UDP 5060 is shown as sip and TCP 80 would be displayed as http. avt-profile-1 is a name for UDP 5004; see Service Name and Transport Protocol Port Number Registry

tcpdump -n -nn
will skip converting addresses and port numbers to names.

At the Asterisk command prompt, type
pjsip set logger on
make a failing *43 call from the Grandstream, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here. Depending on what is shown, we may also need a tcpdump capture.

9

@Stewart1 I just pasted the pjsip log here: https://pastebin.freepbx.org/view/f8c69a02

10

@Stewart1 Since I was in both these boxes I went ahead and ran a *43 call running tcpdump from both sides. I ran: tcpdump -n -nn host 192.168.9.126 on both. Here are the logs of those TCPDUMPS:

**FYI: For all 3 logs I did mask my FQDN with “xxxxxx”…

VPN Router Side:

https://pastebin.freepbx.org/view/8679f8b3

FreeBPX Side:

https://pastebin.freepbx.org/view/87b8948d

11

I’m very puzzled. Even on the router side, RTP from the phone stopped flowing at 20:35:44.844304 . But why? Perhaps if the phone didn’t like what it was ‘hearing’, but we know the incoming RTP is good.

Maybe syslog on the Grandstream will show something, or a capture at the Grandstream will be different.

Also, just as soon as you hear the ‘You are about’, press # and see whether that stops the announcement.

12

When I press # just after the echo test instructions start, nothing happens. The recording keeps going to the end.

I did factory reset the phone this morning just to rule out some sort of set up issue when I had this phone on the other network. No luck.

Syslog of DP752 while making echo test call:

https://pastebin.freepbx.org/view/188128ad

Packet Capture while from DP752 capture tool while making echo test:

https://pastebin.freepbx.org/view/adec2ba7

Not seeing anything standing out to me on these. Maybe someone with more experience will catch something.

Thanks for the communities help on this!

13

How about to check tcpdump data with wireshark?? you can check even by captured data or capturing real time (port mirroring) for check packed loss.

14

@Stewart1 Do you think this could be an MTU issue? I took the phone back to my office yesterday and programmed another Edgerouter exactly the way it is at the VPN location and hooked it up to an LTE modem. Through Wireguard it is working perfectly. So I wonder if this is site specific. It has DSL but the modem is in bridge mode. The Wireguard MTU is 1420 but at 1420 over my LTE test connection it is working. My next test will be to take this test router to the location (Saturday) and plug it in to see if it works. If not, then it has to be the DSL connection or the ISP Modem getting in the way.

15

IMO unlikely, but do a test by disabling all codecs except ulaw (a.k.a. G.711u or PCMU) and alaw (a.k.a. G.711A or PCMA) on both the phone and the FreePBX settings for the extension. That should make all SIP packets well under 1000 bytes and eliminate the possibility of MTU issues.

Another useful test is setting up another device (different brand of phone, ATA, softphone, mobile SIP app) at the VPN location and test. If it fails in the same way, that exonerates the Grandstream. Unfortunately, if the alternate device works fine, that doesn’t prove the Grandstream is guilty, because it could be sending different but valid traffic that some other element is not handling properly.

16

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