Parking, Paging, and Conferencing(Asterisk)
In Asterisk, these two functionalities are exclusive to one another, and can be used independently of one another. Some businesses that contain large warehouses, or have employees who move around the office a lot and don’t necessarily sit at a desk all day, utilize the paging and parking functionality of their systems to direct calls around the office. In this topic we’ll show you how to use both parking and paging in the traditional setting, along with a couple of more modern takes on these commonly used functions.
features.conf
Asterisk also provides several features common to most modern PBXs, many of which have optional parameters. The features.conf file is where you can adjust or define the various feature parameters in Asterisk.
The [general] section
In the [general] section of features.conf, you can define options that fine-tune the behavior of the park and transfer features in Asterisk. These options are listed in Table 1.
The [featuremap] Section
This section allows you to define specific DTMF sequences, which will trigger various features on channels that have been bridged via options in the Dial() or Queue() application. The options are detailed in Table 2.
The [applicationmap] Section
This section of features.conf allows you to map DTMF codes to dialplan applications. The caller will be placed on hold until the application has completed execution. The syntax for defining an application map is as follows (it must appear on a single line; line breaks are not allowed): 3
<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>]
,<Application>([<AppArguments>])[,MOH_Class]
What you are doing is the following:
1. Giving your map a name so that it can be enabled in the dialplan through the use of the DYNAMIC_FEATURES channel variable.
2. Defining the DTMF sequence that activates this feature (we recommend using at least two digits for this).
3. Defining which channel the feature will be activated on, and (optionally) which participant is allowed to activate the feature (the default is to allow both channels to use/activate this feature).
4. Giving the name of the application that this map will trigger, and its arguments.
5. Providing an optional music on hold (MOH) class to assign to this feature (which the opposite channel will hear when the application is executing). If you do not define any MOH class, the caller will hear only silence.
Here is an example of an application map that will trigger an AGI script:
agi_test => *6,self/callee,AGI(agi-test.agi),default
To use an application map, you must declare it in the dialplan by setting the DYNAMIC_FEATURES variable somewhere before the Dial() command that connects the channels. Use the double underscore modifier on the variable name to ensure that the application map is available to both channels throughout the life of the call. For example:
exten => 101,1,NoOp()
same => n,Set(__DYNAMIC_FEATURES=agi_test)
same => n,Dial(SIP/0000FFFF0002)
Don’t forget to reload the features module after making changes to the features.conf file:
*CLI> features reload
You can verify that your changes have taken place through the CLI command features show. Make sure you test out your application map before you turn it over to your users!
Application Map Grouping
If you have a lot of features that you need to activate for a particular context or extension, you can group several features together in an application-map grouping, so that one assignment of the DYNAMIC_FEATURES variable will assign all of the designated features of that map.
The application map groupings are added at the end of the features.conf file. Each grouping is given a name, and then the relevant features are listed:
[shifteight]
unpauseMonitor => *1 ; custom key mapping
pauseMonitor => *2 ; custom key mapping
agi_test => ; no custom key mapping
In the dialplan, you would assign this application map grouping with the Set() application:
Set(__DYNAMIC_FEATURES=shifteight) ; use the double underscore if you want
; to ensure both call legs have the
; variable assigned.
Parking Lots
A parking lot allows a call to be held in the system without being associated with a particular extension. The call can then be retrieved by anyone who knows the park code for that call. This feature is often used in conjunction with an overhead paging system (PA system, or Tannoy, for our UK readers). For this reason, it is often referred to as park-and-page; however, it should be noted that parking and paging are in fact separate.
To park a call in Asterisk, you need to transfer the caller to the feature code assigned to parking, which is assigned in the features.conf file with the parkext directive. By default, this is 700 :
parkext => 700 ; What extension to dial to park (all parking lots)
You have to wait to complete the transfer until you get the number of the parking retrieval slot from the system, or you will have no way of retrieving the call. By default the retrieval slots, assigned with the parkpos directive in features.conf, are numbered from 701 – 720 :
parkpos => 701-720 ; What extensions to park calls on (defafult parking lot)
Once the call is parked, anyone on the system can retrieve it by dialing the number of the retrieval slot ( parkpos ) assigned to that call. The call will then be bridged to the channel that dialed the retrieval code.
There are two common ways to define how retrieval slots are assigned. This is done with the findslot directive in the features.conf file. The default method ( findslot => first ) always uses the lowest-numbered slot if it is available, and only assigns higher- numbered codes if required. The second method ( findslot => next ) will rotate through the retrieval codes with each successive park, returning to the first retrieval code after the last one has been used. Which method you choose will depend on how busy your parking lots are. If you use parking rarely, the default findslot of first will be best (people will be used to their parked calls always being in the same slot). If you use parking a lot (for example, in an automobile dealership), on the other hand, it is far better for each successive page to assign the next slot, since you will often have more than one call parked at a time. Your users will get used to listening carefully to the actual parking lot number (instead of just always dialing 701 ), and this will minimize the chance of people accidentally retrieving the wrong call on a busy system. If you are using parking, you are probably also going to need a way to announce the parked calls so that the intended parties know how to retrieve them. While you could just run down the hall yelling “Bob, there’s a call for you on 701!,” the more professional method is to use a paging system (more formally known as a public address system),
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 3) 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.
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
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 way (potentially simpler, and possibly more robust) 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, which then connects to the paging amplifier.
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:
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:
• 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? 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 method, 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, 7 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, 8 Linksys/Cisco, Polycom (firmware 4.x or later), and Aastra, and it works swell.
VoIP paging adapters
Recently, some VoIP-based paging speakers have been 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 a half-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:
[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
; 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.
