Disable auto-answer on SPA50XG when on an active call.

Unanswered Question
Aug 11th, 2010

We are using Cisco 504Gs with a Broadsoft switch.  When a push-to-talk call or page is sent to the phone, the phone auto-answers as we would expect it to.  However, the phone also auto-answers these types of calls when there is already an active call on the phone, putting that activce call on hold.  This is not the desired behavior for us in these circumstances.

We would like the phone to auto-answer only if there is no active call currently on the line.  Is there any setting on the phone that can set to force the phone to behave this way?  I can turn off auto-answer but that breaks all paging and push-to-talk calls.  I can also turn off call-waiting but that presents it's own issues.  We have several Polycom phone models and none of them exhibit this behavior.  None of them auto-answer these types of calls when there is an active call on the line.

We are running firware 7.4.4

I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
nseto Thu, 08/19/2010 - 14:24

Upgrade to 7.4.6 on cisco.com and this should work the way that you are describing.

bgottlieb Fri, 08/20/2010 - 04:25


Been running 7.4.6 for a couple weeks. Noticed the same problem. 7.4.6 does not resolve unless there is a config option that has to be set as well.

nseto Fri, 08/20/2010 - 09:23

I was testing 7.4.6 with the spa9000 pbx and it works the way that you want.

I inquired with our Broadsoft interop tester and he says that when our phones work with Broadsoft, we listen to what the Broadsoft wants.

Basically, the decision lies with who gets control, the device or the proxy.  When working with the spa9000, the phone takes control in this instance.  When working with Broadsoft, we give Broadsoft the control.

Tester comments

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Presently, we do as what Broadsoft tells us to do, unconditionally if it's a single line or multiple lines.  Just of note, line handling of auto-answer can be provisioned on the Broadworks node, to where

  line A auto-answers

  line B doesn't

we obey the hdr value received.

that how Broadsoft tags the auto-answer

Call Info: auto-answer:0

or something to that value

bgottlieb Fri, 08/20/2010 - 12:22

Your tester is correct..

But what about the instance where there are not two lines (Line A and Line B)? Just line A and Line A has call waiting allowed on Broadsoft. User (Line A) is on the phone and talking. Someone within the group sends a Push To Talk (PTT) call to the user (Line A). If that user is on a Cisco SPA-50X running 7.4.6, the original talk path is put on hold and a new talk path is established on the second (call waiting) line of that phone. That is certainly not the expected behavior and more than likely what adam.baird was talking about. I concur that Polycoms do not react the same way. When a "auto-answer" or "answer-after=0" INVITE comes in on a Polycom, the user receives a call waiting tone. It is his/her decision whether to take the call or not. If the Polycom is idle when the INVITE arrives, the call is auto answered...

Hope this helps.

adam.baird Fri, 08/20/2010 - 13:48


In my situation I have a phone with a single line with call-waiting turned on.  I have verified via packet capture that Broadsoft sends the invite with 'answer-after=0" in the Call-ID field for a push-to-talk call regardless of the current line status of the endpoint (be it Polycom or Cisco).

The only difference is that the way the endpoint behaves.  If there is an active call on the line the Polycom will just present the second call along with a call-waiting beep.  The Cisco SPA504G puts the active call on hold and answers the second call.

So from what I can tell, Broadsoft's signaling to the phone does not change based on the line status of that phone.  It is the device itself that decides how to handle the call.

Some of our customers use Push-to-Talk quite a bit and this will be a major issue for us.

bgottlieb Fri, 08/20/2010 - 14:10

I have one better for you...

I am testing a device that will "page" up to 30 devices on the LAN with just one registration to the Broadsoft switch and takes up no WAN bandwidth (i.e. if we use Instant Group Call along with Push To Talk it uses up a talk path to the Media Server for all phones being paged). This device sends out either answer-after=0 or auto-answer INVITES to all devices based on what they expect.

If I have 30 phones being paged and one of the Ciscos is on the "Paging List" and I use that phone to originate the page.... it calls all 29 phones opens a talk path, the INVITE received by the SPA puts the orignal talk path on hold and answers the "call-waiting" second line. Now all 30 phones including the originator (SPA-50X) hear hold music until the originator drops the second call and picks up the original outbound line....

adam.baird Mon, 08/23/2010 - 13:33

Broadsoft has responded to this issue with the following statement:

"BroadWorks does not attempt to check if there is already an active call on the device before adding the answer-after=0

This looks to be a design flaw or bug with the Cisco SPA5xx phones. It is my opinion that the phone should not behave in this way, or in the least that there should be a setting to turn this behavior on and off as desired.

nseto Mon, 08/23/2010 - 14:15

This has been entered as a feature request for dev and marketing to look at.  The id # for this is CSCti53461.  Thank you.

mobiusworks Thu, 10/07/2010 - 09:03

Any update on this bug? We have the same situation at a clients as well. The bug toolkit will not release any informaton on the status of this bug.

nseto Thu, 10/07/2010 - 09:31

I looked at the status, it's set to be addressed in the next release which is scheduled for Dec of this year.

nseto Tue, 02/01/2011 - 08:24

That bug ID shows as being resolved for the upcoming 7.4.8 release, I believe that release will be out late Feb or sometime in Mar.


This Discussion

Related Content