Call Forward All transform mask not removing 9 access code

[Iyad Musleh]

We have a  problem where the leading 9 access code is not being discarded when using Call Forward All to external numbers (i.e. cell phone).  Because of this, the cell phone user sees the incoming caller ID beginning with 9 followed by the 10-digit ani. Since our country code is 1, all forwarded calls look like they're coming from India, since 91 is India's country code. I ran a debug at the SIP router and found that we are indeed sending the callerID with the leading 9 still attached.

I've read a few discussions on this general topic, but none seem to have applicable solutions. The closest I've gotten is in Route Pattern Configuration page --> Calling Party Transformations section, the Use Calling Party's External Phone Number Mask is checked. However, Calling Party Transform Mask and Prefix Digits (Outgoing Calls) fields are blank.  Attached is a screen grab of the settings.  Running on CUCM 11.5.1.  Is there something missing here?  Any suggestions on where else to look?

[pkinane]

You said that you checked the debugs on the gateway and you can see that the call does send the calling party with a 91; however, did you check if the gateway received it that way?

You have to see if the gateway received it with the leading 9 on the calling number because this will let you know if you should focus on CUCM or on the gateway.

[Iyad Musleh]

Yes, I checked the CDR records and, in the Destination section, it shows the "directoryNum (callingPartyNumber)" field with the 9 in front.  To me, this would indicate that's what CallManager sent out.

[pkinane]

Also, I started a playlist about reading CallManager traces. This may be helpful in troubleshooting the issue.

https://www.youtube.com/playlist?list=PL0TL-g5HVlo2B9QT6wFgoXtwnCFN8nH-W

[Iyad Musleh]

Thank you for this YouTube series. It'll definitely help with future troubleshooting.

[TONY SMITH]

Easiest way is a translation rule on the gateway to strip the leading 9 off any calling number.  The behaviour is not inherent, by which I mean that the calling number will have been originally presented without the leading 9 from the service provider, then something in your gateway or CUCM adds the 9 prefix for the convenience of your users, so they can call back a missed or received call.

I'm pretty sure the external number mask setting is irrelevant in this case, where the call didn't originate from a phone.

[ashok_boin]

Hi,

Pls try with putting a mask in "Calling party transform mask" matching to your Calling party number on the "Route pattern" & uncheck "Use calling party external number mask" like in this following link. Once you have successful test with the local mask on the route pattern, you may apply the same mask as "External mask for calling party numbers".

https://community.cisco.com/t5/collaboration-voice-and-video/cucm-digit-manipulation-amp-call-flow/ta-p/3113389

• Called party transformations > Discard digits: PreDot
• Calling party transformations: 40855530XX --> this is mapping to your DID number.
  
• Route the call to the gateway

[TONY SMITH · Accepted solution]

As far as I can determine the "Use Calling Party's External Phone Number Mask" setting has no affect on a forwarded call, where the original external calling number will be presented on the outbound leg.   The "Calling Party Transform Mask" setting seems to take effect, so if all your forwarded calls were of a consistent format you could possibly use a mask of XXXXXXXXXXX or whatever number of Xs is needed to omit the leading 9.   This would mess things up if some of your redirected calls weren't from North America as it would just blindly forward the last 10 digits.  Would also mess things up if the Route Pattern was used for directly dialled calls and not dedicated soley to forwarded calls.

I would still recommend stripping at the gateway, a rule there can simply remove a leading 9 leaving anything else untouched.

[Iyad Musleh]

The route pattern is indeed dedicated to just call forwarding, so it wouldn't have any impact on direct dialing.  I did change the Calling Party Transform Mask to XXXXXXXXXXX and that seems to work, leaving behind the 9 and allowing the 1+area code+7 digits.  However, you make a good point about how this would impact potential calling numbers from outside North America, so creating a rule on the gateway is something i'd also like to try as well.  Any chance you'd be able to give a generic example of what that rule would look like?

[TONY SMITH]

Quick example, pulled from an actual install but with irrelevant lines deleted.  Dial peer 9001 is the outgoing to the service provider.  (Actually that rule could just be "rule 15 /^9/ //", but I've just pasted in what's in service in that gateway)  If you have any valid calling numbers starting with 9 that you don't want truncated you could revise this rule, or put earlier rules to match them.  As it stands any leading 9 is dropped.

voice translation-rule 1
 rule 15 /^9\(\)/ /\1/

voice translation-profile Outbound_CLI
 translate calling 1

dial-peer voice 9001 voip
 translation-profile outgoing Outbound

You can test with CLI command ...

GATEWAY# test voice translation-rule 1 915556661234
Matched with rule 15
Original number: 915556661234   Translated number: 15556661234
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none