/fe/v1/MonitorStop

with body:
{"monitorCrossRefID": 121}

As I said, the Swagger document is not complete. I would suggest checking out the DMCC documentation. The function calls are almost exactly the same* - just using JSON instead of XML.

* there are some differences where WTI uses a simplified data format. E.g. A DMCC DeviceID looks like:

<monitorObject>              

        <deviceObject mediaClass="notKnown" typeOfNumber="other">50500:CM181:0.0.0.0:3</deviceObject>

</monitorObject>

while WTI looks like:

"monitorObject": {"deviceObject": "50500:CM181:0.0.0.0:3"},

Ignore all APIs except /fe/v1/.. They are deprecated and are from a previous effort which has been replaced by WTI.

The only documentation directly for WTI is the Swagger file. Unfortunately, it is not 100% accurate.

Anyone developing with WTI will need to refer to the DMCC Programmers Guide (e.g. "Avaya Aura® Application Enablement Services Device, Media and Call Control API XML Programmer’s Guide"). If you use Call Control features, you should also refer to "Avaya Aura® Application Enablement Services TSAPI for Avaya Communication Manager Programmer’s Reference".

Martin

Using the AES web manager, click the "Communication Manager Interface -> Switch Connections" menu. Select your Switch Connection and click "Edit Signaling Details". You should see the IP address of your CM listed. If not, type it into the box and click "Add Name or IP".

Go back to the Switch Connection list and click the "Edit PE/Clan IPs" and do the same thing.

If you make any changes, you will need to restart DMCC via the "Maintenance -> Service Controller" menu.

Martin

That doesn't look right. I think your Switch Connection may not be configured correctly on AES.

The name you put into the "switchName " field must be the same as the name of the Switch Connection that you configured on AES and you should configure it with a "PE/CLAN IP address" that is the IP address of CM. The same IP address must be added as a Gatekeeper using the "Edit Signaling Details" button.

Martin

Show me your GetDeviceId request.

Show me your GetDeviceId.

SSH to AES (like you did to see the logs) and run the command "swversion". Make sure you are at 10.2. Only a small number of features were implemented in 10.1.

Martin

Firstly, you MUST use GetDeviceId or GetThirdPartryDeviceId to get a device ID from AES. For example:

Sending WTI request to AES using direct method: GetDeviceId
{
"deviceInstance": 3,
"extension": 50500,
"switchName": "cm181"
}
======== Incoming WTI Response =============

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

You can then use the returned ID in further API calls:

Sending WTI request to AES using direct method: GetAgentState
{"device": "50500:CM181:0.0.0.0:3"}
======== Incoming WTI Response =============

{"GetAgentStateResponse": {
"pendingReasonCode": 0,
"workMode": "auxWork",
"talkState": "idle",
"agentStateList": {"agentStateEntry": {
"agentInfo": {"agentInfoItem": {
"agentState": "agentNotReady",
"pendingAgentState": "agentNull"
}},
"loggedOnState": true
}},
"reasonCode": 0
}}

WTI is basically a wrapper for DMCC. In turn, DMCC, relies on TSAPI for Call Conttrol functions. Therefore, in order to be able to use WTI, you will need to get a copy of the following documents from the Devconnect website (or google):

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

The monitor you tried to start is a Call Control monitor, so, you should refer to the "Monitor Device Service" section of the TSAPI PG. According to this:

GENERIC_SUBSCRIBED_RESOURCE_AVAILABILITY (41)

The request has failed for one of the following reasons:
o A required feature has not been provisioned or enabled. For example:
- The deviceID corresponds to a station with type CTI and the CTI Stations feature is not enabled on Communication Manager.
- The deviceID corresponds to a non-CTI station administered without hardware (AWOH) and the Phantom Calls feature is not enabled on Communication Manager.
- The deviceID corresponds to a SIP station, and the "Type of 3PCC Enabled" administered for the station is not set to "Avaya".
- The device ID corresponds to a SIP station, and there is an off-pbx-telephone station-mapping administered for deviceID on Communication Manager.
o The TSAPI Service could not acquire the license(s) needed to satisfy the request.

So, the most likely reasons are that you do not have a free TSAPI Basic license OR you are monitoring a SIP station and have not set the 3PCC parameter.

Martin

Yeah, there seems to be an error with MonitorStart. I think AES is now right and the json file is wrong. The format that works (AES 10.2 and later) is:

{

        "extensions": {"privateData": {"private": {"AvayaEvents": {

                "logicalDeviceFeaturePrivate": {"agentLoginExtension": true},

                "endpointRegistrationStateEvents": {

                        "registered": true,

                        "unregistered": true

                },

                "callControlPrivate": {

                        "isAaapCallControlRequired": false,

                        "serviceObserveState": true

                },

                "invertFilter": true

        }}}},

        "monitorObject": {"deviceObject": "50501:CM181:0.0.0.0:3"},

        "targetUrl": "http://<My Event URL>/events",

        "requestedMonitorFilter": {

                "physicalDeviceFeature": {"messageWaiting": true},

                "callcontrol": {

                        "established": true,

                        "conferenced": true,

                        "transferred": true,

                        "held": true,

                        "queued": true,

                        "delivered": true,

                        "retrieved": true,

                        "failed": true,

                        "connectionCleared": true,

                        "originated": true,

                        "diverted": true,

                        "serviceInitiated": true,

                        "networkReached": true

                },

                "logicalDeviceFeature": {

                        "agentLoggedOff": true,

                        "agentLoggedOn": true,

                        "doNotDisturb": true,

                        "agentWorkingAfterCall": true,

                        "agentNotReady": true,

                        "agentReady": true,

                        "forwarding": true

                }

        }

}

Note:
1. There is no "MonitorStart" object wrapper
2. monitorObject, targetUrl, requestedMonitorFilter and extensions (with the proprietary filter options) are all on the same level

MR for this is AES-33461

Sorry, I was away for a few days.

I am able to reproduce your issue so it looks like an incompatibility has crept in between DMCC 10.0.1 and AES 8.x. You will need to stay with DMCC 8.x.

I will open a bug report for this but it will be some time before this would be resolved, it at all.

Martin

I don't see that problem with DMCC 10.1.0.2 and AES 10.1.2. There can be a problem when DMCC & AES communicate using a version of the DMCC protocol that is older than the DMCC client. Normally the problem is that the application classpath does not including the XML files from the "mapping" folder in the lib but, occasionally, there can be a bug.

What version of AES are you using and, most important, what version of the DMCC protocol has been negotiated when you started the Application Session? You will need to check the StartApplicationSessionResponse to see this. The easiest way is to check the DMCC traces on AES.

Martin

Make sure the WTI service is in the "Running" state. Use the AES web interface, menu Maintenance -> Service Controller. If WTI is stopped, start it. If it is "Ready" (I think), restart it.

Martin

For the trace issue, make sure you are using the correct version of the log4j libraries for the version of the DMCC client you are using. Avaya changed to log4j v2 some time ago. It is possible that you are still using the old version.

Martin

Make sure you are trying to connect to port 4722 and not 4721.

Also, use Wireshark to check the handshaking as the TLS connection is setup. If there is a certificate error, you should be able to get an idea as to what it is.

Martin