Designing and Implementing an IP Paging System (1 of 4)

Note:  This is the 1st installment of a four part series detailing the design and implementation of an IP paging (paging over VoIP) system. Click here for Part 2, Part 3, and Part 4.

In many new or existing voice over IP deployments, integrating existing paging systems or deploying new IP based paging systems is becoming a much needed necessity.

In this series we will first detail the two common methods that paging is delivered over an IP network utilizing, then discuss how these methods are delivered over network infrastructure such as switches and switches, an IP PBX such as asterisk, and paging endpoints such as IP Phones for desktop paging and overhead speakers and amplifiers that are SIP enabled for much bigger paging solutions.

After we discuss this, we will offer a few product suggestions designed to meet your needs for both desktop paging and overhead paging applications, and last but not least, how to integrate an existing analog based paging system with a new Voice over IP Phone system.

Unicast IP Paging

To fully understand how IP Paging functions, we must first look at the two types of paging that is supported on most IP based PBX’s. The first is called “unicast”, more commonly termed as a unicast page. Unicast pages are delivered on a one to one basis and in our case; the IP PBX is the source for this page. In most common unicast paging setups, administrators will setup a single or numerous page groups in the IP PBX configuration. They will do this by creating a page group by extension. For our example, let’s use a single page group and assign it extension 400.

Paging group 400 then contains (20) SIP extensions that belong to individual users on the system and these extensions are physical SIP endpoints such as an IP Phone. In unicast paging environments, when a user dials paging group 400 from their phone, the IP PBX sets up and maintains 20 individual SIP calls between itself and each IP Phone belonging to the page group 400.The PBX sends SIP and RTP audio traffic to and from each one of these endpoints individually. Now can anyone tell me why this method might not be the most beneficial to use?

OK, you guessed it, since unicast paging is designed to page on a one to one basis; the number of users contained within each page group is the number of simultaneous SIP calls the PBX has to initiate and maintain at that specific moment in time. As you can see, this can get quite taxing on the IP PBX’s CPU and processing power. If the CPU is taxed too much, it can possibly lock up the entire system causing detrimental impact to the server hardware, inevitably drop calls, and affect overall user’s productivity.

In our case, our PBX has to make 20 SIP calls simultaneously at that given time that the paging extension (400) is dialed. In larger applications where paging groups range from 50-100+ users, unicast paging is strongly advised against for this reason. Here is nice diagram of how unicast paging functions:

As you can see, unicast paging has some downfalls and definitely some limitations. In most cases, a typical IP PBX’s can handle around 20 or so concurrent calls without “working to much overtime”, and for those environments, unicast paging will function correctly without many issues. But what if you are one of those environments where you do have 50 or so users in a single page group, let’s say a college or hospital, or large manufacturing warehouse, unicast is just not going to cut it. For this type of environment, we must like multi-cast paging.

Multicast IP Paging

Multicast paging achieves the same outcome as unicast paging but delivers each page much differently. Multicast paging is based upon a one too many architecture. In most multi-cast paging environments, administrators will specify a single multi-cast paging address in the IP PBX setup. They will then configure each paging endpoint such as an IP Phone, overhead speaker, or amplifier, to “listen in” on that multicast addresses.

In a multicast scenario, when a user initiates a page, the page originates from the IP PBX, just like unicast paging however the PBX only sets up a single SIP and RTP audio path to the multicast paging addresses.

The IP Phones or other paging endpoints are always “listening” to this address and when RTP packets or audio is heard, the phone or paging endpoints merely play that audio stream. As you can see, paging groups that contain, oh let’s say 500 users could very easily receive a page using multicast as the PBX only makes 1 SIP call for its 500 users in the multicast page group. This also preserves and protects the IP PBX’s CPU and system resources to maintain a preferable operating environment. Here is a good look at how multi-cast paging takes place:

Unicast vs Multicast IP Paging

The easiest way I try to describe this method is radio stations. Radio stations stream their broadcast, and you, the listener, tune in to the desired radio station to hear what they are playing, one audio stream with possibly thousands of listeners tuning in. As you can see, multicast has its benefits over unicast paging, but there is a catch, not all paging endpoints such as IP Phones can support multicast paging.

Next Segment:  Part 2 of 4

Tune into our next segment where we will discuss the two different types of paging, desktop and overhead paging as well as suggest a few products to these individual paging requirements.

Further Reading

• Designing and Implementing an IP Paging System (2 of 4)
• Designing and Implementing an IP Paging System – Legacy Paging Systems (3 of 4)
• Designing and Implementing an IP Paging System – How to Intercom with VoIP (4 of 4)
• VoIP Supply’s Guide to IP Paging