11-04-2010 08:51 AM - edited 03-16-2019 01:44 AM
Hi,
A customer of us used CUCM 6. We've upgraded them to 8.0.
For a phone that does a call forward on busy to a huntgroup users used to see the originally called number and could answer the phone accordingly.
Ex. 4 phones in a department that call forward on busy to another department (huntgroup). Phones in the other department were able to see the number of the originally called party.
Now with CUCM 8 users that receive calls via the huntgroup now only see the name/number of the huntpilot, not the name/number of the originally called party.
Is this normal behavior?
Is there a service parameter or something to revert to the CUCM 6 behavior?
CUCM6:
External party calls 1234, 1234 does a call forward busy/noanswer to huntgroup X. Users in hunt(group/list) X see a call for 1234.
CUCM8
External party calls 1234, 1234 does a call forward busy/noanswer to huntgroup X. Users in hunt(group/list) X see a call for X.
Regards,
Erik Tamminga
11-04-2010 10:09 AM
Hi Erik,
Not sure what may have changed, but two things to look at;
Service Parameter.
CCM > Retain Forward Information
Or on the Hunt member phones.....excerpt from Cisco Press
Configurable Display of Forwarded Call Information
You can specify, on a per-line basis, the types of information that users see when calls are forwarded to their stations. Each line on a station can display different forwarded call information based on the settings configured in the Forwarded Call Information Display area on the Directory Number Configuration page in CallManager Administration (Device > Phone > find and select a phone > click a line number).
To better understand the display capabilities that can be configured for each line on a station, the following explanations help to clarify some common terms.
###Each line on your station that can be used for calls has an associated directory number. If you originate a call, the line that you use to place the call, for display purposes, is referred to as the calling line ID (CLID) or simply calling party number. There is also a display name associated with that line on your station, and it is referred to as the calling name ID (CNID) or simply the calling party name.
When you make a call by dialing the directory number of the person you want to reach, the number that you dial is referred to as the original dialed number (ODN). Because calls might be forwarded one or more times, the original dialed number might not be the actual number of the line that is answered when the call is completed. The final directory number used to extend the call when the call is actually completed is referred to as the redirected dialed number (RDN).
The following check boxes are provided on the Directory Number Configuration page in CallManager Administration. All can be enabled or disabled by selecting/deselecting the check box. These check boxes control the display of information for calls that have been forwarded to the phone. By default, for forwarded calls that arrive at your phone, you will see the original dialed number and the calling party name.
*Caller name (also known as calling name ID [CNID])— Enabled by default
*Caller number (also known as calling line ID [CLID])— Disabled by default
*Redirected number (also known as redirected dialed number [RDN])— Disabled by default
*Dialed number (also known as original dialed number [ODN])— Enabled by default
Consider the following example: A call arrives at John's station on the line associated with directory number 4444. Delon Whetten originated the call on line 1111, and called Anne Smith at 2222. Anne had forwarded 2222 to Chris Pearce at 3333. Chris had forwarded 3333 to you at 4444. In this example, the calling party name is Delon, and the calling party number is 1111. The original dialed number is 2222. The redirected dialed number is 3333. When the phone arrives at John's station, the information that displays depends on the display options that you configured for John's station. Table 3-1 shows the information that displays for each of the display option combinations you can configure.
Cheers!
Rob
12-20-2010 07:18 AM
Thanks a lot for that post, Rob! I now have the correct forwarding display options set for the situation you quoted from Cisco Press. However, when I call my huntgroup (250) that contains two numbers (201 and 202) with one of my phones (in this example 202), I just see that 202 is calling me in phone 201. So I don't see something like "Call from 202, originating from Hunt 1 (250)".
01-27-2011 06:38 AM
Hi,
I have the same behaviour than Erik.
Upgraded from 6.x to 8.0(3a).
After the upgrade, the display on the phones changed when receiving a forwarded call to a Hunt Group.
Instead of receiving Original called number on the phone, I'm receiving Hunt Pilot Number.
I've read Rob post, but I'm unable to make it work (or there's something I didn't understand).
On the phone which is receiving the call, I have the correct box checked for Forwarded Call Information Display (Caller Name and Dialed Number).
But it's still the same issue.
Any idea ?
Thanks
Fabian
01-27-2011 12:26 PM
Hi,
We have opened a TAC case for this and for now they told us that this is a change in behavior in phone firmware versions 9.0 and later. It seems works as designed .
Cisco has submitted a feature request to have a new service parameter to have us decide on what the phone should display.
If you do need the old behavior, according to TAC, you should revert to phone loads < 9.0 (8.4 for example). Ofcourse this is a workaround, but not the one we liked.
That's the way it is.
Let's hope Cisco doesn't make any other undocumented changes in behavior in the future without a way to select the desired behavior. (Wishfull thinking ??).
Regards,
Erik Tamminga
03-03-2011 11:14 AM
Hi Erik,
I agree with Rob, thanks a lot for posting back the answer to this question.
That helped me a lot and saved me a time consuming TAC case (I have the exact same situation/problem).
@Cisco CUCM Development: Are you guys serious...? I mean, come on!
Is there any news regarding the Feature Request (ETA of a switch to revert back to pre-CUCM8-behavior)?
lukas
01-27-2011 12:35 PM
Hey Erik,
What a "Gong Show"
Thanks so much for posting back with your results here (+5)
Cheers!
Rob
01-28-2011 12:12 AM
Hi Erik,
Thanks for your feedback, I notice this is not only related to firmware version but also CUCM version.
Combination of CUCM8 and Firmware 9.x will have this behaviour.
But firmware 9.x with CUCM7.1(5) for instance works like before.
I agree with you regarding this modification which was not documented, this is really annoying.
I don't understand Cisco on that "feature", I'm little bit confused regarding the interest of displaying last redirected number instead of Original called number...Hope they'll fix that quickly or make it possible to choose between the 2 options.
Thanks again
Regards
Fabian
02-06-2012 02:56 AM
Hi Erik,
Do you know if Cisco have assigned a bug ID to this particular problem? We have the same issue with one of our customers and they would like some evidence to back up our problem description.
Thanks
Oli
02-06-2012 05:41 AM
HI Oli,
Here we go
Description
Symptom:
As of phone load 9.x and higher, calls to a hunt pilot show the following format for the calling party on the ringing phone.
From 'Calling Party Name' for 'hunt pilot DN'
i.e. From John Doe for XXXX
The previous format was
From 'Calling Party Name' ('Calling Party Number')
i.e. From John Doe (XXX-XXX-XXXX)
Need a configurable parameter to change the format to the previous format if the customer desires.
Conditions:
Occurs on phone loads 9.0(x) and above.
Workaround:
Downgrade to 8.4.x
Details
More
Less
Status:
Terminated
Last Modified:
Dec 21,2011
More
Less
More
Less
Product:
Cisco Unified IP Phone 7900 Series
Platform:
Dependent
Severity:
6 - enhancement
Cheers!
Rob
08-08-2012 02:51 AM
Hi all, I notice also this problem. I see the that is shift to 6 enhamcement. Have someone news? We need that feature also.
Regards
Armin
08-08-2012 06:06 AM
Hi Armin,
It's actually been moved to 2- Severe and looks like it is being worked on;
Details
Status:
Fixed
Last Modified:
Jul 30,2012
8.6(2.21023.1),1.9(9.98000.16)
Product:
Cisco Unified Communications Manager (CallManager)
Platform:
Dependent
Severity:
2 - severe
I have opened a thread here
https://supportforums.cisco.com/thread/2164392?tstart=0
So watch to see the results and find out the fix for this
Cheers!
Rob
"Always movin' ahead and never lookin' back" - Springsteen
08-08-2012 11:03 AM
Here is the answer - from one of the very best, Wes Sisk @ Cisco
"The ultimate resolution was committed on the server side. I updated the bug Release-note to include more information about the fix. You will see that in Bug Toolkit and Bug Search Tool in 24-48 hours. Looks like it was necessary to change the information CUCM was sending out in order for the phones to leverage that information. Here is what I added to the bug: New Service Parameter : "Display Hunt Pilot Name or DN for Hunt Group Calls When Alerting" Default Value : True ? Default behavior will be new behavior from 8.x . For customers who want the previous behavior of 7.x will have to set this parameter to false after upgrade. Call Processing Fix from SCCP and SIP Side : - For Hunt Pilot calls, CUCM will not send Hunt Pilot URI to in outgoing INVITE when this service parameter is false but internally CUCM still treats this call as Hunt pilot call so that we do not break other features. - For Hunt Pilot calls, CUCM will send the HP URI to phone when this SP is true. For the versions above: 9.0(0.98000.74) - this is an internal nightly build (.98xxx.). this *may* get it included in 9.0(1) 9.0(0.98000.21) - this is an internal nightly build (.98xxx.). this *may* get it included in 9.0(1) 8.6(4.98000.21) - this is an internal nightly build (.98xxx.). this *may* get it included in 8.6(5) 8.6(2.21023.1) - this gets it fixed in 8.6(2) engineering special branch commonly referred to as es23. TAC can provide this to you. This *may* get it included in the next 8.6.2su that gets posted to Cisco.com. 1.9(9.98000.16) - this appears to be a typo. Regards, Wes"
Cheers!
Rob
"Always movin' ahead and never lookin' back" - Springsteen
11-07-2012 01:11 AM
Sweet! So an upgrade to the latest 8.6.2a will resolve this? Bug shows as fixed in 8.6(2.22900.9), so I guess we'll get the service parameter in that version.
01-23-2013 03:40 AM
Our Problem was solved here:
We found a parameter in
"Display Hunt Pilot Name or DN for Hunt Group Calls when Alerting" --> Setting this to "false" will show the originally called number in a call forward scenario.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide