CUBE Configuration Step-By-Step. Part 1

CUBE ConfigurationIt’s Monday morning, you are checking your Email after a long weekend just to find out that your boss was quite busy and you have been assigned a new project.

The good news? It involves ITSP and CUBE.


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

I figure that you’ve already heard that PRIs are not the latest fashion so I’ll skip the long introduction. I even suspect that some of you have already implemented SIP Trunking to Service Providers.

For those who didn’t, ITSP (Internet Telephony Service Provider) is the Service Provider for SIP services that are slowly but surely replacing the good old PRIs.

CUBE is the device that will securely connect our company’s VOIP network to the ITSP over the internet.

And this is how CUBE configuration is done:

Step 1: ITSP. Know your enemy.

In order for you to nail it right the first time (without banging your head against the wall), before you start with any CUBE configuration, you should get your facts straight. Get in touch with the ITSP and ask them for the following information:

  • SIP Trunk IP Address – IP Address of the ITSP’s proxy(s)
  • SIP Trunk FQDN – the FQDN of the proxy(s)
  • SIP trunk port number – 5060 by default
  • Transport layer – TCP/UDP
  • Supported codec(s)
  • Fax protocol support – T.38 / Pass Through (g711)
  • DTMF signaling Method
  • Early offer requirements
  • Registration requirements – username, password, realm
  • Digest authentication requirements – username, password, realm
  • Calling Number – number of digits to send in the from field

Step 2: Architect CUBE. Prepare yourself.

If the pre-sale didn’t do the design fully, now is the time to realize the connectivity subtleties.

CUBE’s job, among others, is to act as a demarcation point between the enterprise network and the internet. That being said, CUBE is not a security device per se, rather it’s strength lies in implementing it according to best practice.

You can look at it as a proxy to all VOIP traffic between the internal and the external network. The internal network sees one side and the external the other, allowing the internal network to be completely hidden from the external one.

Now, for that to happen several rules should be preserved.

First of all, place your CUBE in a DMZ. It’s bad practice to place it facing the internet with no FW in the front.

Second, enable NAT on the FW to translate external IP address to CUBE’s address.

Third, SIP ALG (Application Layer Gateway) feature on the FW, should inspect voice packets and in turn, replace the IP address fields in the SIP headers, from CUBE’s address to the external address.

*You can actually skip the last two steps if you implemented two interfaces on the CUBE (given CUBE’s WAN interface has a legal routable IP address).

Step 3: CUCM. Stay on the beaten track.

Nothing new here. Just configure a trunk that points to CUBE’s address or hostname.

If you are looking for a High Availability solution you should take a look here and here for best practice.

Follow up with your regular Route Patterns and Route Lists.

Step 4: CUBE Configuration. Start globally.

Finally, it’s time to get our CUBE configuration going. First thing to do would be to enable CUBE application and URI based routing.

Voice service voip
 mode border-element license capacity X
 allow connection SIP to SIP
 call-route url

It would also be a good time to configure some DNS servers in order to be able to resolve names when necessary.

ip name-server

Step 5: CUBE Configuration. Build the foundations.

And the foundations are, as you might have guessed, our dial-peer structure.

So how do we build it?

Personally, I love them nice and organized, each one having its own purpose. Makes it very easy to troubleshoot afterward.

The first thing to do would be to set up the structure.

Dial-peer structure

I use the following structure in all of my deployments and it works great.

  • Incoming DP from ITSP
  • Incoming DP from CUCM
  • Outgoing DP to CUCM
  • Outgoing DP to ITSP

This is the point where you want to get a cup of coffee as the next section of CUBE configuration will involve your favorite subject:

Dial-Peer matching

Actually, this demon can be conquered quite easily as long as you know what goes first.

So, without further ado, this is how the magic happens:

