CUBE Configuration

CUBE Configuration


This is a recent CUBE configuration that I used employing some of the new configurations available in IOS 15.4  I was very excited about this as it was so easy to configure.  I really love what Cisco has been coming out with such as the e164-pattern-map, the voice class uri and the voice class dpg.  It allows you to configure call routing based on the uri rather than wholly on the dialed number, which also helps prevent loops.  I'll explain the configuration as we go through it.



These first configurations are pretty standard.
ip domain name domain.com
ip name-server x.x.x.x
!
voice service voip
 mode border-element
 ip address trusted list
 address-hiding
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 no supplementary-service h225-notify cid-update
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
 sip
  early-offer forced
  midcall-signaling passthru
!

Here is where we start to get into the fun.  We first put in the voice class uri for the callmanagers and the sip provider.  In previous configurations we would have to configure a separate dial peer for each CUCM and each ip address of the sip provider.  No longer!  We can add all of the ip addresses that we need for all of the CUCM's and be able to use it in one single dial-peer!  I love it! Notice that you can also use a dns name.
voice class uri CallManagers sip
 host ipv4:x.x.x.x
 host ipv4:x.x.x.x
!
voice class uri SipProvider sip
 host ipv4:x.x.x.x
 host dns:x.x.com
 !

Normal voice class codec config
voice class codec 1
 codec preference 1 g711ulaw
 !

More fun stuff.  The voice class e164-pattern-map.  In previous configurations we had to put in a separate dial-peer for each dialed number range that we had to match.  This is no longer the case as we can now put in as many number ranges as we need and, again, be able to put them into a single dial-peer. How easy is that! we will configure two pattern maps, one going toward the CUCM and another going toward the sip carrier.
voice class e164-pattern-map 1
 description  To CUCM 
 e164 +8018197…
 e164 4XXX
 e164 5XXX
!
voice class e164-pattern-map 2
 description  To SIP Carrier 
 e164 .T
!

Sip options keep alive to disable the dial-peer if we lose communication on the SIP trunk. We will do one for CUCM and one for the SIP carrier.
voice class sip-options-keepalive 1
 description  To CUCM 
 down-interval 40
 up-interval 20
 retry 6  
!         
voice class sip-options-keepalive 2
 description To SIP Carrier
 down-interval 40
 up-interval 20
 retry 6  
 !

Here is where the real fun begins!  Dial-Peer Groups!  This is what Cisco says about it in the Dial Peer Configuration Guide for IOS 15M&T

Again we are going to create two dial-peer groups.  One to point to the CUCM and one to point to the SIP Carrier.  The first will include dial-peer 100 and the second dial-peer 200. I'll explain more once we get to the dial-peers about how this is going to work.
voice class dpg 1
dial-peer 100
!
voice class dpg 2
dial-peer 200
!

Now we will configure the server-groups.  This is another great configuration that allows us to specify multiple destinations and give them a preference.  For example in the server-group 1 below you can put in two CUCM servers and indicate the secondary to pref 1.  The second server-group is pointing to the SIP carrier.
voice class server-group 1
ipv4 dns or ip
ipv4 dns or ip pref 1
description To CUCM
!
voice class server-group 2
ipv4 dns or ip
description To SIP Carrier
!

Now we put it all together.  First we give the dial-peer a tag of 100 and a description so we can tell what we are doing.  specify the protocol of sipv2 and use session server-group instead of session target.  Next we put in the dial-peer group with the command destination dpg2.  So what exactly is that doing?  Dpg 2 is defined with dial-peer 200 in it.  as specified above "once an incoming call is matched by an inbound dial peer with an active destination dial-peer group, dial-peers from this group are used to route the incoming call."  Dial-peer 200 contains the command incoming uri via 2.  That is the voice class incoming uri.  So the dial-peer is configured to match the incoming uri from the SIP carrier and the dpg tells it to route the call out dial-peer 100.  Dial-peer 100 has the destination e164-pattern-map and the session server-group for the CUCM.  The reverse is also true.   Dial-peer 100 contains the command incoming uri via 1.  That is the voice class incoming uri.  So the dial-peer is configured to match the incoming uri from the CUCM and the dpg tells it to route the call out dial-peer 200.  Dial-peer 200 has the destination e164-pattern-map and the session server-group for the SIP Carrier.
dial-peer voice 100 voip
description To CUCM 
session protocol sipv2
session server-group 1
destination dpg 2
destination e164-pattern-map 1
incoming uri via 1
voice-class codec 1
voice-class sip options-keepalive profile 1
dtmf-relay rtp-nte sip-kpml
no vad
!
dial-peer voice 200 voip
description To SIP Carrier
session protocol sipv2
session server-group 2
destination dpg 1
destination e164-pattern-map 2
incoming uri via 2
voice-class codec 1
voice-class sip options-keepalive profile 2
voice-class sip bind control source-interface G0/1 (external int)
voice-class sip bind media source-interface G0/1 (external int)
no vad
dtmf-relay rtp-nte sip-kpml
!

And that is it.  This config is so simple and extremely scaleable!  I keep this configuration saved and used it for every CUBE deployment I do.  I change a few lines and I'm good to go.  It is so easy to troubleshoot as well.  Let me know what you think of this config in the comments below.  I'd be glad to hear what you have to say.

Comments

  1. Hello Sir. Can you provide alao an example of registration ip phone in cucm v14 in e164 format and also a dial patern to cube ? Thank uou

    ReplyDelete

Post a Comment

Popular Posts