08-08-2012 06:02 AM - edited 03-20-2019 07:58 PM
Hello all,
The "fixed-in" versions for this bug are listed below;
8.6(2.21023.1),1.9(9.98000.16)
But the bug is related to firmware and the "fixed-in" versions look like CUCM versions;
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
Can anyone clarify the "fixed-in" versions for this bug and where the versions are available for download.
Cheers!
Rob
"Always movin' ahead and never lookin' back" - Springsteen
Solved! Go to Solution.
08-08-2012 08:53 AM
Hi Rob, The original documentation highlighted this as a phone issue. You have a good eye to catch this. 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 Toolking 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
08-08-2012 12:06 PM
Thank you for figuring that out Wes! I just heard back from the engineering team (with the same answer of course). I have asked them to update the bug.
Thanks for getting this answered so quickly!
08-08-2012 08:53 AM
Hi Rob, The original documentation highlighted this as a phone issue. You have a good eye to catch this. 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 Toolking 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
08-08-2012 09:49 AM
Hi Wes,
As always.....you are the man!
Thank you so much for this great update Much appreciated my friend!
Cheers!
Rob
"Always movin' ahead and never lookin' back" - Springsteen
08-08-2012 12:06 PM
Thank you for figuring that out Wes! I just heard back from the engineering team (with the same answer of course). I have asked them to update the bug.
Thanks for getting this answered so quickly!
08-08-2012 01:11 PM
Hey Christine,
Thanks to you as well for looking into this for us
This level of service related to the online tools (Bug toolkit/BST) and bug fixes specifically,
is impressive by both you and Wes to say the least!
Cheers!
Rob
"Always movin' ahead and never lookin' back" - Springsteen
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