Overhead and “Underchin” Paging (a.k.a. Public Address)

In many PBX systems, it is desirable to be able to allow a user to send his voice from a telephone into a public address system. This normally involves dialing a feature code or extension that makes a connection to a public address resource of some kind, and then making an announcement through the handset of the telephone that is broadcast to all devices associated with that paging resource. Often, this will be an external paging system consisting of an amplifier connected to overhead speakers; however, paging through the speakers of office telephones is also popular (mainly for cost reasons). If you have the budget (or an existing overhead paging system), overhead paging is generally better, but set paging (a.k.a. “underchin” paging) can work well in many environments. What is perhaps most common is to have a mix of set and overhead paging, where, for example, set-based paging might be in use for offices, but overhead paging would be used for warehouse, hallway, and public areas (cafeteria, reception, etc.).

In Asterisk, the Page() application is used for paging. This application simply takes a list of channels as its argument, calls all of the listed channels simultaneously, and, as they are answered, puts each one into a conference room. With this in mind, it becomes obvious that one requirement for paging to work is that each destination channel must be able to automatically answer the incoming connection and place the resultant audio onto a speaker of some sort (in other words, Page() won’t work if all the phones just ring).

So, while the Page() application itself is painless and simple to use, getting all the destination channels to handle the incoming pages correctly is a bit trickier. We’ll get to that shortly.

The Page() application takes three arguments, defining the group of channels the page is to be connected to, the options, and the timeout:

exten => *724,1,Page(${ChannelsToPage},i,120)

The options (outlined in Table 11.3, “Page() options”) give you some flexibility with respect to how Page() works, but the majority of the configuration is going to have to do with how the target devices handle the incoming connection. We’ll dive into the various ways you can configure devices to receive pages in the next section.

Table 11.3. Page() options

dEnables full-duplex audioSometimes referred to as “talkback paging,” the use of this option implies that the equipment that receives the page has the ability to transmit audio back at the same time as it is receiving audio. Generally, you would not want to use this unless you had a specific need for it.
iIgnores attempts to forward the callYou would normally want this option enabled.
qDoes not play beep to caller (quiet mode)Normally you won’t use this, but if you have an external amplifier that provides its own tone, you may want to set this option.
rRecords the page into a fileIf you intended on using the same page multiple times in the future, you could record the page and then use it again later by triggering it using Originate() or using the A(x) option to Page().
sDials a channel only if the device state is NOT_INUSEThis option is likely only useful (and reliable) on SIP-bound channels, and even so may not work if a single line is allowed multiple calls on it. Therefore, don’t rely on this option in all cases.
A(x)Plays announcement x to all participantsYou could use a previously recorded file to be played over the paging system. If you combined this with Originate() and Record(), you could implement a delayed paging system.
nDoes not play announcement simultaneously to caller (implies A(x))By default the system will play the paged audio to both the caller and the callee. If this option is enabled, the paged audio will not be played to the caller (the person paging).

Because of how Page() works, it is very resource-intensive. We cannot stress this enough. Carefully read on, and we’ll cover how to ensure that paging does not cause performance problems in a production environment (which it is almost certain to do if not designed correctly).

Places to Send Your Pages

As we stated before, Page() is in and of itself very simple. The trick is how to bring it all together. Pages can be sent to different kinds of channels, and they all require different configuration.

External paging

If a public address system is installed in the building, it is common to connect the telephone system to an external amplifier and send pages to it through a call to a channel. One way of doing this is to plug the sound card of your server into the amplifier and send calls to the channel named Console/DSP, but this assumes that the sound drivers on your server are working correctly and the audio levels are normalized correctly on that channel. Another, potentially simpler, and possibly more robust way to handle external paging is to use an FXS device of some kind (such as an ATA), which is connected to a paging interface such as a Bogen UTI1,[100] which then connects to the paging amplifier.[101]

In your dialplan, paging to an external amplifier would look like a simple Dial() to the device that is connected to the paging equipment. For example, if you had an ATA configured in sip.conf as [PagingATA], and you plugged the ATA into a Bogen UTI1, you would perform paging by dialing:

exten => *724,1,Verbose(2,Paging to external amplifier) ; note the '*' in the 
                                                        ; extension is part of 
                                                        ; what you actually dial
   same => n,Set(PageDevice=SIP/PagingATA)
   same => n,Page(${PageDevice},i,120)

