CUBE Configuration Step-By-Step. Part 2

CUBE configurationThis is a second post in the series of CUBE configuration. You can find the first one here.

In this post, I’ll cover some of the more advanced issues and scenarios that most of us are facing with CUBE configuration.


Edit: I recommended using the CUBE Config Utility in conjunction with this post

In the first post, the last step that we were going through was CUBE authentication and registration with ITSP so we’ll pick it up from there.

The next step in our deployment will be the codec selection.

Step 7: Media & Codec selection. The common denominator

Codec Selection

Now, this part can be very straight forward or a complete mess, depends on the complexity of your deployment and the generosity of the ITSP.

What do I mean by that? Well, let’s say you have a single site deployment with CUBE. Your best option is to configure g711 for all VOIP communication and you are done. But what happens if you have a centralized, multi-site deployment (with one CUBE to rule them all) with g729 provisioned as the inter-site codec? And what if your ITSP only supports g711?}

Well, there are probably endless variations and topologies, so let’s define some house rules to make it easier.

First of all, you have to understand what media parameters your ITSP supports.

That’s the easy part. SSH to your CUBE and enable SIP message debug by typing debug ccsip messages. Now, make an inbound call and watch the ITSP’s SDP portion in the INVITE message.

You should be looking at something like that:

 o=- 25678 753849 IN IP4
 c=IN IP4
 t=0 0
 m=audio 3456 RTP/AVP 0 18
 a=tcap:1 RTP/SAVP RTP/AVP
 a=rtpmap:0 PCMU/8000/1
 a=rtpmap:18 G729/8000/1
 a=fmtp:18 annexb=yes
 a=rmcap:1,4 G729/8000/1
 a=rmcap:2 PCMU/8000/1
 a=rmcap:5 telephone-event/8000
 a=mfcap:1 annexb=no
 a=mfcap:4 annexb=yes
 a=mfcap:5 0-11

The a=rtpmap is the parameter you are looking for.

In this example, we can see that both g711 (PCMU) and g729 are supported.

Now, if your ITSP is not using early offer, you’ll have to hardcode g729 on CUBE’s side and watch the SDP included a response from ITSP.

Now that we know what to expect from our ITSP, we can go ahead and decide on the codec distribution in the enterprise.

If your ITSP does support g729, it should be pretty straight forward.

First create your regions in CUCM, as you would normally. In CUBE, have in both ITSP and CUCM facing Dial-Peers, the option to negotiate both g711 and g729. CUBE configuration should like similar to this:

Voice class codec 1
 codec preference 1 g711a
 codec preference 2 g711u
 codec preference 3 g729r8

Dial-peer voice 1 voip
 Description Incoming/Outgoing ITSP
 Voice-class codec 1

If your ITSP doesn’t support g729, some modifications would be required.
Simply put, you are going to have to make a calculated decision regarding what is more costly: adding more bandwidth, in order to support g711 over the WAN or adding more PVDM for transcoding and conference bridging.

If you choose the letter, do remember that you want the transcoding to take place on the CUBE. The recommended configuration would be to use CUBE LTI (local transcoding interface) rather than CUCM SCCP registration.

Basically, LTI has the same features as SCCP based transcoding so do not hesitate to use it. Moreover, it works better for CUBE environments and it will save you some good troubleshooting hours.

Use the following CUBE configuration for LTI based transcoding:

dspfarm profile 1 transcode
 codec g711alaw
 codec g711ulaw
 codec g729r8
 codec g729ar8
 maximum sessions 20
 associate application CUBE

CUBE Configuration


MTP has several roles which mainly focus on bridging between incompatible media capabilities. Among them are: Early Offer/ Delayed Offer, DTMF, uLaw/aLaw, etc.

Early Offer

Whenever your ITSP requires you to use Early Offer, it is best to use CUBE build in EO capability rather than needlessly introducing an MTP into the call flow. You can achieve this by setting the following parameters in CUBE configuration:

Voice service voip
  early-offer forced

Or within a specific dial-peer:

Dial-peer voice 1 voip
 voice-class SIP early-offer forced

As a rule of thumb, avoid using MTP whenever possible as it uses resources and changing the media path. Take some time and design the solution in order to avoid invoking MTP.

If you must, co-locate it with CUBE to optimize the media path. In most cases, software MTP will do the job. Software and hardware MTP are configured the same with one change of parameter:

