Tradesense Wba Status Date

TradeSense WBA Status Date
V 9.5.1 Released 10/06/2020
V 9.5.2 Released 20/08/2020
V 9.5.3 Released 06/10/2020
V 9.5.4 Released 04/12/2020
V 9.5.5 Released 26/02/2021
V 9.5.6 Released 09/04/2021
V 9.5.7 Released 25/05/2021
V 9.5.8 Released 06/08/2021
V 9.5.9 Released 24/08/2021
V 9.5.10 Released 05/10/2021
V 9.5.11 Released 25/11/2021
V 9.5.12 Released 08/02/2022
V 9.5.13 Released 25/04/2022
V 9.5.14 Released 27/05/2022

TradeSense WBA Status Date
V 9.5.15 Released 05/07/2022

TradeSense Websocket Backend API
Introduction
Technical description
Message format
Datetime format
Command message
Response message
Notify message
Error handling
User Creation
Authentication
Errors
Re-authentication
Configuration
Use Cases
Case 1 : Settings Auth Timeout and Auth Gracetime are neither configured or set the value as 0
Case 2 : Client Re-auths within Gracetime
Case 3 : Client re-auths before Gracetime
Case 4 : Client fails to re-auth itself during Gracetime
Case 5 : Client re-authenticates with different token
Case 6 : Settings Auth Gracetime is greater than Auth Timeout
Authentication Responses
Errors
Commands
Fetch data
Get Zones
Optionals arguments
Errors
Get Turrets
Optionals arguments
Errors
Get Users
Optionals arguments
Errors
Get Events
Limitation
Using ID
Using datetime
Response
Errors
Get Calls
Limitation
Using ID
Using datetime
Using call_ref
Using filter
Response
Errors
Call a service
Click To Dial
Place a new outbound call
Limitation
Local extension availability
Outgoing call errors
Response
Accept an incoming call
Hold an established call
Resume a held call
Terminate an opened call
Dispatch an opened call
Transfer an opened call
Limitation
Attended
Unattended
Make a conference call
Limitation
Errors
Subscribe to Notifications
Errors
Notifications
Calls notifications
Outgoing call scenario
Error handling
Presence notifications
Presence state values
Settings
Ping settings
Enable the ping mechanism
Configure the ping interval
Notifications settings
Configure the notification batch size on WBA
Configure the notification delay on WBA
Time out settings
Configure the time out interval for click to dial requests
Configure the polling rate interval for click to dial monitoring
Configure the time out interval for requests
Outdated data settings
Configure the fetch interval for WBA requests
Support
Requirements
Startup
Provisioning
Errors
Commands
Log Level
Get the current log level
Change the log level
Available levels
Errors
Get Health
Get the provisioning status
Provisioning data items
Errors
TradeSense Websocket Backend API
Released from 9.5.0, TradeSense Websocket Backend API (WBA) becomes the standard for
using the Click To Dial (CTD) feature.
The old CTD API remains supported but will not be maintained.
Introduction
This document gives an overview about the functionalities that can be implemented by any third
parties that wish to leverage TradeSense data in their bigger pipe of data that implements
WebSockets.
The WBA allows to:
post Click To Dial (CTD) requests;

get notification for all the Customer Relationship Management (CRM) events.
Technical description

Message format
The API uses JSON serialized objects.
Datetime format
Datetime information are formatted as UTC datetime string following the ISO 8601
representation.
Example: "2018-07-06T12:13:17Z"
Command message
This object always contains the following keys:
command : type of the command;

command_ref : the reference of the command is a string value generated by the client-side.
This reference is used to identify the response linked to client's request;
args : command arguments (optional);
{
"command":"command type",
"command_ref":"command reference",
"args":{}
}

Response message
The server-side will respond to each command with a message indicating if the command is done
and if it was successful. It will contain a data key containing the data object.
{
"command":"response",
"success":true,
"data":{}
}
Notify message
Client-side is able to subscribe to different types of notification. When subscribed, server-side will
send a message every second with all last notifications not yet received by the client.
The notification object sent by the server always contains following keys:
command : the command type of a notification message will always be notify

data : object sent (refer to Notification section for more information)
{
"command":"notify",
"data":{
"..."
}
}
Error handling
If an error occurs, the server will send a response message with success set to false . The
error key contains an object with two keys: code and message .
{
"success":false,
"error":{
"code":"code",
"status":"status",
"message":"message",
"reason":"message for user"
}
}
Code Status Message

Code Status Message
The client has made a bad request, which includes requests with
400 Bad Request malformed JSON, or invalid data values as well as requests in
which the URL contains incorrect values
401 Unauthorized You lack permissions to access this resource
We cannot find what you requested, though the request looks

404 Not Found
well formed
An error happened on our end, and it is not your fault. Please

500 Server Error contact your TSS administrator to find out what may cause this
issue
The client had not sent previously used token. If client needs
498 Invalid Token
new session, please disconnect and connect with new token
In addition, a reason can be provided to help the user understand what went wrong.
Bad request reasons can be :
Unable to deserialize message

