just forwarding from SEMS mailing
list an interesting story of using kamailio and sems in emergency
services...
-------- Original Message --------
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.