Different models have different behaviour

We need to support the answer to the call by pressing the Talk button on the headset. If there is an incoming call, pressing Talk should pick answer the call. And when the call in active, pressing Talk button on the headset should end the call.

 
But we were confronted with the different behaviour of different headset's modles Savi W430A-M and CS520 headsets when pressing Talk button:

 
CS520:
a) When there is no connection, when you click Talk button, a pair of events always arrive
cse_args.callState == CALL_STATE_DEVICE_CHANGE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_UNKNOWN 
cse_args.callState == CALL_STATE_HOOK_IDLE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_IDLE_TALKPRESS 

 
b) When an incoming call comes in, and  Talk button is pressed, a similar pair arrives.
c) When the connection is established, the behaviour changes.
- Pressing Talk button turns off the sound, no events are arriving.
- A second click on Talk button will turn the sound back on and a pair of events will be generated again
cse_args.callState == CALL_STATE_DEVICE_CHANGE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_UNKNOWN 
cse_args.callState == CALL_STATE_HOOK_IDLE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_IDLE_TALKPRESS 

 
Savi W430A-M clearly changes the status to "on-off" and sends different events.
Regardless  the connection (in call/not in call):


a) If the headset is off, when  pressing Talk button:
- the headset turns on
- the pair arrives:
cse_args.callState == CALL_STATE_DEVICE_CHANGE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_UNKNOWN 
cse_args.callState == CALL_STATE_HOOK_IDLE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_IDLE_TALKPRESS 


 
b) If the headset is turned on, again despite the presence or absence of communication (in call/not in call) when  pressing Talk button:
- the headset turns off
- a single event arrives
cse_args.callState == CALL_STATE_DEVICE_CHANGE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_UNKNOWN


 
In this way,
1. CS520 behaves the same regardless of the initial state, but differently depending on the connection. And here there is a problem, although not very unpleasant: to end active call, the operator will have to press the Talk button twice (since the first press does not generate any events)
2. W430A-M behaves differently depending on the initial state, but regardless of the connection. That is, it changes the state as a trigger. And this is a more unpleasant situation - because different scenarios are possible.
a) The headset is off. An incoming call arrives. Pressing the Talk button turns it on and allows you to take a call. OK, everything is fine.
b) The headset is on. An incoming call arrives. Pressing the Talk button turns it off, but allows you to receive a call. You can, of course, ignore the event cse_args.callState == CALL_STATE_DEVICE_CHANGE && cse_args.deviceEventkind == DEVICE_EVENT_KIND_UNKNOWN - but then to take the call you have to press the Talk button twice.
c) The headset is off. A call with the far end is established (connected without the Talk button). The operator discovers that he does not hear the caller. If you now click on Talk button, this will mean disconnection of a call, although the operator just wanted to turn on the sound. This is the most unpleasant consequence.

 
In this connection, there are some questions:
1. Is it a bug of a specific headset  unit?
2. Is it possible to provide the same behaviour of headsets by any settings?
3. Can I find out the current status of the W430A-M headset - is it turned on or off?
4. Is it possible to control the state of the headset? For example, by pressing Talk button, we know for sure that we want to turn it off, and not just to change the state. Or vice versa, turn it on.


WBR, Dmitry Sandul.