Mandatory field/parameter missing
Command not found
Action not found
Args missing for clicktodial command
Missing mandatory parameter: parameter_name
Parameter parameter_name is not a valid expected_type
If the configured time out interval for requests is reached (see settings section)
Request timed out
User Creation
You will need a valid token to connect your websocket implementation. This token is delivered by
creating a new user on Assure.
https://TradeSenseFQDN/assure/admin/user/new/
Connect your implementation to:
wss://TradeSenseFQDN/api
Use the token to authenticate your client-side application
Authentication
Client Server
Connect
Auth
{
"command": "auth",
"command_ref": "command ref",
"args" :
{
"token": "TOKEN",
}
}
OK
{
"command": "response",
"success": true,
"data" :
{
...
}
}
Client Server
Authentication via API token is mandatory. When the client-side code decides to open a
WebSocket, it contacts the server-side using a command auth with the token as argument :
{
"command":"auth",
"args":{
"token":"TOKEN"
}
}
If the client-side supplies valid authentication, the authentication phase will complete by the
server sending the response message:
{
"success":true,
"data":{}
}
Errors
This command may return error messages :
User already authenticated

Another user is already connected with this token
No user found for this token
Missing mandatory parameter: token
Re-authentication
To avoid having long connected client session, TradeSense has introduced a session refresh
mechanism. This means clients needs to reauthenticate their session after a specific time. This
session authentication time is configurable through TSS. The client shall be notified by server
before the expiry time to re-authenticate itself.
Configuration
The following two configurable settings has been introduced. It can be configured at TSS ->
Productivity tools clusters -> Select the Cluster -> Settings. After these configuration the assure
stack needs to be restarted.
Default
Name Settings Description value
(seconds)
This is time duration

after successful
authentication or re-
authentication, the
Auth
application.global.wba.auth.timeout client session will expire 0
Timeout
and will be
disconnected by the
server, if not
reauthenticated.
Default
Name Settings Description value
(seconds)
This is a time in seconds

before the
authentication timeout,
a server notification will
Auth
be sent to client to re-
Grace application.global.wba.auth.gracetime 0
authenticate itself with
Time
the same token. Client
needs to reauthenticate
only after the receipt of
this notification
Note : By default(value of 0), reauthentication mechanism will be disabled, so it will be backward

compatible for existing client implementations. But it is highly recommended for clients to
implement this mechanism in their client applications.
The value of Timeout should always be greater than Gracetime.
For example,
application.global.wba.auth.timeout = 1800
application.global.wba.auth.gracetime = 60
Use Cases
Different re-authentication use cases are described below,
Case 1 : Settings Auth Timeout and Auth Gracetime are neither

configured or set the value as 0
or
The re-authentication process is disabled, client authentication cycle is as same current

behaviour. Once authenticated, the session is alive till the client disconnects.
Client Server
Connect
Auth
{
"command": "auth",
"args" :
{
"token": "TOKEN",
}
}
OK
{
"success": true
}
Client Server
Case 2 : Client Re-auths within Gracetime
Grace Time(60-30) = 30
The server will send re-auth notification at the start of the Auth Gracetime. If client re-
authenticates within grace period (30 seconds) after receiving server re-authentication
notification, client session is refreshed. Server will repeat this re-auth mechanism until
Client/Server websocket disconnects or error cases.
Client Server
Successful Authentication
Start of gracetime(auth.timeout - auth.gracetime)
re-auth notification
{
"command": "server notification",
"command_ref": "authentication expiry",
"message": "Your authentication token is about to expire, please re-authenticate"
}
Auth
{
"command": "auth",
"args" :
{
"token": "TOKEN",
}
}
OK
{
"success": true
}
Start of gracetime(auth.timeout - auth.gracetime)
{
}
Client Server
Case 3 : Client re-auths before Gracetime
If client tries to get re-authenticated before receiving server re-authentication notification with
same user token, server will sends "User already authenticated" error message to client.
Client Server
Auth
{
"command": "auth",
"args" :
{
"token": "TOKEN",
}
}
User already authenticated
{
"success": false,
"error" :
{
"code": 500,
"status": "Server Error",
"message": "An error happened on our end, and it is not your fault.\n Please contact your TSS administrator to find out what may cause this issue",
"reason": "User already authenticated"
}
}
Client Server
Case 4 : Client fails to re-auth itself during Gracetime
Grace Time(60-30) = 30
If client did not re-authenticate within grace period (30 seconds) after receiving server re-
authentication notification, server will send session timed out notification and client session will
be disconnected. Client needs to connect to websocket again and start the new Authentication
process.
Client Server
After auth.timeout - auth.gracetime
{
}
After auth.gracetime
session timed out notification
{
"command_ref": "Session expired",
"message": "Session is expired"
}
session disconnected
Attempting for new session
Connect
Auth
{
"command": "auth",
"args" :
{
"token": "TOKEN",
}
}
OK
{
"success": true
}
Client Server
Case 5 : Client re-authenticates with different token
If client tries to re-authenticate within grace period (30 seconds) with a different token after
receiving server re-authentication notification, server will sends invalid token message to client.
Client Server
After auth.timeout - auth.gracetime
{
}
Attempting to re-authenticate with different token
Auth
{
"command": "auth",
"args" :
{
"token": "DIFFERENT TOKEN",
}
}
Invalid token
{
"success": false,
"error" :
{
"code": 498,
"status": " Invalid Token",
"message": "The client had not sent previously used token. If client needs new session, please disconnect and connect with new token"
}
}
Client Server
Case 6 : Settings Auth Gracetime is greater than Auth Timeout
This is not an expected configuration. However server will try to handle this. In this scenario, the
server will send re-auth notification immediately after the client has authenticated the session
and waits for grace period (30 seconds) to complete, if client re-authenticates within grace period
(30 seconds), server will send again re-auth notification immediately after re-authentication and
the process repeats.
Client Server
Immediately after authentication
{
}
Auth
{
"command": "auth",
"args" :
{
"token": "TOKEN",
}
}
OK
{
"success": true
}
Immediately after re-authentication
Client Server
Authentication Responses
Various responses from the server for authentication/re-authentication are shown as below,
After the successful Authentication , at the start of the GraceTime [AUTH_TIMEOUT -

AUTH_GRACE_TIME] , the client will receive a re-authentication notification from server as
shown below,
{
"message": "Your authentication token is about to expire, please re-
authenticate"
}
If Client reauths to re-authentication notification within the grace time period, the client
session will be refreshed,
{
"command_ref": "command reference",
"success": true,
}
If client reauthenitcates with different token than the one used for initial authentication,
server will respond with the following error
{
"command_ref": " command reference ",
"success": false,
"error":
{
"code": 498,
"status": " Invalid Token ",
"message": " The client had not sent previously used token. If client
needs new session, please disconnect and connect with new token "
}
}
If Client fails to reauthenticate within Gracetime, the client session will be disconnected and
all the subscriptions are cleared and server will send a notification as shown below
{
"command_ref": "Session expired",
"message": "Session is expired"
}
Errors
This command may return the following error messages:
The client had not sent previously used token. If client needs new session, please disconnect
and connect with new token
Invalid token reasons can be:
Mismatch between auth token and re-auth token

