Showing results for 
Search instead for 
Did you mean: 

CUCM sending the DN instead of the desired calling party mask to H 323 gateway


We are running on CUCM 8.6.1 version.

We have the emergency dialing configured where the site has a 999 route pattern which is pointing to a RL -> RG and finally to six H323 gateways (PSTN gateways) which take the call in a round robin fashion.

The requirement is when the user dials the 999 we need to mask the calling party to a specific number(1110001111) and the same is mentioned in the route pattern.

When a call is made to 999, the call hits the gateway, the Station D message shows the calling party as 1110001111. However, the H225 setup or connect message is showing the six digit DN which is initiating the call. And the same (6 digit DN) is recieved by the called party.

We tried to change the service paratmeter "Apply External Phone Number Mask for H.323 Calls  Required Field" to true but still no luck.

We changed the calling party selection on the gateway to "Last redirect number"

But still no luck.. Any ideas on how to get this working?

Cisco Employee

A few things here, StationD is a SCCP process so it wouldn't come into play with a call going to an H323 gateway.  StationD is from CUCM to a SCCP device, StationInit is from a SCCP device to CUCM.  You have a few options, if your h323 gateways are ever being used for SRST it's recommended to do your digit manipulation at the gateway so that the modification is preserved should the phones be in SRST.  A voice translation rule can change the calling party (ANI) number of a call that hits your dial-peer with destination-pattern 999.  If you really want to do your manipulation in CUCM you can do it in a few places, route pattern, route group, gateway, or calling party transformation.  Remember that if you have anything non-default it will take priority over the higher level setting.  For instance if you have a route group level manipulation the route pattern manipulation will be ignored.  Other than looking over your config since you've narrowed down that the SETUP has the wrong ANI, collecting a call manager trace (set to detailed) would be the next easiest way to see why the 6 digit number is being sent.  Here's how to turn on a collect traces if you're not familiar with it: