Off-hook dialing fails to certain route pattern, works when onhook... CUCM

[markmonteleone_2]

When I try to dial a number to certain area within Local Lata while phone is on hook, the call completes properly.

When I try to dial that number while is off hook, there seems to be some route pattern chopping off digits. These are SCCP phones, using CUCM 8.5.1

When I run the analyzer, the proper route pattern is choosen...

Any ideas?

Mark Monte

[Rob Huffman]

Hi Mark,

Could be this bug;

CSCtk75027 - First digit not sent with overlap sending via MGCP GW

Description

Symptom:

First digit is not sent to the pstn via MGCP GW when overlap sending is used

Conditions:

This happens only when the phone sends the first digit to cucm before the setup ack is received from the pstn

Workaround:

Use on hook dialing

Details

1st Found-in:                          (1)

8.0

More

Less

Status:

Fixed

Last Modified:

Dec 06,2011

Known Affected Versions:

More

Less

Fixed-in:                          (7)

8.6(1.10001.1), 8.6(1.10000.43), 8.6(1.10000.1)

8.5(1.98000.73), 8.5(1.98000.31), 8.5(1.12008.2)

8.0(3.22019.1)

More

Less

Product:

Cisco Unified Communications Manager (CallManager)

Platform:

Dependent

Severity:

2 - severe

Customer Reported:                          (12)

Cheers!

Rob

[markmonteleone_2]

I am using H323

[Jonathan Schulenberg]

When on-hook and DNA you're using enblock routing. With off-hook CUCM is doing digit-by-digit analysis. The only way to nail this down definitively is with a dialing forest dump. It will write all possible/choosen pattern matches for each digit as its entered into the SDI log.To be frank you should just call TAC here. Reading the SDI traces from a forest dump is no easy task. Forest dumps are also a fun way to crash a callmanager process if the system has even a moderate load on it.

Normally I would give you the instructions how to run the dump if you're feeling adventerous but I don't even have them written down anymore; sorry.

[acampbell]

Hi,

I agree with Rob & Jonathan.

The issue looks to be something like overlapping route patterns

Look at your route plan report and see if there are route patterns or translations

that start with similar digits.

Regards

Alex

[markmonteleone_2]

More info:

I have 9[2-9]XXXXXX for 7 digit dialing and  9[2-9]XX[2-9]XXXXXX for 10 digit dialing local dialing within the LATA

I also have 91[2-9]XX{2-9]XXXXXX for certain toll areas of LATA and InterLATA calling

I believe the striping to being done at the GW dial-peer

Since the calls within the LATA and dont need a 1, the last one isnt a factor.

I did find the the 7 digit dialing did affect the 10digit dialing. I figured that out by removing the

9[2-9]XXXXXX and presto, the 9+10digit dial worked.

This however isn't a fix as the Enterprise still is expecting to dial 9+7digit for local calls.

Is there a logical fix?

[Chris Deren]

Mark,

10 digit local dialing is not that common, so my solution to these has been to build explicit 10 digit route pattners, for example are acode 407 allows for 10 digit local dilaing, I would create 9407[2-9]XXXXXX, and so forth, you can put these in site specific parition or global parition if you are using these with Local Route Groups.

Yes, depending on your size you may end up with quite a few of these, I am not aware of other solutions, as these 2 patterns fo overlap.

HTH,

Chris

[markmonteleone_2]

Chris, appreicate the reply, you must be a little north of me.

I had done what you share, if you look above, and it didn't work. Yes, I tried with the explict 9941[2-9]XXXXXX

REMEMBER this does work off a redial or via a onhook call. BUT once you life that reciever is seems to default to a 7digit pattern. Is there a timer or default timer when going off-hook?

[Chris Deren · Accepted solution]

Do you have "Urgent Priority" checked on the 7 digit route pattern?  It should not be checked.

Chris

[markmonteleone_2]

dingdingding.... we have a winner

thanks Chris and all who helped me along my way.

This forum is very cool....   IS there an IRC?

[ankit.chauhan7]

Hello Chris,

I also resolved the same issue by un-checking the UP on TP. I have 9.0044! TP that has Pre dot configured.

With Urgent priority checked > When I dial 9004420, when I enter 7th digit, it then says call cannot be completed.

Urgent priority un-checked > It works fine

If possible can you please explain the behavior.

Thanks in advance!