Commands
The TradeSense WebSocket API commands allows to:
fetch data from the Assure database

call a service (e.g. CTD)
subscribe to notifications
Client Server
Authentication
phase ends
Command
{
"command": "command type",
"args" :
{
...
}
}
Response
{
"success": true,
"data" :
{
...
}
}
Client Server
After successfully completing the authentication phase the client is allowed to send commands to
the Server:
{
"command":"command type",
"args":{}
}
Mandatory:
command : type of the command;
command_ref : the reference of the command is a string value generated by the client-side.
This reference is used to identify the response linked to client's request;
Optional:
args : command arguments.
Fetch data
Available commands:
get_zones
get_turrets
get_users
get_events
get_calls
Get Zones
Retrieves data for all the Zones monitored by Assure.
{
"command":"get_zones",
"args":{}
}
The response from the server will contain a list of Zone objects.
{
"success":true,
"data":{
"zones":[
{
"id":"003O90001",
"name":"Zone Assure (emtpy)",
"locationCountryCode":null,
"locationRegion":null,
"locationCity":null,
"callPrefix":null
},
{
"id":"003NV0001",
"name":"Assure (Verba)",
"locationCountryCode":"BE",
"locationRegion":"Province de Liège",
"locationCity":"Huy",
"callPrefix":"04"
}
]
}
}
Optionals arguments
{
"command":"get_zones",
"args":
{
"search": "value",
"operator": "contains",
"limit": response limit
}
}
search : search (string)

operator : specify search operator (string)
limit : limit the number of records returned (integer)
Available operators are is_exactly , contains , begins_with . Default is contains .
The TradeSense WBA will return all the entries which satisfies the search arguments.
The scope of the search is limited on:
Zone name
Errors
Parameter search is not a valid string

Parameter operator is not a valid string
Parameter limit is not a valid integer
Get Turrets
Retrieves data for all the Turrets monitored by Assure.
{
"command":"get_turrets",
"args":{}
}
The response from the server will contain a list of Turret objects.
{
"success":true,
"data":{
"turrets":[
{
"name":"T4-LOADTEST1",
"alive":true,
"tssVersion":"default",
"zone":"Assure (Verba)",
"username": "612341089",
"firmwareVersion":"R9.3_5.50278",
"firmwareTargetVersion":null,
"model":"1015"
},
{
"name":"T4-LOADTEST2",
"alive":true,
"tssVersion":"default",
"zone":"Assure (Verba)",
"username": null,
"firmwareVersion":"R9.3_5.50278",
"firmwareTargetVersion":null,
"model":"1015"
}
]
}
}
The property "firmwareTargetVersion" is the target version for upgrade. This property will
be set only pending upgrade process.
Optionals arguments
{
"command":"get_turrets",
"args":
{
"search": "value",
"operator": "begins_with",
}
}

