How can I disable the internal call control?

7 posts / 0 new

Tue, 07/12/2016 - 12:15

boldaslove

I'm using the Native C++ library and would like to control all aspects of the device myself. For example, when the user clicks the talk button I would like only to receive the event for it and would like to disable all internal state setting that normally occurs, such as setting the Audio to Mono On or Mono Off, setting the mute, selecting the active line, etc. How can this be achieved? Thanks

Thu, 07/14/2016 - 06:11

lcollins

Hi there, The Plantronics SDK provides a lot of events and functionality you can use to acheive this without the need to have call state syncronized into the Plantronics SDK. If you want to process all the call state in your own software that is fine. But at a minimum you would need to: <ol> <li>Listen for the call control button event from headset (talk button)</li> <li>When your call goes active tell headset to turn on audio (to support Plantronics legacy wireless devices)</li> </ol> Besides those 2 things, other functionality such as mute, hold/resume, selecting active line can be done entirely in your software without need to inform Plantronics via the Plantronics call state sync features (IncomingCall/OutgoingCall etc). I have prepared a modified Native sample code to illustrate how to receive raw device events such as talk button from the interface known as "IDeviceListener" It is here: <a href="/files/spokes3gsdksamples-devicelistenerzip">http://developer.plantronics.com/files/spokes3gsdksamples-devicelistenerzip</a> Here is a picture of that running. The HEADSET_BUTTON_TALK you can use as a trigger to answer/end your phone call: [[{"fid":"103","view_mode":"default","type":"media","attributes":{"height":"493","width":"917","class":"media-element file-default"}}]] Beyond that when you want the audio link active on headset you should tell Plantronics to activate the audio link, otherwise some legacy wireless devices may not do it. You can call:                 hostCommand->setAudioState(AUDIO_STATE_MONOON);  // to turn the audio link on                 hostCommand->setAudioState(AUDIO_STATE_MONOOFF);   // to turn the audio link off Note, you may need to trap errors with this setAudioState call as the feature is not supported on Plantronics newer products (Focus UC, Voyager 5200 UC). These devices do not need the audio link turned on as they have automatic audio sensing feature all the time. Below are some code snippets from the sample code that obtains the IDeviceListener interface: 1. Define some variables to connect to the IDeviceListener interface: IDeviceListener* devListener = nullptr; CMDeviceListenerCallback deviceListenerCallback; 2. Get the device listener for the active device, then register the callback: // sink to device events if (activeDevice->getDeviceListener(&devListener) != DM_RESULT_SUCCESS) {     cout << "Failed to get device listener." << endl; } if (devListener->registerCallback(&deviceListenerCallback) != DM_RESULT_SUCCESS) {     cout << "Failed to register callback." << endl; } 3. The callback code can look something like this: class CMDeviceListenerCallback : public IDeviceListenerCallback {     virtual void onBaseButtonPressed(DeviceListenerEventArgs const& args)     {         cout << "onBaseButtonPressed: " << BaseButtonToString(args.baseButton) << endl;     }     virtual void onATDStateChanged(DeviceListenerEventArgs const& args)     {         switch (args.ATDStateChange)         {         case ATD_STATE_CHANGE_MOBILE_CALLER_ID:             //GetCallerID();         case ATD_STATE_CHANGE_MOBILE_INCOMING:         case ATD_STATE_CHANGE_MOBILE_ON_CALL:         case ATD_STATE_CHANGE_MOBILE_CALL_ENDED:         case ATD_STATE_CHANGE_MOBILE_OUTGOING:             //ATDEventCallback(args.ATDStateChange);         default:             break;         }         cout << "onATDStateChanged: " << ATDStateChangeToString(args.ATDStateChange) << endl;     }     virtual void onBaseStateChanged(DeviceListenerEventArgs const& args)     {         cout << "onBaseStateChanged: " << BaseStateChangeToString(args.baseStateChange) << endl;     }     virtual void onHeadsetButtonPressed(DeviceListenerEventArgs const& args)     {         cout << "onHeadsetButtonPressed: " << HeadsetButtonToString(args.headsetButton) << endl;     }     virtual void onHeadsetStateChanged(DeviceListenerEventArgs const& args)     {         switch (args.headsetStateChange)         {         case HS_STATE_CHANGE_MONO_ON:         case HS_STATE_CHANGE_MONO_OFF:         case HS_STATE_CHANGE_DON:         case HS_STATE_CHANGE_DOFF:         case HS_STATE_CHANGE_NEAR:         case HS_STATE_CHANGE_FAR:             //HeadsetEventCallback((int32_t)args.headsetStateChange);             break;         case HS_STATE_CHANGE_MUTE_OFF:         case HS_STATE_CHANGE_MUTE_ON:             //HeadsetEventCallback((int32_t)args.headsetStateChange);             break;         case HS_STATE_CHANGE_OUT_OF_RANGE:         case HS_STATE_CHANGE_IN_RANGE:         case HS_STATE_CHANGE_PROXIMITY_UNKNOWN:         case HS_STATE_CHANGE_PROXIMITY_ENABLED:         case HS_STATE_CHANGE_PROXIMITY_DISABLED:             //HeadsetEventCallback((int32_t)args.headsetStateChange);             break;         default:             break;         }         cout << "onHeadsetStateChanged: " << HeadsetStateChangeToString(args.headsetStateChange) << endl;     } }; --- hope it helps! Cheers, Lewis.

