Keep Monitor alive and validate for incomming calls

[avc866856278884]

A few issues I am facing related to the monitor and incomming calls:

Issue 1:
For what I understand, the Monitor is stopped when the application session expires. Is this correct?

If so, is there a way to extend the duration of the monitor?
The "sessionDuration" property is taken in consideration on ApplicationSession for the monitor? Even if the response says "actualSessionDuration": 300?

Issue 2:
I am not being able to use the GetMonitorList to check for active monitors, for a specific token/session. I'm allways getting the error: { "stateIncompatibility": "invalidDeviceState" }
Is this the expected usage of this method?
If not, I have to keep track of all active monitor sessions and how they will end? Or is there any other way of doing this?

Issues 3:
To keep in sync both my integration and the AES, I am trying to validate if a device has incomming calls and get information about that call, so:

For what I've seen the GetRingerStatus, should allow me to get information if a specific device is currently ringing. Correct?
If not, is there any other way to know if a device is currently ringing? And get information about that incomming call?

Issue 4:
Following the issue 3, I am not being able to get a correct response from this method. Allways getting: { "operation": "invalidDeviceID" }

[flynn1]

Issue 1:
If a session times out, all resources (DeviceIDs, Monitors and Terminal Registrations) will expire some time later. In order to keep a session active, the application must call /api/fe/v1/ResetApplicationSessionTimer periodically. You will get more information on this topic in the "Maintaining a Session" section of the DMCC Programmers Guide.

Issue 2:
transferMonitorObjects, getMonitorList & getDeviceIdList send their data as a series of events. Therefore, an application must first start an appropriate monitor. Otherwise, they return an error such as you are getting. example:

Sending WTI request to AES using direct method: MonitorStart
{
"extensions": {"privateData": {"private": {"AvayaEvents": {
"invertFilter": true,
"deviceServices": {
"transferMonitorObjects": true,
"getMonitorList": true,
"getDeviceIdList": true
}
}}}},
"monitorObject": {"deviceObject": ""},
"targetUrl": "http://<My Events URL>"
}

Issue 4:
GetRingerStatus is a First-Party feature so, to use it, you must first register a Terminal for that Device ID..

Issue 3:
Alternatively, you could use the Call Control function, SnapshotDevice. I am not sure if it gives enough information to know if the call is incoming or outgoing but I think the first state in localCallState is always the snapshot device.

Sending WTI request to AES using direct method: SnapshotDevice
{"snapshotObject": "50500:CM181::0"}

Response:
{"SnapshotDeviceResponse": {"crossRefIDorSnapshotData": {"snapshotData": {"snapshotDeviceResponseInfo": {
"connectionIdentifier": {
"callID": 2594,
"deviceID": "50500:CM181::0"
},
"localCallState": {"compoundCallState": {"localConnectionState": [
"alerting",
"connected"
]}}
}}}}}

[avc859587618170]

So far as the ringer status, here's what I get when I'm monitoring a station and I call my Avaya One-X with my cell phone. It comes through as a broadcaststationevent, and the field: "localConnectionInfo": "alerting", is showing my phone is ringing.. Is that what you were looking for? Below is the payload I got:

BroadcastStationEvent: {
  "DeliveredEvent": {
    "callLinkageData": {
      "globalCallData": {
        "globalCallLinkageID": {
          "globallyUniqueCallLinkageID": "00036022731725474477"
        }
      }
    },
    "trunkGroup": 1,
    "monitorCrossRefID": 10,
    "cause": "newCall",
    "networkCalledDevice": {
      "notKnown": ""
    },
    "channelType": "VOICE",
    "callingDevice": {
      "deviceIdentifier": "3138675309:RCD2CM2ACT81T::0"
    },
    "callCharacteristics": "",
    "trunkMember": 1,
    "alertingDevice": {
      "deviceIdentifier": "3135551212:rcd2cm2act81t:0.0.0.0:1"
    },
    "lastRedirectionDevice": {
      "notKnown": ""
    },
    "localConnectionInfo": "alerting",
    "calledDevice": {
      "deviceIdentifier": "3135551212:rcd2cm2act81t:0.0.0.0:1"
    },
    "connection": {
      "callID": 2980,
      "deviceID": "3135551212:RCD2CM2ACT81T::0"
    },
    "distributingVDN": {
      "notKnown": ""
    },
    "distributingDevice": {
      "notKnown": ""
    },
    "networkCallingDevice": {
      "notKnown": ""
    },
    "originalCallInfo": {
      "reason": 0,
      "callLinkageData": {
        "globalCallData": {
          "globalCallLinkageID": {
            "globallyUniqueCallLinkageID": "00000000000000000000"
          }
        }
      }
    }
  },
  "timestamp": 1725474477362
}

Dave

[flynn1]

Correct Dave,

Monitoring a station is the preferred way to keep track on what's going on. The resulting events will give an application real-time information about what's happening.

It is possible to register a terminal and use a first-party monitor to keep track on what's happening at the terminal (lamps, display, hook-state, ringer, media etc.). Alternatively, use a Call Control monitor to get call-related events, as you have done here.

BTW, where did "BroadcastStationEvent" come from? It's not part of the WTI data.

Martin

[avc859587618170]

Oh.. heh.. I forgot. That's from the Post endpoint I created to get events. It's the line in my broadcast method that sends a message to all connected clients using SignalR. Until you pointed it out, I never realized the name I gave it became part of the json!

            // Broadcast the message to all clients
            Clients.All.SendAsync("BroadcastStationEvent", message);

Dave

[avc866856278884]

Issues 1, 2
Related to the issue 1, I havn't found any reference for the /api/fe/v1/ResetApplicationSessionTimer method, not even in the swagger for the 10.2.X,
Is this something new or maybe missing documentation?

I only saw documentation for ResetApplicationSessionTimer in the DMCC document, but nothing I could use through the WTI API.

Issues 3, 4
Related to the issues 3 and 4, SnapshotDevice solved the syncronization between the AES and my application.

For context:
I am developing a web application that is connected to the AES to get call notifications, answer calls and finish calls.
For that I have an integration that is connected to the web clients through SignalR like avc859587618170.
This integration also keeps track of active calls, so to prevent miss calls I need to keep the monitor alive.

[avc866856278884]

Ok, me again

It seems that I have the ResetApplicationSessionTimer giving me an Ok response,
I'll be testing this and come back to you

[avc859587618170]

Ok, me again

It seems that I have the ResetApplicationSessionTimer giving me an Ok response,
I'll be testing this and come back to you

Good news!!