What version of private data did your client application negotiate?
Where exactly are you seeing that error? in your client? in AES logs somewhere? etc.

Thank you.

I have included your question in the issue I raised with the product team. In the meantime, assuming you're operating in an EAS environment, I would suggest that your application does not provide a hunt group value. The hunt group parameter is not needed for EAS environments, and that parameter "should" be ignored, but providing a value is apparently impacting the behavior as noted in this thread.

I was able to reproduce the issue. When the Exerciser attempts to log the second agent in while specifying the hunt group, I see an error returned in the AES server logs (csta_out & g3trace), as well as the JTAPI client logs. Therefore, I believe this is an issue with the Exerciser/application. I have informed the product team for them to consider including an updated version of the Exerciser in a future release to handle this scenario correctly. However, for anyone developing their own application, I expect the application to receive the correct events.

Best Regards.

After doing some quick experimentation on that form, I found that variable names change after each set of 252 variables. See the example below where I put some entries in at the boundaries of each set.

For example, the description field for variable "IR" is "Description position". It is the 252th variable on that form and it is the last variable in what we'll call Set 1.

The description for the very next variable, "IS", starts the next set of variables. All the fields in Set 2 have an "_2" in the name. You'll notice that even though "IR" is the 253rd variable on the form, it is the first variable/row for all the field names that have a "_2" in the name (e.g. "Description_2 position").

Likewise, variable "SK" is the first variable for all the fields that have "_3", (e.g., "Description_3 position). "ZZ" is the last variable on the form and it is on row 198 of the 3rd set of variables.

Response {
var $result_code = 0
var $result_data =
'<?xml version="1.0"?>
<result_data>
<VectorVariables>
<Description position="1">A - Set 1, Row 1</Description>
<Description position="252">IR - Set 1, Row 252</Description>
<Type position="1">collect</Type>
<Type position="252">collect</Type>
<Scope position="1">L</Scope>
<Scope position="252">L</Scope>
<Length position="1">16</Length>
<Length position="252">16</Length>
<Start position="1">1</Start>
<Start position="252">1</Start>
<Description_2 position="1">IS - Set 2, Row 1 (253)</Description_2>
<Description_2 position="252">SJ - Set 2, Row 252 (504)</Description_2>
<Type_2 position="1">collect</Type_2>
<Type_2 position="252">collect</Type_2>
<Scope_2 position="1">L</Scope_2>
<Scope_2 position="252">L</Scope_2>
<Length_2 position="1">16</Length_2>
<Length_2 position="252">16</Length_2>
<Start_2 position="1">1</Start_2>
<Start_2 position="252">1</Start_2>
<Description_3 position="1">SK - Set 3, Row 1 (505)</Description_3>
<Description_3 position="198">ZZ - Set 3, Row 198 (702)</Description_3>
<Type_3 position="1">collect</Type_3>
<Type_3 position="198">collect</Type_3>
<Scope_3 position="1">L</Scope_3>
<Scope_3 position="198">L</Scope_3>
<Length_3 position="1">16</Length_3>
<Length_3 position="198">16</Length_3>
<Start_3 position="1">1</Start_3>
<Start_3 position="198">1</Start_3>
</VectorVariables>
</result_data>
'
var $message_text = ''
}

The fields are positional for that form. The fields in the first row have a position of "1", the fields in the second row have a position of 2, and so forth. For example, see the attached pic of two variables I created on that form in rows 1 and 3.

Below is the output I receive when I use the built-in AES SMS test page to "display variables".
Response {
var $result_code = 0
var $result_data =
'<?xml version="1.0"?>
<result_data>
<VectorVariables>
<Description position="1">weather</Description>
<Description position="3">test</Description>
<Type position="1">collect</Type>
<Type position="3">collect</Type>
<Scope position="1">G</Scope>
<Scope position="3">G</Scope>
<Length position="1">1</Length>
<Length position="3">1</Length>
<Start position="1">1</Start>
<Start position="3">1</Start>
<Assignment position="1">2</Assignment>
<Assignment position="3">1</Assignment>
</VectorVariables>
</result_data>
'
var $message_text = ''
}

Hello,

Please test your scenario using the JTAPI Exerciser (which is included with the JTAPI SDK). With the Exerciser...

1) Create a Provider
2) Create an address for your VDN, 5706
3) Add a call listener to 5706
4) Run your test call

If you examine the events logged, you should find that the application was notified that the call was redirected to and answered by the target station, 5003.

I did a quick test call in my lab, where station 23101 calls VDN 20002, and the associated vector routes the call to station 23001. The attached output is for my call listener on VDN 20002.

Best Regards.

On my CM, there there 16 entries available on page 1, and 16 available on page 2, making position 32 that correct position for the last row on the form.

I also believe CM doesn't enforce the qualifier. So you could potentially use "9999999999999999" (sixteen 9's) for example as your qualifier, which would hopefully give you a blank form, and then position 32 for all the fields to add your entry to the last row of the form (just to be safe).

I would suggest you start by using the CM SAT to manually add the desired values (e.g. ""change station x", where x is an existing station extension).

Then use built-in AES SMS test page to display that station. You can look at the response returned to see the format expected, and then use that format to add/change a station with SMS.

To reiterate what some of what John has said, polling and setting Agent states must be done through one of the Application Enablement Services (AES) APIs that supports third party call control (3PCC). Therefore, your options are to use one of these AES APIs; TSAPI, JTAPI, or DMCC. Your application will send a request (e.g. to change an Agent's state) to the AES server and the AES server send the request to CM.

TSAPI is C++
JTAPI is Java
DMCC has three flavors. C#, Java, and access to the protocol XSDs which can be used by various code generators to produce interface source code.

Information on those interfaces can be found here.

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/releases/8_1_3/index.gsp#tabs-product-horiz-2

If you choose to use JTAPI, for example, then you will need to download and use JTAPI SDK to develop your application.

Sample JTAPI applications can be found here:

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/educational_resources/sample_applications/jtapi/index.gsp

The "JTAPI Agent Viewer" sample application would be very useful to you as it demonstrates how to "monitor" and change an agent's state.

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/educational_resources/sample_applications/jtapi/agent_viewer/index.gsp

Example screenshot attached. If that is not working for you, please submit a DevConnect technical support ticket for further investigation.

By logging into the CM SAT and attempting "add authorization-code". As far as I know, that command doesn't exist/is not supported on the CM SAT any longer (I tested on R8). SMS supports a subset of the commands that are supported via the CM SAT.

With JTAPI you can call ACDAddress.getLoggedOnAgents for each ACD.

The "add" operation is no longer officially supported for "authorization-code". That is, you cannot issue an "add authorization-code" command directly from the CM SAT, and SMS is intended to extended a subset of the commands available from the SAT.

However, there is a known issue, and the issue you're seeing should be fixed in release 8.1.3.1. 8.1.3.1 is targeted to be available by the end of this month (February 2021)

In the "Trunk Selection" field for your "OPS" entry on that form, you have a route pattern defined (e.g. rp1). Route-patterns are not supported with the "EC500" application. Therefore, when switching the application from "OPS" to "EC500", you must also change the "Trunk Selection" field from "rp1" to a valid value [i.e. 'aar', 'ars', trunk group (tg1 - tg99), or blank].

Best Regards.

I am unable to reproduce this issue; therefore, more information/investigation will be required. Please open a DevConnect Technical Support ticket and we will help you to look deeper into this problem.

Thank you.