Hi,

We have developed custom agent desktop using dotnet DMCC API's. Call transfer and conference is working fine when we do transfer within internal network VDN number but when we do call transfer to external mobile number call it connected but receiving different event hence button enable and disable not working properly to complete transfer.

For Internal 4 digit VDN transfer we Thirparty ger ondelivered evetn after onmake call event where For external more than 10 digit mobile number transfer we are not getting Thirparty ger ondelivered evetn after onmake call event instead getting Terminal update.

When tested same case working fine in Avaya One-X desktop without issue. Need assistance to identify difference between events when doing internal and external transfer. How can we manage button enable and disable and which event.

Regards,
Pravin

Usually, when a call to another switch does not receive a Delivered or Established event, it is because the call traveled over a trunk that does not support ISDN signalling (e.g. an Analog trunk). In this case, Communication Manager will report a Network Reached event to indicate that the application should not expect to get any more events for this call.

You should make sure that your application is listening for Network Reached events and handle them appropriately.

Martin

We are able to listen Network Reached events but getting held and active callId same. How can we get active and held callId different. What method we need to use to complete consult transfer. Please provide method to complete external call transfer.

I am not sure what you mean by " getting held and active callId same". Can you explain? Do you have traces for these calls?

Martin

Hi Martin,

Please see attached internal extension successful transfer call logs as well as external mobile transfer unsuccessful logs.


1) Internal successful transfer -

2019-04-22 14:38:47,390 [9] ERROR CCVA - snapShot: False,currentCallStateEstablished
2019-04-22 14:38:47,407 [9] ERROR CCVA - index: 0
2019-04-22 14:38:47,407 [9] INFO CCVA - getThirdPartyCallController_OnHeldEvent index :0
2019-04-22 14:38:47,407 [9] INFO CCVA - GetExtension Extension : 2300
2019-04-22 14:38:47,408 [7] INFO CCVA - UpdatePopupUI isstate : Hold
2019-04-22 14:38:49,822 [6] DEBUG CCVA -
2019-04-22 14:38:51,477 [9] INFO CCVA - heldCallDeviceID: 2300:ACM2XXXPE::0,heldCallCallID: 9092
2019-04-22 14:38:51,513 [9] INFO CCVA - GetThirdPartyDeviceID invokeId : 11
2019-04-22 14:38:51,513 [9] INFO CCVA - GetThirdPartyDeviceID cmName: ACM2xxxPE,newExtension:
2019-04-22 14:38:51,513 [9] INFO CCVA - getThirdPartyCallController_OnHeldEvent consultationFlag :True
2019-04-22 14:38:51,628 [9] INFO CCVA - OriginateCall error 12
2019-04-22 14:38:51,628 [9] INFO CCVA - getThirdPartyCallController_OnGetThirdPartyDeviceIdResponse consultationFlag :True
2019-04-22 14:38:51,681 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=
2019-04-22 14:38:51,682 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:38:51,682 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=
2019-04-22 14:38:51,682 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:38:51,682 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=OneX Agent3
2019-04-22 14:38:51,682 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=OneX Agent3 2302
2019-04-22 14:38:52,902 [9] INFO CCVA - getThirdPartyCallController_OnMakeCallResponse currentCallState :Held
2019-04-22 14:38:54,990 [9] INFO CCVA - ThirdPartyCallController.DeliveredEventEventArgs e
2019-04-22 14:38:55,030 [9] INFO CCVA - Telephony:String callID = e.getConnectionId.getCallId......LineNo722
2019-04-22 14:38:55,030 [9] INFO CCVA - Telephony:String deviceID = e.getConnectionId.getDeviceIdAsString;.....LineNo724
2019-04-22 14:38:55,030 [9] INFO CCVA - Telephony:calledId = e.getCalledDeviceId;.....LineNo726
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony:if (contentOfDisplay.Length != 0).....LineNo729
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony: nameOfParty = ExtractPartyName();.....LineNo733
2019-04-22 14:38:56,614 [9] INFO CCVA - ExtractPartyName index : 29
2019-04-22 14:38:56,614 [9] ERROR CCVA - getThirdPartyCallController_OnDeliveredEvent nameOfParty: OneX Agent3
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony: if (snapShot).....LineNo738
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony:if (deviceID.StartsWith(GetExtension(DeviceId)))....LineNo771
2019-04-22 14:38:56,614 [9] INFO CCVA - GetExtension Extension : 2300
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony:.else if (e.getCallingDeviceId.Equals(DeviceId))......LineNo835
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony: if (currentCallState == TelephonyCallState.Held)......LineNo851
2019-04-22 14:38:56,614 [9] INFO CCVA - e.getConnectionId.getCallId : 9106
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony: callList[callList.CurrentIndex].CallId = e.getConnectionId.getCallId;......LineNo861
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony: ConsultationCall consultCall = new ConsultationCall(callManager.ConsultationCall);......LineNo862
2019-04-22 14:38:56,614 [9] INFO CCVA - Telephony:consultCall.BeginInvoke(GetExtension(e.getCalledDeviceId), null, null);......LineNo865
2019-04-22 14:38:59,001 [9] INFO CCVA - GetExtension Extension : 2302
2019-04-22 14:38:59,004 [10] DEBUG CCVA - CallManger:ConsultationCall(2302)
2019-04-22 14:38:59,004 [10] INFO CCVA - ConsultationCall _ConsultedParty : 2302
2019-04-22 14:39:04,995 [6] DEBUG CCVA - PopupForm:Transfer

2019-04-22 14:39:06,484 [6] INFO CCVA - TransferCall - activeCall DeviceId : 2300:ACM2xxxPE:0.0.0.0:0,activeCallID : 9106
2019-04-22 14:39:06,484 [6] INFO CCVA - TransferCall - heldCallDeviceID : 2300:ACM2XXXPE::0,heldCallCallID : 9092

2019-04-22 14:39:32,440 [6] INFO CCVA - TransferCall invokeId : 13
2019-04-22 14:39:32,440 [6] DEBUG CCVA - telephony.TransferCall();
2019-04-22 14:39:32,440 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:39:32,441 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=OneX Agent3
2019-04-22 14:39:32,441 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent updatePopupUI :False
2019-04-22 14:39:32,441 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=OneX Agent3 2302
2019-04-22 14:39:32,441 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent updatePopupUI :False
2019-04-22 14:39:32,442 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:39:32,443 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :Transfer Completed.
2019-04-22 14:39:34,504 [9] INFO CCVA - GetExtension Extension : 2300
2019-04-22 14:39:34,504 [9] INFO CCVA - GetExtension Extension : 2302
2019-04-22 14:39:34,504 [9] INFO CCVA - getThirdPartyCallController_OnTransferredEvent transferMsg :
Call transferred from 2300 to 2302

2019-04-22 14:39:34,504 [9] INFO CCVA - GetExtension Extension : 2300
2019-04-22 14:39:34,504 [9] INFO CCVA - getThirdPartyCallController_OnTransferredEvent DeviceId :2300:ACM2xxxPE:0.0.0.0:0
2019-04-22 14:39:34,505 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:39:34,507 [6] DEBUG CCVA - CallManger:CallTransferred(
Call transferred from 2300 to 2302
)

Here activeCallID : 9106 and heldCallCallID : 9092 are different hence transfercall is working.


2) External mobile transfer - unsuccessful

2019-04-22 14:46:54,636 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:46:54,683 [9] ERROR CCVA - snapShot: False,currentCallStateEstablished
2019-04-22 14:46:54,683 [9] ERROR CCVA - index: 0
2019-04-22 14:46:54,683 [9] INFO CCVA - getThirdPartyCallController_OnHeldEvent index :0
2019-04-22 14:46:54,683 [9] INFO CCVA - GetExtension Extension : 2300
2019-04-22 14:46:54,684 [10] INFO CCVA - UpdatePopupUI isstate : Hold
2019-04-22 14:46:57,354 [6] DEBUG CCVA -
2019-04-22 14:46:58,417 [9] INFO CCVA - heldCallDeviceID: 2300:ACM2XXXPE::0,heldCallCallID: 9323
2019-04-22 14:46:58,459 [9] INFO CCVA - GetThirdPartyDeviceID invokeId : 11
2019-04-22 14:46:58,459 [9] INFO CCVA - GetThirdPartyDeviceID cmName: ACM2xxxPE,newExtension:
2019-04-22 14:46:58,459 [9] INFO CCVA - getThirdPartyCallController_OnHeldEvent consultationFlag :True
2019-04-22 14:46:58,582 [9] INFO CCVA - OriginateCall error 12
2019-04-22 14:46:58,582 [9] INFO CCVA - getThirdPartyCallController_OnGetThirdPartyDeviceIdResponse consultationFlag :True
2019-04-22 14:46:58,630 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=
2019-04-22 14:46:58,631 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:46:58,632 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=
2019-04-22 14:46:58,659 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:46:58,659 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=9011919552504006
2019-04-22 14:47:01,126 [9] INFO CCVA - getThirdPartyCallController_OnMakeCallResponse currentCallState :Held
2019-04-22 14:47:03,381 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:47:03,395 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=9011919552504006
2019-04-22 14:47:14,481 [9] INFO CCVA - GetExtension Extension : 9011919552504006
2019-04-22 14:47:14,481 [9] INFO CCVA - GetCallInformation_OnNetworkReachedEvent getCalledDevice :
2019-04-22 14:47:14,482 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:47:14,482 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=9011919552504006
2019-04-22 14:47:14,483 [7] DEBUG CCVA - CallManger:ConsultationCall(9011919552504006)
2019-04-22 14:47:14,483 [7] INFO CCVA - ConsultationCall _ConsultedParty : 9011919552504006
2019-04-22 14:47:14,882 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :
2019-04-22 14:47:14,891 [9] INFO CCVA - Terminal_OnDisplayUpdatedEvent contentOfDisplay :b=9011919552504006
2019-04-22 14:47:14,894 [9] INFO CCVA - GetExtension Extension : 2300
2019-04-22 14:47:20,637 [7] DEBUG CCVA - PopupForm:Transfer

2019-04-22 14:47:22,637 [7] INFO CCVA - TransferCall - activeCall DeviceId : 2300:ACM2xxxPE:0.0.0.0:0,activeCallID : 9323
2019-04-22 14:47:22,637 [7] INFO CCVA - TransferCall - heldCallDeviceID : 2300:ACM2XXXPE::0,heldCallCallID : 9323

2019-04-22 14:47:31,767 [7] INFO CCVA - TransferCall invokeId : 14

2019-04-22 14:47:31,767 [7] DEBUG CCVA - telephony.TransferCall();


Here activeCallID : 9323 and heldCallCallID : 9323 are same hence transfercall not working.

Is this correct observation or we are missing any other coding to complete transfer call to external number.


Regards,
Pravin

Your traces do not show where you get activeCallID from. My guess is that you normally take it from a Delivered event. I also guess that when you don't get a Delivered event, you use whatever is lying around in the variable.

You can get the CallID of the active call from either of:

1. The MakeCallResponseEvent which you can listen for. or
2. The NetworkReached event.

Martin

Thanks. It's our application logs. from where can we get heldcallID. Do we need to pass only active callID and held callID to complete transfer or need to pass any other parameters like number which we are transferring etc.

Regards,
Pravin

You can get the Held Call ID from any of the Call Control events for that call (e.g. its Delivered, Established or Held events).

There is information on what parameters each function call requires in the API documentation which is included in the SDK.

I also recommend that you download a copy of the document "TSAPI for Avaya Communication Manager Programmer's Reference". DMCC uses TSAPI behind the scenes for all Call Control features. The TSAPI guide usually gives much more detail than the DMCC documents.

Martin

Thanks Martin.

Hi Martin,

Now we passed Active and Held Called along with Device ID from Networkreachevent but call transfer complete now working. Can we get some sample code to complete transfer to external number or guidelines.

Regards,
Pravin

There is a DMCC .Net sample application called "DMCC Popup" on the Devconnect website which includes transfer code. This may be useful to you. You can find it using the "Products & Resources -> Application Enablement Services" menu. Sample applications are in the "Educational Resources" section.

Martin

Hi Martin,

We are using same code and transfer working fine for internal call. Only transfer not working for external mobile number.

Now we are able to pass active and held callID along with Device ID to transfer call menthod from NetworkReachEvent but transfer is not happening. Consult party number is also correct.

Can you please advise how can we debug or find out what is wrong happening in our code. If we perform transfer from Avaya Onbe X desktop it is working fine for external number.

Regards,
Pravin

You may be able to get better information by examining the TSAPI traces on AE Services. You can get instructions in the Devconnect Product FAQ "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?".
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp#10

The csta file will show the messages to/from the application and the g3 files will show the messages to/from Communication Manager. There should be an error in the g3 file. The document "TSAPI for Avaya Communication Manager Programmer's Reference" will help you to understand the messages and error.

Martin

Hi Martin,

We have tested code after added network reach event and it is working sometimes but majority of time it does not. Please see our application logs for working and non working transfer call case. Please advise are there any delay or any other event we need to add.

I am not familiar with how your tracing works so I can only guess at what they mean.

In the working trace, I see some activity at 07:17:19,687 which does not seem to exist in the non-working case. This trace includes "CallManger:CallAnswered" so I presume it is triggered from an Established event (though this is far from certain from the traces).

So, my guess is that maybe you are getting Answer Supervision from the far-end in the working case but are not getting is in the non-working case. This may be due to the configuration of the trunks on Communication Manager (I think they can generate Answer Supervision after a timeout). Or, it may be that one SP provides Answer Supervision but another does not.

Martin