Get information about any current call for an extension

[avc866856278884]

I am trying to get information on any active call for a specific agent,
I were taking a look at the methods

* api/fe/v1/GetCall
* api/fe/v1/GetCallInformation
* api/fe/v1/SnapshotDevice

But there were some problems with each option:

* api/fe/v1/GetCall
Were not able to make it work, what's the correct body format?
Every try I got { "unspecified": "" }


* api/fe/v1/GetCallInformation
I get information about the call but not the number that originated the call.
The closest to that I see is recordingExtension, but I am not sure if this field is the correct one in case of a call from a public number


* api/fe/v1/SnapshotDevice
Gives me only the state of the current extension, but don't gives me information about the number that originated the call.


Maybe is there any other method I havn't check for that.
I am trying to get who initiated the call, when (date and time), if it's ringing or active, id of the call.

[jtb1]

In general with AE Services there must be a monitor on the station extension before the call arives for AE Services to provide calling party information. Communication Manager only provides the information to AE Services as the call is originating (pre answer - i.e., as the call is being delivered). I recall opening a support ticket about this over a decade ago and the response was 'working as designed'

[avc866856278884]

So, in summary if I loss from memory, for any reason that information, There is no way to retrive it again (after the new call event)?
A shame because in the context of a webapp, it will help to keep the sync between the AES and the application (if conextion loss for eg.)

Ok so I'll be looking for alternatives or reforce from our side...

Any sugestion will be wellcome
Thxs

[avc866856278884]

And what about the api/fe/v1/GetCall?
Anyone knows what is the correct structure? I am still not able to get a correct response and didn't found any documentation about it

[jtb1]

"if I loss from memory, for any reason that information, There is no way to retrive it again (after the new call event)?" that is not quite what I said, If there is a monitor on the extension then Communication Manager sends the information to AE Services where I believe it is cached and forwarded to the monitoring application(s). When there are queries (e.g. snapshot device), the information that AES has available for the call is added to what Communication Manager provides in response to the query and provided to the application. This is easilly tested with either the TSAPI or JTAPI exerciser. I believe the behavior is an encouragement to utilize monitors (which consume licenses which are held as long as the monitor exists) as opposed to doing everything via snapshot (which holds a license only for a short period).

The person on the DevConnect team that can answer your GetCall() question is on holiday till Jan 6th.

[jtb1]

In taking a look, GetCall() has precious little information irelated to it. While the response seems to include a list of participants, I expect it to fall short of your expectations/desires in the same ways as snapshotDevice will given the back end behaviors that can retrieve calling party information. I also don't see a GetCall() exposed in DMCC - thus my impression is it is either a placeholder method or something that should have been removed from the documentation. Note that the deviceID used in the getCall request must have been generated by an getDeviceID API call.


"GetCall": {
"type": "object",
"properties": {
"device": {
"$ref": "#/components/schemas/DeviceID"
}
},
"description": "",
"example": {}
},

"GetCallResponse": {
"type": "object",
"properties": {
"participants": {
"$ref": "#/components/schemas/DeviceID"
}
},
"description": "",
"example": {}
},

Hopefully you can be patient and wait for a better response from the SME after Jan 6th.

[flynn1]

I don't think GetCall actually exists. I get an unspecified error when I try to invoke it which is the same response I get when I send gibberish. There are a number of such errors in the json file. I have opened several MRs so hopefully, the next version will be better.
In general, if there is no DMCC equivalent for a WTI function, it does not exist.
Martin

[avc859587618170]

I see there is a /api/fe/v1/GetCallInformation endpoint, could you mean that one?

Dave

[flynn1]

It is possible to use api/fe/v1/SnapshotDevice to get the CallID in which the device is currently involved. Then use api/fe/v1/SnapshotCall to get information on the call.

I don't generally recommend the use of GetCallInformation as it does not always return correct information.

The best way to get the most accurate call information it to have a Call Control monitor on your stations and VDNs.