Hello,
I previously have used Avaya DMCC to monitor call events on different avaya hardphones..
Now my goal is to track calls on level higher, n the moment they come in vdn before routing.
I tried this:

tpc.StartMonitor("11111111", callControlEvents, null);

where

tpc = new ThirdPartyCallController()

and

var callControlEvents = new ThirdPartyCallController.ThirdPartyCallsViaDeviceCallControlEvents(false)

            {

                EstablishedEvent = true, // answer

                ConnectionClearedEvent = true,

                DeliveredEvent = true,

            };

I get the respons from server :

<?xml version="1.0" encoding="UTF-8"?><CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><unspecified /></CSTAErrorCode>

Except for the extension, i have changed nothing else from previous configuration where i monitored avaya hardphone's extension..
I am using PROTOCOL_VERSION_6_3_3 ..

Is this the wrong way how to configure monitoring a vdn? If yes, where can i find an example or even full documentation for this?

Thank you in advance
Esmeralda

Your number, "11111111", is incorrect. You must do a GetDeviceID or GetThirdPartyDevceID and toString() the returned value.

Martin

The number "11111111" it's just an example, in my code i am using a real number (extension) ..

When trying this :

Console.WriteLine(tpc.GetThirdPartyDeviceId("DEFFMAES05", "39056200", null).ToString());

i get written in the console the number 2..

The value you are printing there (2) is the Invoke ID of the XML message sent to the server.

In order to get the actual third party device ID, you must setup a callback function. The Device ID will be sent to it asynchronously. This is described in the programmers guide.

Martin

Thinking that i was making a mistake from code, i tried it from DMCC dashboard but i get a "securityViolation" response from AES.
This is the response :

Incoming XML 42 
<?xml version="1.0" encoding="UTF-8"?>
<CSTAErrorCode xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <operation>securityViolation</operation>
</CSTAErrorCode>

While googling i found out this :
" 19 The request violates a security requirement. State Incompatibility Errors "

EDIT :
Also found this one :
"19. Security Violation. The request violates a security requirement."

What could be the meaning of this?

securityViolation usually means that the request is being blocked by the Security Database (SDB) on AE Services.

On the AE Services Web interface, use the Security -> Security Database -> Control menu. If the SDB is enabled for DMCC or TSAPI, disable it. Then restart AE Services using the Maintenance -> Service Controller menu.

Martin

Hi Martin,
I found that i had a problem in configuration.. Fixing it, it worked.

Also, wanted to ask, how many VDN extensions can i monitor at the same time?
Can i monitor let's say 100 VDNs? at the same time?
I want to do something like this

var lines = File.ReadLines(pathOfFile);

            foreach (var line in lines)

            {

                try

                {

                    tpc.StartMonitor(line, callControlEvents, null);

                    Console.WriteLine($"Started monitoring extension {line}");

                }

                catch(Exception ex)

                {

                    Console.WriteLine($"{ex}");

                }

            }

Where "line" is an extension...

I believe it is possible to monitor several thousand VDNs so 100 will not be a problem.

Martin

When creating the monitors on the VDNs (or any other type of request), do not blast out 100 StartMonitor's back to back. An application should limit itself to 10 outstanding requests at any one moment in time, when it gets a response with the monitorID, it can initiate another StartMonitor. Since the AES is a shared (multiplexing) resource, all applications should insert real-time breaks to avoid flooding the AES/CM AEP/DAPI channels with those requests.

I see. Then how do i wait for a response with monitorID?

Martin can tell you best - 'real' code is no longer my forte, but I believe the monitorID comes via a call back that you provide with the StartMonitor request. You will need the monitorIDs to associate events that are being reported as occurring at the VDN with the specific VDN that the monitorID relates to.

Thank you John! I implemented it and it works fine.
I also wanted to ask if there is anything else that maybe i need to keep in mind when monitoring too many VDNs at the same time?
Any issue or problem i should avoid? Any advices? :)

Thanks in advance!

One thing of which you should be aware is that there is a limit to the number of messages per second that can be passed between AE Services and Communication Manager. You can find details in the "System capacities – Communication Manager" section of "Avaya Aura Application Enablement Services Overview and Specification". Having a large number of VDN monitors may lead to a large number of messages.

Also, make sure your application is designed to handle a large number of events. The event callback functions are run using a thread that belongs to the SDK. If you process events using this thread (as the sample applications do) then following events could get backed up. You should only use the callbacks to receive events and pass them on to your own internal queue. This queue should be serviced by your own threads. Make sure you have enough threads to handle the load. If you get congestion or link down errors while your CPU usage is low, then you probably do not have enough threads.

Martin

Thank you for your answers guys!
I was searching for topics related to this or documentation for VDN's monitoring, but i can't find something completed.
Is there any link or pdf file?

Thank you!

Historically call control monitors were developed with ASAI, and then CVLAN utilized ASAI, and then TSAPI utilized ASAI, and then DMCC utilized TSAPI. Most of the information related to call control services is in the ASAI documentation and the TSAPI documentation, but most of it is rather dry reading about the protocol and not how to guides, and most of that is focused on monitoring station devices.

The educational information related to the AE Services APIs is largely behind this link
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/educational_resources/index.gsp

The TSAPI documentation can be found by starting with the AE Services page on the DevConnect portal
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/overview/index.gsp

clicking latest release in the right column
if it applicable, clicking a different release from the right column
clicking on Downloads
clicking on TSAPI
and then accessing the programmer's guide e.g. "TSAPI for Avaya Communication Manager Programmer's Reference Guide"


The ASAI documentation is no longer available through an Avaya portal in an attempt to dissuade direct use of the protocol. Copies of the documentation can be found from other sources by using a search engine and looking for "Avaya ASAI" or similar.