sccp local GigabitEthernet0/0
 sccp ccm identifier 1 priority 1 version 7.0
 sccp ccm identifier 2 priority 2 version 7.0
sccp ccm group 1
 associate ccm 1 priority 1
 associate ccm 2 priority 2
dspfarm profile 2 mtp
 Codec g729r8
 Codec pass-through
 maximum sessions hardware/software 200
 associate application SCCP

If you have a specific scenario that you need assistance with, let us know in the comments and we’ll be happy to help.


Fax Over IP is a known troublemaker in our community. Ask me and I’ll say that it should have been out the door for a while now, but humankind just can’t seem to let this dying bastard go. Thus, for the time being, we’ll have to learn to live with it.

Since our communication to the provider is IP based, some extra considerations have to be made when using FoIP.

For example, moving to the IP world introduces latency and packet loss towards the provider, flaws which have a great influence on fax transmission. These flaws could be handled on the LAN side and weren’t an issue on TDM links, but on WAN links it’s a different story. Another issue is the g729 codec, which can’t properly encode fax transmissions. Luckily there is a solution.

The solution to both of the above problems is the T.38 protocol. You can think of it as the TCP of faxing. It negotiates, controls and verifies (and re-transmits) the fax transmission.

Once again, our first step would be to check whether our ITSP supports T.38. We can do it the good old way, by just asking the ITSP reps. But, if we want to be on the safe side, debug ccsip messages can give us all the info we need. Just send an incoming fax and watch the SDP from ITSP. And again, if your ITSP is not using early offer you’ll have to hard-code T.38 on CUBE side and watch the response from ITSP. In regards to CUBE configuration, you can achieve this by enabling T.38 on the dial-peer level or in global config. For example:

Voice service voip
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

T.38 version may vary between 0 and 3, so keep your eyes open.

You should be looking at something similar to this in the SDP:

 m=image 17682 udptl t38
 c=IN IP4

This outcome, as you might have guessed, suggests that T.38 is supported.

Unfortunately, this might not be the end of the road for our FAX adventures. Depending on what you use for faxing in your organization, solutions may vary from Fax Servers and Fax2Mail to analog gateways with physical fax machines. Needless to say that they might not all be happy with our new T.38 friend.

Whenever the ITSP does not support T.38, g711 codec will have to be used end-to-end. Assuming g729 is used towards your over-the-wan site, a specific Device Pool will have to be provisioned for the fax devices to allow g711 negotiation. In CUBE configuration, apply the fax protocol pass-through g711u on the Dial-Peer level or globally under Voice Service Voip similarly to this:

Voice service voip
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
dial-peer voice 1 voip
 fax protocol pass-through g711u

Once you understand your options and what you are up against, you can go with one of the solutions or even both. To allow both T.38 and g711, where T.38 is the first choice and g711 is your backup option, the following CUBE configuration is required:

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback fallback pass-through g711a

Since fax over IP is not the main purpose of this post, I’ll stop here. If you need any help or want to know more, please feel free to write in the comments.

Step 8: SIP compatibility. Dig deeper.

Since ITSPs are vendor agnostic, they will not always fit like a glove. There are several compatibility issues that you might encounter, that would introduce the need for changing SIP headers. It might sound a bit overwhelming at first, but once you get the hang of it, you’ll have a very powerful tool in your hands.

I have already written about two common issues here and here.

You can find the more common examples here.

Step 9: CUBE Configuration. Secure the perimeter.

We’ve already established the fact that CUBE is not an information security device. Having said that, it does have some security features. Most of these features are related to layer 7 UC applications that you should implement to secure your environment.

IP Address trust list.

Having a SIP-UA that fronts the internet with access to the PSTN is an obvious security issue. You wouldn’t want every SIP client out there to send invites to your CUBE, using it as a proxy to call whoever he wishes. To avoid that, Cisco had implemented a “white list” feature to filter out unwanted leeches.

The rules are basic. Every IP address that appears under a session target ip within a dial-peer, is trusted by default. All of the other addresses must be manually entered.

For example, if your ITSP provides you with a hostname for his SIP proxy, resolve the name to IP and place it in your trust list. It is recommended that you send an inquiry to the ITSP to get all of his active SIP servers IP addresses.

CUBE configuration should look like this:

Voice service voip
 ip address trusted list

