[SR-Users] [OT] sems [and kamailio] in risk-of-life service

just forwarding from SEMS mailing list an interesting story of using kamailio and sems in emergency services... -------- Original Message -------- Subject: [Sems] sems in risk-of-life service Date: Thu, 24 May 2012 15:29:38 +0800 From: Jeremy A <jeremy(a)electrosilk.net> To: sems(a)lists.iptel.org Hi, This is a belated report on the use of SEMS in a risk of life service. The system uses kamailio in a distributed architecture of dozens of Fire & Rescue stations. This is heavily based on distributed and replicated DNS. A single '911' style headquarters has duplicate hot swap-over control rooms at other locations. The headquarter and alternate posts have servers that service HQ operator positions with SIP phones. These provides sidecar indication of F&R Station state for up to 64 F&R stations - using BLF. These phones are hooked into an integrated analogue audio management system. Each Fire and Rescue station has an embedded SIP based controller that runs Kamailio and proprietary software to control the F&R station electrical and safety systems as well as provide public address functions to alert the F&R staff of a new emergency. These PA announcements are SIP based using a DSL network and are live from the HQ positions, plus computer synthesized voice, as well as alerting tones. Each station also has multiple SIP phones for in-station and station to station calling. The network is decentralized so failure of the central control system still allows point to point communications between Fire and Rescue stations. The headquarter systems uses SEMS as the primary operator manager to perform multiple simultaneous deployment calls to remote Fire and Rescue stations. SEMS is used to create a dynamic conference between an operator and multiple Fire & Rescue stations. These are automatically initiated by SEMS and answered by the F&R embedded systems. This means an operator can broadcast a deployment message and initiate station control activities at up to five stations (fifth alarm) This is only constrained by the bandwidth available at the headquarters. Our SEMS packages have been designed to handle non-answered calls to the conference and provide operator indication by 'SMS' messages to the handsets and audio feedback. The system provides full forensic recording by using rtpproxy at all locations. These recordings are archived by an out-of-band process. Control of the system is purely SIP based - so every item in the system is a SIP based entity. This includes servers, embedded systems, and phones. The phones are physically integrated into operator positions that also handle PSTN, PBX, and radio traffic. The interface is purely keyboard on the operator phones. Options for integration of the SIP system into CAD (Computer Aided Dispatch) are obvious. The only drawback is the rusty and ancient systems and the unbelievable process required to get approval to integrate. The system as provided provides at least 5 nines reliability. Probably a lot better. The only downside is the DSL network (provided by others at amazing expense) that provides a system with a lousy 2 nines reliability. We are in the process of developing an offering using redundant DLS/3G routing to improve this. The field stations are a hybrid Centos 5/Slax system running out of flash. The HQ systems are straight Centos 5 systems running off disk or off flash. Future versions will be pure Centos out of flash with no fancy memory overlay - flash is well good enough. The system has been live for over a year with no major issues. I can't say how many lives have been saved, but certainly quite a few. At least we haven't been sued yet :-) Cheers.