Showing results for 
Search instead for 
Did you mean: 

Calling Party Tranformations Issue

Recently I've been playing with Calling and Called Party Transformations on route patterns, primarily external route patterns directed at a PRI gateway to verify information being passed to the gateway and accross my ISDN simulator. Last night I came across what I can only see as a bug, this is on my 3.3(3) cluster, I have not yet tried to reproduce on my 3.3(4) cluster.

If I take a known working route pattern that has the default settings for the Calling Party Transformation(no Prefix Digits or transform Mask, just calling party Presentation is Default) and check the Use Calling Party's External Phone Number Mask option, the route pattern becomes unrecognized by CallManager.

As soon as I dial 9 (external access code) I get fast busy. The phone is using a test CSS with just access to the internal IP Phone PT and the PT with this external RP. I can still dial IP to IP.

At first I thought maybe reseting the gateway from the GW configuration page instead of relying on the update to the route pattern would resolve it. No luck. I went back and unchecked the Use C'ing Pty mask option and updated again. Still no access to that RP. This was along with resets of the phone each time as well.

Finally I rebooted my subscriber, where all devices are registered, and as soon as the subscriber was back online, the RP worked. It also never worked while homed to the Pub during the Sub reboot. I can consistently reproduce this issue by checking or unchecking the Use Calling Party External Phone Mask on the RP.

Checked the bug list with no luck.


Weird :)

You may want to have TAC do a "Topic" search on this but first I would check the basics of SQL replication between the Publisher and Subscriber. Go into SQL Enterprise Manager and make sure the subscription is valid. This sounds like it could be some kind of a replication issue or a bug :)

I can positively tell you that I have over 10 installations still on 3.3(3) service packed up and we haven't had any reports on issues like this. (But Cisco bugs can be stealthy)