cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1785
Views
13
Helpful
8
Replies

Outbound DNIS and Outbound CLI - ISDN

Carl Ratcliffe
Level 3
Level 3

Hi Support Community

 

I have 2 queries 1 regarding Called number display on Cisco IP phones on calls destined for the ISDN. The 2nd relates to Calling number CLI for outbound PSTN calls. At this stage im not sure if it is a bug/fault, an issue with the telco, CUCM configuration or Gateway configuration.

 

 

Query 1 - Called Number Display

Globalisation is used for outbound calls. When a call is placed to an MGCP gateway a translation pattern manipulates the called number to E164 so 901234112233 is translated to +441234112233. This number is then displayed on the IP phone display whilst connecting and connected ( although number is localised at the gateway ) and this is what we want. However when the same is done with a H323 gateway when the number is dialled so 901234112233 the display immediatley changes to +441234112233 but as soon as ringback starts the display has the localised number as it would be sent out of the gateway so 01234112233.

 

Query 2 - Calling Number CLI

 

Globalisation is used for outbound calls in the UK. All calls are succesful and calling and called numbers are manipulated as expected except for 1 particular scenario. Most phones have a full UK 11 digit mask so for example 0123411XXXX. When a call is made a translation pattern is used to manipulate the calling number with settings 'use calling number external mask' , the mask is set to 10 wildcard digits XXXXXXXXXX and a prefix +44. So the calling number becomes +441234112233. This is correct and a 'calling party transformation mask' is used on the CUCM gateway config to match \+44.!. and localise the number back to 01234112233. The MGCP gateway is then set to restrict CLI on the port and the number is sent as unknown. All works exactly as we want it to work.

 

Now the issue is when an IP phone has a mask less than the 10 wildcard digits in the translation pattern  ( public phones, non DDI phones etc us 5 digits with no mask so the mask will be the 5 digit extension ).  We have a catch on 'calling party transformation mask' configured as \+! and this should translate all unknown calling numbers so the public phones etc to our main number 012345888888, the CLI is then restricted on the MGCP voice port. However what happens is the outbound call is sent with a CLI of our main billing number and what we see on the gateway is no calling number in the ISDN q931 messages ( see attched ). So it seems if an IP phone has a mask less then the 10 digits is causes weird results.

 

Any help is appreciated.

 

Thanks, Carl Ratcliffe

 

1 Accepted Solution

Accepted Solutions

Carl,

Query 1..

With H323 gateway, the h225 signalling is going to send some info back to the CUCM telling the CUCM about any digit manipulation it is doing. Hence the reason why you see the localised number on the gateway showing on the IP phone. To prevent this from happening use the ff command:

no supplementary-service h225-notify cid-update.

 

Query two:

 

Can you send the CUCM traces for a call from a non ddi phone? You are correct, there is no calling number sent to the gateway

 

 

Please rate all useful posts

View solution in original post

8 Replies 8

Anthony Holloway
Cisco Employee
Cisco Employee

1. This is expected behavior and I have the same result when using SIP to my CUBE instead of H323 to a Voicegateway.  I can transform the called party number with an Xform on the trunk, or on the outgoing leg Dial Peer, either way, and the IP Phone still updates with the localized number.  Maybe someone knows of a way to turn this off, but as far as I know, that's the way it works.

 

2.  This sounds expected as well.  If you have a mask of 5 digits and a transform of 10 X's, then in my experience, ?'s are used to fill in the middle digits.  Why don't you just mask the 5 digit phones with the main number right on the line?  Alternatively, and there's a few different ways to solve this, but if you move your Calling Party transformation away from Explicit in the translationlation pattern where there's little intelligence, and move it to the Explicit on the H323 gateway, where you have more control over the matching, you could get away with blindly masking with 10 X's as a one size fits all solution.

 

As a general rule, you shouldn't mix explicit and implicit transformations in a call flow.  It causes confusion and sometimes undesireable results.  Source: BRKUCC-3000 Advanced Dial Plan Design

Hi Anthony

 