Turret name
Errors
Get Users
Retrieves data for all the Users linked to the Zones managed by Assure.
{
"command":"get_users",
"args":{}
}
The response from the server will contain a list of Users objects with their lines.
{
"success":true,
"data":{
"users":[
{
"login":"612341089",
"firstName":"IPTNetrix1",
"lastName":"Turret1",
"turret": "T4-LOADTEST1",
"zone":"Assure",
"status":"ACTIVE",
"primaryLine":"+99999993201",
"profile":{
"lines":[
{
"userExtension": "+99999304300",
"userDisplayName": "PW 3043",
"lineType": "DDI",
"tpoDnsName": "dnsName",
"subscriptionState": "SUBSCRIBED",
"defaultGlobalLine": false,
"voiceRecording": true,
"place":{
"name": "placeName",
"type": "RINGDOWN_DYNAMIC",
"state": "STARTED",
"cluster": "clusterName",
"groupId": 1234
},
"slots": [
{
"slot": "304301",
"label": "ARD 304301",
"type": "PERMANENT",
"target": "304301@Vega400G02",
"mrd": true,
"ard": "FIRST_USER",
"answer_only": null (or true/false)
},
{
"slot": "304302",
"label": "MRD 304302",
"type": "PERMANENT",
"target": "304302@Vega400G02",
"mrd": true,
"ard": "ALWAYS",
"answer_only": null (or true/false)
}
],
"virtualSlotStart": null,
"virtualSlotEnd": null
},
]
}
}
]
}
}
Optionals arguments
{
"command":"get_users",
"args":
{
"search": "value",
"operator": "is_exactly",
}
}

User login
User firstname
User lastname
Errors

Get Events
Limitation
To prevent performance degradation over time, the application will only return the most recent
records. The default value is set to 2 days and can be overrided in application settings.
application.global.wba.db.fetch.max.interval
Using ID
The client-side are allowed to retrieve all the events by categories. Indicate the segment of events
using from_id and to_id keys. If to_id is not specified then all the events from indicated id will
be sent.
{
"command":"get_events",
"args":{
"category":"event category",
"from_id":event_id,
"to_id":event_id
}
}
category : events categories that the third party request
Possible values :
calls
presences
from_id : the id of the first element of the batch that the third party request
to_id : the id of the last element of the batch that the third party request
Using datetime
The client-side are also allowed to retrieve events by datetime. Indicate the segment of calls using
start_time and end_time keys.
{
"command":"get_events",
"args":{
"category":"event category",
"start_time":"datetime",
"end_time":"datetime"
}
}
category : events categories that the third party request
Possible values :
calls
presences
start_time : the datetime concidered as start
end_time : the datetime concidered as end
Response
The response from the server will contain a list of Event objects.
The event with asked from_id will be considered as already received by the third party, and
then will not be included in the returned batch. However the event with the to_id will be
included in the batch.
{
"success":true,
"data":{
"current_batch":1,
"last_batch":1,
"events":[
{
"event_id":event id,
"turret":"turret name",
"zone":"zone",
"login":"login",
"device":"HS1",
"microphone_state":"On",
"local_extension":"6018",
"remote_extension":"6017",
"call_direction":"OUTGOING",
"call_ref":"call ref",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
},
{
"zone":"zone",
"login":"login",
"device":"HS1",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
}
]
}
}
When making calls that return a large number of results as a list, WBA will page the result set in
batch of 100. The current and the last batch number will be referred in the data object.
{
"success":true,
"data":{
"current_batch":1,
"last_batch":10,
"events":[
{
"zone":"zone",
"login":"login",
"device":"HS1",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
},
{
"zone":"zone",
"login":"login",
"device":"HS1",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
},
"..."
]
}
}
Errors
Missing mandatory parameter: category

Parameter category is not valid
Parameter from_id is not a valid integer
Parameter to_id is not a valid integer
Parameter start_time is not a valid ISO8601 date
Parameter end_time is not a valid ISO8601 date
Can't use to_id without a from_id parameter
Can't use end_time without a start_time parameter
Can't mix from_id/to_id with start_time/end_time
Get Calls
Limitation
To prevent performance degradation over time, the application will only return the most recent
records. The default value is set to 2 days and can be overrided in application settings.
application.global.wba.db.fetch.max.interval
Using ID
The client-side are allowed to retrieve calls with corresponding events. Indicate the segment of
calls using from_id and to_id keys. If to_id is not specified then all the calls from indicated id
will be sent.
{
"command":"get_calls",
"args":{
"from_id":call id,
"to_id":call id
}
}
from_id : the id of the first call of the batch that the third party request
to_id : the id of the last call of the batch that the third party request
filter : request filtering of returned calls depending on their state
all (default)
in_progress
done
Using datetime
The client-side are also allowed to retrieve calls by datetime. Indicate the segment of calls using
start_time and end_time keys. Only calls started during the segment will be returned.
{
"args":{
"start_time":"datetime",
"end_time":"datetime"
}
}
start_time : the datetime concidered as start
end_time : the datetime concidered as end
all (default)
in_progress
done
Using call_ref
The client-side are also allowed to retrieve a single call by its call_ref .
{
"args":{
"call_ref":"2147491577@601602"
}
}
call_ref : the requested call_ref
Using filter
The client-side are also allowed to querry calls using filter.
{
"args":{
"filter":filter
}
}
all
in_progress
done
Response
The response from the server will contain a list with the call object and its events.
{
"success":true,
"data":{
"current_batch":1,
"last_batch":1,
"calls":[
{
"call_id":call id,
"call_ref":"2147491577@601602",
"login":"login",
"call_start_time":"2020-05-08T15:57:19Z",
"call_end_time":"2020-05-08T15:57:24Z",
"sip_call_id": "3136a8e-735608ff-68c2e-919cfd0-a61ddd0a-13c4-759",
"events":[
{
"operation":"Ringing",
"device":"HS1",
"microphone_state":"Off",
"time":"2020-05-08T15:57:19Z"
},
{
"operation":"Connected",
"device":"HS1",
"time":"2020-05-08T15:57:19Z"
},
{
"operation":"Disconnected",
"device":"HS1",
"time":"2020-05-08T15:57:24Z"
}
],
"created_at":"2020-05-11T16:19:34Z"
}
]
}
}
Possible values:
device : turret audio device name where the call is actually hosted
HS1
HS2
LD1.1
LD2.4
microphone_state : state of the microphone
On
Off
Errors
Parameter from_id is not a valid integer

