Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

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 ?





Everyone's tags (3)

Accepted Solutions

9.4(2) Firmware was released

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.
New Member

Apparently that fixed

Apparently that fixed firmware does not exist.

We have to downgrade our phones...

New Member

The fixed firmware have been

The fixed firmware have been made available.

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

No issues reported.

New Member

Where did you find the new

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

New Member

A link was sent to me from

A link was sent to me from the TAC.

New Member

I beleive the ES27 means

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.

New Member

Any news on the chances of

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

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.... :-(


New Member

Hi,I ran into this problem


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.



New Member

An ES isn't an acceptable

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

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.
New Member

Rolling back is possible, I

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.

9.4(2) Firmware was released

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.

The support policy states

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

New Member

I had the problem described

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!

New Member

Did you get an answer on this

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

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?



Please rate all helpful posts.
New Member

I see you're right, thanks. 

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

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.



Please rate all helpful posts.
New Member

Just confirming that the

Just confirming that the latest device pack resolved the issue for us.


I'm running CUCM and Device Pack

New Member

We updated CUCM to 9.1.2

We updated CUCM to 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:

This resolved our issues. Thanks!

New Member

Running CUCM

Running CUCM 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.


New Member

You'll need to keep those

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.

New Member

Thanks kdotten,I have pushed

Thanks kdotten,

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?

New Member

Sorry, I misspoke after

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.


New Member

Good afternoon All,I am

Good afternoon All,

I am coming across the same issue and wondering how your TAC cases turned out?  We previously upgraded to CallManager version 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!!  

Thank you,



New Member

I'm using version SCCP45.9-4

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.

New Member

Awesome, thank you kdotten!

Awesome, thank you kdotten!  I wasn't exactly sure where to look for previous firmware loads..

I will check, thanks again!

CreatePlease to create content