Hi Martin-san,

Thank you for your reply.

I see. Actually, we already rised SR ticket for this phenomenon.
So, I will co-work it with SR engineer.

Btw, I found below previous forum ticket.
If it is fit for my faced phenomenon, it is really good information for us to find out route cause.
If you have any sugession on this, please advice.

-----
http://www.devconnectprogram.com/forums/posts/list/5214.page
by JohnBiggs
If you get a monitor ended, and can not re-establish the monitor using the same stream/T-Link, then open another stream to the alternate T-Link and attempt to establish the monitor on that stream. Some applications open both streams as they initialize, and setup half the monitors on one stream and half on the other. That way they get a better indication of T-Link failure and they impact fewer clients if and when it does occur.
-----

Best regards, K.Yamahara

Hi Team,

Please comment on this.
If remaining ACS stream after restart CM and AES is normal phenomenon as TSAPI spec, please explain reason why it was remain.
Currently, we don't think that it is critical issue.
We just would like to know reason.

Best regards, K.Yamahara

Hi Team,

Could anyone advice on this?

Best regards, K.Yamahara

Hi Team,

We are configuring our system as below.

CM#1 -- -- AES#1 -- -- WAS#1(9*AESconncter with vms/applications)
X X Call Routing#1(1*CallRoutingApp)
CM#2 -- -- AES#2 -- -- WAS#2(6*AESconncter with vms/applications)

OD : 07.00.18.01
JTAPI client 6.1.0.94
AESconnector 07.00.18.01
AES : 6.3.3 Super Patch 5

Please refer detail configuration to "events09282016-2.pptx".

