Some tips when working with WTI

[flynn1]

WTI provides both a REST and Websocket mechanism to interact with Avaya Aura Communication Manager, via Avaya Aura Application Enablement Services. It replicates functions that are provided by DMCC and TSAPI. Using WTI, an application can perform several functions. These can be grouped into two categories - Call Control (aka Third-Party) functions and First-Party functions:

Call Control Functions:

• Monitor stations and VDNs for Call-related events
• Monitor Hunt Groups (skills) for Agent Login/Logout events
• Make/Control calls to/from a station
• Change Agent state
• Query certain information about a device, agent or call
• Perform Adjunct Routing
• Miscellaneous other functions

First-Party Functions:

• Register a DMCC terminal at a station ID
• Perform device-level functions such as taking the terminal on/off hook, pressing buttons etc.
• Monitor for device-level events such as lamp mode changes, display changes etc.
• Inject media into a call
• Receive media from a call

WTI relies on DMCC for its functions. In turn, DMCC relies on TSAPI for the Call Control functions. Therefore, anyone using WTI will need to become familiar with both of these interfaces.

Useful Documents
WTI developers will really benefit from the information in the DMCC and TSAPI programmers guides. Unfortunately, they are too large to attach here and are not currently available on the Devconnect website. You can, however, download them from the Avaya support site, though this process is not trivial. You will first need to sign up to and login with an Avaya SSO account. Click the Sign In link on the top right to begin this process.

Once you have signed on, browse to https://support.avaya.com/support/en/documents and enter the following search terms:

• Search Product - Application Enablement Services
• Select Release - 10.2.x
• Enter Keyword - TSAPI
• Select Content Type - Application & technical Notes.

Click the magnifying glass after Application Notes|Application & Technical Notes. The documents you want are:

• Avaya Aura® Application Enablement Services TSAPI for Avaya Communication Manager Programmers Reference
• Avaya Aura® Application Enablement Services Device, Media and Call Control API XML Programmer’s Guide

Tracing
For troubleshooting, you will almost certainly need to use server-side traces on AE Services. Enable traces via the AE Services Web Management Console, https://<AES IP-Address>. Use the Status -> Log Manager -> Trace Logging Levels menu. Set all the DMCC traces to FINEST. Change TSAPI Service to Everything.

The Following trace files will then be populated:

• WTI - /var/log/avaya/aes/telrestsvc.log
• DMCC - /var/log/avaya/dmcc-trace.log
• TSAPI - /var/log/avaya/aes/TSAPI/csta_trace.out & /var/log/avaya/aes/TSAPI/g3trace.out

Useful Tool
The DMCC .Net SDK (free download from https://www.avaya.com/en/partners/devconnect/program/) includes the DMCC Dashboard. This will allow you to perform DMCC requests without having to write code. While it does not use WTI, the flow and format of DMCC messages are very similar to WTI so you should find this very useful as a learning tool.

Martin

[avc859587618170]

This is great info Martin! Thank you!!

[flynn1]

DeviceIDs

Most WTI requests will refer to one or more devices (Station, VDN, Customer number, etc.). To do this, an application will require an ID for the device.

DMCC, and therefore WTI, uses two types of device ID:

• DeviceID. This is used for First-party features (anything that requires the application to register a terminal) or to start a monitor. You must use /api/fe/v1/GetDeviceId to get a DeviceID.
• Third-Party DeviceID. This can be used for Call Control requests. You can get a Third-Party DeviceID with any of the following methods:
  • Use /api/fe/v1/GetThirdPartyDeviceId
  • "Harvest" it from an incoming Call Control event
  • It is also possible to use a (First-Party) DeviceID for call control functions

(First-Party) DeviceIDs and Third-Party DeviceIDs are very similar in form. The main difference is that a DeviceID contains a Device Instance. This is a number between 0 and 9. If you leave it out, it defaults to 0.

When an application gets a Device ID instance, that instance & device combination is not available to other applications. This means that, for each station, there can be up to 10 DeviceIDs used by different applications (sessions). So, say two applications want to monitor station 5000. One application could get DeviceID for 5000 using deviceInstance 0. This means that the other application would need to use a different deviceInstance.

If an application ends without releasing its device ID, the ID will remain 'blocked' until the session times out and AES releases it.

Examples:

Request: https://<aes>/api/fe/v1/GetDeviceId

{
"deviceInstance": 1,
"extension": 50500,
"switchName": "cm181"
}

Response:

{"GetDeviceIdResponse": {"device": "50500:CM181:0.0.0.0:1"}}

Request: https://<aes>/api/fe/v1/GetThirdPartyDeviceId

{
"extension": 50501,
"switchName": "cm181"
}

Response:

{"GetThirdPartyDeviceIdResponse": {"device": "50501:cm181::0"}}

You can get more information in Device IDs in one of the DMCC Programmers Guides.