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 with a new project.

The good news? It involves ITSP and CUBE.

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 say, 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 legal routable IP address).

If you really want to understand SIP ,NAT & ALG, you should really enroll in the Learn SIP course. Keith thoroughly explain these issues, along with SIP Authentication & Registration and in depth SIP protocol exploration. Big Like.

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
 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 8.8.8.8 4.4.4.4

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 afterwards.
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: ucrpos.net
  • CUCM pub: 192.168.1.10
  • CUCM sub: 192.168.1.11
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:192.168.1.10
 host ipv4:192.168.1.11

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:

Received:
INVITE sip:403454@192.168.1.20:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.10:5060;branch=z9hG4bK1279e20870
From: "ucpros" <sip:100@192.168.1.10>;tag=63~caf26ba8-507b-44f8-ac22-461d3d689977-32037284
To: <sip:403454@192.168.1.20>
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:192.168.1.10
 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 dns:ucpros.net
 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:

Received:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK2B595B;received=84.84.5.5
From: "ucpros" <sip:100@ucpros.net>;tag=1B41168-16C2
To: <sip:pashat@iptel.org>;tag=3B6A681F-57FE7956000BB3F6-C4437700
Call-ID: ED38729-8FDC11E6-8009C435-E1F05117@192.168.1.20
CSeq: 101 INVITE
Proxy-Authenticate: Digest realm="ucpros.net", nonce="V/57q1f+eVNRh1YSGWtBICw3xqS+b2gG"
Server: ser (3.3.0-pre1 (i386/linux))
Warning: 392 192.168.0.85:5060 "Noisy feedback tells:  pid=1820 req_src_ip=192.168.0.155 req_src_port=5060 in_uri=sip:pashat@iptel.org out_uri=sip:pashat@iptel.org via_cnt==1"
Content-Length: 0

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

SIP-ua
 authentication username ucpros password 7 123a1231245ade realm ucpros.net

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:

sip-ua
 credentials username ucpros password 7 1243124ea3432 realm ucpros.net
 registrar dns:ucpros.net

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

CUBE#

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 you 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

20 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.

    this
    Contact:

    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.

      from
      REGISTER sip:proxy.trunk.seven13.tnltd.net:5060 SIP/2.0

      to
      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

    Received:
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP 192.168.100.45:5060;received=13.13.13.13;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

    Thanks

    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.

        Sent:
        REGISTER sip:856782xxxx SIP/2.0
        Via: SIP/2.0/UDP 192.168.100.45:5060;branch=z9hG4bK1A05D4AF
        From: ;tag=9EE4ADEC-1E2D
        To:
        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
        Contact:
        Expires: 3600
        Supported: path
        Authorization: Digest username=”856782xxxx”,realm=”proxy.trunk.seven13.tnltd.net”,uri=”sip:proxy.trunk.seven13.tnltd.net:5060″,response=””,nonce=””
        Content-Length: 0

        sip-ua
        credentials username 856782xxxx password 7 xxxx realm proxy.trunk.seven13.tnltd.net
        authentication username 856782xxxx password 7 xxxx realm proxy.trunk.seven13.tnltd.net
        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:10.10.10.2 expires 3600
        registrar 2 dns:proxy.trunk.seven13.tnltd.net expires 60 auth-realm proxy.trunk.seven13.tnltd.net

        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,

    SIPTEST#
    007996: *Apr 24 17:32:48.434: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:856782xxxx@192.168.100.45:5060 SIP/2.0
    Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”
    Call-ID: BW101347756240417-577832090@216.27.193.70
    CSeq: 276446199 INVITE
    Contact:
    Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
    Call-Info: ;appearance-index=1
    Recv-Info: x-broadworks-client-session-info
    Accept: application/media_control+xml,application/sdp,multipart/mixed
    Supported:
    Max-Forwards: 39
    Content-Type: application/sdp
    Content-Disposition: session;handling=required
    Content-Length: 291

    v=0
    o=BroadWorks 846750027 1 IN IP4 216.27.201.249
    s=-
    c=IN IP4 216.27.201.249
    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
    a=sendrecv
    a=maxptime:20

    007997: *Apr 24 17:32:48.446: //2881/DE89A7F89DAB/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”
    Date: Mon, 24 Apr 2017 17:32:48 GMT
    Call-ID: BW101347756240417-577832090@216.27.193.70
    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:
    Sent:
    SIP/2.0 403 Forbidden
    Via: SIP/2.0/UDP 216.27.201.249:5060;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: BW101347756240417-577832090@216.27.193.70
    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:
    Received:

    SIPTEST#ACK sip:856782xxxx@192.168.100.45:5060 SIP/2.0
    Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
    CSeq: 276446199 ACK
    From: “Unavailable”;tag=355001702-1493054027756-
    To: “856782xxxx 856782xxxx”;tag=161C128-1E8
    Call-ID: BW101347756240417-577832090@216.27.193.70
    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 http://ucpros.net/configure-cisco-cube/ 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:
    Sent:
    SIP/2.0 487 Request Cancelled
    Via: SIP/2.0/UDP 216.27.201.249:5060;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: BW1232319142404171403269964@216.27.193.70
    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 🙂

  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..

Leave a Reply

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