Did you get an answer on this? Although I'd really prefer to see a CUCM update with the firmware included, or at least a Device Pack versus an individual firmware file, I suppose I'll take what I can get if it actually works.
Is the TH1.1 version only available from TAC since 9.4(2) doesn't work as another poster claimed?
The latest CUCM device packs have the latest 79xx firmware in them and that firmware works for us fine. (We were hitting the headset transfer problem at first)
BTW - Why the aversion to an individual firmware version?
I see you're right, thanks. The way they were listed in the download window had the 9.1(1) device packs at the top with a May 2013 release date. Didn't notice the 9.1(2) releases a little further down.
As to the aversion, for the same reason I'd rather install a Service Pack Rollup to Windows instead of individually installing each released patch and reboot in between. I reboot my CUCM as infrequently as possible. Often when I do there tend to be replication issues or partnership failures with other UC applications, in addition to a handful of IP Phones or sidecars not re-registering and requiring a manual reset.
Firmware updates only require a restart of the TFTP Process. No need for a cluster reboot.
Device packs only need a cluster reboot if you are adding support for new phones. If it's just a firmware update, a TFTP Process restart is your friend, again.
We updated CUCM to 220.127.116.1101-3 and had the same issues with our 7961/7962 phones. Found this discussion and we decided to update to the latest devicepack 9.1.2 (Nov 4 2014) using the devicepack matrix: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/compat/matrix/CMDP_BK_CCBDA741_00_cucm-device-package-compatibility-matrix/CMDP_BK_CCBDA741_00_cucm-device-package-compatibility-matrix_chapter_00.html#CMDP_RF_C89B97BE_00
This resolved our issues. Thanks!
Running CUCM 18.104.22.168900-8 with most call center agents using 7941-7961 model phones. We have upgraded all of our agents phones to SCCP41.9-4-2SR1-1S but we continue to experience the transfer issue. However, it appears to be intermittent. Opened a TAC case for further analysis.
You'll need to keep those phones at firmware release SCCP41.9-3-1SR3-1S per my last case with TAC. SCCP41.9-3-1SR4-1S may also work but I can't confirm.
It didn't appear they had any plans to resolve it from my previous cases, closed in June 2014 and February 2015.
Associated BugID is CSCun26289.
You should also notice on your updated release that if a 79XX IP Phone has a line set to "Auto-Answer on Speakerphone" it will actually auto answer to either the headset or speaker depending on which the user last fielded a call, with no visual indication of this behavior.
Hope that's helpful. Don't shoot the messenger.
I have pushed SCCP41.9-3-1SR3-1S to a couple agent phones to test. Also provided logs to TAC engineer. He stated that if the problem is still existing on 9.4.2 that he would have to go to the developers. Did you get that far with your TAC case? Or they simply chalk it up as a workaround fix?
Sorry, I misspoke after reviewing my case. The transfer problem was fixed for us with 9-4-2-1S. The reason I kept my firmware at the previous version is because of the auto-answer going to the headset port. Doesn't fly in our environment because we use DNs for intercoms rather than the built-in feature. So definitely continue to pursue your case with TAC. I haven't tested with 9-4-2-SR1-1S but I assume it should still work since it did with with 9-4-2-1S.
Good afternoon All,
I am coming across the same issue and wondering how your TAC cases turned out? We previously upgraded to CallManager version 22.214.171.124900-8 and immediately started experiencing this transfer/headset issue.
Since we just upgraded, will the previous firmware version be available? Or do I have to install the old 9.3(1)cop file in order to revert the firmware version?
Any assistance or information is greatly appreciated!!
I'm using version SCCP45.9-4-2SR1-1S (and SCCP42...) and no longer have the problem. If you need it, any firmware you haven't deleted from your TFTP Server will still be there. Go to OS Administration and search to check.