Hi,

We are getting logged in extension number as a calling party number(ANI/CLI) in telephony event (callingdevice) instead of original calling party number.

What configuration is required at AVaya server site and where. It will be good if we get steps or document for same.

I have copied our connector logs as below and marked parameters in red which we are using for CLI popup. In our lab and other customer site we have never faced such CLI issue. Please check what configuration is required at AES/Avaya server site to send callingdevice as CLI (calling party number) instead of logged in agent extension.

2019-09-05 16:17:19,679 [11] INFO CCVA - Telephony:if ((e.getEventCause == newCall|| e.getEventCause == keyOperation) && e.getLocalConnectionInfo ==alerting)...LineNo786
2019-09-05 16:17:19,679 [11] INFO CCVA - Telephony:currentCallState = TelephonyCallState.Alerting;...LineNo789
2019-09-05 16:17:19,679 [11] INFO CCVA - Telephony: CallRecord crt = callList.GetRecord(e.getCallingDeviceId);...LineNo796
2019-09-05 16:17:19,680 [11] INFO CCVA - Telephony:if (crt != null)...LineNo798
2019-09-05 16:17:19,680 [11] INFO CCVA - Telephony: callList.AddCallRecord(nameOfParty, e.getConnectionId.getCallId, e.getCallingDeviceId, CallState.CallInit.ToString(), DateTime.MinValue, true);...LineNo806
2019-09-05 16:17:19,680 [11] INFO CCVA - nameOfParty: ,e.getConnectionId.getCallId : 782, e.getCallingDeviceId :7222361787:CM::0
2019-09-05 16:17:19,680 [11] DEBUG CCVA - CallRecord temp : name= callID=782 callingdevice=5050:CM::0 state=CallInitchangeActoev inve=True
2019-09-05 16:17:19,680 [11] INFO CCVA - Telephony: IncomingCall incomingCall = new IncomingCall(callManager.IncomingCall);...LineNo817
2019-09-05 16:17:19,680 [11] INFO CCVA - Telephony: incomingCall.BeginInvoke(e.getConnectionId.getCallId, e.getCallingDeviceId, contentOfDisplay,null , null);...LineNo820
2019-09-05 16:17:19,680 [54] DEBUG CCVA - CallManger:IncomingCall(782,5050:CM::0,)

Regards,
Pravin

This is really not an issue that we can work through in the forums, and would require a support enabled level of DevConnect membership to work with a Technical Support ticket.

You don't mention what release you are working with (API, AES, and Communication Manager), and how that may differ from what is in place on the customer sites you indicate you don't see the issue.

Using the AE Services csta and g3trace information is a lot more informative to AES people then your application's logs. I suggest collecting the AES logs from a working site and comparing them with the problem site.
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp

Have you checked the agent form to see if there is an option for displaying the agent extension instead of the station extension that the agent logged in from? In particular the "LoginID for ISDN/SIP Display?" field.

Thanks John. at customer site they are using AACC routing configuration where as in lab it is non AACC routing configuration.


In non AACC following is call routing.

1) Customer dial e.g. 1944 standard VDN and that routes to Vector e.g. 72 .
2) Vector e.g. 72 is routing directly to an agent that is logged into Skill e.g. 16.
3) Agents that are assigned to Skill 1e.g. 6 are not associated with AACC.

and we are getting CLI in callingdevice, Unique CallID in CAllID and DNIS in CalledID variable (DMCC Parameter).

DDD2 callId=11168 cli=5050 DN=4446 callingdevice=5050:CHDC1CM::0 calledID=4446:chdc1cm:0.0.0.0:0

We just want to know in AACC environment in which parameter we can get CLI, DNIS and CallID like above.

As we are getting callingdevice as a agent loggedin extension.


Also want to know if calls will be answered by DMCC AACC agent (custom desktop) then call will be answered for AACC Avaya Aura Agent Desktop agent as well right?

Basically synchronisation between two desktop for call events.

In our lab for non AACC call routing configuration if Avaya one-x Agent answer call then it replicates on Custom Agent desktop as well.

Many thanks in advance.

Regards,
Pravin

I am afraid that I can not follow the call scenario from the information provided.
1) AACC does not used avaya aura communication manager elite agents. The Agents in AACC are a totally separate concept from those in communication manager. Any CTI events from AACC will not reflect a communication manager agentID because it is unaware of communication manager agentIDs.
2) somewhat worse from your perspective call handling on communication manager when it is integrated with AACC is not per call but rather a nailed agent that AACC connects to one call after another without communication manager CTI being aware of the transitions.


"We just want to know in AACC environment in which parameter we can get CLI, DNIS and CallID like above." You will have to use AACC APIs. DMCC APIs will not give you this information on a call by call basis.

"Also want to know if calls will be answered by DMCC AACC agent (custom desktop) then call will be answered for AACC Avaya Aura Agent Desktop agent as well right?"
I don't know what configuration you have in place whereby activity on one desktop is reflected in another. I am not saying you can't do that, just that you haven't explained it. Asking enough questions to get to an answer to that exceeds what we can do on the forum. Since AACC Agents are nailed up, 'answered' is handled differently. Basically there will be only one answer event per day per agent with AACC when integrated with CM.

Hi John,

We have tested the DMCC custom desktop for both (AACC and non AACC call routing) in our Lab and below are our observations. We are getting incorrect CLI and DNIS for AACC call routing.

We are using following third party call control event to get CLI, CallID and DNIS details.

#region getThirdPartyCallController_OnDeliveredEvent(object sender, ThirdPartyCallController.DeliveredEventEventArgs e)

/// <summary>
/// This event handler will be called in response to the Delivered event which is received
/// whenever a new call arrives and is in ringing callState

In non AACC Routing (Avaya One-X desktop and VDN 1944 for 2300 and 2302 extension) – we are getting following in above event parameters when calling from 2302 to 1944 VDN. Call landed to 2300 extension.

CallID (e.getConnectionId.getCallId)-2785 (e.g.)
CLI (e.getCallingDeviceId) – 2302
DNIS (e.getCalledDeviceId) – 1944

In AACC Routing (Avaya Aura Agent desktop and VDN 9+1634 for 2300 and 2302 extension) – we are getting following in above event parameters when calling from 2302 to 91634 CDN. Call landed to 2300 extension.

CallID (e.getConnectionId.getCallId)-9108 (e.g.)
CLI (e.getCallingDeviceId) – 1634
DNIS (e.getCalledDeviceId) – 2300

But on AACC desktop getting correct details.

CallID -9108 (e.g.)
CLI – 2302
DNIS – 1634_CDN_CCVA

Why we are getting different CLI and DNIS in AES server telephony event for AACC routing.

CLI (e.getCallingDeviceId) – 1634
DNIS (e.getCalledDeviceId) – 2300

Actually it should be

CLI (e.getCallingDeviceId) – 2302
DNIS (e.getCalledDeviceId) – 1634


Regards,
Pravin

The information you will get in DMCC Call Control events depends on the call flow and the configuration of Communication Manager.

I am not familiar with how AACC works but it seems likely that it transfers an incoming call to an agent's phone. This would lead to different data in events than a call that uses a straight flow using VDN and vector - the events are for the transfer call, not the original, incoming, call.

In the case of transfers and conferences, the events will also include Original Call Information (OCI) data. This usually holds the calling and called numbers of the original call.

You can get more information on OCI in the TSAPI Programmers Guide (DMCC relied on TSAPI for Call Control features)
https://www.devconnectprogram.com/fileMedia/download/9122902c-68d2-4e7b-81e8-aedb6c52b00b

You may also find the following FAQ useful. It deals with how Call ID and UCID change during transfers & conferences.
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/index.gsp#1260

Martin

If you are using AACC you MUST use AACC APIs to get call related data for calls involving AACC Agents. The application CANNOT use DMCC APIs when AACC is used to get call by call data for AACC agents.

Thanks John. Can you please let me know which API we need to use CCT one or any other API's we need to use for AACC.


I think in AAAC original call get transferred to Agent hence we are getting transferred caller details instead of original call. Is there any way original caller details will be set via UUI or any other way in call routing script.

We tried using getoriginalcallingdeviceID and getoriginalcalledID in DMCC but no luck.


Regards,
Pravin

I will get someone who knows more than I about AACC to answer that - i'd only be guessing.

How are calls flowing TO AACC? direct SIP from SM? Some other path?

Yeah, the call to the agent comes from AACC and not from the originating party. You'll need to use CCT to get Agent information (and reliable telephony information including the original caller#). There's a CCT/.NET and CCT/SOAP interfaces which are roughly equivalent (although CCT/.NET scales-vertically; CCT/SOAP has some limitations).

Thanks John. In our Lab We are dialing 1634 CDN and it routes to 1634_skill and then AAAD Agent who has 1634 skill assigned. Yes we are using SIP.

Basically all event working fine for DMCC desktop for AACC routing only thing is we are not getting original call information (ANI, DNIS and CallID) because call redirect from 1634 VDN to AAAD Agent hence it is sending 1634 as a ANI and Agent logged in extension as a DNIS.

We tried using getoriginalinfo.getnetworkcallingdeviceID and getoriginalinfo.getnetworkcalledID but these paramerts return null when call delivered event fire.

Need help how can we get original caller number and original called number in above parameters. If that is not possible then is it possible to pass original caller details via UUI parameter for each new call.

Regards,
Pravin



Regards,
Pravin

Again, you can not get calling party information for AACC calls that reach Communication Manager stations using DMCC. You will have to use AACC's CCT API per Fergus's response. That may have crossed on the wire as your post and Fergus's were very close in time.

I am afraid I have no idea where 1634 CDN and 1634_skill are implemented.. CS1000? Communication Manager? some other product? I don't think it matters anymore though, but for us to be able to describe the tap points to get information about calls traversing systems, we need to know what systems are involved (CS1000, Communication Manager, AACC, Experience Portal, Session Manager, Breeze, IPOffice, etc), and in what sequence the calls traverse those systems.

So, John touches on the problem here when he says "no idea where [CDN is] implemented" because, the reality is, it is not necessarily strictly defined. Lab work can pervert this and make the problem seem simpler than it is. Long-story-short, you should get reliable data from the AACC via the CCT interfaces (otherwise the AACC cannot report accurately on calls and thus there's an underlying business problem, so you can't avoid that one).

The simplest way to engage this is, get to the AACC and fire-up CCT/RefClient (or CCT/OI/RefClient). You can then look at the calls there, check intrinsics and call-attach-data and all that good stuff.

Theoretically, you *could* stuff some of that from CCT back into UUI but I've yet to see an instance where, after you've integrated to AACC and have the data, that really made sense (particularly because UUI is a rather tricky business).

Here is the call flow of the Contact Center Components:

ACM->SM->AACC->AAAD


Also below configuration done for UCID on AES server but still not getting original call information. We tried getcallinformation, get userdata (to decode) method in Thirdpartycallcontrol call delivered event but all parameters are empty except getcallingdevice,callid and getcalledid.


The basic configurations for UCID. Please find the screen shot below for ref.


The consistent opinion appears to be that DMCC will always be
inadequate for AACC agent call control (and absolutely inadequate for
an agent desktop). The fundamental design is one where a "contact" is
answered and handled by the AACC with the CM station being attached
and detached passively, as a voice channel, where needed; it has no
explicit relationship to the AACC contact outside of CCT.

We might solve this query for a portion of the problem space, with
particular call construction, by decoding the UUI but in Dot NET DMCC API we tried to fetch data using get userdata method when thirpartycallcontrol delivered event occurred to get original call information (ANI,Callid and DNIS).


It will be good if you guide us how can we get original caller details in AACC , AES data information.

Regards,
Pravin

You cannot use AES to get at call information for calls managed by AACC. Use AACC APIs when working with AACC. Do not use DMCC APIs. If you need help with AACC APIs please open a DevConnect Technical Ticket - there is no forum for it.