On this configuration, we performed call test after CM outage test and AES start/stop test.
Before all of test, we confiremd to establish total 16 ACS stream with AES Management console.
(9*ACS stream on WAS#1, 6*ACS stream on WAS#2, 1*ACS stream on Call Routing#1, Total 16*ACS stream)

Then we performed CM#1 and CM#2 outage/down at the same time.
(Lot of ACS streams were increased)

About 10 minutes later, CM#1 and #2 were re-connected to AES#1 and AES#2.
(Lot of ACS streams were remained)

Then we stoped AES#2 -> stop AES#1 -> restart AES#1 -> restart AES#2.
After that, lot of ACS stream were terminated.
However one more ACS stream were remained on each AESconncter.
(18*ACS stream on WAS#1, 12*ACS stream on WAS#2, 1*ACS stream on Call Routing#1, Total 31*ACS stream)

We believe that an application should only open one stream per advertised service.

So, please advice reason why those additional ACS stream were remained.
We believe that those additional ACS stream should be terminated after restart AES#1 and #2.


All of trace files were uploaded to below ftp site.
ftp.avaya.com/incoming/guests/kkudo/1-12366059322/
username: kkudo_g1
password: Wel1234

Best regards, K.Yamahara

Hi Team,

We are configuring our system as below.

CM#1 -- -- AES#1 -- -- WAS#1(9*AESconncter with vms/applications)
X X Call Routing#1(1*CallRoutingApp)
CM#2 -- -- AES#2 -- -- WAS#2(6*AESconncter with vms/applications)

OD : 07.00.18.01
AES : 6.3.3 Super Patch 5

Please refer detail configuration to "events09282016-2.pptx".

On this configuration, we performed call test after CM outage test and AES start/stop test.
Before all of test, we confiremd to establish total 16 ACS stream with AES Management console.
(9*ACS stream on WAS#1, 6*ACS stream on WAS#2, 1*ACS stream on Call Routing#1, Total 16*ACS stream)

Then we performed CM#1 and CM#2 outage/down at the same time.
(Lot of ACS streams were increased)

About 10 minutes later, CM#1 and #2 were re-connected to AES#1 and AES#2.
(Lot of ACS streams were remained)

Then we stoped AES#2 -> stop AES#1 -> restart AES#1 -> restart AES#2.
After that, lot of ACS stream were terminated.
However some of additional ACS stream were remained on each AESconncter.
(18*ACS stream on WAS#1, 12*ACS stream on WAS#2, 1*ACS stream on Call Routing#1, Total 31*ACS stream)

So, please advice reason why those additional ACS stream were remained.
We believe that those additional ACS stream should be terminated after restart AES#1 and #2.

All of trace files were uploaded to below ftp site.
ftp.avaya.com/incoming/guests/kkudo/1-12366059322/
username: kkudo_g1
password: Wel1234

Best regards, K.Yamahara

Hi Team,

We are going to use OD7.1.
In release note, it was discribed to support Websphere 8.5.5 application server.

Can OD7.1 support the Websphere 9 application server?

If not at this moment, does AVAYA has plan to support the Websphere 9 application server on future version?

Best regards, K.Yamahara

Hi WilsonYu-san,

Thank you for your suggestion.

We are asking to do simulation to Apps team.
In parallel, we raised SR for this.

Then we don't have any update from both side today.
If we need your help, we will ask it to you again.

Best regards, K.Yamahara

Hi WilsonYu-san,

We have rised SR for this.

And we tried to do some test.
Originally, we transfered call to Tranking Line(01860362635859) from Extension(59902).
In this case, we can not catch "no answer" after RingMax=1(6sec) setting.

Then we tried to transfer it to other Extension.
In this case, we can catch "no answer" after RingMax=1(6sec) setting.

So, we are thinking that there are some setting issue on AES or CM.
we will investigate it with SR continuously.
If we need your help again, we will ask it to you again.

Best regards, k.Yamahara

Hi WilsonYu-san,

I'm co-working this with Norimasa.

>Did you get this error on a live call or simulation?
[Kenji]
Actually, we got this error on a live call.

>Have you tested the app in simulation?
[Kenji]
We will suggenst to do simulation to our App team.
In this simulation, should we test this step by step by simulation?
If you have any suggestion, please advice.

Best regards, K.Yamahara

Hi WilsonYu-san,

Thank you for your investigation and advice.

We will rise SR to investigate your pointed out portion.

Best regards, K.Yamahara

Hi RossYakulis-san,

> Try setting “transfer on ring” = true and see if that helps.
[Kenji]
We have tried to do this.

When we set “transfer on ring” = true, Ring Max value portion was hide(We can not set any value to RingMax.).
Then we have make call.
As a results, Caller heared RBT(RingBackTone). Then the FetchTimeOut was occuered after 30sec.
Those were almost same phenomenon as Blind Transfer.
Is this your expected correct phenomenon?

On the other hands, we also confirmed below setting on CM.
system-parameters features
Station Tone Forward Disconnect = "silence"

So, should we ask investigation on this via SR?

>Also, a ringmax of 1 is very uncommon as a transfer can take more than 6 seconds. I always recommend at least 2.
[Kenji]
When we set “transfer on ring” = false again with RingMax = 2 or 3, we can not catch "no answer".

So, Please advice how to set any parameter including RingMax and fecthTimeout to catch "no answer".


Btw, if there are any other methodologies to catch "no answer", please advice to us as well.
Your ealy reply is really appritiate for us. Because we don't have enough time to resolve this issue.

Best regards, K.Yamahara

Hi WilsonYu-san,

Thank you for your advice.

We will try to replace it once. Then If I need your help, we will ask it again.
Please close this ticket.

Thank you and regards, k.Yamahara

Hi RossYakulis-san,

Thank you for your suggestion.

We will try to do that.
Then we will feed it back to you.

Best regards, K.Yamahara

Hi Team,

We are using below version.
Aura Orchestration Designer 07.00.18.01?
JTAPI client 6.1.0.94
AESconnector 07.00.18.01
AE Services 6.3.3 Super Patch 5

In this configuration, we faced similar phenomenon as below.
Actually, we asked to compare our phenomenon and below with SR1-12363304004.
And we also confirmed there is a fixed version of JTAPI client(ecsjtapia-6.1.0.SJ12254A.jar) for this phenomenon.

So, can we use the fixed version of JTAPI client(ecsjtapia-6.1.0.SJ12254A.jar) for Orchestration Designer 07.00.18.01?
If you accept, please advice how we can install it?
Can we over write it to current version of JTAPI client in Orchestration Designer 07.00.18.01?
-----
In a JTAPI application with multiple providers, if one provider went Out Of
Service (due to lost network connectivity between the client and AE Services
Server, for example), event delivery for events from the other providers was
also stopped. Any events received from the other providers were not
delivered to the client application. This issue has been resolved in R6.3.
-----

Best regards, K.Yamahara

Hi RossYakulis-san,

Do you have any update?
If you need more information, please let me know.

Best regards, K.Yamahara