This article originally appeared in the July 2013 issue of SD&I magazine.
The “network-everywhere” methodology has infiltrated our lives and most of us are attempting to negotiate a network connection at some point every day. This is the very nature of Session Initiation Protocol, or SIP, which primarily exists for the purpose of negotiating a voice or video connection between two points.
SIP plays a role in the security industry when it comes to paging systems, intercoms and emergency phones. SIP should not be confused as a standard to ensure the reliability of other security technologies such as voice evacuation and emergency messaging systems. Standards such as UL864, EN 60489A or EN 54-16 apply to these types of systems.
While SIP typically doesn’t fare well when simultaneously addressing multiple zones in evacuation scenarios or otherwise, there are many useful applications in the security space, including: connection from phones, desktops and other VoIP devices into paging systems; intercom connectivity to and from help points and emergency distress phones; and simple paging or intercom system protocols without a phone system connection.
Nuts and bolts of SIP
SIP is best known in the business world for the simple purpose of signaling phone calls in the IP domain. What is perhaps less often understood is the fact that SIP has little to do with the audio transfer itself. SIP carries out the call setup negotiation between two devices at the initiation phase, signaling call events (transfer requests, for example) during the connection, as well as call termination.
SIP does not play a role in the actual audio/video delivery. In the SIP environment, audio carriage is almost always carried out using RTP (real-time protocol), with parameters and details such as audio formats and transmission methods negotiated between two peers using SIP. The combined power of SIP and RTP can support VoIP as well video connections and audio contribution to monitoring centers, for example. From this perspective, SIP provides a flexible architecture to enable device communication, mainly for point-to-point connections.
Paging systems
The majority of SIP-related communications have an IP PBX phone system at the core, such as for paging systems and intercoms. Integrators will require some basic IT and phone system programming knowledge to enable SIP across security applications. This essentially means defining extensions for each connected device through server ports and IP addresses, extension numbers and secrets.
The range of potential connected devices is what makes SIP intriguing in the security space. Linking to paging systems—or alternatively, using an IP phone system as a paging system— simply requires SIP endpoints to translate between IP and analog audio. One example is a Barix Exstreamer device, which feeds its audio output into a traditional paging amplifier that feeds the audio to a room, zone or building. Other Exstreamer models will directly feed into speakers with their built-in amplifiers. In both cases, the device supports the necessary audio decoding and represents an IP-addressable, SIP-capable receiving device that the PBX recognizes as a phone extension.
In such scenarios, a security guard in a monitoring center can place a phone (SIP) call direct to the endpoint device, and upon acceptance, a relay fires, activating the paging system and, if necessary, overriding general audio streams (such as background music in office environments). Devices with integrated amplifiers override IP-based backup streams and of course do not need the relay to activate.
This is a very basic application that is best used for general paging or backup emergency communication. The advantage for integrators is simplicity, essentially turning an analog paging system or speaker into an IP paging system or IP speaker without additional components.
Emergency distress
IP-based intercoms are gaining momentum in the security market, and the SIP environment is particularly useful for establishing intercom functionality at help points. In this case, integrators can establish one-way streaming from the remote help point, or enable bi-directional streaming for two-way communications based on PBX and network configurations.
Take transportation for example: Board any train today and you will most likely notice a panel with a button and a lamp—this is the passenger’s connection to the outside. In the SIP environment, pressing the button will automatically route the call to an available source. This is because the SIP protocol also supports automatic call forwarding services to enable that automatic routing, often via blind transfers to ensure interoperability with automated devices.
The SIP call refer/forwarding capability is significant for emergency situations where it is imperative the call is received. The integration of a SIP server establishes that mediation point with central routing intelligence. This enables the system to recognize that a call is being targeted for a group, while also identifying destinations that are unable to accept such a request do to being busy, offline or otherwise unavailable.
Schools represent another example where SIP-driven emergency intercom makes sense. Here, a press-to-talk button in the classroom opens a direct two-way channel to the main office; and SIP automatically transfers unanswered calls to the local police station. This represents a controlled telephone system, typically operating completely independent of a certified evacuation system, where a teacher or student presses a button and waits for an external source to answer the call. This is another case where SIP essentially establishes a lifeline to the outside.
It is possible to use the SIP protocol without an IP PBX, employing a series of paging stations and receivers to enable one- and two-way communications. As a real-world example, a paging station acts as a specialized phone, with press-to-talk buttons that establish connection to an IP phone or another receiving device. This would require the necessary intelligence in the paging stations so that they can operate with the SIP protocol “peer to peer” mode.
The benefit here is that this kind of system can later be seamlessly integrated into an IP PBX phone system to expand functionality; however, this system can remain separate if desired. In any instance, SIP is not tied to the fixed environment — roaming security guards, for example, can receive SIP calls on mobile phones and VHF radios without challenge. Those same guards can easily make calls from their phones as well by dialing into the PBX and entering a security code to page a specific location or zone. This is most typical in a “SIP Gateway” scenario, where a guard can unlock the announcement capability on any connected device. Here, security personnel can then select a group or zone, and the SIP Gateway will translate the information into the Audio over IP domain. This enables immediate, priority-based stream delivery to other receiving devices in the network.
SIP beyond security
SIP delivers another benefit through automatic negotiation of codec choice. SIP devices typically enable negotiations of the audio codec used on a per-connection basis, chiefly because bandwidth may be more important than audio quality in telephone communications. In other cases, a communication partner may not support the standard codec used for most connections.
The SIP protocol can automatically negotiate the use of a matching, VoIP supported codec when SIP-capable devices are operating within a larger Audio over IP domain, for example. Although naturally inclined to use high-quality audio codecs, the SIP-enabled Audio over IP device will accept 8 kHz voice quality if that is what is provided by the VoIP system.
The introduction of a SIP Gateway also unlocks a new universe that can combine both security and more common applications. This is most useful when directing background music, paging and public address to loudspeaker systems as opposed to simply routing phone calls.
Let’s assume an integrator is installing 100 devices in an office-wide communications system, with background music streaming in high-quality, MP3 encoding, to each device from 10 channels. This can be easily accomplished without any need for SIP by using 10 multicast MP3 encoded streams and 100 receivers with local control for channel selection. Let's further assume that the end-user wants to make announcements to these 100 devices from a SIP-based phone system. This traditionally means that each device must be subscribed to the PBX system. The PBX needs to talk to each device to communicate it wants to send an announcement, while also negotiating the codec. This can take some time before all the devices in the system are online and willing to listen. And it can be costly to add 100 telephone licenses to the PBX.
The gateway solution enables one device to translate a unicast (single) SIP call to a broadcast/multicast in the audio over IP domain, for purposes such as group addressing. This allows use of the same codec to distribute a multicast announcement that the receiving devices understand. The SIP gateway can also be programmed to prioritize announcements over other audio stream sources. The SIP protocol will translate the priority announcement request only to the targeted groups or zones, allowing the general Audio over IP streaming to continue uninterrupted in all other areas.
This is the essence of what it means when comparing audio over IP and SIP concepts: a continuous stream, zoning and priority compared to temporary, exclusive connections. Integrating both over a common network infrastructure creates a solution that provides the best of both worlds.
