Meraki MX ❤️ Cisco CUBE

Meraki products provide incredibly simple setup, excellent network visibility, and cloud management. The CUBE (Cisco Unified Border Element) is the SBC market leader. Sounds like a match made in heaven! Unfortunately, utilizing a CUBE with a Meraki MX isn’t entirely straightforward.

What’s the big deal? Three letters, NAT

NAT has been known to cause havoc with SIP. Unlike many web-based protocols, SIP requires session establishment in both directions. This means that the SIP SDPs contain both public and private IP addresses. (see our previous article on SIP basics). Firewalls enabled with application-level gateway (ALG) capabilities, such as Cisco’s ASA, are able to open packets and rewrite public and private addresses. Unfortunately, Meraki MX units don’t support ALG.

What to do? Below is sample configuration highlighting one possible solution. Let us start by looking at a diagram of the sample network.

CUBE Config: (only showing relevant CUBE portions)

Depending on your dial-peer configuration, the inbound call may ring through, connect for a couple seconds, and then disconnect. If that is the case, you will see SIP messages similar to the one below repeating over and over.  As you can see, the contents of the SIP message contain the internal IP address and not our public IP. The SIP provider will reject these responses and the call will never properly setup.

debug ccsip messages output:

If inbound calls simply fail, you may see a similar message in your debug. The invite is addressed to: [email protected] Because is the public IP and not an address assigned to the CUBE router, the call is being rejected with an error of: SIP/2.0 400 Bad Request – ‘Invalid Host’.

The Fix

CUBE is able to modify the sip and sdp headers via sip profiles. This sip profile will replace the internal IP address ( with the Public IP address (

Once the sip profile has been created. Add it to voice service voip -> sip. It should look like this:

If you are receiving the ‘Invalid Host’ message, create a loopback interface with the the public IP address.

Since the router now has that IP address assigned to it, CUBE will accept the inbound sip message.

If you haven’t already done so, create a DMZ on the Meraki MX and assign it to one of the secondary LAN ports of the MX.  Click here for details on creating a DMZ:
meraki-dmzNext, create a 1:1 NAT entry:

I recommend being more specific on the allowed inbound connections. For testing, this was set to Any/Any.

Once these changes have been made, inbound and outbound calls should be working! The debug on working inbound call will now look like the below message. Notice, all of the IP references have been updated with the public IP addresses. The final message is an ACK from the provider.

With these changes in place, inbound and outbound calls should be working perfectly behind a Meraki MX!

If you have any questions or comments, please leave them below. I would love to hear how this config works in your deployment.


Who is calling???

Twilio Elastic SIP Trunking

1/27/19 – Update: Elastic SIP trunks now support CNAM. This method outlined below is still useful for passing caller name with programmable voice.

A couple months ago I switched my Dad’s business over to Twilio Elastic SIP trunks. I have been very happy with the service. Not only was it really easy to deploy, but the service has been rock solid. The only downside that I discovered during my initial testing was that Twilio doesn’t deliver the caller name in the SIP header! Twilio offers a service for lookups and there are a couple add-ons that will do caller name lookups, however, they don’t alter the SIP headers. In the solution below, I am using the addOn OpenCNAM by telo. This will work with Twilio’s lookup service, but the function will need to be altered to capture the correct data.  I found OpenCNAM to be more accurate. It took me a bit of trial and error, but I finally figured out a solution!  In order to make this work, follow the steps below.

  1. Twilio Function: Here we will send the caller name as a custom SIP header
  2. CUBE SIP Profile: Using SIP Profiles on the Cisco Unified Border Element, we can insert the customer header containing the Caller Name into the P-Asserted-Identity SIP header

Twilio Function:


A handful of things need to be done on CUBE. First a sip-copylist and sip-profile will need to be created.



Once the copylist and profile have been created, they will be applied to an inbound and outbound dial-peer.

dial-peer example

The final step is to point the phone number at the Twilio Function. You should now see caller name on inbound calls!

Hopefully this will save some time for the next person trying to figure this out!


– Brad