About the same time I started working on CUCM setups I noticed a problem with dial-plans on gateways not going where I wanted them to as easily as I wanted them to. The first was a hospital receiving 4 digits on a PRI. Every time someone called the cafeteria they got transferred to the 911 PSAP. Ended up the DID ended in 9911 which matched A pattern. The next time I ran into it the customer got 10 digits on a PRI and calls immediately started looping through the PSTN until the PRI bounced. I never understood the rational of needing to define each specific DID or block on a router when the router only serviced 1 purpose – to send the call to CUCM to handle. And yes I know MGCP is great for this type stuff, but MGCP just wasn’t as reliable for remote locations as H.323 was and coming from a bunch of CME deployments I liked dial-peers even if they are a little funny at times.

What I came up with was creating translations that provided steering digits for the inbound leg. Anything coming from the PRI, I prepended with A# and then anything with the destination of A#.T i sent it to CUCM. Problem solved. All the rest of the patterns on the gateway were PSTN facing. No loops, no 9911 calls and no going to the gateway to add DID ranges and dial-peers when a number was ported.

voice translation-rule 500
  rule 1 /[^A]/ /A#\0/
!
dial-peer voice 500 voip
  destination-pattern A#.T

When I first started I would add the translation onto trunk groups so anything inbound would get tagged before the dialplan processors kicked in. That way I could easily identify the inbound dial-peer used as well. As SIP started to grow I started using voice class source group and an ACL. This kicks in prior to any dialplan processing so I could make inbound dial-peers on the same A#.T pattern as well.

access-list 30 permit ip 4.4.4.4
!
voice class source group 300
  access-list 30
  translation-profile incoming DNIS-STEERING

Then can voice class uri which let me match the inbound call based on the originating IP and brought the somewhat obscure source group and translation into a dial-peer that everyone would easily recognize.

voice class uri 300 sip
  host ipv4:1.1.1.1
!
dial-peer voice 300 voip
 description *** from ITSP ***
 translation-profile incoming DNIS-STEERING
 incoming uri via 300

So given all this I was really excited to see the newer Dial Peer Groups come around. I’m not that crazy about the syntax and I find it a little hard to easily follow a call, but I’ve got some tricks still.

With dial peer groups you can specify the outbound dial-peer used based on the inbound dial-peer selected. So I still match the inbound dial-peer based on the uri, but now instead to prepending digits etc. I can get tell it to send it out dial-peer 500 which goes to my CM. Done.

voice class dpg 500
 description *** CUCM destination dial-peers
 dial-peer 500 preference 1
!
voice class e164-pattern-map 500
 description *** All Patterns to CUCM from Dial-peer 300
!
dial-peer voice 300 voip
 description *** from ITSP ***
 incoming uri via 300
!
dial-peer voice 500 voip
 description *** to CUCM ***
 session server-group 500
 destination e164-pattern-map 500

That’s all there is to it. When a call comes in and the sending URI matches all the ITSP peer IPs I’ve defined it just gets sent out dial-peer 500 to CUCM. It ignores any digit processing all together.

Now the weird things about it. It still requires a destination on the dial-peer even thought it doesn’t use it. The first time I came across a running config I had to do some googling to figure out what it was doing and why there was basically 2 ways to get to the same dial-peer. I’ve got a little bit of a work around going though. As you can see a destination e164-pattern-map is supported as a destination, and even if the pattern map is empty, it still works for what it’s needed for. I can also add a description there. So now when I’m looking at the dial-peers I can look up the target pattern map and get a hint at how it’s being used.

Based on the router IOS and PSTN connection I’m dealing with makes a difference in what I configure, but this pass-through method means no touching a router unless you’re debugging. Its not a one size fits all, but for companies where the gateway is just there to get you to and from CUCM it’s a great method to simplify things and be able to enjoy porting whatever number you want whenever it ports.