There are several features common to most modern PBXs that Asterisk also provides. Many of these features 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 11.1, “features.conf [general] section”.

Table 11.1. features.conf [general] section

parkext700Sets the default extension used to park calls.
parkpos701-720Sets the range of extensions used as the parking lot. Parked calls may be retrieved by dialing the numbers in this range.
contextparkedcallsSets the default dialplan context where the parking extension and the parking lot extensions are created.
parkinghintsnoEnables/disables automatic creation of dialplan hints for the parking lot extensions so that phones can subscribe to the state of extensions in the parking lot. The default is no.
parkingtime45Specifies the number of seconds a call will wait in the parking lot before timing out.
comebacktooriginyesConfigures the handling of timed-out parked calls. For more information on the behavior of this option, see the sidebar titled Handling Timed-Out Parked Calls with the comebacktoorigin Option.
courtesytonebeepSpecifies the sound file to be played to the parked caller when the parked call is retrieved from the parking lot.
parkedplaycallerIndicates which side of the call to play the courtesytone to when a parked call is picked up. Valid options include callee, caller, both, or no. The default is no.
parkedcalltransferscallerControls which side of a call has the ability to execute a DTMF-based transfer in the call that results from picking up a parked call. Valid options include callee, caller, both, or no. The default is no.
parkedcallreparkingcallerControls which side of a call has the ability to execute a DTMF-based park in the call that results from picking up a parked call.[a] Valid options include callee, caller, both, or no. The default is no.
parkedcallhangupcallerControls which side of a call has the ability to execute a DTMF-based hangup in the call that results from picking up a parked call. Valid options include callee, caller, both, or no. The default is no.
parkedcallrecordingcallerControls which side of a call has the ability to initiate a DTMF-based one-touch recording in the call that results from picking up a parked call. Valid options include callee, caller, both, or no. The default is no.
parkeddynamicyesEnables the dynamic creation of parking lots in the dialplan. The channel variables PARKINGDYNAMIC, PARKINGDYNCONTEXT, and PARKINGDYNPOS need to be set.
adsiparkyesPasses ADSI information regarding the parked call back to the originating set.
findslotnextConfigures the parking slot selection behavior. See Parking Lots for more details.
parkedmusicclassdefaultSpecifies the class to be used for the music on hold played to a parked caller. A music class set in the dialplan using the CHANNEL(musicclass) dialplan function will override this setting.
transferdigittimeout3Sets the number of seconds to wait for each digit from the caller executing a transfer.
xfersoundbeepSpecifies the sound to be played to indicate that an attended transfer is complete.
xferfailsoundbeeperrSpecifies the sound to be played to indicate that an attended transfer has failed to complete.
pickupexten*8Configures the extension used for call pickup.
pickupsoundbeepSpecifies the sound to be played to indicate a successful call pickup attempt. No sound is played by default.
pickupfailsoundbeeperrSpecifies the sound to be played to indicate a failed call pickup attempt. No sound is played by default.
featuredigittimeout1000Sets the number of milliseconds to wait in between digits pressed during a bridged call when matching against DTMF activated call features.
atxfernoanswertimeout15Configures the number of seconds to wait for the target of an attended transfer to answer before considering the attempt timed out.
atxferdropcallnoConfigures behavior of attended transfer call handling when the transferer hangs up before the transfer is complete and the transfer fails. By default, this option is set to no and a call will be originated to attempt to connect the transferee back to the caller that initiated the transfer. If set to yes, the call will be dropped after the transfer fails.
atxferloopdelay10Sets the number of seconds to wait in between callback retries if atxferdropcall is set to no.
atxfercallbackretries2Sets the number of callback attempts to make if atxferdropcall is set to no. By default, this is set to 2 callback attempts.

[a] Read that again. It makes sense.

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 11.2, “features.conf [featuremap] section”.

Table 11.2. features.conf [featuremap] section

OptionValue/ExampleNotesDial()/Queue() Flags
blindxfer#1Invokes a blind (unsupervised) transferT, t
disconnect*0Hangs up the callH, h
automon*1Starts recording of the current call using the Monitor() application (pressing this key sequence a second time stops the recording)W, w
atxfer*2Performs an automated transferT, t
parkcall#72Parks a callK, k
automixmon*3Starts recording of the current call using the MixMonitor() application (pressing this key sequence again stops the recording)X, x


The default blindxfer and disconnect codes are # and *, respectively. Normally you’ll want to change them from the defaults, as they will interfere with other things that you might want to do (for example, if you use the Tt option in your Dial() command, every time you press the # key you’ll initiate a transfer).

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)[99]:

<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>]

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


Since applications spawned from the application map are run outside the PBX core, you cannot execute any applications that trigger the dialplan (such as Goto(), Macro(), Background(), etc.). If you wish to use the application map to spawn external processes (including executing dialplan code), you will need to trigger an external application through an AGI() call or the System() application. Point being, if you want anything complex to happen through the use of an application map, you will need to test very carefully, as not all things will work as you might expect.

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 in order to ensure that the application map is available to both channels throughout the life of the call. For example:

exten => 101,n,Set(__DYNAMIC_FEATURES=agi_test)
exten => 101,n,Dial(SIP/0000FFFF0002)


If you want to allow more than one application map to be available on a call, you will need to use the # symbol as a delimiter between multiple map names:


The reason why the # character was chosen instead of a simple comma is that older versions of the Set() application interpreted the comma differently than more recent versions, and the syntax for application maps has never been updated.

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.

unpauseMonitor => *1    ; custom key mapping
pauseMonitor => *2      ; custom key mapping
agi_test =>             ; no custom key mapping


If you want to specify a custom key mapping to a feature in an application map grouping, simply follow the => with the key mapping you want. If you do not specify a key mapping, the default key map for that feature will be used (as found in the [featuremap] section). Regardless of whether you want to assign a custom key mapping or not, the => operator is required.

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), which we will discuss in the next section.

[97] Yes, we realize that a SIP INFO message is in fact a SIP message, and is not technically part of the audio channel, but the point is that you can’t use the “transfer” or “park” button on your SIP phone to access these features while on a call. You’ll have to send DTMF.

[98] We hope you realize that the actual extension will be related to the channel name that parked the call, and will not be SIP_0004F2040808 (unless Leif sells you the Polycom phone from his lab).

[99] There is some flexibility in the syntax (you can look at the sample file for details), but our example uses the style we recommend, since it’s the most consistent with typical dialplan syntax.