Note that for this to work you will have had to register your ATA as a SIP device under sip.conf, and in this case we named the device [PagingATA]. You can name this device anything you want (for example, we often use the MAC address as the name of a SIP device), but for anything that is not a user telephone, it can be helpful to use a name that makes it stand out from other devices.

If you had an FXS card in your system and you connected the UTI1 to that, you would Dial() to the channel for that FXS port instead:

   same => n,Dial(DAHDI/25)

The UTI1 answers the call and opens a channel to the paging system; you then make your announcement and hang up.

Set paging

Set-based paging first became popular in key telephone systems, where the speakers of the office telephones are used as a poor-man’s public address system. Most SIP telephones have the ability to auto-answer a call on handsfree, which accomplishes what is required on a per-telephone basis. In addition to this, however, it is necessary to pass the audio to more than one set at the same time. Asterisk uses its built-in conferencing engine to handle the under-the-hood details. You use the Page() application to make it happen.

Like Dial(), the Page() application can handle several channels. Since you will generally want Page() to signal several sets at once (perhaps even all the sets on your system) you may end up with lengthy device strings that look something like this:



Beyond a certain size, your Asterisk system will be unable to page multiple sets. For example, in an office with 200 telephones, using SIP to page every set would not be possible; the traffic and CPU load on your Asterisk server would simply be too much. In cases like this, you should be looking at either multicast paging or external paging.

Perhaps the trickiest part of SIP-based paging is the fact that you usually have to tell each set that it must auto-answer, but different manufacturers of SIP telephones use different SIP messages for this purpose. So, depending on the telephone model you are using, the commands needed to accomplish SIP-based set paging will be different. Here are some examples:

  • For Aastra:

    exten => *724,1,Verbose(2,Paging to Aastra sets)
       same => n,SIPAddHeader(Alert-Info: info=alert-autoanswer)
       same => n,Set(PageDevice=SIP/00085D000000)
       same => n,Page(${PageDevice},i)
  • For Polycom:

    exten => *724,1,Verbose(2,Paging to Polycom sets)
       same => n,SIPAddHeader(Alert-Info: Ring Answer)
       same => n,Set(PageDevice=SIP/0004F2000000)
       same => n,Page(${PageDevice},i)
  • For Snom:

    exten => *724,1,Verbose(2,Paging to Snom sets)
       same => n,Set(VXML_URL=intercom=true)
    ; replace 'domain.com' with the domain of your system
       same => n,SIPAddHeader(Call-Info: sip:domain.com\;answer-after=0)
       same => n,Set(PageDevice=SIP/000413000000)
       same => n,Page(${PageDevice},i)
  • For Cisco SPA (the former Linksys phones, not the 79XX series):

    exten => *724,1,Verbose(2,Paging to Cisco SPA sets -- but not Cisco 79XX sets)
       same => n,SIPAddHeader(Call-Info:\;answer-after=0)        ; Cisco SPA phones
       same => n,Set(PageDevice=SIP/0004F2000000)
       same => n,Page(${PageDevice},i)

Assuming you’ve figured that out, what happens if you have a mix of phones in your environment? How do you control which headers to send to which phones?[102]

Any way you slice it, it’s not pretty.

Fortunately, many of these sets support IP multicast, which is a far better way to send a page to multiple sets (read on for details). Still, if you only have a few phones on your system and they are all from the same manufacturer, SIP-based paging could be the simplest, so we don’t want to scare you off it completely.

Multicast paging via the MulticastRTP channel

If you are serious about paging through the sets on your system, and you have more than a handful of phones, you will need to look at using IP multicast. The concept of IP multicast has been around for a long time,[103] but it has not been widely used. Nevertheless, it is ideal for paging within a single location.

Asterisk has a channel (chan_multicast_rtp) that is designed to create an RTP multicast. This stream is then subscribed to by the various phones, and the result is that whenever media appears on the multicast stream, the phones will pass that media to their speakers.

Since MulticastRTP is a channel driver, it does not have an application, but instead will work anywhere in the dialplan that you might otherwise use a channel. In our case, we’ll be using the Page() application to initiate our multicast.

To use the multicast channel, you simply send a call to it the same as you would to any other channel. The syntax for the channel is as follows:

MulticastRTP/<type>/<ip address:port>[/<linksys address:port>]

The type can be either basic or linksys. The basic syntax of the MulticastRTP channel looks like this:

