AES CSTA Question 1

[telcomwork]

I'm trying to fail over an application produced by GE called MasterMind aka MAS. We successfully have it running on an S8500C AES server but when we try to manually fail it over to the 8500B AES MAS is unable to take control of the phone via a transfer button in the application.



I been going back and fourth with their engineers and they came back and said the problem is on the switch configuration and I should there for the problem. They also stated thier application is sending a "CSTA route selectINV"
but the switch is not sending them a "cstaRouteEndInv". If I look on the AES server the links are up, I changed the vector to adjunct to the failover AES server, .... not sure what else to do or why the switch is not sending "cstaRouteEndInv"


Running a list trace on the vector everything looks good and I don’t have any denials or errors.



Any ideas?

 

[Zowwie438]

wow... I don't like to consider myself the chosen one, but I know this csta stuff like the back of my hand. LOL

Here are some things to note:

1) If your PBX already has a CTI application registered as the "default" gateway... That gateway CTI application is GOD to your PBX and nobody else can register for a route request.

2) Even if #1 is not the case... Only ONE CTI Application can be the route Requestor of any VDN.

The easiest way to test this is:

1) Get a copy and install the Avaya SDK kit that contains the program TSAPIExcerciser (tsapiex.exe).

2) Update the INI file tslib.ini on the machine you install the excerciser to... To point to your tServer or AES server or other TSAPI like gateway.

3) Once you connect... Authenticate using the SAME username and password that the CTI Application that is having issues is using.

Now that you are connected... Try this:

1) From the excerciser, select cstaRouteRegisterReq and enter the VDN in question.

2) Once you get your route register confirmation in your avaya tool... Put a test call in and see if you get prompted with a route request. If you DO, then all is well on the PBX and CTI gateway and your issue is inside this CTI app you made ref to.

3) If you CAN'T route registerReq... Then look at the error code and look it up in the avaya docs. Normally the only reason why you can't register for a route would be:
a) Something else is already using it.
b) Your tryin to register a VDN that doesn't exist.
c) The VDN in question IS NOT inside the SDB database (see the avaya admin tool) or whatever they call it in the aes world.

In closing... If everything is working right, this is how it should flow:

1) CTI application communicates with tServer or AES and asks for a list of advertised names.
2) The tServer/AES and client app (CTI) talk a little and they shake a little.
3) The CTI App will then attempt to authenticate to the tServer or AES using the connection (advertised name) and username/password.
4) Once this auth is done... The CTI app CAN ONLY control what VDNs it has permission to use. See the avaya admin tool or whatever aes uses.
5) Once all that is done... The CTI app will try to perform a cstaRouteRequestReq and the tServer or AES will respond back with a routeReqID that will be his for the duration of his connection to that VDN.
6) Once registered... Calls coming into that vector will have to perform an adjunct link to the correct link number in order to reach the CTI application.
7) In our world... WE MUST put a 2-3sec wait PRIOR to adjunct link and a 6 SEC wait after the link in order to make it work... Without it, the link will never happen and the CTI will never be called.
8) Once the CTI receives the adjunct link request (cstaRouteRequestExt OR cstaRouteRequest)... It may respond back with the following:
cstaRouteSelect
cstaRouteSelectInv
cstaRouteEnd
cstaRouteEndInv
9) Once the routeSelect has been made, the call will be routed to or diverted to where you want it to go. If you are attempting to route to outside lines, be sure to put a 9 in front if that is what your dial plan uses.
10) If the CTI app doesn't want to route the call... It can allow the 6 seconds after the adjunct to timeout and take the default vector route, or it can send back an immediate routeEnd(inv) and allow the default vector route to occur.

Good luck!!!

Let us all know how it turns out.

T. May - Cincinnati Bell
NOTE: Your helpful answer didn't come from the cable company!!!!

 

[Zowwie438]

I forgot a couple things....

1) If you are a CTI application that ROUTES a call... You will see a ROUTE_USED or ROUTE_USED_INV like response that is part of the Route Select Service Response struct. *See note below.

2) If you are a CTI application that FAILS to route a call... Or the PBX vector fly's by and doesn't give you time to respond with a route... Then you MAY NOT get an a route_used event unless you specifically say you want to hear the route_used when you registered.

NOTE: When you register for the route, you can specify in that method if you wish to be notified of routeUsed events... it's a bool setting. If they are not setting it, then they will not be notified of the route that was used by them or a default vector route.

I am assuming that since the CTI app folks are saying "Well, we sent your PBX a cstaRouteRequestInv"... Where is our "cstaRouteEndInv"....

I hate to say it... But they will be waiting for a cstaRouteEndInv until h*ll freezes over because the switch will NEVER send them one! LOL cstaRouteEndInv is something that THEY CALL from their API, not something that they receive!

Basically... If they call:
cstaRouteRequest they should get an ACK of the call to the method.

cstaRouteRequestInv they should get an ACK of their call to the method.

IF and ONLY IF... They specified that they want to be notified of ROUTE_USED or ROUTE_USED_INV when they registered for the route... Will they be notified that the route was used.

I would HIGHLY recommend that you download a copy of defprog.pdf (you can find it on google) and search for:
cstaRouteSelectInv
cstaRouteEndInv
cstaRouteRegisterReq

Each of those methods will tell you exactly what is being sent back to the application, what possible error messages are expected, etc.

In closing... If your vendor is saying that the PBX is NOT sending them a cstaRouteEndInv, you may wish to question their knowledge of the API's and if they know how to use them.

--Todd

 

[telcomwork]

THANK YOU VERY MUCH!