Calling onhookAsync() also fires button press event?

[Nederby]

Using @gnaudio/jabra-node-sdk v3.0.0 Headset: Jabra evolve 75 with Jabra Link 370

When setting the device onHook it fires the button (btn) press event too. Is that a bug? What I did.:

• Calling device.onhookAsync();
• The button event listener is also fired

  device.on('btnPress', (btnType, btnValue) => {
  logger.log(`New input from device ${device.deviceName} is received: type ${btnType} ${enumDeviceBtnType[btnType]} value: ${btnValue}`);
  }

  Outputs: New input from device Jabra Link 370 is received: type 1 OffHook value: false

I understand that setting the device onHook on the device should fire the button event, but why fire a button event when no button was pressed?

[jabra-slawaetz]

Good question. We'll investigate and come back with info. As this is usage-support rather than development, I've taken the liberty to duplicate the issue in the developer zone, this allows us to track the ticket internally in our support systems.

[sboily]

Hello, is there is an answer for this comment? Why do you fired this event?

[nilsbandel]

@jabra-slawaetz has your investigations resulted in anything you can share with us?

The sequence diagrams in the docs suggest that this is the intended behaviour, but it results in a number of faulty situations.

1. User has an active call
2. User calls device.onhookAsync()
3. A new incoming call arrives
4. device.on(btnPress,(Offhook, false)) is emitted (because of the onhook command)
5. The app interpretes that as if the user wants to end the call via the headset

Because there is a pretty noticeable delay between calling device.onhookAsync() and triggering of device.on(btnPress,(Offhook, false)), this scenario is not uncommon.

1. User has an active call
2. User puts call on hold
3. User takes another call
4. User hangs upp call2, calling device.onhookAsync()
5. device.on(btnPress,(Offhook, false)) is emitted
6. The app interprets that as if the user wants to end call1

The above scenario makes it very difficult to handle juggling of multiple calls while still supporting Jabra devices.

[domnich]

Any updates here ? Im also stuck here as it really difficult to handle multiple calls here

[emolr]

This doesn't seem to be the case with the Jabra 930 pro and the Jabra Handset 450.

Seems the events are a bit different for the evolve series than the two i mentioned, but what's written below by @jabra-slawaetz was the solution to my problem :)

[jabra-slawaetz]

Hello,

as per the github readme, these components are primarily support through the Jabra Developer Zone at developer.jabra.com This channel is infrequently monitored, response time will therefore vary.

The OP's issue has been dealt with and resolved in the Developer Zone. For clarity, we've included the resolution here.

But please note that we have released a new genration of the JavaScript library in Autumn 2021 that provides a much improved handling of call control, especially in the shape of "Easy Call Control" module. You can find it here:

https://developer.jabra.com/site/global/software/integration-components/javascript/index.gsp

This does require re-integration as it has a rewritten API, but has many benefits including supporting both node.js and Chrome, as well as WebHID support when running in Chrome.

thanks

--- Resolution to this specific problem ---

Summary: The buttonpress event is not an actual button press, it is a confirmation from the device that it has gone off-hook.

For a clear discussion of the request-acknowledge protocol, please see

https://developer.jabra.com/fileMedia/download/096501fc-5339-43c1-af98-39b13bc02549

For reference, we copy the detailed resolution responses to the issue here:

--- begin ---

We've gone through your ticket and scenarios in detail with the eingeering team. [...]

Our discussions with the engineering team has accordingly resulted in the following answers:

1> Why is the button press event emitted when no button has been pressed? 2> Is this a bug or is it the intended behaviour?

What you receive is not actually a button press event, it is really an acknowledgement from the headset to your onhook command. So in a sense it is the headset saying "yes, I have gone onhook".

This is actually following the USB standard (https://usb.org) and how both ours and competitors headsets work. The interaction between the application and the headset is based on a request/acknowledge protocol, which means that:

a) An offhook/onhook request sent from the headset will require an acknowledge command to be sent from the application, and b) any offhook/onhook command sent from the application will cause an acknowledge message to be sent from the headset.

It is not clear from your description how the user "calls device.onhookAsync()", but we assume this must be by pressing a button in the UI. This means that case b above is triggered.

This is why you see the onhook event as onhook command in USB lingo translates to "Offhook:false". If the application sends "offhook:false" the headset acknowledges with "offhook:false".

3> If it the intended behaviour, how are we supposed to handle the two cases described above?

It is the intended behaviour.

Without knowing your specific appliction structure and coding details, we can probably best give you the following guidelines:

Scenario 1 and 2:

You will need to match the acknowledgement with your request. So when you get the onhook event (ie an acknowledgement) you should check if you've asked the device to go onhook, if so it is just the acknowledgement to that command. If the user presses offhook to answer the new incoming call, you should get that offhook event request after the onhook acknowledgement.

Please note that we are a little unsure about your step 5 in scenario 1. It may not be entirely following the USB logic. (We read your description as an call incoming, device is ringing, but user has not picked it up yet).

If the device is ringing (because of an incoming call), but the user has no active call (not picked up the call yet), any onhook (offhook:false) events should be ignored. Only after the user has picked up the call (and has an active call) does it makes sense to go hang up (onhook) again. If you want to implement a call rejection mechanism, you need to react specifically for the call reject event, which is a different button interaction that just "offhook".

If we assuming wrongly, and the user has indeed picked up the call, then the guidelines above apply.

Hope this clarifies things.

--- end ---

[emolr]

Hi @jabra-slawaetz, thank you for clarifying this and responding.

I was looking through the documentation for the latest SDK today and found information about the acknowledgement, and it helped me to make a fix for my issue, and will start looking into the differences in the latest SDK and implementation. I'm looking very much forward for the webHID support.

Have a great day, and thank you for your time