CTI solution
- Thread starter Andyd358
- Start date
- Status
Thank god for that thought I was goinig mad. Been searching for days for one. I know my previous manager had setup a TAPI solution but that hooked into the yealink phones for a customer we had, no idea how it worked though.
thanks for replying so quickly and putting me out of my mysery
Hey @DigitalDaz , I was thinking, a CTI provides events and integration into the system. Isn't it what ESL can provide? I know, it would be all custom code but I was thinking about getting started on such a project. What do you think?
I am more of a telecom guy than a developer, so that would be a huge undertake for me but it could be interesting. Just want to have validation from someone with more experience. Is that a viable path for a CTI solution?
I am more of a telecom guy than a developer, so that would be a huge undertake for me but it could be interesting. Just want to have validation from someone with more experience. Is that a viable path for a CTI solution?
The event socket, yes you can create custom events. I made one quite recently that triggered an event for a registration attempt.
For event notification, ESL will work but it isn't straight forward at all. Controlling the phone on the other hand needs to be done in a different manner. I have this working with yealink phones and have a poc with polycom but I would like a more standard based approach using csta and I am looking at options now. That being said, using ESL and yealink work very well and we have this running in Salesforce today.
CTI (Computer Telephony Integration) By this are you referring to a specific protocol if so do you have a link to any documentation for the protocol? Or you are just referring to things like controlling phone from a computer like through a REST API or click to call? CTI integration as the entire description seems like you could be more direct on what elements of the telephony integration you are referring to.
CTI is a concept. Each telephony vendor has its own approach. For instance Genesys T-SAPI or SIP server, Avaya TSAPI. Cisco and Microsoft have been using TAPI which is, as far as know, the closes to a standard protocol you can get.
I have been working, as an integrator, with CTI powered system for many years. Call recording and Work Force Management systems are notorious examples.
Basically what CTI is useful for is for third party systems to receive details of what is happening in the call center: call start, call send to ACD, call send to agent, transfer, etc. CTI is also used to pass information back to the telephony system based on actions by the call centre agent.
So, in that sense, CTI becomes a notifier of events and receiver of instructions. I agree ESL has the basics to get to that point but it is far from being easy to have a full working enterprise ready implementation. Enterprise is where it matters, an office PBX benefits almost nothing from a CTI integration, call centres is where it becomes really useful.
I know that from a modern communication system perspective this all sounds a bit odd. After all, all data is going through SIP or WebRTC. A developer may say, just get an API to give you the information you need or, in the worst case scenario, parse it from the wire. Well, this started when telephony was a world appart from computing systems. Telephony people had (and many still do not) have any idea of coding or even what an API is (I know, I used to be one of those - I am still trying to catch up) and developers tend to consider voice and video as just another piece of code without taking into account the incredible reliability those systems were designed for.
Anyway, CTI in the industry is still useful although the name and origin seem a bit odd nowadays.
I have been working, as an integrator, with CTI powered system for many years. Call recording and Work Force Management systems are notorious examples.
Basically what CTI is useful for is for third party systems to receive details of what is happening in the call center: call start, call send to ACD, call send to agent, transfer, etc. CTI is also used to pass information back to the telephony system based on actions by the call centre agent.
So, in that sense, CTI becomes a notifier of events and receiver of instructions. I agree ESL has the basics to get to that point but it is far from being easy to have a full working enterprise ready implementation. Enterprise is where it matters, an office PBX benefits almost nothing from a CTI integration, call centres is where it becomes really useful.
I know that from a modern communication system perspective this all sounds a bit odd. After all, all data is going through SIP or WebRTC. A developer may say, just get an API to give you the information you need or, in the worst case scenario, parse it from the wire. Well, this started when telephony was a world appart from computing systems. Telephony people had (and many still do not) have any idea of coding or even what an API is (I know, I used to be one of those - I am still trying to catch up) and developers tend to consider voice and video as just another piece of code without taking into account the incredible reliability those systems were designed for.
Anyway, CTI in the industry is still useful although the name and origin seem a bit odd nowadays.
Last edited:
ECMA (European manufacturers association) publishes the CSTA standard which is the backbone for almost all of the CTI protocols - JTAPI (mostly used by Avaya and Cisco) and TSAPI (mostly used by Genesys and Avaya). Most phone vendors today (polycom/yealink/et al) support CSTA over SIP (uaCSTA or also known as TR/87) and that XML protocol is documented here:
http://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm
https://www.ecma-international.org/publications/techreports/E-TR-087.htm
Ultimately I think the goal is to support uaCSTA and I have done a lot of research and here are some of my findings:
http://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm
https://www.ecma-international.org/publications/techreports/E-TR-087.htm
Ultimately I think the goal is to support uaCSTA and I have done a lot of research and here are some of my findings:
- There was a FreeSWITCH module created several years ago that attempted this. I have read through all of the code and it looks pretty well done but I have yet to install/test it just because it is so old. https://sourceforge.net/projects/cstainside/
- ESL events are really great and meet 50% of the CSTA needs (event subscription) and also add other functionality that CSTA doesnt support today. Obviously you don't want to expose ESL to the public so publishing this via some other connectivity (like web socket) would be preferable.
- Meeting the other half of the CTI needs (controlling the end phone to answer, transfer, hold, conference, etc) could be done by only invoking those specific function calls in CSTA. FreeSWITCH supports sending NOTIFY messages with some flexibility via ESL but the INFO messages that can be send from ESL is very limited. Se the mod_sofia.c code for sending info (to_uri is not set properly for a NAT environment among other things): https://github.com/signalwire/frees...src/mod/endpoints/mod_sofia/mod_sofia.c#L5699 You can see sending NOTIFY messages via ESL is much more extensive and essentially has what we need: https://github.com/signalwire/frees...src/mod/endpoints/mod_sofia/mod_sofia.c#L5338 I have a fork of FreeSWITCH that supports the proper sending of INFO messages but need to find time to finish testing with phone.
- I am still stuck in an analysis paralysis situation about how to best support event notification within the current PHP based solution and I would love some feedback. I have heavily research how to get PHP to support this via websockets and/or long running processes (event loops) but I am pretty confident that PHP is not the right solution due to scalability and stability issues. What I typically use would be Java (and it works well) but implementing the entire java stack (runtime, tomcat, etc) isn't a preferable approach and that led me to look at Go/Golang. I went down the path of Go but implementing the event loop there turns out to be a real mess (I see a lot of people using uWebSockets instead) and ESL socket support is limited in my cursory review. This all leads me to NodeJS as it has great ESL support, the event loop is already there but the single threading nature give me concern and I would like the broader community buy in before heading down that path.
Awesome review! Thanks for taking the time @brb5548. As I mentioned before I am not a developer so I am not sure about all the architectural differences in the languages but coming from a Telecom background I have a lot of confidence on Erlang, it is multi thread and HA is its DNA. It's been running the backbone of telecom for many years. There is even a mod_erlang already built in freeswitch and I believe Kazoo uses it.
That being said, I tried learning Erlang but my poor brain could not handle it. I found Elixir which actually runs on the same Erlang VM. I have coded a couple of non-telecom apps and I must say it is a very flexible language. I believe more dev trained guys than myself could do a lot of interesting things using Elixir and freeswitch. There is even an old project on it.
Just food for thought.
I haven't spent much time with erlang but it intrigues me quite a bit (functional programming and failure handling specifically) but I am not sure a community based open source project would be successful using erlang. Elastic uses it and does wonders but that isn't really built by a community.
Curious if @markjcrane has thought about what comes after PHP for needs like this (long running processes, web sockets, etc).
Curious if @markjcrane has thought about what comes after PHP for needs like this (long running processes, web sockets, etc).
I have zero interest in Erlang. If FusionPBX were to ever change languages or add another language it is very unlikely to be Erlang. So if you want Erlang I suggest using Kazoo they have been working with it for several years.
I have written a Caller ID and Click to dial app. It works with Escene, Fanvil and Yealink phones. It Works directly with the phone and has no need to link to the PBX. At the moment it looks up Caller ID from HighriseCRM CommitCRM A custom Sales force app and a custom CakePHP app. With chome addons it can also do click to dial and SMS with Click send.
@markjcrane I totally agree but how to we best handle things like websocket support and long running processes? Node? Java?
Erlang seems too complicated to me. I think Elixir would be a good fit: the power of Erlang plus the flexible code experience of Ruby.
- Status