cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10396
Views
41
Helpful
17
Replies

CUCM 8 change in Hunt name display

etamminga
Spotlight
Spotlight

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

17 Replies 17

Rob Huffman
Hall of Fame
Hall of Fame

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

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)".

f.giordano
Level 1
Level 1

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

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

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

Rob Huffman
Hall of Fame
Hall of Fame

Hey Erik,

What a "Gong Show"

Thanks so much for posting back with your results here (+5)

Cheers!

Rob

f.giordano
Level 1
Level 1

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

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

HI Oli,

Here we go

CSCth95017 - Configurable parameter on how callingparty is displayed for hunt groups.

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

1st Found-in:                          (1)

9.0(3)

Status:

Terminated

Last Modified:

Dec 21,2011

Product:

Cisco Unified IP Phone 7900 Series

Platform:

Dependent

Severity:

6 - enhancement

Customer Reported:                          (19)

Cheers!

Rob

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

HTH, please rate all useful posts and right answers.

Hi Armin,

It's actually been moved to 2- Severe and looks like it is being worked on;

Details

First Found in:                          (1)

8.6(2)

Status:

Fixed

Last Modified:

Jul 30,2012

Fixed in:                          (5)

9.0(0.98000.74),9.0(0.98000.21),8.6(4.98000.21)

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

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

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.

UC_Anne
Level 1
Level 1

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.

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: