What is the recommended practice for triggering (and receiving) CTI events for VOIP calls into Asterisk? Here are examples of CTI events we would like to receive:
- Caller is connected to someone.
- Caller is disconnected.
- Caller is transferred.
Thanks.
1 Like
The most common interface people use is AMI[1] which provides various events[2].
[1] The Asterisk Manager TCP IP API - Asterisk Documentation
[2] AMI Events - Asterisk Documentation
I believe AMI dispatches CTI events over a TCP socket to our application. Is there any way to avoid a persistent connection like a socket? The socket seems like overkill, as the CTI events – at least for our use case – our sparse (in many cases, only 2 CTI events per call).
1 Like
On Tuesday 04 March 2025 at 21:28:58, kc20250128 via Asterisk Community wrote:
I believe AMI dispatches CTI events over a TCP socket to our application.
This is correct.
Is there any way to avoid a persistent connection like a socket? The
socket seems like overkill, as the CTI events – at least for our use case
– our sparse (in many cases, only 2 CTI events per call).
a) What is your problem with a persistent socket? If no data arrives, what
resources get used?
b) How else can you receive asynchronous events over a network connection
where the client has to subscribe to the server?
Asterisk has no mechanism for setting up what are commonly called callbacks,
which would mean that it would spontaneously make a connection to a listener
somewhere, every time Asterisk had some event to report.
For most people’s use of AMI, this would in fact be a real resource hog, since
the number of events per minute, or per second, would mean the cost of setting
up a new connection from Asterisk to the listener for every event would be
extreme.
Antony.
–
If my advice was worth anything, I wouldn’t just give it away.
I believe the pub/sub pattern is commonly used to address this sort of problem. In the case of Amazon Connect, for example, CTI events are published to the default messaging bus. If you’re interested, you subscribe to that messaging bus and then do whatever you want with the events.
By directly connecting to the Asterisk server – IE, by opening a TCP socket – your application absorbs and underutilizes resources that could be otherwise deployed.
1 Like
Other individuals have written proxies that connect to AMI, and publish into other message buses. There’s nothing built in though.
AMI does allow filtering of events to reduce traffic.
1 Like
How is this “messaging bus” implemented? Isn’t it over some kind of network? Or is it internal to a single node?
1 Like
I don’t know how Amazon Connect does it. But Kafka is an example of an enterprise messaging bus that implements the pub/sub pattern.
1 Like
Kafka uses a TCP connection.
It sounds like you want a complete solution, while Asterisk is a component that can be used with other things.
1 Like
Kafka uses a TCP connection.
True.
Are any of the subscriber-proxies available as Asterisk modules?
1 Like
There’s nothing built into Asterisk, no.
1 Like
Maybe I can help, I have an easy way to provide data!
How about an MQTT Server in Node-RED?
So the OP wants a solution that avoids a persistent TCP connection to Asterisk, by adding a persistent TCP connection to something else instead?
If you are worried about keeping some connection open but idle for a long time, only to discover, when you try to use it, that it has become disconnected in the meantime, that’s a legitimate concern that any seasoned network programmer can identify with. 
One way to reassure yourself the connection is still up is to send a periodic Ping request, say every 60 seconds if nothing else has happened in the meantime.
The response to a Ping request is not documented on that page, but it looks like
Response: Success
Ping: Pong
Timestamp: ...