Answering a call using WTI services

[avc866856278884]

I am using the WTI that the AES provides to monitor a set of devices for changes,
when a notification of an incomming call is triggered, I should let the user answer that call from a web portal.

For that I am trying to make use of the /AnswerCall that the WTI provides.
But I am not undertanding how can I reference a specific call or a specific extension/device to be able to answer that call.

This portal I am working on, doesn't have an audio streamming, for that will be a softphone connected to an extension.
When the user answers the call from the portal, it should be answered in the softphone.

Maybe something there is something I am not seeing (not a lot of experiense with call centers).

[flynn1]

If you have a Call Control monitor on a station, you will receive a Delivered event whenever there is an incoming call to the station. It will look something like:

{
"DeliveredEvent": {
"callLinkageData": {"globalCallData": {"globalCallLinkageID": {"globallyUniqueCallLinkageID": "00081017211722265561"}}},
"monitorCrossRefID": 50,
"cause": "newCall",
"networkCalledDevice": {"notKnown": ""},
"channelType": "UNKNOWN",
"callingDevice": {"deviceIdentifier": "50501:CM181::0"},
"callCharacteristics": "",
"alertingDevice": {"deviceIdentifier": "50500:CM181:0.0.0.0:2"},
"lastRedirectionDevice": {"notKnown": ""},
"localConnectionInfo": "alerting",
"calledDevice": {"deviceIdentifier": "50500:CM181:0.0.0.0:2"},
"connection": {
"callID": 1721,
"deviceID": "50500:CM181::0"
},
"distributingVDN": {"notKnown": ""},
"distributingDevice": {"notKnown": ""},
"networkCallingDevice": {"notKnown": ""},
"originalCallInfo": {
"reason": 0,
"callLinkageData": {"globalCallData": {"globalCallLinkageID": {"globallyUniqueCallLinkageID": "00000000000000000000"}}}
}
},
"timestamp": 1722265564816
}

Note the Connection data. You can use the Call ID and device ID to answer the call using AnswerCall. E.g.:

Sending WTI request to AES using direct method: AnswerCall
{"callToBeAnswered": {
"callID": 1721,
"deviceID": "50500:CM181::0"
}}

[avc866856278884]

Using the method AnswerCall with that body, I am getting an error (link to the json api response),
Is a really long stacktrace, but maybe someone could give me some insight.

Json response:

https://drive.google.com/file/d/1-lMu4SHq4xGdnl-Zjshxl9VfeE_Uz0fB/view

[flynn1]

Can you show us the request that you actually sent?

In https://support.avaya.com/forums/for...rking-with-wti, there is information on how to enable tracing on AES. These traces should give you a better indication of what is going on.

Martin

[avc866856278884]

I will be trying to get access to the AES logs, but while I am at it,

This is the request,

POST api/fe/v1/AnswerCall
{
"callToBeAnswered": {
"callID": 11010,
"deviceID": "4200:CM::0"
}
}

And this is the monitor event I got before making the AnswerCall request

{
"DeliveredEvent": {
"callLinkageData": {
"globalCallData": {
"globalCallLinkageID": {
"globallyUniqueCallLinkageID": "00555110101724281272"
}
}
},
"monitorCrossRefID": 41,
"cause": "newCall",
"networkCalledDevice": {
"notKnown": ""
},
"channelType": "UNKNOWN",
"callingDevice": {
"deviceIdentifier": "2481:CM::0"
},
"callCharacteristics": "",
"alertingDevice": {
"deviceIdentifier": "4200:CM:AES02:0"
},
"lastRedirectionDevice": {
"notKnown": ""
},
"localConnectionInfo": "alerting",
"calledDevice": {
"deviceIdentifier": "4200:CM:AES02:0"
},
"connection": {
"callID": 11010,
"deviceID": "4200:CM::0"
},
"distributingVDN": {
"notKnown": ""
},
"distributingDevice": {
"notKnown": ""
},
"networkCallingDevice": {
"notKnown": ""
},
"originalCallInfo": {
"reason": 0,
"callLinkageData": {
"globalCallData": {
"globalCallLinkageID": {
"globallyUniqueCallLinkageID": "00000000000000000000"
}
}
}
}
},
"timestamp": 1724270841538
}

[flynn1]

Your AnswerCall looks OK but the alertingDevice and calledDevice in the Delivered event looks weird. I can't think of any way to get a DeviceID of 4200:CM:AES02:0. The "AES02" part would normally be 0.0.0.0 or, depending on the configuration, the IP Address of Communication Manager.

How did you generate the DeviceID you used when starting the monitor?

[avc866856278884]

I have them assigned to each user in my application like that.
The knowledge I have is that this is the current configuration in the AES: "4200:CM:AES02:0" (this is the device Id I use in the monitor also)

Bu I was able to solve my problem and now I have the AnswerCall working as expected.

-----------------------------------
Other question I have related to answer/clear calls
In the case of the ClearCall the body is the same structure? Or maybe has some variation?
Or is it the correct method to release a current call?

Srry for all this basic questions, but I am not being able to find updated documentation for the WTI

[flynn1]

You should not generate DeviceID strings manually. You must use getDeviceID.

Clear Call body looks like:

{"callToBeCleared": {
"callID": 1327,
"deviceID": "50500:CM181::0"
}}

The thread I linked previously shows how to get the DMCC and TSAPI programmers guised from support.avaya.com. You will need these documents. WTI documentation, such as it is, will never fully reproduce all the information that is in these.

I also suggest that you get and use the DMCC Dashboard to manually test DMCC function calls. DMCC is XML based but the data it contains is almost exactly the same as WTI.

[avc866856278884]

About the GetDeviceId,

yes that was the first approach, but every time I started getting the error: { "systemResourceAvailibility": "resourceBusy" }
And didn't find a reason or a way to solve it. Only after some time this gets fixed by itself (or at least it seems). So for the time being, I started storing the deviceId's.

The strange thing is that this error does not happened if I make the request from applications like postman, so clearly I am doing somthing wrong but can't find out what.
Probably I'll be opening another thread to this specific problem.

About the link you sent I am taking a look at that documentation, but to make things a little more chalenging, I dont have direct access to the AES, only through a third party team. So if required it usually takes some time to get access to logs 😞

[flynn1]

One of the parameters to getDeviceID is deviceInstance. 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.

I suspect that you are not providing a deviceInstance when you getDeviceID and so you are always using instance 0. If an application ends without releasing its device ID, the ID will remain 'blocked' until the session times out and AES releases it.

[avc866856278884]

You were right, I was mixing some instance ids between two environments.

Thanks a lot, I've was able to get all this flow working as expected.
A few details but better in another thread.