This document outlines our VoIP requirements and implementation requirements, the main driver behind this is to have a system that we can deploy in an automated way that automatically gets picked up by controlling software, receives a configuration over an API and runs.
The intended use is to have a 1 to 1 relationship with the controlling software so at this time clustering is not a requirement, we have a requirement that the final solution should be able to be deployed as a Docker image.
We envisage Asterisk to be used as the base system however this is not a hard requirement, if another PBX platform proves to be a better fit for the requirements then we are open to change. This document however will focus on Asterisk concepts and functionality, though these should be understandable and interchangeable with other system concepts.
This is a VoIP PBX system for a cloud based taxi dispatch system, these systems are automatically provisioned with SALT and presently we deploy one or more systems in a load balanced configuration depending on the size of the customer.
We now want to move our VoIP offerings from being on-prem to in the cloud as well, to do this we need to have a solution that we can deploy and configure like our current services. The main requirements are being able to provision and configure inbound and outbound trunks in an automated way, configure extensions for operators and driver’s Android handsets, have extension ring groups and hunt strategies, provisions and configure IVR’s and other TTS announcements.
Any inbound calls should in real time signal to the controlling system when they are received, and which extension answers them, care should be take accurately notify of hold states as well. The controlling system API should be allowed to initiate calls between extensions and also between an extension and trunks.
Systems could crash or be moved at any time, so they need should not store any persistent data. Our SALT stack will detect any failures and will attempt to re-start the container or move it to another location with a fresh configuration, any persistent data will cause the system to fail.
Asterisk has a couple of interface’s that we presently use the AMI and AGI, it is critical that these services are not publically exposed, they should remain bound to localhost in the container the same is a requirement is another system is used.
There is no need to provide any GUI interface for this system all interaction is to be done over the controlling interface API.
• All code is to be developed on our private github repo
• All code developed is owned and copyrighted to us.
• All code requires unit tests to be in place and passing before being accepted
• All integrations require a complete passing set of integration tests, an integration suite will be provided.
• The final solution is to be a deployable Docker image
• We take security very seriously; all code will be reviewed for security flaws.
• API must be over SSL (TLS 1.2) on port 6000 and should be certificate pinned to our root CA
• All Extension SIP signalling should be over SSL (TLS 1.2) and also should be certificate pinned to our root CA
• Extensions should be able to be grouped
• The AGI or similar interface should be available for providing custom IVR workflows
• Real time call information is to be extracted and sent through to the controlling application VIA our message bus, there are 2 protocols available AMPQ or DDP
• Extensions and additional lines should be provisioned as required without requiring a system reboot
• The final Application should be state less loading it’s configuration from a Docker volume, this means no databases as it allows us to kill and replace images and containers as required IE in the event of fail over.
• IP Addresses can change in a moment’s notice as we utilise Docker swarm for the provision of services, this needs to be taken into consideration for NAT rules from the container to the outside world.
• We need to be able to initiate calls in real time, from extension to extension and also extension to trunk, presently we use the Asterisk AMI to do this.
• Any critical ports such as the AGI and AMI should not be exposed outside of the container, exposed ports should be the API, SIP and ports for RPT (10000-20000)
• Extensions will be a combination of Andorid SIP connections and Cisco hardware VoIP phones, the final solution needs to be tested to work with both.
• Internal logging should monitor outbound calls and warn and block unusual activity, for the most part there should be no outbound calls from Android extensions and extensions with permitted outbound routes will be supplied over the API.
• Ideally we want to provision new Trunks in an automated way when deploying new systems, having the API being able to interact with a provider to query and provision these will be a big win for us.
• Due to our need to be able to receive real time call information to our control applications it’s envisaged that rolling out own solution is the best course of action however if there are any providers known to provide this level of exposure we can consider these to build the service around.
15 freelancers are bidding on average £1301 for this job
I have developed many software based on Asterisk PBX, Like IVRS, Conference/Recording/Voicemail system, Voice/Video switch, Inter-Office communication system and more.