The [general] Section

In the [general] section of features.conf, you can define options that fine-tune the behavior of the transfers feature in Asterisk. These have nothing to do with how SIP telephones handle call transfers. You instead access these features by using DTMF digits while on a call (the call must be bridged, so calls ringing or in progress will not have access to these features).

The features.conf.sample file in your ~/asterisk/ folder contains details of the various options, and examples of how they can be set.

These features are not as commonly used as they were in the past, mostly because many of these things can be handled in more advanced ways than firing DTMF from the telephone set (for example, through an external integration of some sort, or for that matter from the telephone itself using its own internal transfer features).

The [featuremap] Section

The [featuremap] section, summarized in Table 11-1, allows you to define specific DTMF sequences that will trigger features on channels that have been bridged via options in the Dial() or Queue() application. The two options you are most likely to use are parkcall and automixmon.

The [applicationmap] Section

The [applicationmap] section of features.conf is arguably the most nifty, as it 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):²

Name => DTMF_sequence,ActivateOn[/ActivatedBy],App([Args])[,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 (more on this in a moment).

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

You may add this to your /etc/asterisk/features.conf file if you wish.

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. Let’s toss this one in our subDialUser subroutine, so that it’ll be available whenever any of our extensions call each other:

[subDialUser]
exten => _[0-9].,1,Noop(Dial extension ${EXTEN},channel: ${ARG1},  mailbox: ${ARG2})
  same => n,Noop(mboxcontext: ${ARG3}, timeout ${ARG4})
  same => n,Set(__DYNAMIC_FEATURES=agi_test)
  same => n,Dial(${ARG1},${ARG4})
  same => n,GotoIf($["${DIALSTATUS}" = "BUSY"]?busy:unavail)

Don’t forget to reload the features module after making changes to the features.conf file:

*CLI> module reload features

You can verify that your changes have taken place through the CLI command features show.

Also, since we are introducing an AGI script here, there are some commands that must be run to make the referenced AGI script available to Asterisk.

$ sudo cp ~/src/asterisk-16.<TAB>/agi/agi-test.agi /var/lib/asterisk/agi-bin/ 

$ sudo chown asterisk:asterisk /var/lib/asterisk/agi-bin/* 

$ sudo chmod 755 /var/lib/asterisk/agi-bin/* 

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:

  same => Set(__DYNAMIC_FEATURES=shifteight) ; use the double underscore if you want
                                   ; to ensure both call legs have the
                                   ; variable assigned.

Call Parking

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 a public address (PA), or “paging” system. For this reason, it is often referred to as “park-and-page.” It should be noted that parking and paging are in fact separate. We’ll cover paging momentarily, but first, let’s talk about call parking.

Let’s grab a copy of the sample file that we’ll use to configure call parking:

$ sudo cp ~/src/asterisk-16.<TAB>/configs/samples/res_parking.conf.sample 
/etc/asterisk/res_parking.conf 

$ sudo chown asterisk:asterisk /etc/asterisk/res_parking.conf 

$ sudo asterisk -rx 'module load res_parking.so'

To park a call in Asterisk, you need to transfer the caller to the feature code assigned to parking, which is assigned in the res_parking.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 res_parking.conf, are numbered from 701 to 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 res_parking.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 constantly use the parking feature (for example, in an automobile dealership), 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 also going to need a way to announce the parked calls so users 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), which we will discuss now.

Paging (aka Public Address)

In many PBX systems, it is useful to connect the telephone system to some sort of public address system. This 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 (perhaps you’ve heard the clerk at your grocery store request a price check through the telephone). 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-based paging can work well in many environments. It is also possible to have a mix of set-based and overhead paging, where, for example, set-based paging might be in use for the administrative offices, but overhead paging would be used for warehouse, hallway, parking lot, 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 call 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: 1) the group of channels the page is to be connected to, 2) the options, and 3) the timeout:

exten => *724,1,Noop(Page)
  same => n,Set(ChannelsToPage=${UserA_DeskPhone}&${UserA_SoftPhone}}&${UserB_DeskPhone})
  same => n,Page(${ChannelsToPage},i,120)

The options (outlined in Table 11-2) 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.

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.

exten => *725,1,Verbose(2,Paging to external amplifier) ; The '*' is part of what you dial
    same => n,Set(PageDevice=PJSIP/PagingATA)          ; This probably belongs in [globals]
    same => n,Page(${PageDevice},i,120)

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

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

exten => *730,1,Page(MulticastRTP/basic/239.0.0.1:1234)

[globals]
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 phones

BOGEN=PJSIP/ATAforPaging  ; Assumes an ATA named [ATAforPaging]
PAGELIST=${MULTICAST}&${BOGEN} ; Variable names are arbitrary. 
;...

[sets]
; ...
exten => *731,1,Page(${PAGELIST},i,120)

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 do not want to hear each other’s pages.

In zone paging, the person sending the page needs to select which zone 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 to which zone the page is to be sent. 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.

And that’s parking and paging. It’s a ton of information to digest, but once you get the hang of it, it’s quite logical.

Video Conferencing

The conference engine in Asterisk can handle video, but it is a very simplified offering, and you should evaluate it carefully to ensure it meets your needs. Some of the more serious limitations include:

• All video participants must be using the same video codec; no video transcoding is available in Asterisk.

• There is no video multiplexing in Asterisk; only one video source can be shown at a time to a participant.

For a user to be able to use video (whether in a conference, or just for normal calls), they need to have the video codecs enabled. This can be done by modifying the allow field in the asterisk.endpoints table, and adding 'h264,vp8' to the allow field. Make sure you don’t remove the codecs that are already there (for example, the ulaw audio codec). A functional entry in that field might look like:

ulaw,h264,vp8

Before attempting to use video with your conferences, make sure your sets are able to use it with direct desk-to-desk calls. If you can use video conferencing between your sets, it’s likely it’ll also work in your conference rooms.

In Chapter 20, we’ll dive into WebRTC, which is where we’ll explore more powerful concepts in the delivery of multimedia communication, including conferencing.