It’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
Contents
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 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 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:
- voice class uri URI-class-identifier with incoming uri {via} URI-class-identifier
- voice class uri URI-class-identifier with incoming uri {request} URI-class-identifier
- voice class uri URI-class-identifier with incoming uri {to} URI-class-identifier
- voice class uri URI-class-identifier with incoming uri {from} URI-class-identifier
- incoming called-number DNIS-string
- answer-address ANI-string
SIP: outbound dial-peer matching preference:
- destination route-string
- destination URI-class-identifier with target carrier-id string
- destination-pattern with target carrier-id string
- destination URI-class-identifier
- destination-pattern
- 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@localhost>;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="https://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: 0In 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 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.
Build pro IOS configs. FAST.
