Number of CTI Links through AES

[defjon]

Anyone got thoughts on this? Have just upgraded from CM2.2 to CM3.1. We had 3 CTI boxes (Live, redundant & development) running through DLG to CLAN - no problem.

We bring in 1 AES box (2nd to follow - design oversight) expecting to be able to implement the same design, but it seems (according to maintainer) now we can only have 1 TSAPI link to our CTI boxes for each AES box - which means we lose redundancy & development servers unless we buy an AES server for each...?? Can this be right?

Can anyone help or point me in the direction of some decent documentation to challeng our maintainers with?

Thanks in advance
dj

 

[Cti4all]

You can do dev on either box unless you are serving some huge number of users (like 10K). Presumably the backup server would be a good candidate for DEV to be configured on as it will typically not be used for production. And you will probably be busy recovering the primary rather than working on DEV projects in the event of primary failure.

Simply create additional Switch Connections, and create additional TSAPI Links set to use different CTI links in CM. Then, associate the devices the Dev system will control to the TLINK for the Dev CTI links which in turn will use the DEV CTI Links in CM. Anytime a user requests control of a device that has the TLINK defined as the DEV link, it will use the alternate link. You will also need all of the other devices associated with the prod TLINK as AES might try to use either link if left at ANY.

The combo of Switch Connections and TSAPI Links will generate new TLINKS, and the app simply logs in specifying which TLINK it wishes to use (or you associate the login used for each app to the TLINK you want the login to use).

You aksi might need additional AES CLAN connection licenses to do this (each CLAN you connect to will consume a licensed connection).

 

[defjon]

Thanks for the response, but the issue is that we need at least 2 live links up, then in the event of a failure on the primary it routes to the backup seamlessly.

Hence a failure in the primary shouldn't be noticed by the business & we can recover it at our leisure.

This is what we had in place, as well as a 3rd link to Dev which we could could work on whenever we needed - allowing us to test off line, then apply changes to the secondary box during the day, switch to that box for call control and then update the primary, all without the business noticing.

So one link kicking in through AES (if thats what you were getting at) when the other fails is really a loss of functionality & resiliance..apologies if i read this wrong but thanks for the response..

 

[petran]

Ask whoever provided the AES server if you can have more links with more licenses activated on the AES and see what they reply

Petran.

 

[defjon]

Yes - we did that. They initially provided it on the understanding (from them) it would support our current 3 link configuration. While installing they fopund it would only accept 1 (from however they had it conbfigured).

Now they seem to be adamant they were wrong in the first place and seem very reluctant to double check with Avaya.

I'm after a bit of experience to confirm this as I'm not so sure Avaya would reduce functionality so spectacularly (though it will bring them in plenty of cash when we all have to buy numerous AES boxes) - I'm actually trying to do the maintainers a favour!

 

[defjon]

oh - it's not something that can be licenced per S8500...apparently