exten => *723,1,Page(MulticastRTP/basic/

Not all sets support IP multicast, but we have tested it out on Snom,[104] Linksys/Cisco, and Aastra, and it works swell.[105]

VoIP paging adaptors

Recently, there have been some VoIP-based paging speakers introduced to the market. These devices are addressed in the dialplan in the exact same way as a SIP ATA connected to a UTI1, but they can be installed in the same manner as overhead speakers would be. Since they auto-answer, there is no need to pass them any extra information, the way you would need to with a SIP telephone set.

For smaller installations (where no more than perhaps half a dozen speakers are required), these devices may be cost-effective. However, for anything larger than that, (or installation in a complex environment such as a warehouse or parking lot), you will get better performance at far less cost with a traditional analog paging system connected to the phone system by an analog (FXS) interface.

We don’t know if these devices support multicast. Keep this in mind if you are planning to use a large number of them.

Combination paging

In many organizations, there may be a need for both set-based and external paging. As an example, a manufacturing facility might want to use set-based paging for the office area but overhead paging for the plant and warehouse. From Asterisk’s perspective, this is fairly simple to accomplish. When you call the Page() application, you simply specify the various resources you want to page, separated by the & character, and they will all be included in the conference that the Page() application creates.

Bringing it all together

At this point you should have a list of the various channel types that you want to page. Since Page() will nearly always want to signal more than one channel, we recommend setting a global variable that defines the list of channels to include, and then calling the Page() application with that string:


;MULTICAST=MulticastRTP/linksys/ ; if you have SPA 
                                                              ; (Linksys/Cisco)
                                                              ; phones

BOGEN=SIP/ATAforPaging  ; This assumes an ATA in your sip.conf file named 
                        ; [ATAforPaging]
;BOGEN=DAHDI/25         ; We could do this too, assuming we have an analog 
                        ; FXS card at DAHDI channel 25
PAGELIST=${MULTICAST}&${BOGEN} ; All of these variable names are arbitrary. 
                               ; Asterisk doesn't care what you call these strings

[page_context] ; You don't need a page context, so long as the extension you 
               ; assign to paging is dialable by your sets

exten => *724,1,Page(${PAGELIST},i,120)

This example offers several possible configurations, depending on the hardware. While it is not strictly required to have a PAGELIST variable defined, we have found that this will tend to simplify the management of multiple paging resources, especially during the configuration and testing process.

We created a context for paging for the purposes of this example. In order for this to work, you’ll need to either include this context in the contexts where your sets enter the dialplan, or code a Goto() in those contexts to take the user to this context and extension (i.e., Goto(page_context,*724,1)) Alternatively, you could hardcode an extension for the Page() application in each context that services sets.

Zone Paging

Zone paging is popular in places such as automobile dealerships, where the parts department, the sales department, and perhaps the used car department all require paging, but have no need to hear each other’s pages.

In zone paging, the person sending the page needs to select which zone she wishes to page into. A zone paging controller such as a Bogen PCM2000 is generally used to allow signaling of the different zones: the Page() application signals the zone controller, the zone controller answers, and then an additional digit is sent to select which zone the page is to be sent to. Most zone controllers will allow for a page to all zones, in addition to combining zones (for example, a page to both the new and used car sales departments).

You could also have separate extensions in the dialplan going to separate ATAs (or groups of telephones), but this may prove more complicated and expensive than simply purchasing a paging controller that is designed to handle this. Zone paging doesn’t require any significantly different technology, but it does require a little more thought and planning with respect to both the dialplan and the hardware.

[100] The Bogen UTI1 is useful because it can handle all manner of different kinds of incoming and outgoing connections, which pretty nearly guarantees that you’ll be able to painlessly connect your telephone system to any sort of external paging equipment, no matter how old or obscure.

[101] In this book we’re assuming that the external paging equipment is already installed and was working with the old phone system.

[102] Hint: the local channel will be your friend here.

[103] It even has its own Class D reserved IP address space, from to (but read up on IP multicast before you just grab one of these and assign it). Parts of this address space are private, parts are public, and parts are designated for purposes other than what you might want to use them for. For information about multicast addressing, see http://en.wikipedia.org/wiki/IP_multicast#IP_multicast_addressing_assignments.

[104] Very loud, and no way to adjust gain.

[105] So far as we can tell, Polycom sets do not support multicast. We certainly were not able to find a way to use it.