nseto,

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.

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

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

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.

Correct.

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.

I have opened a TAC case with Broadsoft for their opinion.

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

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
parameter."

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.

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

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.

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

By any chance did CSCti53461 get implemented in December? Is there any status update?

Thank you

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.