After you are done with building the trust list you can add another layer of defense from TDoS attacks by adding the command silent-discard untrusted. This command will just ignore incoming messages from unauthorized entities instead of responding with a 403 error. If your router is above 15.3.3M this option is enabled by default.

Voice service voip
  silent-discard untrusted

Another thing you want to consider would be disabling the local registrar feature. Since in most scenarios, no one is going to be registering to your CUBE, it’s a good practice to disable it altogether.

Voice service voip
 no registrar server

Let me know if you find this helpful and need any help with your deployment!

Image Designed by Freepik

Build pro IOS configs. FAST.

3 thoughts on “CUBE Configuration Step-By-Step. Part 2”

  1. Hello Pasha,
    Great tech blog! it is very helpful and easy to understand.
    I know you dint cover sip profiles much.

    I have this interesting scenario. and yes I’m new to SIP Profiles.

    I’m attempting to prefix 3 digit site code to 4 digit extension in Remote-Party-ID so that calling is would display 7 digits.

    I got this

    voice class sip-pro 10
    response 180 sip-header Remote-Party-ID modify sip:(….)@ sip:698\[email protected]
    response 2000 sip-header Remote-Party-ID modify sip:(….)@ sip:698\[email protected]

    In SIP-Profile Test Tool it worked as desired but in CUBE itself replaces it. and carry on 6981 only

    Once entered in IOS adjusting as [email protected] in the profile
    Is there alternative you can advise? want to keep it simple.

    IOS 15.7(3)M3
    CUBE 11.5.2


    1. Hi EJ,

      Kinda hard to TS without looking at the SIP messages coming in an out but let’s try to figure this out.
      One thing I noticed is that our SIP profile include only responses, any reason for this? Remote-Party-ID can appear in INVITE as well.
      Can you also try to replace the (….) with (.*)

      Let me know if the behavior changes and if you can paste the SIP debug here.

  2. Hi Pasha,

    The issues what it seems like appears to be tied to one router, but why I don’t know
    same IOS same ROM version, don’t think it has to do anything with SIP profile syntax/regex.
    Here’s outputs when entering profiles itself once sh run display with \[email protected]” it will work as desired but those that don’t work only in replacing and not prefixing that \ interpret as 1

    —–NON WORKING Router:
    Entering profiles:
    APPO1-RTWAN01(config)#voice class sip-profiles 1
    APPO1-RTWAN01(config-class)# response 180 sip-header Remote-Party-ID modify “sip:(….)@” “sip:698\[email protected]
    APPO1-RTWAN01(config-class)# response 200 sip-header Remote-Party-ID modify “sip:(….)@” “sip:698\[email protected]
    APPO1-RTWAN01(config-class)#voice class sip-profiles 2
    APPO1-RTWAN01(config-class)# response 180 sip-header Remote-Party-ID modify “sip:(.*)@” “sip:698\[email protected]
    APPO1-RTWAN01(config-class)# response 200 sip-header Remote-Party-ID modify “sip:(.*)@” “sip:698\[email protected]
    sh run!!!output
    voice class sip-profiles 1
    response 180 sip-header Remote-Party-ID modify “sip:(….)@” “sip:[email protected]
    response 200 sip-header Remote-Party-ID modify “sip:(….)@” “sip:[email protected]
    voice class sip-profiles 2
    response 180 sip-header Remote-Party-ID modify “sip:(.*)@” “sip:[email protected]
    response 200 sip-header Remote-Party-ID modify “sip:(.*)@” “sip:[email protected]

    —-Different Working router:
    CRPO1-RTWAN01(config)#voice class sip-profiles 1
    CRPO1-RTWAN01(config-class)# response 180 sip-header Remote-Party-ID modify “sip:(.*)@” “sip:677\[email protected]
    CRPO1-RTWAN01(config-class)# response 200 sip-header Remote-Party-ID modify “sip:(.*)@” “sip:677\[email protected]
    CRPO1-RTWAN01(config-class)#do sh run
    voice class sip-profiles 1
    response 180 sip-header Remote-Party-ID modify “sip:(….)@” “sip:677\[email protected]
    response 200 sip-header Remote-Party-ID modify “sip:(….)@” “sip:677\[email protected]

    The reason to have only responses, no specific reason, idea to show called number for the calling party to 7 digits extensions remote cme site have 4 digits.

    Thank you for your support.

Leave a Reply

Your email address will not be published. Required fields are marked *