Does anyone know how to disable SIP AGL in Cisco Meraki MX64?

[Lorcan]

I am trying to set up a FreePBX on-premises server on my LAN. 

Currently I have the server working with softphones, so I have an app on my phone and an app on my desktop, both assigned extensions accessing the FreePBX phone server, and they are able to make a phone call to each other and speak with clear audio.

However, when I try to connect with my phone and call the desktop from outside the LAN (I turned wifi off on my phone, therefore connecting with 4G Mobile Data) this does not work.

I am still able to ring the desktop, but when I answer on the desktop, there is no audio at all on either side.

Many have told me to disable SIP AGL, and to check my NAT settings. Anyone have any idea how to do this in MX64 dashboard?

[BrandonS]

There is no SIP ALG on Meraki MX so you must have some other issue. 

[ww · Accepted solution]

Could be that you need some port forwarding to your pbx. 

UDP/5060 -> Forward to <ip pbx>

UDP/10000-20000 -> Forward to <ip pbx>

https://wiki.freepbx.org/plugins/servlet/mobile?contentId=4161590#content/view/4161590

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#Port_forwardin...

[Lorcan]

Thanks everyone, this was the solution:

"UDP/10000-20000 -> Forward to <ip pbx>"

[ParatrooperJoe]

I know this is an old thread, but I am having same issue. How did you go about implementing this resolution exactly, if you dont mind sharing?  Also, we use a VOIP service for our phones, so I am wondering what exactly is the "<ip pbx>" you mentioned?

[Lorcan]

Hi,

The issue I was having was that while I could call on the same LAN (Local area network) between my phone and PC, I was unable to from outside the LAN.

The phone, the desktop PC, and the FreePBX phone server/service were all on the same network, local private network in the building.

Therefore the FreePBX SIP Server settings programmed into the phone / desktop PC on the softphone clients e.g. 192.168.10.20, user + pass, were all working fine.

Once you go outside the network and are trying to connect to the SIP server with your phone, you must use port forwarding / NAT. You are opening a port on your network to the outside world. That is what I had to do (ports 5060, and ports 10000-20000). Now when someone goes to my public IP address port 5060 or 10000-20000, the local IP address it gets on my network is the SIP server.

Your setup is slightly different, because you are using a VOIP service. That is somewhat unspecific. I assume you mean cloud-hosted phone server? So you dont have a server in your workplace, but you are using a service online? Do they provide you with a SIP server address, username and password?

If you are able to connect the calls, but there is no voice heard on either device, its likely that the VOIP service themselves will have to allow port forwarding on more / different ports. You will likely need to contact your VOIP service for help if this is the issue. With mine, I had the VOIP service set up my self, so I had to port forward on my own network 10000-20000 for voice data. The call connects with port 5060, but voice data is in 10000-20000 i think

[ParatrooperJoe]

10-4 Thanks so much for the quick and thorough explanation! I greatly appreciate that!

[Lorcan]

No problem best of luck 🙂 

[ParatrooperJoe]

So I m back again. We have tried literally everything we can think of hilariously, my last google search brought me right back here, and I was like.. hey this looks familiar!  Any chance you might be able to offer me advice exactly how to forward UDp to my voip vendors ip address within meraki firewall?

What I have discovered with packet captures, is that our phones are requesting to register every 30 seconds. Here is the breakdown:

1.  Phone send request: REGISTER to external Server

2.  External server sends back  Status: 407 Proxy Authentication Required

3.  Phone sends second request: REGISTER to external Server

4.  External server sends back  Status: 200 OK (REGISTER) (1 binding)

Voip company confirmed that is not expected behavior. They say it should ask to register, their server then asks for username and password, the phone sends it, and then it registers...it shouldnt be asking twice to register.

They seem to think somewhere along the way, within our network, packets are getting dropped/lost.  We have ruled out SIP ALG, so it must be some sort of port forwarding/DSCP tagg type issue.

In any case, Using Meraki Firewall, is there a way to do some sort of port forward rule that ensures "UDP/10000-20000 -> Forward to <external IP of my VOIP Provider>" as well as any applicable forwards for port 5060?

I do have QoS rules setup under traffic shaping that is set to tag VOIP traffic as EF 46 with highest priority.

Any help is appreciated!

[GIdenJoe]

There is no concept of outbound port forwarding.
The only thing the MX does is first create an outbound flow between your phone and the external server and perform SNAT on the packet.  (so the source IP of your phone is translated to the WAN IP on the MX)  Destination address is unaltered.  It is the job of the phone to make sure it has the correct destination IP of the SBC it has to register to.  The only thing you can manipulate is the outbound WAN circuit for that traffic.

SIP ALG cannot be an issue since the MX simply does not implement it.

I also take issue with the explanation of the phone provider.  Proxy authentication required logically seems like the phone setup has not been done correctly and has nothing to do with possible packet loss.  Proxy auth would be that the phone cannot directly authenticate using that server directly but has to go through another device.  If that is not the desired behavior, then something is wrong in the config of the phone system.

[ParatrooperJoe]

Well, I would be inclined to agree about rejecting their explanation, however, we have removed a couple fo phones off our Meraki Network entirely, and hooked them directly to a backup internet source that is not connected to our network at all, and the phones work flawlessly with no problems.  If we hook up that internet source to WAN 2 and hook the phones back up to ports on the MX250 firewall in out network, and force those phones to use WAN 2 (and VLAN 88, it's own voice vlan) the problem presents again. This would suggest thebproblem is our network and not the phones.  I want it to be their problem, but it seems it's within our network, sadly.

The next thing I want to attempt, os to see if I can get packet captures of these two phones when they are outside our network, on the backup internet, when they are working fine, and compare packet captures.

Any ideas on how to find this gremlin and fix it would be greatly appreciated!!

[GIdenJoe]

Well when the phones were off the Meraki network, did you manage to take a pcap of the phones there.

- Boot process (getting IP)
- Registering

There are a multitude of variables why the phones act like they do.

Have you opened all necessary ports outbound according to the documentation of the vendor.  In that different network were they also behind a closed firewall.

[ParatrooperJoe]

Well, finally have a solution!

Turns out it was 100% the Meraki Firewall. O have an MX250, and it was a bug in Firmware MX 18.211.2...related to some changes in the way traffic is routed. One of the issues specifically cited SIP/RTP traffic internally potentially being dropped.

The fix was to upgrade the Firmware to MX18.211.3 where the bug was fixed. 

They also indicated that there was a workaround before the newest version was released that could also resolve the issue. The workaround, was to go to QoS rules for VoIP traffic and if you had it set to High or Low, change it to Normal and the problem should go away.

Now why on earth did Meraki Support not suggest either of those options to me 6 weeks  ago as a first thing to try, given they have known about this for at least 4 months?

Who knows, but it seems that when I had packet captures on and off the meraki network and could prove the issue only exists when on the meraki network, then and only then did they cough up an answer.

I'm just glad this nightmare is over and I can back to enjoying a quiet, and smooth network.

Hope this info helps someone else who may run Into this issue.

[GIdenJoe]

Ah I see, that was an issue a while back but was not limited to SIP and RTP traffic but all kinds of IP traffic.  That issue was why the 18.211.0.1 was released back then.  I also had issues with that firmware build a few months ago but that was purely over the AutoVPN tunnel, not straight to the internet.

[DarrenOC]

One way or no audio is typically down to a routing issue.  Confirm your port forwarding. 5060 is used for signalling, I would focus on the ports used for the actual voice streams.