cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

AMA-CUCM Troubleshooting: Best Practices for Reading Trace Files

696
Views
30
Helpful
12
Replies
Highlighted
Beginner

Help with Dialing Rules

We are running CUCM System version: 8.6.2.20000-2 and the voice gateway is a cisco 2901. The problem we are having is random phone numbers just do not want to dial out. our prefix to dial out is 8. I never setup the dialing rules but the year and a half we have had this system certain numbers will just not dial out. Or we get a disconnected sound yet if we dial from our cell phone it works fine.

Where can I look either on the voice gateway or in CUCM to fix these problems. I cant tell where in the phone number its causing the disconnected. If its the area code or what. We have people making phone calls from personal cell phones in order to complete calls due to the dialing problems.

1 ACCEPTED SOLUTION

Accepted Solutions
Advisor

Help with Dialing Rules

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)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

12 REPLIES 12
Advisor

Help with Dialing Rules

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)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Hall of Fame Community Legend

Help with Dialing Rules

Hey Bill,

Wonderful answer here buddy! +5 for sure

Hope 2013 finds you happy & well! How's the studies going?

Cheers!

Huff

"Far away from your trouble and worry
You belong somewhere you feel free" - Tom Petty

Advisor

Help with Dialing Rules

Hey Rob,

Happy New Year to you and yours! The studies are going slow and steady. Took the holidays off and now trying to get back into the groove.

Thanks for the endorsement!

-Bill (http://ucguerrilla.com)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Beginner

Re: Help with Dialing Rules

I apologize.. we are using a PRI and h323. With the debug how do I turn it off after I place the test call? I may have a follow-up question on how to fix it once I test it. Also once i enter debug isdn q931 on the command line it will output the debug right away or do i have to enter more commands to view the debug log?

As a follow-up I tried the DNA call analysis and used the phone. I entered it as 8 to dial out then 1 because its long distance and the 10 digit number after that and it seemed to show no errors. I tried it without the 8 and same thing no errors.

The I tried the DNA analysis with the gateway and whethere I put the 8 and 1 or no 8 and 1 regardless of how I entered the number the match result was = BlockThisPattern. I am guessing the problem is with the gateway?

Its a long distance call with the area code of 201. I dont see why we would be blocking that anywhere. which makes me think the vendor who setup the system accidently messed some calling codes up.

Advisor

Help with Dialing Rules

Todd,

Debugs can be written to a local log buffer if configured to do so. You can also dump the debug output to the screen. If you ssh or telnet to the device then you can execute the following commands:

Router#term mon

Router#debug isdn q931

Place your test call and the debug will be dumped to your terminal output. The debug for isdn q931 is pretty tame. Meaning it won't flood your screen with a bunch of output. Further, the output is pretty easy to read/follow.

Once you are done, you turn off debugging as follows:

Router#undebug all

HTH.

-Bill (http://ucguerrilla.com)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Beginner

Re: Help with Dialing Rules

Looks like it hit the gateway. Here is the output. I removed the numbers for privacy they seemed to be presented correct. I also edited my previous message but you had replied before I hit save.

debug isdn q931 is              ON.

R2901#

Jan  4 08:12:17: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0                                                                                    0x0 may be overriden; sw-type 13

Jan  4 08:12:17: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0                                                                                    0x0, Calling num 9499005505

Jan  4 08:12:17: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x16E1 callID =                                                                                    0x9566 switch = primary-ni interface = User

Jan  4 08:12:17: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x16E1

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98396

                Exclusive, Channel 22

        Facility i = 0x9F8B0100A11302012D020100800B546F6464204D6F7267616E

                Protocol Profile =  Networking Extensions

                0xA11302012D020100800B546F6464204D6F7267616E

                Component = Invoke component

                        Invoke Id = 45

                        Operation = CallingName

                                Name Presentation Allowed Extended

                                Name = Todd M

        Calling Party Number i = 0x0081, 'removed for privacy'

                Plan:Unknown, Type:Unknown

        Called Party Number i = 0x80, 'removed for privacy'

                Plan:Unknown, Type:Unknown

Jan  4 08:12:18: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x96E1

        Channel ID i = 0xA98396

                Exclusive, Channel 22

Jan  4 08:12:19: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8  callref = 0x96E1

        Progress Ind i = 0x8288 - In-band info or appropriate now available

Jan  4 08:12:19: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x96E1                                                                                  

        Cause i = 0x84AF - Resource unavailable, unspecified

Jan  4 08:12:19: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x16E1

Jan  4 08:12:19: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x96   

Advisor

Re: Help with Dialing Rules

The disconnect Cause 0x84AF indicates that the issue is reported by your CO switch (that is what the 84 means) and the cause code is 47 (translated from AF). This cause code is (unfortunately) a generic code for an unspecified reason. It basically means that the channel you are attempting to use is not available for some reason.

The front end of your trace has some messages I have to dig into further (the stuff about pak_private_number: Invalid type/plan) is interesting. Looks like it is for your calling number (the 949 NPA number).

I would check the following:

1. Can you confirm scope of problem. For instance, is it every long distance call? Local calls only? Other? For instance, let's say you are in MD and you dial 10d for local to 410 and it works great but dialing 10d local to 240 (an overlay in MD) fails every time. Well, that gives a clue that you can use with your carrier.

2. Check with your carrier and see if they expect the CALLING party to be sent with a specific:

- digit length (7 or 10)

- Plan ISDN

- Type (Subscriber, National, or International)

You can also check a "known good call" and look at the Calling Party Number section of the ISDN q931 output to see if there is a difference between the "bad call" and "good call". If there is a diffference, fix it as you should be sending the same. (Note: I am assuming we are dealing with the same PRI and/or carrier with good and bad calls).

3. Check with your carrier and see if they expect the CALLED party to be sent with a specific:

- digit length

- Plan ISDN

- Type (Subscriber, National, or International)

4. Check with your carrier to determine if you have a full PRI or fractional. IOW, do you have 23 channels or some fraction of that. Your call went out channel 22 so I am guessing you have a full PRI but worth a check.

5. Check with your carrier to see if they expect you to send calls "top down" or "bottom up" (aka ascending and descending, respectively).

6. Make sure your switch type (provisioned on the gateway) matches/is compatible with what the carrier expects.

Some of the above may be moot but I don't have any information on the scope of your issue (i.e. what is affected, what is common about the failed calls, what is diff between "good" and "bad" calls, etc.).

HTH

-Bill (http://ucguerrilla.com)

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Beginner

Re: Help with Dialing Rules

Thanks for the quick replies Bill. I am going to contact my carrier with these question. As far as the calls failing.. it appears to be only certain long distance numbers. Although if I recall certain local calling numbers at one point would not work either unless they were prefixed with the local area code. not sure if the first 3 digits of the phone number caused it to fail or what. That issue may have been resolved as I have not heard any complaints of it.

Beginner

Re: Help with Dialing Rules

I stand corrected on the DNA test. I redid it and added the 8+1 before the LD area code and it does show to route the pattern. So I would assume from what you saw on my first output vs the DNA is that its either carrier side or something on the voice gateway?

Advisor

Re: Help with Dialing Rules

If the DNA results match your expectations in regards to providing a valid call path then you should be good there. Based on the ISDN disconnect message it still appears like your carrier's CO switch does not like something about what you are sending to them.

-Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Beginner

Re: Help with Dialing Rules

How do I clear a dial-peer voice xx voip

off the gateway? there is some stale settings in here from day 1 on a voip fax solution we never used. its shutdown but i would prefer to just clear its settings to default.

Advisor

Re: Help with Dialing Rules

Use no dial-peer voice xx from global config mode

-Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards