Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Translation and Transformation query

Hi All,

I have small query regarding applying the translation patterns on the gateway and the number displayed on the phone while ringing.Below is the scenario.

All calls from the telco are to be prefixed with the outside access code when they are forwarded to the CUCM so that the users can redial them from their missed calls or recieved calls and i think this can be done by applying translation pattern on the gateway for incoming calls.

My query is related to the display of the number on the phone while ringing whether it will display by adding the prfixed digit .i.e outside access code or it will display as it is.

Thanks           

1 REPLY
VIP Super Bronze

Re: Translation and Transformation query

Your best option is to use calling party transformations.  Details below

1. You use the incoming calling partty settings on the gateway to  prefix the appropriate digits...ie 9 for local, 91 National, 900  international etc

2. You configure a calling party xformation  pattern that macthes each of these numbers eg. 9.1[2-9]XX[2-9]XXXXXX. ,  9.00! On the pattern you configure it to strip predot..

3. You configure your calling party xformation  CSS to have access to the partition of these patterns...You then check  your phones to eithe use calling party CSS on the phone settings or use  the device pool settings...

Now when the cal comes  into your gateway, if it is a national call a 91 is prefixed as you  have defined it. Now this 91.XXXXXXX pattern is passed through the  calling party xformation pattern an the 91 is stripped before it is  presented to the phones. However on the call logs i.e missed calls, the  91 will be there

SIP Trunks...

1.On the incoming calling party settings...Set the CSS that has access to the xformation pattern

2.define  your xformatiom pattern for all inbound calls eg 07XXXXXXX, set to  prefix 9---at this point the call is globalized..the stored data in  cucmdb will be 907XXXXX

3. Next configure a new xformation pattern with 9.07XxxX in a different patition, set it to srip predot

4.  configure a new calling party xformation css, that has access only to  the new 9.07xxxx xformation..asign this to the phones...here before the  call is presented to the phones, the 9 is stripped...hence the user sees  normal calls.

-----------

Using a prefix on the Incoming calling party settings with the CSS

calling number 0057000, prefix 9 ==== 90057000

cs  xform is applied (pattern configured to prefix 900)....900 is  prefixed...so we have 90090057000...this is what is recorded by cucm in  DB in missed calls

when the phone xformation is applied , 9 is dropped so we have 0090057000..this is what is seen by the phone

NB That for the CSS to be used you have to uncheck the use device pool CSS..

If you want to use device pool CSS, it is set for sip trunks at the unknown number CSS..NB the prefix on that level doesnt work

++++++++++++++++++++++++++++

This method works with only  on the Gen 2 and Gen 3 phones (79X1 and 79X2). That’s because of the way the directory works on those. The call history is stored on the server on the newer phones, whereas on the older (79X0)phones, the call history and directory are stored as a local copy.

So the whole idea is that if a user at a Gen3 hardware IP phone (7941, 7961, 7971 or newer) looks at their call history logs (Directories–>Call History–>Missed Calls or Received Calls), they will see the Globalized format of any number that has come from the PSTN, and not the Localized format, and that user will wish to very simply press the “Dial” softkey without the need to first press the “EditDial” softkey and make any sort of amends to the number for it to be able to work properly.

As a somewhat brief aside, any Gen2 or older hardware IP phone as well as all softphone clients including CUPC, CIPC, IPBlue (even IPBlue registered as a 7961) will display the localized format of these same numbers coming in from the PSTN when viewing these same call history logs. This is due to the nature of how the Globalization –> Localization –> Call History process occurs. The call coming in from the PSTN upon hitting the gateway is always Globalized, and that number is forever rooted in CUCM’s DBs in that Globalized format. However as soon as the CUCM is about to hand the call off from itself to an IP Phone (hardware or software), CUCM Localizes the call, and then hands it to the phone. It is here where the real difference between Gen1/2 and Gen3/4 phones behaves in regards to storing Call History logs. You see, the Gen1/2 phones (and all softphones) do just that – they receive the Localized number, and then they (the phones) store the number in their local running memory. However the Gen3/4 phones do not. Instead they do not ever store any call history. “Well then how do they access their call history logs then? Don’t they have the ability to do so?” you might ask. Yes, of course they do, however they access these logs, not from stored running memory as the Gen1/2 phones do, but rather from a DB on the CUCM servers who stores them on behalf of the Gen3/4 phones. So the Gen3/4 phones place an HTTP call to a URI where they can access these call logs – in real time I might add. In fact it is the ability to access these logs in real time directly from the CUCM server – which is also the primary Presence server in any implementation to which all users/server place Subscribe/Notify requests – that gives the CUCM server the ability to display to the Gen3/4 phone looking at their call history lists – real time Presence/Status for any DN registered to the same Cluster with the appropriate Presence Group / Subscribe CSS settings.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
204
Views
4
Helpful
1
Replies
CreatePlease to create content