This small article will not cover anything about Asterisk dialplan. It will be about ARI – a flexible interface for Asterisk management.
As soon as Asterisk receives an invite and the call goes to our application (Stasis), we get the opportunity for low-level call construction.
Interaction with ARI occurs through receiving events via WebSocket from Asterisk, processing and creating new events through HTTP REST API towards ARI.
StasisStart
The event that our program receives when the channel enters the Stasis context is StasisStart. It can signal, for example, the start of an outbound or inbound call, as a result of which we launch low-level logic to create a channel towards another subscriber, add it to the bridge with the initiator channel, and make a call.
Simplified scenario of a regular call
- Received StasisStart event from ARI indicating channel A has been created.
- Created channel B with an endpoint towards a SIP peer, or a local proxy (example: SIP/MY_PEER/331234567890).
- Combined channel A from step 1 and channel B from step 2 into a bridge.
- Initiated a dial into channel B.
- Waited for the ARI ChannelStateChange event for channel B. And if the state is ‘Up’, launched an answer in channel A and the dialog begins.
- When receiving the ChannelHangupRequest event for either channel A or B, we terminate the call.
Call session
It may be necessary to store data about the call process, including CDR, for each channel.
As a storage solution, I would recommend using Redis, as high CPS and intensive database queries can create significant load on the hard drives and cause performance degradation.
Optimization
To ensure optimal operation of your ARI application under high CPS, I would recommend minimizing queries to the relational database. In my practice, I used queries only for minor limiting logic during call initialization and for recording CDR data after the call is completed. All other queries are performed in Redis.
I also recommend placing the your ARI application on the same host as Asterisk for infrastructure purposes in order to reduce latency.
Performance test
For testing, I used the console utility baresip, initiating a bash script to perform 200 calls to a pool of test numbers that answer with asterisk tt-monkeys.
200 parallel calls consumed about 5% of CPU load in total. All calls ended successfully, including recorded CDR data.
