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.
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
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"
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...