Parameter to_id is not a valid integer
Parameter start_time is not a valid ISO8601 date
Parameter end_time is not a valid ISO8601 date
Parameter call_ref is not a valid string
Filter parameter is not valid
Can't use to_id without a from_id parameter
Can't use end_time without a start_time parameter
Can't mix from_id/to_id with start_time/end_time
Can't mix from_id/start_time with call_ref
Can't mix filter with call_ref
Call a service
Available services:
ctd (Click To Dial)
Click To Dial
Remotely performs call actions on a turret.
The current version supports the following actions:
Resume a held call
Attended mode
Unattended mode
The server-side will respond to each command with an object data containing the call_ref .
This response doesn't mean that the command are actually executed by the turret but that the
command was successfully transmitted.
Initiating a new outbound call is requested with the following message:
{
"command":"service_ctd",
"args":{
"action":"place",
"login":"user login",
"remote_extension":"extension to call",
"local_extension":"Line",
"ddi_slot":"DDI slot extension",
"device":"device"
}
}
Mandatory:
action : category must be place

login : user login
Optional:
remote_extension : remote target phone extension to contact

local_extension : the extension of the line that will be used to host the call. If not set, then
the turret will automatically select a Slot and/or line.
ddi_slot : allows to set the DDI slot used to place the call, to join a DDI slot with parameter
or with a call already running.
device : The audio device that will be used to host the call: in the IPTrade turret audio
device format (HS1,HS2, LD1.1, LD2.4, …). If not specified, the turret uses the current selected
or active handset.
The remote_extension , local_extension and ddi_slot are all optional but at least one
parameter is necessary.
Permissible combinations:
remote_extension alone
remote_extension and local_extension
remote_extension and ddi_slot
ddi_slot alone
Limitation
Default settings will refresh data every couple of minute. In order to get real time data about line
registration state, target user must be configured with :
profile.setting.crm.linestate.enable = true
TPO place state is not updated in real time.

Local extension availability
Before placing the call, the application will check for local extension availability.
Possible errors are:
No line found for local extension

No line found for DDI slot
No default or primary line available
Local extension TPO place is not started.
Local extension is not registered.
Can't call remote_extension from the same extension
Outgoing call errors
An outgoing call can fail for practical reasons. In that case, an additional call event will be sent
with the failure reason in the state field.
These additional call events are not saved in assure or WBA. They are only here to notify
subscribers why the call cannot complete and to allow them to clear the call from the turret.
{
"event_id": null,
"turret": "TS-TURRET-01",
"zone": "Belgium - Liege - FHO",
"login": "fho3",
"device": "HS1",
"microphone_state": "OFF",
"local_extension": "6202",
"remote_extension": "6402",
"call_direction": "OUTGOING",
"call_ref": "2147483671@620202",
"state": "Extension has no free slot available",
"created_at": "2022-01-13T23:20:35Z"
}
Possible errors are:
Extension is unreachable
Extension has no free slot available
This is only available for turrets running firmware 9.5.12, 9.7.1 or later.
Response
The server will respond with an object data containing the call_ref . Subsequent actions or
notifications will use that reference to identify the call. The server will also provide
local_extension that will actually be used to host the call.
{
"success":true,
"data":{
"action":"place",
"local_extension":"Line or DDI slot extension"
}
}
Accepting an incoming call is requested with the following message:
{
"args":{
"action":"accept",
"device":"device"
}
}
Mandatory:
action : action must be accept

login : user login
call_ref : the reference of the call to accept
Optional:
device : The audio device that will be used to host the call: in the IPTrade turret audio
device format (HS1,HS2, LD1.1, LD2.4, …). If not specified, the turret uses the current selected
or active handset.
The user's line of the incoming call must be subscribed or monitored.
Holding an established call is requested with the following message:

{
"args":{
"action":"hold",
"call_ref":"call ref"
}
}
Mandatory:
action : action must be hold

login : user login
call_ref : the reference of the call to hold
Resume a held call
Resume a held call is requested with the following message:
{
"args":{
"action":"resume",
}
}
Mandatory:
action : action must be hold

login : user login
Terminate an opened call is requested with the following message:
{
"args":{
"action":"terminate",
}
}
Mandatory:
action : action must be terminate
login : user login
Dispatching request will transfer an opened call to a specified target extension without follow-up.
Requested with the following message:
{
"args":{
"action":"dispatch",
"remote_extension":"extension to call"
}
}
Mandatory:
action : action must be dispatch

login : user login
With the Transfer feature, an ongoing call can be transferred to another party. This can be made
in two different manner, attended or unattended mode.
Limitation
The transfer will only happen if:
The two calls are both DDI calls or non DDI calls
The two calls are established
For transfer off DDI calls from a non-default DDI line, please be aware that the target turret must
be configured with:
profile.setting.ddi.advanced.handling.on.all = true
Attended
Party A Party B Party C
Opened call
Party A is in a call
with Party B
Press the Transfer button
Held call for transfer
Party A can resume

