What happens if the number we are trying to dial into EDP, is either incorrect/invalid or not – reachable?

Also, for the mobile number, how to handle the voice mail situation? For example, if we are calling a mobile number, and the user disconnects the call, it will go to the user's voice mail directly. But EDP treat this as the user picks up the call such that it goes to CallOriginated (2-party call) method which we will play an announcement. The result is that the user declines the call but he/she will get a voice mail anyway after 1 minute (part of our announcement).

You should get a Call.terminated() callback in this case. I believe that the CallTerminationCause would be TARGET_DOES_NOT_EXIST but in some cases (especially outside numbers) you might get NETWORK_FAILED.

And regarding your mobile use case, you're right that if your timeout is 1 minute, the user would get a minute-long voicemail of silence. You might consider lowering your timeout but unless you make it less than 10 seconds you're probably likely to go past the beep.

The only way around this that I can think of will be when Engagement Development Platform is able to take advantage of the Answering Machine Detection capability in the Avaya Aura Media Server. This is on the roadmap but not in our immediate plans.

Hi Joel,

I tried the wrong number case. It does not go to the callTerminated() method. Actually no code after call.initiate() will be triggered.

I'm using CE 3.0.3.006 SDK and testing the sample service "ClickToCall".

I put "+15132288152@net.avaya.com" as first party. Since this number is our EDP lab extension and it's not logged on Avaya Communicator or any other device, this number will be regarded unreachable.

Here is the log I get:

2015-05-19 08:55:22,762 [WebContainer : 3] ClickToCall FINER - ClickToCall-3.0.3.0.303003 - processHttpPost ENTER
2015-05-19 08:55:22,765 [WebContainer : 3] ClickToCall FINE - ClickToCall-3.0.3.0.303003 - 6717649
2015-05-19 08:55:22,780 [WebContainer : 3] ClickToCall FINEST - ClickToCall-3.0.3.0.303003 - makeCall:+15132288152@net.avaya.com to secondParty=+15132288888@net.avaya.com
2015-05-19 08:55:22,780 [WebContainer : 3] ClickToCall FINER - ClickToCall-3.0.3.0.303003 - processHttpPost EXIT

I modified MyCallListener.java to print out CallTerminationCause:

@Override
public final void callTerminated(Call call, CallTerminationCause cause)
{
if (logger.isFinestEnabled())
{
logger.finest("callTerminated: cause: " + cause);
}
}

But it turns out that if the number is either incorrect/invalid or not – reachable, the callTerminated() method will not be triggered at all.

It looks like you've unfortunately found a bug in the platform. I've written a bug report and we'll be working on fixing it in our next release. Please open a DevConnect ticket so you can stay apprised of the status.

Hi Joel,

I opened a DevConnect Ticket for technical support of EDP this morning, but it shows closed now.
The ticket number is 21328.
Is the ticket type "technical support" the right one?

Thanks,
Qian

Hi Qian, we're looking into what happened with your ticket. Rest assured that this won't impact our work to resolve the problem. We'll let you know whether we're able to re-open the ticket you referenced below or if we need to open a new one. Sorry about that.

I'm told that your ticket has been re-opened. You will get status through this ticket when the issue is resolved. I'm sorry for your inconvenience.

Thanks Joel,

we will keep track of the ticket.

And this issue is really important to be solved ASAP.

Hi, a workaround has been identified for this issue. You can use the IncomingSipMessageListener Interface and check to see if the response is an error message. You'll need to remember to annotate your implementation as documented in the Javadoc.

Here's how I'd recommend you do it:
- Set an attribute on the Call that indicates that it has not yet been originated (calling out to the calling party).
- Set a second attribute with the Call ID
- In the messageReceived implementation, check to see if it's an error response and ceck the attribute (from the map) to see if the call is in the "not originated" state.
- If so, perform whatever logging / cleanup is necessary

Do you think this will work for you until release 3.1 is GA?

Hi Joel,

Thanks for the workaround.

It seems that the IncomingSipMessageListener is not in the EDP SDK doc we are using.

We have been using this doc for development:

http://www.devconnectprogram.com/media/global/products_resources/avaya_aura_collaboration_environment/releases/3_0/ce-api-javadoc-3_0_2/index.html

In this doc, I only see SipMessageListener class and SipMessageListenerAbstract class with methods sendingOut().

I did find the IncomingSipMessageListener here:

https://www.devconnectprogram.com/media/global/products_resources/edp/3_0/javadocs-3_0_3/com/avaya/collaboration/call/sip/IncomingSipMessageListener.html

Is this doc the up-to-date one that we should use for development ?

And just to make it clear that is the messageReceived you mentioned the same thing as responseReceived method?

Thank you !

This API is new for our 3.0.3 release. Please see here:
http://www.devconnectprogram.com/media/global/products_resources/edp/3_0/javadocs-3_0_3/index.html

Thank you Joel.

And it's solved now.

I can report a wrong number message to my client whenever I received a SipResponse status that is over 400 in responseReceived (IncomingSipMessageListener).

Response ReasonPhrase example:
403: Forbidden (Denial 1166)
404: Not found (No route available)
480: Temporarily Unavailable

BTW, if this is officially fixed in 3.1. it will be invoking the callTerminated method in callListener right ? I after that I might need to remove my code of this temporary solution.

Yes, that's right. This should be considered as a temporary workaround, with the real fix coming in 3.1. I'm happy to hear that you got it working, and I'm sorry for the inconvenience.