Translation pattern fails - Cisco Unified CM 6.0.1

[Donald Holman]

Translation pattern 884X is configured to prefix a 1 in front creating 1884X. If the user dials 8842 it rings DN 18842, but when dialing 8840 there is silence for around 240 seconds before returning a fast busy. DN 18840 never rings. The phone device line 1 is 18840 and rings if dialed as 18840. A work around was created using a translation pattern 8840 which prefixs a 1. Both DNs, 18840 and 18842, belong to the same partition and the 8840 translation pattern uses the same calling search space as 884X. X should represent 0-9, so why do I have to create two translation patterns 884X and 8840?

Cisco Unified CM Ver 6.0.1.20003

[miket]

You should be able to use wild cards... Run a route plan report and verify that there is no overlaps.

Also watch your route patterns in case it is trying to call the pstn for some reason

[Donald Holman]

I ran the route plan report and there are no duplicates. I also ran Dialed Number Analyzer side by side with 8842 and they are exactly the same. When 8842 is dialed, it always rings 18842. I found out today the work around only works about 50% of the time. I deleted the DN 18840 along with the route pattern 8840 and rebuilt them. I also tried moving the DN to another device and set Call Forward All to another destination. I tested each of the steps above separately and the phone never rang for any of the tests.

[vince.castro]

Here is some info and hope it helps...

1. in the RoutePlanReport, do a search for contains; 884 this should return all devices/dns that are out their with the same prefix or contains this prefix. If you find it delete them if not associated to anything.

2. the 240sec (4min) sounds like a time out. I would check under Service Parameters for your T301 Timer. Default is 180000ms(3min) and can go as high as 15min. This timer controls how long the device will ring until it terminates the call.

3. Any PBX in the mix? just checking.

4. If DNA says 18841, then it thinks there is a DN out there with a closer match. Might want to check the Traces logs both SDI and SDL.

5. What the translation will do is provide a more closer match for the route pattern. Creating the exact match should (known to NOT do it this way) go directly to the Device that is associated to that DN.

6. keep using the DNA with different Route Patterns configs to get the 8840 pattern, eventually it will show you what is happening in its call flow.

7. Just a note from my experience; When using either route patterns and/or translation patterns the top of the order in each (Partition) if CCMA finds a match it that CSS it will route that call their, even if their is a closer match down further in its CSS partitions list. You could try moving the Partitions in the CSS to the top of the order as a test.

Post the fix if you find one. Hope this helps...

[Donald Holman]

I applied an Engineer Special 6.1.1-2112-2 and it resolved the issue, however it introduced a new problem with a 7940G IP phone. When the phone is in DND and set to Beep only, the hands free speaker turns on when going off hook to answer a call and the headset speaker does not activate for about five seconds. After the five seconds the called party is able to hear the calling party through the handset and the hands free speaker turns off.