6 posts / 0 new
Last post
d.sandul@mighty...
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.

d.sandul@mighty...
Sorry, formatting has been gone...

d.sandul@mighty...
Anybody home? )

lcollins
Hi,<br /> Sorry for delay in responding.<br /> The recommended way to handle call control with any of the Plantronics devices that support Plantronics Hub and the Plantronics Hub SDK is not to handle individual button presses and events, as the signature (pattern) of these events will vary from device to device and device family.<br /> <br /> The recommended way is to use the Plantronics SDK CallCommand interface which offers incomingcall/outgoing/answercall methodology. You recognise call is answered/terminate via a Session event CallStateChange of CallAnswered, CallTerminated, etc.<br /> <br /> To try this in practice may I suggest you install latest Plantronics Hub (3.11.2), and visit this URL:<br /> <br /> https://pltdev.github.io/Plantronics%20JavaScript%20Sample.html<br /> <br /> (see note at top of that page about whitelisting if using Firefox)<br /> <br /> This allows you to exercise the incoming/outgoing call flow etc of the Plantronics SDK as I described above. The same interfaces are offered by COM and COM .NET API options. You can use this live demo of the Plantronics SDK to test with both your devices and see what result you get.<br /> <br /> Note, which EHS are you using CS520 with, APU-75?<br /> <br /> Let me know.<br /> Thanks,<br /> Lewis.<br /> <br /> <br /> <br /> <br /> &nbsp;

d.sandul@mighty...
OK, one more question. When I turn some music on (e.g. with VLC media player), I hear relay click from the headset base, the headset automatically turnes on and music appears in the headphone. But when our software produces some audio stuff (e.g. ringtone), nothing happens until I press talk button to turn headset on. (Any usual headphones successfully translate the ringtone.)<br /> <br /> It seems it is the key to our trouble.<br /> <br /> What can be wrong? Why VLC media player is friendly to Plantronics devices?

lcollins
What controls the enablement of the radio RF link and audio with for example the wireless DECT product Savi 400 series (D100 dongle) is one of 2 things:<br /> 1: if the device has &ldquo;audio sensing enabled&rdquo; setting turned on using the Plantronics Hub software, that setting will be remembered and only when an audio application plays sound via that device the audio sensing of the device will turn on the RF link<br /> OR<br /> 2: if the audio application (whether softphone or media player) has an active application &ldquo;session&rdquo; in Plantronics Hub (either an in built plugin DLL or a 3rd party Plantronics SDK integration). That application can then control the enablement of RF link (note: in the case of legacy devices like Savi 400 this requires that audio sensing is disabled, but not so with newer BT600 Bluetooth products. For this reason if using the product for RCC remote call control, the preferred configuration for legacy devices is audio sensing disabled).<br /> Hub has built in plugin support for Windows Media Player and iTunes enabling these media players to bring up RF link even when audio sensing is disabled on legacy devices. I&rsquo;m not sure though whether VLC was supported...

Add new comment