Good morning!!

I got the code for determine the hunt group extension from the sample agentView application.

	public static String getCallACDAddressName(Call call) {



		if (call instanceof LucentCallInfo) {



			LucentCallInfo lucentCall = (LucentCallInfo) call;

			ACDAddress address = lucentCall.getDeliveringACDAddress();



			return (address != null) ? address.getName() : null;

		}



		return null;

	}

We ask for that method when a call is answered to perform some executions according to the returned value.

The method normally works fine. But recently we did some availability tests and the method returns NULL under the next scenario:

Meanwhile the incoming call is ringing, the application is intentionally rebooted in order to simulate a suddenly fail.
When the application is completely up again, the incoming call is answered by using JTAPI instructions in other words the application executes the answer method to the Terminal connection object.

termConn.answer();

Then in the intercepted event terminalConnectionTalking the getCallACDAddressName returns null.

We'e replicated the fail scenario by answering the incoming call using the avaya one x softphone and the getCallACDAddressName return the correct value.

Currently we are using the AES versión 7.1 and I've tested the fail scenario using JTAPI library versions 5.2 and 7.0 and the fail persist.

Any idea ?

Hi Ricardo,

When a call alerts at a monitored station, Communication Manager sends an ASAI AlertList event to AE Services. AE services converts this to a TSAPI Delivered event and passes it to the application.

When a call is answered at a monitored station, Communication Manager sends an ASAI ConnectList event to AE Services. AE services converts this to a TSAPI Established event and passes this to the application.

The only ASAI event containg the ACD Split number is the AlertList. Under normal circumstances, AE Services saves the ACD Split number from the AlertList event so it can include it in the Established event, later on. However, if the device was not monitored from the very beginning, the ACD number may be missed and not be available to an application.

In your case, I think the following happens:

1. An incoming call is made and AE Services receives an AlertList. AE Services passes a Delivered event to the JTAPI Client. The JTAPI Client converts this into the various JTAPI events and objects.
2. The application stops. This causes AE Services to drop its monitor on the station and dump cached data for the device & call.
3. The application starts and monitos the station again. The JTAPI client requests snapshot data for the device and call.
4. The agent answers the call and AE Services receives a Connect List. AE Services passes an Established event to the JTAPI Client. The JTAPI Client converts this into the various JTAPI events and objects.

Here, the first instance of the application received the ACD number at step 1. However, then the application stops, AE Services dumps the ACD number at step 2. This means that it is not available for second instance of the application at steps 3 or 4.

Unfortunately, there is no way for an application to request the ACD number. It can only receive it in a Delivered or Established event.

Martin

Thanks Martin

I can understand the behavior that you describe. That sounds pretty logical for any application that starts working when an existing transaction already exists.

But, what a different thing happens when we answer the call using the soft phone? (Step 4)

As mentioned before under the same scenario(reboot) and answering by using the soft phone, the error does not occur and I can obtain the ACD number correctly.

Regards

I am not able to reproduce that behaviour using the JTAPI exerciser. If you need further help with this, I suggest you open a technical support ticket and one of my colleagues will try to help you. Please note that, for non-paid members, there may be a fee for this service.

Martin