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-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:

Page(SIP/SET1&SIP/SET2&SIP/SET3&SIP/SET4&SIP/SET5&SIP/SET6&SIP/SET7&...

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:

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.

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/239.0.0.1:1234)

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

exten => *724,1,Page(MulticastRTP/linksys/239.0.0.1:1234/239.0.0.1:6061)

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.

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.

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:

[global]

MULTICAST=MulticastRTP/linksys/239.0.0.1:1234
;MULTICAST=MulticastRTP/linksys/239.0.0.1:1234/239.0.0.1:6061 ; 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.