SIP: Inbound dial-peer matching preference:
  1. voice class uri URI-class-identifier with incoming uri {via} URI-class-identifier
  2. voice class uri URI-class-identifier with incoming uri {request} URI-class-identifier
  3. voice class uri URI-class-identifier with incoming uri {to} URI-class-identifier
  4. voice class uri URI-class-identifier with incoming uri {from} URI-class-identifier
  5. incoming called-number DNIS-string
  6. answer-address ANI-string
SIP: outbound dial-peer matching preference:
  1. destination route-string
  2. destination URI-class-identifier with target carrier-id string
  3. destination-pattern with target carrier-id string
  4. destination URI-class-identifier
  5. destination-pattern
  6. target carrier-id string

As you can see, SIP and URI based parameters have priority over dialed numbers so it’s better to get familiar with it.

Now, that the force is strong with you, let’s see some examples. I’ll use the following parameters:

  • DID is 97212345XX
  • Outbound calls are prefixed with a 9
  • ITSP Server:
  • CUCM pub:
  • CUCM sub:
Incoming DP from ITSP

Easiest way to get all of the traffic coming from ITSP is to match your DID range

dial-peer voice 1 voip
 description incoming calls from ITSP
 session protocol sipv2
 incoming called-number 97212345..
 voice-class codec 1
 dtmf-relay rtp-nte sip-notify
 no vad
Incoming DP from CUCM
voice class uri 2 SIP
 host ipv4:
 host ipv4:

dial-peer voice 2 voip
 description incoming calls from CUCM
 session protocol sipv2
 incoming uri via 2
 voice-class codec 1
 dtmf-relay rtp-nte sip-notify
 no vad

Using incoming uri via is a great way to match calls coming from CUCM servers. First, CUCM will always replace the VIA field with its own address (or host). Second, it has the highest priority in dial-peer matching

That is how the incoming packet from CUCM would look:

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP;branch=z9hG4bK1279e20870
From: "ucpros" <sip:[email protected]>;tag=63~caf26ba8-507b-44f8-ac22-461d3d689977-32037284
To: <sip:[email protected]>
Outgoing DP to CUCM

Nothing fancy here, it’s a good practice to keep the DID structure here with the destination-pattern command:

dial-peer voice 11 voip
 description Outgoing calls to CUCM
 destination-pattern 97212345..
 session protocol sipv2
 session target ipv4:
 voice-class codec 1
 dtmf-relay rtp-nte sip-notify
 no vad
Outgoing DP to ITSP

Create as many DP as you need for your dial plan. It should look something like this:

dial-peer voice 10 voip
 description Outgoing calls to ITSP
 destination-pattern [2-9]……..
 session protocol sipv2
 session target
 voice-class codec 1
 dtmf-relay rtp-nte sip-notify
 no vad

Step 6: CUBE Authentication and Registration

Authentication and registration are two methods that have different roles in the SIP-based SP architecture.

In most cases, what you’ll see is that for outgoing calls, the ITSP will challenge you with digest authentication. It will look something like this:

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP;branch=z9hG4bK2B595B;received=
From: "ucpros" <sip:[email protected]>;tag=1B41168-16C2
To: <sip:[email protected]>;tag=3B6A681F-57FE7956000BB3F6-C4437700
Call-ID: [email protected]
CSeq: 101 INVITE
Proxy-Authenticate: Digest realm="", nonce="V/57q1f+eVNRh1YSGWtBICw3xqS+b2gG"
Server: ser (3.3.0-pre1 (i386/linux))
Warning: 392 "Noisy feedback tells:  pid=1820 req_src_ip= req_src_port=5060 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt==1"
Content-Length: 0

In order for your CUBE to pass the auth challenge you’d have to configure the following parameters:

 authentication username ucpros password 7 123a1231245ade realm

For the ITSP to know where to send your calls, there is a need for registration. Of course they would have to provide you all the details beforehand.

Registration is done with the following config:

 credentials username ucpros password 7 1243124ea3432 realm

To check if you are registered, run the following command

CUBE#show sip-ua register status

Line                             peer       expires(sec) reg survival P-Associ-URI

================================ ========== ============ === ======== ============

ucpros                           -1         56           yes normal


