You can approach this from a couple of different angles. You could start at the voice gateway. You don't indicate whether you are using FXO, PRI, or an IP trunking protocol to your carrier. I'll take a guess. If you are using PRI then I would start with this debug command:
debug isdn q931
Then place a test call. If you see nothing at your gateway then your issue is likely in how the dial plan is provisioned on CUCM. If you see debug output then the issue may still be at your CUCM but you are at least getting to the gateway. From here the next steps depend on whether you are using MGCP or H323 with your gateway. If H323 then you can fix digit presentation on the gateway (look at your egress POTS dial peers) or you can fix it on CUCM. Which way you go depends on the nature of the issue.
If you are using SIP to your carrier then you will likely want to use:
debug ccsip messages
Again, if you don't see anything then your issue is on CUCM. If you do see something then look at the INVITE message and see if you are presenting the correct digits, etc.
Note: on the gateway you have to be aware that other calls not related to your test call would show up in your debug output. Just keep that in mind.
There are other debugs on the voice gateway that you could use. Depending on what protocols you are using. More specific guidance can be provided once that information is known. I start at the gateway because is a real quick way to see if (a) you are getting anything from the UCM to the gateway and (b) if what you are sending to the PSTN is garbage.
From the CUCM side of things, you can walk through the config pages as they relate to the call routing process. Which means you can go through the process of checking partition, css, route pattern, route list, route group, and gateway configurations. Paying particular attention to transformations along the way. Keeping in mind that transforms on the GW override the route list/route group, which override the route pattern. If you are using route filters (your PSTN pattern is 8.@) then you have a fun day ahead of you. Just kidding, check the route filter rules if this fits your environment.
I like to use DNA on the CUCM to get a quick view of things (https:///dna). You will need to have the DNA service running on the pub to use this feature. (www.cisco.com/en/US/docs/voice_ip.../dna/8_6_1/dnaguide.pdf) for more info.
In DNA I like to do a phone analysis. Pick a phone that you would place a call from. Select the line and put in the number as you would dial it. A nifty call hierarchy is spawned that should offer clues as to what is happening.
From a general TS perspective you need to ask yourself questions like are all of the numbers that fail local? Long distance? Toll free? Does the call fail for all callers or just some? Basically, apply basic logic to localize the issue.
It is always possible that after you verify everything is configured correctly on CUCM and your gateway that the problem is still present. Meaning, the issue could be in your carrier network. Maybe your carrier requires you to send plan and type with your call set up and you aren't, consistently. I had a customer with a SIP trunk that had issues calling certain toll-free numbers (I believe it was a conference provider or something along those lines). This issue had to be resolved by the SIP provider because they were messing something up in their translations.
The above is mostly generic since I don't have enough information on your specific issue. Hope it gets you going in the right direction.
-Bill (http://ucguerrilla.com)
