Showing results for 
Search instead for 
Did you mean: 
Walkthrough Wednesdays

Problems transferring/answering calls when using headset with 79XX phone - CSCun26289



Runing on CUCM 8.6.2 and preparing for an upgrade to v9, we have recently upgraded our IP Phone firmware.

We are using the 79xx serie. we upgraded the firmware to *SCCP41.9-3-1SR4-1S*

We are now facing a very strange issue that is referenced in the bug below.


When using the headset our users cannot transfer an active call or answer a call when ther is one already active.

There seems to be a fix in 9.3(1)ES27

Does anyone knwo where this fixed version can be found ?






Accepted Solutions
Gordon Ross

9.4(2) Firmware was released on Friday. There are no release notes for this version, but in testing, it appears that the bug has been squashed.



Please rate all helpful posts.

View solution in original post


Apparently that fixed firmware does not exist.

We have to downgrade our phones...

The fixed firmware have been made available.

We are now running: SCCPxx.9-3-1ES27S

No issues reported.

Where did you find the new files?  I cannot locate them.

A link was sent to me from the TAC.


I beleive the ES27 means Engineering Special.  It can only be downloaded from TAC if they give you a special link.  You have to have CUCM or phone maintenance to get it.


Any news on the chances of fixing this bug?  When I contacted TAC about this issue, they did not provide an ES but instead had me roll back the firmware to 9.3(1).

This is a fine solution in the interim but as CUCM software updates are released I can no longer install them since they still use the crippled 9.4(1) firmware for IP Phones.

There is an actual need to update to resolve an unrelated issue, but I cannot do so without manually rolling back the firmware until this bug is fixed.


Just FYI:

The software with the issue is bundled in the Device Pack Release 8.6(2.25132) which is the newest (still today, 18.8.14) one for 8.6 releases.

The bug CSCun26289 already has 280 customer cases attached to it. (+1 since today).

Not happy.... :-(




I ran into this problem right after I updated to the latest device package on Apr 20, 2014. The bug was reported two days later and I contacted TAC, got the SCCP45.9-3-1ES27S & SCCP75.9-3-1ES27S cop files (did get for SIP as well). We are operating a call center and can't ask agents to always answer the phone using handsets. I had to roll back to FW 9.2.3 which was working fine. I deployed SCCP75.9-3-1ES27S on selected phones and I haven't heard any problems so far.

We are going to upgrade our CUCM from 8.6.2 to 9.1.2 and I got a confirmation from PDI helpdesk that 9-3-1ES27S will work with 9.1.2 so now I am in a process of upgrading all the 7945 and 7975 phones to the ES release.



An ES isn't an acceptable solution.  Neither is rolling back to a previous version.  Cisco needs to either release an updated and corrected version of the firmware or start releasing new updates with the previous firmware for 7945/65/75. 

I refuse to accept that we should be expected to "roll back" our firmware after every upgrade or sit on an ES until end-of-life, which should be nowhere near announcement.

If this is an attempt to bully customers into replacing phones with later models it is a stain on the Cisco brand.

I just received an alert last week that yet another CUCM update was released and STILL it contains the broken 9.3(1SR4.1) firmware.  This is absurd.  This thread alone is 5 months old.  There's no one at Cisco willing to accept liability for continuously releasing faulty firmware for their devices?


Why is rolling back not possible? What feature in the latest firmware does your business need that is not present in the previous SR3 version?


An ES version of any Cisco software is just a stop-gap until a release that has undergone the full pre-release testing. e.g. I'm currently running an ES version of CallManager. This doesn't mean that Cisco are now going to ditch CallManager. It just means I've hit a bug in CallManager that is only fixed by the latest ES version. Once the next formal version comes out, I'll upgrade to that. This isn't the first ES version of CallManager I've run - I've run three of four versions over the past six years.


As to this thread being five months old: I can beat that. I've got three bugs open with Cisco about 78xx firmware: These calls were logged back in January and there's still no sign of a fix (ES or otherwise) Cisco seem to be very slow in fixing handset bugs. I believe a 7937 bug I hit took nearly a year for a formal fix to appear. (Although did get an ES version sooner than that)


I understand your frustration with the speed at which Cisco fix handset bugs, but you don't give any reason why you can't back rev to SR3. We've hit this same bug and are running all headset capable 79xx phones on SR3 rather than SR4.



Please rate all helpful posts.

Rolling back is possible, I've already done so. 

I think you've misread me.  I don't need any feature of the new firmware.  I can do without it completely.  What I do need is new features/fixes of new CallManager releases, but it's a hassle to have to roll back the device firmware after each upgrade.  I don't know about you, but I typically get a few devices that don't get the firmware applied until a manual reset, so I prefer to do device updates as infrequently as possible to avoid interruption for users.

As for CUCM ES's, that's a little more understandable.  If I'm stuck at a version while waiting on a bug, I can still apply device packages to phones if need be, but the CUCM updates come packaged with the new firmware so I don't have the same flexibility there.

So, ^^^ that's my reason, as I said before.

Gordon Ross

9.4(2) Firmware was released on Friday. There are no release notes for this version, but in testing, it appears that the bug has been squashed.



Please rate all helpful posts.

View solution in original post


The support policy states that only the newest firmware is supported:

A release that has this sev 2 issue with hundreds of customer cases is in the most current device pack for month and there is no info (some text in the release notes or a field notice would have been useful).

If such an issue is found there MUST be a better info and/or this firmware has to be removed from the device packs.

352 customer cases until now. Imagine the hours wasted for customers, partners, and Cisco


I had the problem described here with multiple model phones, I dwnld and install the updated firmware released Sep 5th (cmterm-7945_7965-sccp.9-4-2-1.cop.sgn), but I'm still having the same problem and had to rollback to an older version.

The bug report says that the fix is ver. 9.4(2)TH1.1, which is not quite the same as what's posted for dwld.  So is there another version out there that WILL fix the bug???  Do I have to open a TAC case to obtain it?

Common now!

Content for Community-Ad

Spotlight Awards 2021