the call if need.
Place a new call
Wait response from C
C Pick up the call
Opened call
Party A is now
removed from the
call between
Party B and Party C.
Opened call
Let’s say that Party A is in a call with Party B. To transfer the call to Party C, Party A will proceed as
follow:
{
"args":{
"action":"hold_transfer",
}
}
Established call with B must be held in special hold_transfer mode. Then establish a new call
using action new and the same local_extension as the transferred call.
{
"args":{
"action":"new",
"remote_extension":"extension to call",
"local_extension":"Line or DDI slot extension"
}
}
Mandatory:
action : action must be new as you need to establish a new call before performing the
transfer
login : user login
local_extension : the local extension must be the same as the one used for the
transferred call
As for the place call command, local extension availability will be verified.
When Party C will pick-up the call. A notification will be sent to the client-side with the reference of
the new call. To finish the transfer phase, send the action perform_transfer using both call ref.
{
"args":{
"action":"perform_transfer",
"call_ref_source":"call ref",
"call_ref_destination":"call ref"
}
}
Mandatory:
action : action must be perform_transfer

login : user login
call_ref_source : the reference of the source call for transfer
call_ref_destination : the reference of the target call
The source call for transfer is always the last call put on-hold with the hold_transfer mode. If
this call is terminated or resumed, the transfer is not available anymore, even if there are other
calls that have been previously put on-hold.
If the Party C do not pick up the call, Party A can resume the call and continue to talk to Party B.
Resume a held call is requested with the following message:
{
"args":{
"action":"resume",
}
}
Unattended
Opened call
with Party B
Held call for transfer
Party A can resume

the call if need.
Place a new call
Party A is now
removed from the
call between
Party B and Party C.
Wait response from C
C Pick up the call
Opened call
The only difference with the attended transfer is that Party A do not wait to establish the call and
perform the transfer directly after placing the call to Party C. Thus the party A will be removed
from the call and will not be able to resume it.

Limitation
The conference will only happen if:
The two calls are DDI calls

The two calls are established
The two calls are both hosted on handset audio devices: [“HS1”; “HS2”]
The turret is configured to allow merging DDI calls (See
profile.setting.ddi.conference.mode documentation)
with Party B
Opened call
with Party C
Opened call
Initiate Conference
A B and C
are in conference call
Opened conference call
Let's say A is in a call with B and with C, but B and C can't talk to each others. To start a
conference, Party A should initiate a conference call.
Initiate a conference call is requested with the following message:

{
"args":{
"action":"conference",
"call_ref_source":"call ref",
"call_ref_destination":"call ref"
}
}
Mandatory:
action : action must be conference

login : user login
call_ref_source : the reference of the first call to put in the conference (here call between
A and B)
call_ref_destination : the reference of the second call to put in the conference (here call
between A and C)
As for transfer, the conference must be performed on the same local_extension .
When the conference call will be established between all parties, only the call_ref_source will
be kept. The call_ref_destination will be terminated. call_ref_source will then be able to
host new participant.
Errors
These commands may return error messages :
Command_ref already in use

User not found
User is not logged to any turret
Turret not found
No call found with this call_ref
Unable to retrieve tradesense ip address
Place command may return additional error messages :
Clicktodial: Can't use local_extension and ddi_slot at the same time

Clicktodial: Can't use local_extension as only parameter
Transfer and Conference commands may return additional error messages :
No call found with this call_ref (source_call)

