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!!!!
