Dear Sir,
Our customer is going to build 2 AES systems. Call will be transferred and redirected between them controlled by JTAPI software.
Currently we are testing call transactions on one AES system and so far no big problems. What I would like to ask you is how to transfer and redirect calls between 2 AES systems and how to get information of calls from another AES system.
Or is there any JTAPI API and/or documents to access to another AES?

Thank you for your help in advance.
Best regards,

your use case is not clear to me.

If both AES's are connected to the same communicaiton manager, then they are functionally equivilent and can monitor the same device and get the same event streams (alibet through separate providers and T-Links)

If the two AES's are connected to separate Communicaiton Managers, and your question relates to knowing that a call handled by CM1 has been transfered to a device on CM2, then you will need to make use of Universal Call Identifier meta data that can be attached to CTI events. There are forum and FAQs covering the necessary provisioning of UCID and how to access it in events in order to be able to corrolate calls from one system to another.

Call handling (transfer and redirect) ith one or two AESs is no different than doing it with a single AES.
AESs do not host calls, they report on call activity that is occurring on one or more CMs that they are connected to and that the application has requested data about calls occuring on stations, VDNs, or non ACD hunt groups on those systems

Perhaps you can elaborate on the actual deployment and the actual use case you are interested in. and I may have information that is more on point.

Thank you for your quick response and help.
I will get information and configuration on AES systems which we are working for. Then I may ask you again.
Best regards,

Dear John,
Let's assume every AES is connected to its own CM and there are 3 pairs of AES and CM.
1) What you said in the previous reply is that how to transfer/consult call from AES1 to AES2/AES3 is no different than doing so within AES1. Am I right?
2) To watching all events, we need 3 JTAPI servers (each server watching event listener of each AES), don't we?
Best regards,

1) yes, with the obvious differences in separate connections to the various AES's and limitations on what devices you can operate on being those that are hosted on the corresponding CM. To transfer a call, you put it on hold, do a make call to a destination - that destination can be on switch or off. then you invoke transfer using the two call identifiers. Whether the destination of the second call is on CM 1 or another PBX makes no difference in the sequence of actions to invoke call transfer.
2) yes sort of. One application can create three connections, one to each AES, and if the application can keep thigns straight with what provider connection / AES it needs to work with for what station, everything will work out assuming the server you are running the application on can keep up with the workload. Alternatively, you can do it with 3 versions of the application each with one connection to one of the AESs. That solution can be deployed on 3 servers or one depending on the resource needs of the application.

Hi John,

Thank you very much for your quick response and help.

Best regards,

Dear John,

Regarding 3 AES and 3 CM I have questions as follows:
1) Tracking originator call.
-There are Phones P1, P2 ----- Pn and --> means call.
P1 of AES1 --> P2 of AES2 --> P3 of AES3 --> P4 of AES2
When I P3of AES3 calls P4 of AES2 above, I would like to trace back originator call, i.e. P1. Is it possible?
2) Is UCID unique among AES1, AES2 and AES3?

Best regards,

I am guessing that -> means call and transfer.
So your real use case is
P1 calls P2, P2 answers, puts P1 on hold, P2 calls P3, and P2 completes a transfer.

P3 answers. P3 puts the call on hold, calls P4, and then transfers.
When the call is delivered to P4 you want to know if you can trace things back to P1.

Yes you can, assuming, P1, P2, P3 and P4 are monitored by AES (TSAPI/JTAPI or DMCC), and that UCID is provisioned on all of the CMs, and UCID is configured to be sent across the CM1, CM2 and CM3 trunks.

UCID is created when the call is created. When two calls are merged (conference or transfere scenarios), one of the two UCID values is used for the subsequent call. You will need to read and understand the following FAQ to understand how this will impact your application.
https://www.devconnectprogram.com/fileMedia/download/2f97cad6-c21f-4a56-98ab-1627e604bcb0

Thank you for your quick response and help.

Best regards,

Hi John,

you mentioned above that UCID is provisioned on all of the CMs, and UCID is configured to be sent across the CM1, CM2 and CM3 trunks. In order to set up CM for UCID please let me know the documents which describe how to configure CM.

Best regards,

Please review these two FAQs.

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/general/index.gsp#faq-1000


https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/general/index.gsp#faq-1260

Hi John,

Thank you very much for your help.

Best regards,