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
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).
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.
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&...
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:
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)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)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.
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]
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.
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 224.0.0.0 to 239.255.255.255 (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.