Thu, 07/14/2016 - 15:12

(Reply to #2) #3

boldaslove

To be more clear heres an example of what I would like to accomplish: Headset is off User clicks TalkButton - Audio Turns On User clicks TalkButton - Audio Stays On Using your example below, I run into the problem of the CallManagers internal logic overlapping with the external 'setAudioState' command called during the OnHeadsetStateChanged, resulting in a 'flickering' in the state of the headset (can be seen on the base by the VOIP light changing back and forth) followed by the final headset state of MonoOff. Below you can see in the Spokes logs that the 'DeviceMonoOff' starts when we hit the talk button and finishes after our call to 'setAudioState' finishes. It looks like the 'setAudioState' from my API call starts and completes after the 'setAudioState' from the Talk Button Press but completes execution before the completion of the 'DeviceMonoOff' logic running from that event ( which Im *guessing* forces it back to a 'MonoOff' state? ) Here's the only changes I made to your example program in the link: >>>>>>>>>> SpokesNativeSample.cpp <<<<<<<<<< IHostCommand* hostCommand = nullptr; // changed from local scope of _tmain to global scope >>>>>>>>>> EventSink.h <<<<<<<<<< eHeadsetButton lastHeadsetButton = HEADSET_BUTTON_UNKNOWN; // used keep track of last headset button extern IHostCommand* hostCommand; // used to perform setAudioState virtual void onHeadsetButtonPressed(DeviceListenerEventArgs const& args) // changed function from no-op to do following try { const time_t tStart = time(0); struct tm* tmStart = localtime(&tStart); std::cout << "onHeadsetButtonPressed: " << HeadsetButtonToString(args.headsetButton) << " curtime: " << (1900 + tmStart->tm_year) << "-" << tmStart->tm_mon << "-" << tmStart->tm_mday << " " << tmStart->tm_hour << ":" << tmStart->tm_min << ":" << tmStart->tm_sec << "\n\n"; } catch (exception ex) { cout << "Exception! code (" << ex.what() << ")\n"; } if (args.headsetButton != HEADSET_BUTTON_UNKNOWN) { cout << "setting headset button" << endl; lastHeadsetButton = args.headsetButton; } virtual void onHeadsetStateChanged(DeviceListenerEventArgs const& args) // changed function from no-op to do following if (lastHeadsetButton == HEADSET_BUTTON_TALK) { try { const time_t tStart = time(0); struct tm* tmStart = localtime(&tStart); std::cout << "onheadsetstatechange setAudioState: " << HeadsetButtonToString(lastHeadsetButton) << " curtime: " << (1900 + tmStart->tm_year) << "-" << tmStart->tm_mon << "-" << tmStart->tm_mday << " " << tmStart->tm_hour << ":" << tmStart->tm_min << ":" << tmStart->tm_sec << "\n\n"; hostCommand->setAudioState(AUDIO_STATE_MONOON); // to turn the audio link on lastHeadsetButton = HEADSET_BUTTON_UNKNOWN; } catch (exception ex) { cout << "Exception! code (" << ex.what() << ")\n"; } } I've done a similar test setting the audio state inside of 'OnHeadsetButtonPressed', setting the audio state to MonoOn when its a talk button, and get the same result from a high level perspective (didn't dig deeper into those logs, but the headset stays off) **Also just a note, it looks like the Spokes timestamps don't use local time, so thats why the hours dont match between the spokes traces and console output Here's what I think is the key part from the Spokes log and the console output: ///// this is result of search for 'MonoOff' in Spokes.log Search "MonoOff" (3 hits in 1 file) C:\Users\John Wojner\AppData\Local\Plantronics\logs\Spokes.log (3 hits) Line 1451: TRACE 14-Jul-2016 16:33:19,747 [0x00007b10]: Plantronics::CallManager::DeviceMonoOff - entry Line 1454: INFO 14-Jul-2016 16:33:19,747 [0x00007b10]: Plantronics::CallManager::MonoOnOff - Setting audio: MonoOff Line 2114: DEBUG 14-Jul-2016 16:33:20,911 [0x00007b10]: Plantronics::CallManager::DeviceMonoOff - exit ///// this is result of search for 'setAudioState' in Spokes.log Search "setAudioState" (10 hits in 1 file) C:\Users\John Wojner\AppData\Local\Plantronics\logs\Spokes.log (10 hits) Line 773: TRACE 14-Jul-2016 16:33:18,126 [0x00007b10]: BaseDeviceListener::setAudioState - entry ///// from clicking headset button first time (turning on audio) Line 774: TRACE 14-Jul-2016 16:33:18,126 [0x00007b10]: PoseidonCommand::setAudioState - entry Line 800: DEBUG 14-Jul-2016 16:33:18,129 [0x00007b10]: PoseidonCommand::setAudioState - exit Line 801: DEBUG 14-Jul-2016 16:33:18,130 [0x00007b10]: BaseDeviceListener::setAudioState - exit Line 1455: TRACE 14-Jul-2016 16:33:19,747 [0x00007b10]: BaseDeviceListener::setAudioState - entry ///// from clicking headset button second time (audio already enabled before click) Line 1456: TRACE 14-Jul-2016 16:33:19,747 [0x00007b10]: PoseidonCommand::setAudioState - entry Line 1480: DEBUG 14-Jul-2016 16:33:19,750 [0x00007b10]: PoseidonCommand::setAudioState - exit Line 1481: DEBUG 14-Jul-2016 16:33:19,750 [0x00007b10]: BaseDeviceListener::setAudioState - exit Line 1505: TRACE 14-Jul-2016 16:33:19,761 [0x000057b4]: PoseidonCommand::setAudioState - entry //// from calling 'setAudioState' Line 1529: DEBUG 14-Jul-2016 16:33:19,764 [0x000057b4]: PoseidonCommand::setAudioState - exit ///// this is result of search for 'setAudioState' in the console output of the modified sample program Search "setAudioState" (1 hit in 1 file) C:\Users\John Wojner\AppData\Local\Plantronics\logs\ConsoleOutput.log (1 hit) Line 32: onheadsetstatechange setAudioState: HEADSET_BUTTON_TALK curtime: 2016-6-14 11:33:19 ///// this is the entire log from the console output ********************************* * PID: 0xac01 * VID: 0x47f * Path: \\?\hid#vid_047f&pid_ac01&mi_03&col03#8&987786&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030} * Name: Poseidon * Product: Plantronics Savi 7xx * Manufacturer: Plantronics * Serial NO HID: DC2B394099C04F92B5EE831463B0864E ********************************* > onHeadsetButtonPressed: HEADSET_BUTTON_TALK curtime: 2016-6-14 11:33:18 setting headset button OnCallStateChanged Session Manager event CALL_STATE_HOOK_IDLE onHeadsetStateChanged: HS_STATE_IN_CONFERENCE = 12 onHeadsetStateChanged: HS_STATE_IN_RANGE = 8 OnCallStateChanged Session Manager event CALL_STATE_UNKNOWN onHeadsetButtonPressed: HEADSET_BUTTON_UNKNOWN curtime: 2016-6-14 11:33:18 onBaseStateChanged: BASE_STATE_CHANGE_AUDIO_LOCATION_CHANGED = 11 onHeadsetButtonPressed: HEADSET_BUTTON_UNKNOWN curtime: 2016-6-14 11:33:18 onHeadsetButtonPressed: HEADSET_BUTTON_UNKNOWN curtime: 2016-6-14 11:33:18 onBaseStateChanged: BASE_STATE_CHANGE_VOIP_LINK_ESTABLISHED = 3 onHeadsetStateChanged: HS_STATE_MONO_ON = 1 onHeadsetButtonPressed: HEADSET_BUTTON_TALK curtime: 2016-6-14 11:33:19 OnCallStateChanged Session Manager event CALL_STATE_UNKNOWN setting headset button onHeadsetStateChanged: HS_STATE_MONO_OFF = 2 onheadsetstatechange setAudioState: HEADSET_BUTTON_TALK curtime: 2016-6-14 11:33:19 onHeadsetStateChanged: HS_STATE_IN_CONFERENCE = 12 onBaseStateChanged: BASE_STATE_CHANGE_VOIP_LINK_DOWN = 4 onHeadsetStateChanged: HS_STATE_MONO_ON = 1 onBaseStateChanged: BASE_STATE_CHANGE_VOIP_LINK_ESTABLISHED = 3 onHeadsetStateChanged: HS_STATE_MONO_OFF = 2 OnCallStateChanged Session Manager event CALL_STATE_CALL_IDLE onHeadsetStateChanged: HS_STATE_IN_CONFERENCE = 12 onBaseStateChanged: BASE_STATE_CHANGE_VOIP_LINK_DOWN = 4

Mon, 07/18/2016 - 04:03

(Reply to #3) #4

lcollins

Hi again, So when you bring the audio link up hostCommand->setAudioState(AUDIO_STATE_MONOON); this causes internal call state changes in the Savi 7xx base and the Plantronics SDK runtime (PLTHub.exe) (and/or Plantronics Hub software if installed). The internal call state changes means the Savi 7xx goes into state "VOIP_LINK_ESTABLISHED" (base state change event) (because your software has told it to set audio state to monoon). When software tells Savi 7xx to go to monoon, it basically means a VOIP (softphone) call is in progress on the device. The PC link LED will light up on the Savi 7xx base. When the user presses the "talk button" on the Savi headset, this signals the Savi 7xx base to end the current active VOIP call (it will transition to VOIP_LINK_DOWN, and the LED will go off). During this state transition, setting the audio state back to MONOON may cause issues. It is probably advisable not to do so. Why do you want to keep the audio state on? The product is designed to have audio state MONOON only during a call. If you were to leave audio state on all the time, it would shorten the battery life of the product. The problem you have is the talk button is designed to close the VOIP link of the Savi 7xx base. BUT - you can change this behaviour! If you install the Plantronics Hub software from www.plantronics.com/software Then you can set the device to always keep the radio/audio link on (see image below). However, this will shorten the headset's battery when headset is not docked in the base. With this configuration you only need to set audio state to MONOON. At the next talk button event, the Savi 7xx base will remain with link active / LED lit. Give it a try and see if it meets your needs. I think it may cause another issue where the base is not aware you are on a call.  [[{"fid":"104","view_mode":"default","type":"media","attributes":{"height":"807","width":"1041","class":"media-element file-default"}}]] Thanks, Lewis.

Wed, 07/20/2016 - 14:04

boldaslove

If I use your suggested solution I run into problems when calling 'setAudioState' with a value of MonoOff, so I can't use it. Since turning off the internal call control performed by the CallManager doesnt seem to be an option my question changes to "as a developer how do I know when a 'safe' time to perform a spokes API call is?". Firstly, a little more on my actual problem and whats happening. I work at a software company that deals in IVR and Call Center solutions. We have been supporting plantronics for a number of years now, going back to 2007 when we interfaced using the COM API. The logic in our process that interacts with your device has been tested and works on a number of devices, off the top of my head I know we have customers currently using the CS50's, D100's, and Savi 7xx's. The problem only occurs with the Savi 740's running the latest firmware. I've tested using multiple Savi 740 devices running 2 different sets of firmware. One test with a base firmware of 28.47, remote firmware 28.25, and usb firmware 179. The other with a base firmware 19.85, remote firmware 19.41, and usb firmware 165. In both versions I get conflicts between the internal call manager and my external API calls. But only in the headsets with the latest firmware ( base 28.47) do I run into trouble. The problem isn't from the state conflicts but from erroneous events being thrown by the device after the conflicts occur. I am receiving *multiple* erroneous events for the devices running the newer firmware. These erroneous events do not just occur when calling a state changing API call during an event. It occurs when you call any number of API calls inbetween state change events that are related to the originiating event. Heres an example that does *not* include a person doing anything with the physical device: 1) Headset is set to MonoOn 2) An internal timer goes off in my process, and in the main thread I call 'setAudioState' with a value of MonoOff 3) I start receiving plantronics events, starting with 'onHeadsetStateChanged' and 'onAudioStateChanged' 4) After these 2 events my internal timer goes off again and I call *only* the state querrying API calls 'isLineActive' and 'getHoldState' for each line type using the device listener instance. these calls all succeed. I then call 'getAudioState' which fails with a DM_RESULT_FAILURE 5) After this I get a onHeadsetStateChanged, onBaseStateChanged, and OnCallStateChanged event from plantronics 6) After these I once again call 'isLineActive' only on the VOIP line 7) I then receive a OnTalkButtonPressed plantronics event!!! In the example path above I don't react to your events, I simply query the state of the device, and I still get failures and erroneous events, and if I react to these failures too soon I get in a loop of repeated failures. How can I know when the device is in a valid state to perform an API call on Savi 740s running the newest firmwares? Note: I've contacted your support and put in a ticket for this, asking them to confirm if this is either intended behavior or a bug. I've been escalated 3 times now, first to a Senior Tehcnical Asisstance Specialist, then to Engineering, then to the 'Rapid Response Group'. I've emailed back asking for any updates and haven't received a word. My original contact date was June 30th. We have multiple customers with Savi 740 headsets that are rendered useless at the moment. I'm hoping for some progress to be made soon, either in the form of being updated on the status of my ticket [05165619] or receiving guidance on how to properly use the API so I dont run into these erroneous events and failed API calls. Thanks!

Fri, 07/22/2016 - 02:55

(Reply to #5) #6

lcollins

Hi, I will email you about this now. Thanks

Mon, 07/25/2016 - 06:51

lcollins

Hi, One possible suggestion is to use the BaseStateChanged events to inform your application when "VOIP_LINK_DOWN" (i.e. PC line is closed). At that point open it again via IHostCommandExt interface: hostCommandExt->setActiveLink(LINK_TYPE_VOIP, true). I have test this with code like below and it works. Here is a download of the modified sample code illustrating this: <a href="/system/files/Native%20SDK%20sample%20with%20pc%20line%20always%20on%20demo.zip">http://developer.plantronics.com/system/files/Native%20SDK%20sample%20with%20pc%20line%20always%20on%20demo.zip</a> // This is how the code fragment looks, first we get a IHostCommandExt from the IHostCommand using dynamic_cast:         activeDevice->getHostCommand(&hostCommand)                 hostCommandExt = dynamic_cast<IHostCommandExt*>(hostCommand); // Then in our event handler (eventsink.h) we wait for the voip link to go down, then open it again: extern IHostCommandExt* hostCommandExt;     virtual void onBaseStateChanged(DeviceListenerEventArgs const& args)     {         cout << "onBaseStateChanged: " << BaseStateChangeToString(args.baseStateChange) << endl;         switch (args.baseStateChange)         {             case BASE_STATE_CHANGE_VOIP_LINK_DOWN:                 cout << "BASE_EVENT_TYPE_VOIP_LINK_DOWN" << endl;                 hostCommandExt->setActiveLink(LINE_TYPE_VOIP, true);             break;         }     } Thanks, Lewis.

Add new comment