Thanks for your response. In regards to query 1 i have done exactly the same, i have tried digit manipulation in various places but always the same but not had any joy. We wanted to standardise across the globe but as we have a mixture of mgcp , sip and H323 gateways we are getting the different results in the display for CLI.

For query 2, its all relating to the UK, other countries like the US i dont have this issue. We have followed Cisco's guidlines of Globalising at the ingress so translation pattern then localising at egress in this case transformation patterns on the gateway. The problem is because in the UK we need to drop the 0 to Globalise there isnt a drop digits option on a translation pattern i can only use masks and prefix so we went with the 10 wildcards as this seemed to work perfectly. We were aware of the internal phones without a full DDI mask but we thought that as CLI was set to restrict we would be ok but it seems when the mask isnt 10 digits for whatever reason the restrict CLI is ignored so not sure if thats some sort of bug ?

 

Thanks, Carl Ratcliffe

Carl,

Query 1..

With H323 gateway, the h225 signalling is going to send some info back to the CUCM telling the CUCM about any digit manipulation it is doing. Hence the reason why you see the localised number on the gateway showing on the IP phone. To prevent this from happening use the ff command:

no supplementary-service h225-notify cid-update.

 

Query two:

 

Can you send the CUCM traces for a call from a non ddi phone? You are correct, there is no calling number sent to the gateway

 

 

Please rate all useful posts

Hi Ayodeji

 

Query 1 - applied fix as you advised and this now works perfectly. Thanks for your help on this.

 

Query 2 - i will run some traces / debugs shortly and upload these for you to have a look at.

 

Thanks, Carl Ratcliffe

Carl,

 

The traces confirmed that because the mask is not up to 10 digits, cucm replaces th emissing digits with ?? so what we see from the transformed number is:

CallingPartyNumber=+44??30111599

Now this is not a valid number , hence the reason why its not matching the calling party xformation..

Anthony's suggestion is a valid one. Use your main number DDI for all non-DDI phones. This is what we do normally especially since we are using sip trunks.

 

Please rate all useful posts

Thanks Ayodeji

 

I may have to look at that option, i just figured becasue we apply the restrict CLI to the MGCP port and not pattern that has to be matched to restrict the CLI then this should block all calling numbers regardless of the number type, length etc.

 

Thanks, Carl Ratcliffe

Hi Ayodeji

Please see attached traces i have used notepad ++ and highlighted the relevant parts.

 

Anthony is correct, if the mask of the calling phone is less digits than the mask in the translation pattern it replaces with question marks

 

So i called from 30111599 which is an 8 digit internal logged out extension. The mask XXXXXXXXXX then actucally becomes ??30111599 with a prefix of +44.

 

We could add masks to all logged out phones to represent the main numbers however we didnt want to do this as all CLI are restricted anyway. It seems if the mask gets replaced and has to use ?? it then ignores the restirct CLI setting.

 

Thanks, Carl Ratcliffe

Carl Ratcliffe
Level 3
Level 3

Hi Support Community

I original raised this 8 months ago in regards to query 2, i basically wanted to use globalization but on the IP phone display i wanted it to display the translated globalized number with the + format however when the call it hit the H323 gateway the IP phone display changed to the number that was sent out of this gateway. The fix was to use no supplementary-service h225-notify cid-update on the gateway and this worked perfectly.

I now however have a requirement for the same but slightly different scenario in that im using TEHO so the call traverses a non gatekeeper controlled inter-cluster trunk.

  • When you make the call from the IP phone in the localised format it hits a translation pattern to globalize and the phone initially displays the + format which is what we want
  • However when you then get ringback the IP phone display changes to the non globalised format which is what we dont want
  • So exactly the same as previous except the no supplementary-service h225-notify cid-update seems to have no affect when the call traverses the intercluster trunk.

 

Now what i know is that the H323 intercluster trunk cannot handle the + symbol so at the other side of the trunk we have to globalise again via a translation pattern to include + so dont know if this has anything to do with it.

 

Any help would be appreciated.

Thanks, Carl Ratcliffe

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: