There are a few interesting things about what you are encountering:

1. I installed the Callable Service sample snap-in in my lab, and the record and later play back of the recording worked without the need to modify the snap-in in any way. At this point it's not obvious to me what is different with what you are doing that would explain the behavior you are seeing.

2. You mention two URLs in your description. One of them is in the form http:/serverip/services/CallableService/CallableServiceServlet/mycustomrecording.wav
and the other is in the form http:/serverip/services/CallableService/mycustomrecording.wav. The difference, of course, is the presence/absence of "CallableServiceServlet" in the path. It turns out that the snap-in has been constructed in a way so that operations related to the management (creation and deletion) of the recording require use of the form that includes the "CallableServiceServlet". However, the play out of the recording does not require the "CallableServiceServlet" portion; in fact, it is not possible to invoke the play out of the recording using the form with "CallableServiceServlet".

So while it is admittedly inconsistent for using two different forms to reference the recording, it appears that the creator of the sample service did so by design. I'm speculating when I say that perhaps the creator wanted to show the flexibility available within a snap-in for resolving URL targets.

3. The physical location of the recording on disk is at /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/Node01Cell/CallableService-3.5.0.0.350007.ear/CallableService-war-3.5.0.0.350007.war/, where "3.5.0.0.350007" is the version of the snap-in. When you run the snap-in with your file name modification of "mycustomrecording.wav", you should find the file in this directory. Can you check if you find it there and if it has a size greater than 0?

4. Can you double check that you changed the wav file name in all places that it needs to be changed in the code? I found three places where it needed to be changed:

- 2 in CallableServiceMainMenuMediaListener
- 1 in RecordMessageOperationImpl

Can you also double check that you did not include the ".wav" extension in the file name in any of those locations?

Hi,

This particular exception typically points to another cause. In this case it appears that, during an SDP negotiation between an endpoint and the media server, an SDP answer has been sent to the media server. The state machine in this part of the code is expecting a response from the media server indicating that the answer has been accepted. Higher levels of code are then passing another SDP answer to the media server, and the state machine is rejecting the answer since an acknowledgement of the previous answer has not been processed by the state machine.

This exception probably indicates a bug. I would suggest opening a service ticket.

Thanks.

The call would be disconnected.

I've checked with a few colleagues, and none of us know of a way to allow the call to proceed gracefully to its original destination. You might consider working with your account team to open a GRIP request for an enhancement along the following lines. Allow a call to proceed if a snap-in encounters a non-critical media operation and/or allow the setting of a policy to indicate desired behavior on media server failure. Please be sure to reference this forum posting in the request, so that we have adequate context for the request.

Then, here's an interim solution that you might consider. It would allow a large majority of your calls to proceed without failing under these circumstances. When your snap-in gets the notification of a call termination due to media server failure, set an internal flag making note of this error. From this point forward, bypass media operations for x minutes. After x minutes, return to normal media operations. If you get the media server failure again, repeat the process. While this approach is admittedly not optimal, it would allow a high percentage of the calls to proceed to the original destination. And when the media server service is restored, normal call treatment will resume automatically.

There is a bug fix in 3.4 service pack 1 plus patch (3.4.0.1.340120 plus patch 3.4.0.1.09340120) that provides an indication to a snap-in when all media servers -- along the lines you've indicated here -- are unable to provide service. The precise behavior varies a bit depending on the precise scenario. But based on what you've described, here's what I think you would see under 3.4.0.1.09340120. Your snap-in's callTerminated method would get invoked with a cause of MEDIA_SERVER_FAILURE. Additionally, a SIP 503 message would be sent to the caller's phone, which will probably result in most phones playing a busy signal to the caller. In some other scenarios, the add participant failed callback will be invoked, too.

There is a bit of an irony in a situation like this. One nice thing about being able to play announcements to callers is that your snap-in can "play out" announcements with useful information for certain kinds of error conditions that a caller might encounter. Of course, the ability to play an announcement from a snap-in requires use of a media server. In your scenario here, with no media server available, the options available to indicate an error to a calling party are pretty limited. I do think typically a busy signal is a better experience for a caller than silence, so I think the fix in the patch is a good improvement.

I believe we may have made changes in a later version of Breeze related to the ability for a snap-in to have a way to detect that the AAMS is in a state where it cannot fulfill requests. I need to investigate further.

Hi,

What version of Breeze is being used here?

--Rob

Hi,

No mark up of this type is supported through the Breeze API. In recent versions of the Breeze API, the language can be set at the PlayItem level to specify the language to be used for TTS. Other things you've mentioned cannot be set.

--Rob

Good to hear and thanks for the update.

Then, just to finish this out, the screen capture of your configuration that you provided matched what I had in my lab, so I thought probably it was OK (and of course your results confirm this).

Also, I'm pretty sure that it is not necessary to restart the media server after configuring the TTS server in the MRCP area of the AAMS.

Finally to expand more on how to force a particular AAMS to be used when doing troubleshooting, in Breeze 3.4, if you configure a location for the Breeze (in the System Manager at Routing->SIP Entities) and configure the same location for an AAMS (in the System Manager at Media Server->Server Administration), that AAMS will be chosen for use with calls on that Breeze (assuming the AAMS is in an active, non-overloaded state). With Breeze 3.5 additional, enhanced configuration is available for influencing how an AAMS is selected.

Hi,

What version of Breeze are you using? One way to force everything to one AAMS is to put all but one AAMS in locked mode. If you are using a new enough version of Breeze, there is also a way to configure locations so that the AAMS in the same location as the Breeze node will be preferred.

Here are some additional questions:

1. What engine do you have configured for TTS? Is it Nuance?
2. What happens when you try using the "cstore" announcement source that I mentioned previously?

Thanks.

--Rob

Hi,

Right after the prompt and collect operation is passed to the media server, the media server generates the following event:

<?xml version="1.0" encoding="UTF-8"?>
<controlContextEventList version="1.0" loadfactor="1">
<msmlEvent sid="59d93bc9-f21c-3227-b2af-5f9ab93d4ba6" seq="1">
<msml version="1.1">
<event name="msml.dialog.exit"
id="conn:fe46b358-96cf-3322-9b79-38a3b37ffb15/dialog:787a0037-cd98-4102-9964-48a9de275da8">
<name>dialog.exit.description</name>
<value>No resource to fulfill request</value>
<name>dialog.exit.status</name>
<value>520</value>
</event>
</msml>

I believe this probably indicates that your TTS settings are still not quite correct. To confirm this, could you please try doing prompt and collect with an audio file? I believe the following wav file should be present on your AAMS:

cstore://october?ns=mmf&cg=system/default

(Just use this as your source instead of "Please press 1 to approve your order".) If this works, then I'm wondering if you have configured a TTS engine like Nuance or similar on your AAMS?

Thanks.

--Rob

Unfortunately, Breeze does not provide a way for a snap-in to get notified when a fax (CNG) tone is present on a call.

Hi,

Could you please post the full exception stack you are getting? Also, you said the following:

================
The dependecy that is giving probles is aspectjweaver. I have seen third party libraries in my cluster they do not have aspectjweaver jar in ext folder. It should ideally download teh jar and use the classes in it.
================

I'm not sure exactly what you mean with the above statement, but I just want to be sure that something is clear. Breeze itself will not dynamically download any jars and place them on the system as a result of a dependency needed by a snap-in. On the other hand, the dependency of aspectjweaver that you have specified in your POM file should result in the aspectjweaver jar being included in your snap-in during the build of your snap-in. And perhaps it is this latter sense of "download the jar" that you had in mind.

Thanks.

--Rob

To add to what Joel has said, the current error is this:

2018-04-10 18:52:30,351 [WorkManager.MediaServerThreadPool : 0] com.avaya.AamsConnectorLibrary FINE - [retryRequest threadId=0x000000CB executionCount=1 exception=javax.net.ssl.SSLPeerUnverifiedException: Host name 'ipclab-mediaserver.ipclab.org' does not match the certificate subject provided by the peer (CN=Default Staging Certificate, OU=Avaya Media Server, O=Avaya, C=US)]

This looks to me as if the default certificate that comes with AAMS is being used. During enrollment of the AAMS to the System Manager, a certificate gets created. Can you double check that the steps have been followed on the AAMS to assign that certificate to the service profiles accessed at Home » Security » Certificate Management » Key Store ?

It's not clear what might be going on. Could you enable finest logging ("ce dlogon" from the Breeze command line) and then run the test several times so that you capture 1 successful case and 1 failed case? Then attach the asm.log file(s) that include the success and failure? Also, be sure to indicate the time (machine time) that the call started for each case.

Thank you.

The FQDN of the AAMS must either be configured in DNS or it must be added to /etc/hosts on each Breeze node.