Now, if you have issues with registration, a simple debug ccsip messages won’t do it. This is because by default, outgoing, non-call related debugs just won’t appear there. If you want to debug your registration run the Debug ccsip non-call command along with debug ccsip messages to get the full output.

This sums up the basics of CUBE configuration. There is one more thing though that you have to do to be able to receive calls. For your CUBE to accept SIP messages from a certain host, you have to let your CUBE know about it implicitly. I’ve covered the process in the next post in the series. If you want to disable this feature (not recommended) and accept the security risks, just place the command no ip address trusted authenticate under voice service voip configuration.

If you have any issues, questions, doubts or feel that something is missing, please feel free to post it in the comments below.

Image Designed by Freepik

Build pro IOS configs. FAST.

37 thoughts on “CUBE Configuration Step-By-Step. Part 1”

  1. Why would t you add a preference on the dial peer? :-). Btw do you ever set a loopback for the connection to the itsp?

    1. Hi Jc,
      The “preference” command exists on the dial-peer whether you manually enter it or not. The preference value is set by default to “0”, which means the highest priority.
      So “preference” is only needed if you want to prioritize a certain dial-peer over the other.

      Regarding the loopback, i presume that you mean binding the loopback address for signaling and media to use in SIP messages towards the ITSP.
      There are no restrictions on which interface to bind your VOIP communication to, the rule of thumb is to use the closest routable interface to the destination. For example, if your next hop towards the ITSP would be the FW, it would be logical to bind VOIP traffic to an interface that routes towards the FW. On CUCM facing dial-peers it’s best to set the binding to an interface that routes to CUCM. That being said, there are dozens of different scenarios and topologies, each requires a slightly different solution. Do you have a specific scenario in mind?

  2. Nope, you answered my question for me! Man, I can’t say how much I appreciate this blog! I have been going over sip trunk and cube guide… and I must admit I messed a few things out while I was setting up my cube configuration and going back to change a few things on the cucm side, so thank you and keep it up!!!!!

  3. Hi,
    Thanks ,your explanation cleared up a lot of things. But I have one question , please help me out as im new to this. We have taken a new ITSP service, they are asking for the below value to be changed to connect to their service.


    need to be changed to this

    can you please provide the command, im in urgent need of this.

    Thank you

    1. I have cleared that hurdle, but my register message needs to be changed too.

      REGISTER SIP/2.0

      REGISTER sip:856782xxxx SIP/2.0

      Can you please provide the command for that.
      Thank you

  4. Hi
    Was able to fix that, still its not registering, debug below

    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP;received=;branch=z9hG4bK1A0722C2;rport=56416
    From: ;tag=9EFD6C50-B17
    To: ;tag=1591349535-1493025884924
    Call-ID: B2C32019-27A011E7-86F5B472-62A085D2
    Timestamp: 1493026948
    CSeq: 251 REGISTER
    WWW-Authenticate: DIGEST qop=”auth”,nonce=”BroadWorksXj1vx29rwTrm53mpBW”,realm=”BroadWorks”,algorithm=MD5
    Content-Length: 0

    043198: *Apr 24 09:42:28.180: //170181/0
    SIPTEST#00000000000/SIP/Info/sipSPICheckResponseExt: non-INVITE response with no RSEQ – do not disable IS_REL1XX
    043199: *Apr 24 09:42:28.180: //170181/000000000000/SIP/Error/sipSPIHandleAuthChallenge: Error getting credentials

    Can you please help out


    1. Hi Sharaq,
      seems like your register message is missing the proper credentials.
      Please attach the register message you send to ITSP and your sip-ua config.
      I would also recommend you to download the CUBE Configuration Utility from this website, it would help you to get your configuration straight.

      1. Hi
        Please note our current ITSP provides a physical ITSP line to the cube, we are taking another ITSP who is cloud-based and i need to set it up.

        REGISTER sip:856782xxxx SIP/2.0
        Via: SIP/2.0/UDP;branch=z9hG4bK1A05D4AF
        From: ;tag=9EE4ADEC-1E2D
        Date: Mon, 24 Apr 2017 09:15:26 GMT
        Call-ID: B2C32019-27A011E7-86F5B472-62A085D2
        User-Agent: Cisco-SIPGateway/IOS-12.x
        Max-Forwards: 70
        Timestamp: 1493025326
        CSeq: 242 REGISTER
        Expires: 3600
        Supported: path
        Authorization: Digest username=”856782xxxx”,realm=””,uri=”″,response=””,nonce=””
        Content-Length: 0

        credentials username 856782xxxx password 7 xxxx realm
        authentication username 856782xxxx password 7 xxxx realm
        retry invite 4
        retry response 3
        retry bye 2
        retry cancel 2
        retry notify 6
        retry register 5
        timers notify 1000
        timers register 1000
        registrar 1 ipv4: expires 3600
        registrar 2 expires 60 auth-realm

        Thank you

  5. Seems like we have a realm miss-match.
    Try removing the realm option or change it to BroadWorks.

  6. Hi , thanks a lot!!!
    changing the realm to broadworks worked, out going is working fine .
    Just 2 questions 🙂

    1. Incoming not working, this is the debug when i call in,

    007996: *Apr 24 17:32:48.434: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    INVITE sip:[email protected]:5060 SIP/2.0
    Via: SIP/2.0/UDP;branch=z9hG4bKf8vq8n205gr0ambed361.1
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”
    Call-ID: [email protected]
    CSeq: 276446199 INVITE
    Call-Info: ;appearance-index=1
    Recv-Info: x-broadworks-client-session-info
    Accept: application/media_control+xml,application/sdp,multipart/mixed
    Max-Forwards: 39
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 291

    o=BroadWorks 846750027 1 IN IP4
    c=IN IP4
    t=0 0
    m=audio 22022 RTP/AVP 0 8 18 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    007997: *Apr 24 17:32:48.446: //2881/DE89A7F89DAB/SIP/Msg/ccsipDisplayMsg:
    SIP/2.0 100 Trying
    Via: SIP/2.0/UDP;branch=z9hG4bKf8vq8n205gr0ambed361.1
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”
    Date: Mon, 24 Apr 2017 17:32:48 GMT
    Call-ID: [email protected]
    CSeq: 276446199 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-12.x
    Content-Length: 0

    007998: *Apr 24 17:32:48.450: //2881/DE89A7F89DAB/SIP/Msg/ccsipDisplayMsg:
    SIP/2.0 403 Forbidden
    Via: SIP/2.0/UDP;branch=z9hG4bKf8vq8n205gr0ambed361.1
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”;tag=161C128-1E8
    Date: Mon, 24 Apr 2017 17:32:48 GMT
    Call-ID: [email protected]
    CSeq: 276446199 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-12.x
    Reason: Q.850;cause=21
    Content-Length: 0

    007999: *Apr 24 17:32:48.486: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

    SIPTEST#ACK sip:[email protected]:5060 SIP/2.0
    Via: SIP/2.0/UDP;branch=z9hG4bKf8vq8n205gr0ambed361.1
    CSeq: 276446199 ACK
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”;tag=161C128-1E8
    Call-ID: [email protected]
    Max-Forwards: 39
    Content-Length: 0

    2. My ITSP guy is sayin, “I do not see your registered at this time. When I send you the 401 unauthorized, you need to send a new REGISTER message with authentication.

    The flow is as such, you send register message without authentication, I reply with a 401, you send a register message with authentication and receive a 200 OK.”
    Should i be concerned?

  7. For the first part, it seems like CUBE sends the forbidden message. make sure that your ITSP ip addresses are configured in the ip address trust list (you can see an extended explanation in the second part 2 of this article series.

    For the second part, you can check your registration with the “show sip-ua register status” command. look for the “Reg” status.

    In most cases, registration is actually just for incoming calls. That is how the ITSP knows where to send calls for your DID block. Registration uses the “credentials” command under sip-ua first, so make sure your realm is good there.

    For outgoing calls your ITSP is right. you send an invite, get a challenged response and send another invite with credentials. this is where the authentication command under sip-ua kicks in.
    I think this post might be of help in your case.

  8. The sip line is register status shows as yes, outgoing calls are working fine, incoming are also coming to the cube, here is a debug for incoming call,

    after quite a few invite and try messages this message shows up,

    016097: *Apr 24 19:51:38.397: //4212/40024979AC57/SIP/Msg/ccsipDisplayMsg:
    SIP/2.0 487 Request Cancelled
    Via: SIP/2.0/UDP;branch=z9hG4bKu8ah1u10agd13mjlr160.1
    From: “john ed “;tag=1495946870-1493062351914-
    To: “856782xxxx 856782xxxx”;tag=1E0DC04-D6F
    Date: Mon, 24 Apr 2017 19:51:38 GMT
    Call-ID: [email protected]
    CSeq: 280608278 INVITE
    Allow-Events: telephone-event
    Server: Cisco-SIPGateway/IOS-12.x
    Reason: Q.850;cause=16
    Content-Length: 0

    1. Great to hear that things are moving forward.
      Cause 16 is Normal Call Clearing.
      The view is quite limited from here but it looks like a call routing issue.
      You should verify that you have proper dial-peers that point towards CUCM.
      You can verify it with SIP debug. Make sure that CUBE sends an invite towards CUCM in the process and check for the response. If CUCM is not involved, CUBE probably can’t find a match for the outgoing leg or sends it to the wrong destination.

  9. Hi , its finally working with incoming too. Thanks a lot for your help.
    Dial-peer was misconfigured 🙂

    1. I’m having the same issue with incoming calls. Outgoing are working fine. Can you post examples of your dial-peers? that would be very helpful.

      Thanks for your ports

      1. Hi Fernando,
        Can you please post the output of debug ccsip messages while the issue occurs?

  10. We have a CUBE implementation with the SIP-UA configurations but I could not find any SIP or proxy servers mentioned. Only under the dial-peers I see the session target of the ISP server mentioned.

    So am just trying to understand how this setup works and is it not mandatory to mention the register server address in SIP-UA.

    Please clarify my doubts.

    1. Hi Rad,
      Sorry for the late response,
      Usually ITSPs require registration to allow incoming calls
      as it will allow them to send traffic to co-relate your DID range with your IP address, just like CUCM does with phones (registers an ext with it’s location in the network – it’s IP address).
      If they don’t use registration, they would have to manually add every entry to their routing table. Imagine you would have to add every phone to CUCM with it’s IP address.. not only it makes provisioning hellish it’s also quite difficult to maintain as IP addresses tend to change.

      Referring you question, i can’t see your configuration but you can check you registration status by running
      “show sip-ua register status”
      If it is indeed not registered, my guess would be that your ITSP uses static routing (much like we do with dial-peers). Although not likely, it is still possible..

  11. Hello i want to ask something
    i do the same configuration on my SIP Router but without the Command
    mode border-element
    and the call work fine

    can you correct me if im wrong

    1. Hi,
      The Mode Boarder-Element command enables some CUBE related CLI commands.
      It even requires a router reset on some platforms.
      The command is not required for basic functionality tho, this is taken care of by the ‘allow connections sip-to-sip’.

      Hope that helps.

  12. Hello Team,

    I need your help:

    I have a problem with the username that expect my ITSP:
    with my cube I cant register my account, but when I register with phoneline (softphone) it work properly.

    my ITSP expect the username in this format:
    [email protected] — example

    1. Hi Guillermo,
      why won’t you open a thread in the forum section and we’ll get to the bottom if it?

  13. Hey UCPROS,
    Thanks for this BLOG you guys are maintaining. I have reached here via cisco forums website when I was searching to setup SIP trunk between ITSP – CUBE with authentication.
    I have been used to with un-authenticated SIP trunks. This is something new i got to know.
    Cheers and appreciate to your efforts in managing. (+5)

Leave a Reply

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