No call found with this call_ref (destination_call
If the configured time out interval for click to dial requests is reached (see settings section)
Click-to-dial: Request timed out

Subscribe to Notifications
Client Server
Command
{
"command": "subscribe",
"args" :
{
"category": "calls",
}
}
Response
{
"command": "return",
"success": true,
"data" :
{
"category": "calls",
"last_id": last id,
}
}
Client Server
The command subscribe will subscribe your client-side to the event bus. You can either listen to
all events or to a specific event category. If you want to listen to multiple event categories, you will
have to send multiple subscribe commands.
{
"command":"subscribe",
"args":{
"category":"events category"
}
}
Mandatory:
category : the category of events to subscribe on
The server will respond with a result message to indicate that the subscription is active.
{
"success":true,
"data":{
"category":"calls",
"last_id":last event id
}
}
Client-side will receive the last event id available on server-side. If this id is different from the last
received event, the client is able to request the server to re-transmit all the missed events (see
Get Events).
Available notification categories:
calls : receive all the notification for all alive calls and their state evolution
presences : receive all the notification for presence state on turret.
Errors
Missing mandatory argument: category

Unknown value provided for argument: category
Notifications
In order to avoid an overflow of notifications, TradeSense API sends notifications grouped by sets.
When a client-side is subscribed, server-side will send a message every second with all last
notifications received.
Calls notifications
TradeSense API allows third party to obtain contextual information to be eventually displayed
when a call is either on the active handset, in ringing state or in held state. To be able to monitor
all alive calls and their state evolution.
{
"command":"notify",
"data":{
"category":"calls",
"events":[
{
"zone":"zone",
"login":"login",
"device":"HS1",
"microphone_state":"ON",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
},
{
"zone":"zone",
"login":"login",
"device":"HS1",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
}
]
}
}
All the notifications will contain following data:
event_id : event id
turret : turret name
zone : turret's zone
login : user login
device : turret audio device name where the call is actually hosted
HS1
HS2
LD1.1
LD2.4
microphone_state : state of the microphone
ON
OFF
null
local_extension : local extension used for the call
remote_extension : remote called extension
call_direction : direction of the call
OUTGOING
INCOMING
call_ref : call reference
state : the current state of the call
Ringing
Connected
Held
Held Transfer
Disconnected
Dispatched
Transferred
In Conference
created_at : the exact time when the call switch to the indicated state
Outgoing call scenario
If A want to establish a call with B. For an outgoing call TradeSense WBA will notify all the
subscribers with following notifications:
In this scenario we consider that there is 2 separate Zones monitored by 2 separate

TradeSense WBA
Third party on A side send a request to initiate a new call from A to B. Here we will use DDI
slot id as local extension to specify the slot.
{
"command_ref":"201",
"args":{
"action":"place",
"login":"A",
"local_extension":"10001"
}
}
A response will be sent back to notify if the request was successfully took into account
{
"success":true,
"data":{
"action":"place"
}
}
All the subscribers on B side events will be notified with an incoming call event. Multiple
events messages will be sent if multiple users subscribe/monitor the line.
{
"command":"notify",
"data":{
"category":"calls",
"events":[
{
"event_id":1,
"turret":"Turret_B",
"zone":"Zone_Name",
"login":"B",
"device":"HS1",
"call_direction":"INCOMING",
"call_ref":"CALLREF01",
"state":"Ringing",
"created_at":"2020-05-07T18:13:03Z"
}
]
}
}
Third party on B side send a request to accept the incoming call. Here we will use DDI slot id
as local extension to specify the slot.
{
"args":{
"action":"accept",
"login":"B",
"device":"HS1"
}
}
{
"success":true,
"data":{
"action":"accept"
}
}
When B will pick up the call. All the subscribers on A and B side events will be notified with an
Connected call event.
On side A:
{
"command":"notify",
"data":{
"category":"calls",
"events":[
{
"event_id":1,
"turret":"Turret_A",
"zone":"Zone_NameA",
"login":"A",
"device":"HS1",
"state":"Connected",
"created_at":"2020-05-07T18:13:03Z"
}
]
}
}
On side B:
{
"command":"notify",
"data":{
"category":"calls",
"events":[
{
"event_id":1,
"zone":"Zone_NameB",
"login":"B",
"device":"HS1",
"state":"Connected",
"created_at":"2020-05-07T18:13:03Z"
}
]
}
}
Third party on side A sends a request to terminate the call with B
{
"args":{
"action":"terminate",
"call_ref":"CALLREF01"
}
}
{
"success":true,
"data":{
"action":"terminate"
}
}
As soon as the call is ended, all the subscribers on side A and B will be notified with an
Disconnected call event
On side A:
{
"command":"notify",
"data":{
"category":"calls",
"events":[
{
"event_id":1,
"turret":"Turret_A",
"zone":"Zone_NameA",
"login":"A",
"device":"HS1",
"state":"Disconnected",
"created_at":"2020-05-07T18:13:03Z"
}
]
}
}
On side B:
{
"command":"notify",
"data":{
"category":"calls",
"events":[
{
"event_id":1,
"zone":"Zone_NameB",
"login":"B",
"device":"HS1",
"state":"Disconnected",
"created_at":"2020-05-07T18:13:03Z"
},
"..."
]
}
}
Error handling
If 401 Unauthorized error response is received, then client needs to re-authenticate and subscribe
to notifications.
Presence notifications
TradeSense API will notify all the subscribers with a presence message that the user has just
performed a login or logout.
{
"command":"notify",
"data":{
"category":"presences",
"events":[
{
"zone":"turret's zone",
"state":"presence state",
"created_at":"datetime"
},
{
"zone":"turret's zone",
"state":"presence state",
"created_at":"datetime"
}
]
}
}
All the notifications will contain following data:
event_id : event id
turret : turret name
login : user login
state : the current state of the presence
created_at : the exact time when the presence switched to the indicated state

Presence state values
TradeSense API will notify all the subscribers with information about users presence on turrets.
The state value can be:
login : user is logged-in
logout : user is logged-out
Settings
It is possible to change default values by overriding the setting in the productivity tools clusters
TSS page.
Ping settings
The server needs to be restarted for the changes to take effect
To keep the connection alive, a ping mechanism is enabled by default server-side.
A ping frame will be sent every N seconds.
Enable the ping mechanism
Setting key Default value
application.global.wba.ping.enabled True
Configure the ping interval
application.global.wba.ping.interval 5 (in seconds)
Notifications settings
In order to avoid an overflow of notifications, WBA sends notifications grouped by batches. When
a client-side is subscribed, server-side will send a message every N milliseconds with all last
notifications received.
Configure the notification batch size on WBA
application.global.wba.notification.batch.size 100
Configure the notification delay on WBA
application.global.wba.notification.batch.delay 1000 (in milliseconds)

Time out settings
As we don't have feedback from the turrets, when using the click to dial service, we need to
monitor incoming events in order to be able to check if the request was executed.
Configure the time out interval for click to dial requests
This setting configure the time interval to wait for the event before sending an error message.
application.global.wba.ctd.monitoring.timeout 10 (in seconds)
Configure the polling rate interval for click to dial monitoring
This setting configure how often we check for timed out ctd requests.
application.global.wba.ctd.monitoring.poll.rate 1 (in seconds)
Configure the time out interval for requests
To avoid being overloaded by requests, incoming messages are only processed if not already
timed out.
This setting configure the time interval to wait for a regular request to be timed out.
application.global.wba.request.timeout 15 (in seconds)
Outdated data settings
Configure the fetch interval for WBA requests
To avoid too many records being returned, we set a maximum fetch interval in days.
Calls/events older than N days won't be fetched from database.
Setting key
application.global.wba.db.fetch.max.interval 2 (in days)
Support
Requirements
The application relies on data gathered from gecko and enriched through assure. Both of them
needs to be started and properly configured to report valid real time information and to monitor
the click to dial service.
Startup
The application won't allow user to connect until gecko is started, provisionned and his caches
updated. This can take a few minutes.
Provisioning
When performing assure first time configuration, gecko's address must be provided (the platform)
and assure will start retrieving data from gecko's api.
Data will be refreshed every minute.
Errors
No platform has been added in assure

Data provisioning still in progress - Please try again later
Since 9.5.11, authentication is prevented until provisioning is complete.
Commands
Log Level
When asking for support, the user will often be required to provide the logs of the application.
The loglevel command allows the user to get the current level and to change it.
Get the current log level
{
"command" : "loglevel",
"command_ref" : "command reference"
}
The response from the server will return the current level.
{
"command": "loglevel",
"args": {
"level": "DEBUG"
}
}
Change the log level
If the level argument is provided, the current level will be changed.
{
"command" : "loglevel",
"command_ref" : "command reference",
"args": {
"level": "info"
}
}
The response from the server will return the previous and current level.
{
"success": true,
"data": {
"previous_level": "DEBUG",
"current_level": "INFO"
}
}
Available levels
The available levels are warning , info , debug and error .
Errors
Unknown value provided for argument: level
Get Health
This support command provides information about data provisioning status.
Get the provisioning status
{
"command" : "get_health",
"command_ref" : "command reference"
}
The response from the server will return completion status for assure and gecko.
{
"success": true,
"data": {
"provisioning": {
"assure": {
"completed": true,
"last_refresh": "2021-09-24T12:00:00Z"
},
"gecko": {
"completed": true,
"recently_updated": true,
"max_age": 10
}
}
}
}
Information about gecko are read from its API health path.
Provisioning data items
completed : provisioning completion status

last_refresh : UTC datetime of provisioning completion or last data refresh
recently_updated : true if data has been updated less than max_age ago
max_age : maximum time frame between updates (in minutes)
Errors
Empty response from gecko

Unable to extract maxAge from gecko's response

Tradesense Wba Status Date

Uploaded by

Copyright:

Available Formats

Tradesense Wba Status Date

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tradesense Wba Status Date

Uploaded by

Copyright:

Available Formats

TradeSense WBA Status Date

V 9.5.1 Released 10/06/2020

V 9.5.2 Released 20/08/2020

V 9.5.3 Released 06/10/2020

V 9.5.4 Released 04/12/2020

V 9.5.5 Released 26/02/2021

V 9.5.6 Released 09/04/2021

V 9.5.7 Released 25/05/2021

V 9.5.8 Released 06/08/2021

V 9.5.9 Released 24/08/2021

V 9.5.10 Released 05/10/2021

V 9.5.11 Released 25/11/2021

V 9.5.12 Released 08/02/2022

V 9.5.13 Released 25/04/2022

V 9.5.14 Released 27/05/2022

V 9.5.15 Released 05/07/2022

The WBA allows to:

post Click To Dial (CTD) requests;

command : type of the command;

command : the command type of a notification message will always be notify

Code Status Message

401 Unauthorized You lack permissions to access this resource

We cannot find what you requested, though the request looks

An error happened on our end, and it is not your fault. Please

Bad request reasons can be :

Unable to deserialize message

Request timed out

Connect your implementation to:

Use the token to authenticate your client-side application

User already authenticated

This is time duration

This is a time in seconds

Note : By default(value of 0), reauthentication mechanism will be disabled, so it will be backward

The value of Timeout should always be greater than Gracetime.

Case 1 : Settings Auth Timeout and Auth Gracetime are neither

The re-authentication process is disabled, client authentication cycle is as same current

Case 2 : Client Re-auths within Gracetime

Start of gracetime(auth.timeout - auth.gracetime)

Start of gracetime(auth.timeout - auth.gracetime)

User already authenticated

Case 4 : Client fails to re-auth itself during Gracetime

After auth.timeout - auth.gracetime

session timed out notification

Attempting for new session

After auth.timeout - auth.gracetime

Attempting to re-authenticate with different token

Immediately after authentication

Immediately after re-authentication

After the successful Authentication , at the start of the GraceTime [AUTH_TIMEOUT -

Invalid token reasons can be:

Mismatch between auth token and re-auth token

fetch data from the Assure database

args : command arguments.

Retrieves data for all the Zones monitored by Assure.

search : search (string)

Available operators are is_exactly , contains , begins_with . Default is contains .

The scope of the search is limited on:

This command may return error messages :

Parameter search is not a valid string