Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Move TOC format to our typical format


Table of Contents
excludeTable of Contents


Some organizations have the need to facilitate calls to employees who move around the office a lot or who don't necessarily sit at a desk all day. In Asterisk, it is possible to allow a call to be put on hold at one location and then picked up from a different location such that the conversation can be continued from a device other than the one from which call was originally answered. This concept is known as call parking.

Call parking is a feature that allows a participant in a call to put the other participants on hold while they themselves hang up. When parking, the party that initiates the park will be told a parking space, which under standard configuration doubles as an extension. This extension, or parking space, serves as the conduit for accessing the parked call. At this point, as long as the parking space is known, the parked call can be retrieved from a different location/device from where it was originally answered.

Call Parking Configuration Files and Module

In versions of Asterisk prior to Asterisk 12, call parking was considered an Asterisk core feature and was configured using features.conf . However, Asterisk 12 underwent vast architectural changes, several of which were directed at call parking support. Because the amount of changes introduced in Asterisk 12 was quite extensive, they have been omitted from this document. For reference, you can find a comprehensive list of these changes here:  New in 12 .

In a nutshell, Asterisk 12 relocated its support for call parking from the Asterisk core into a separate, loadable module, res_parking . As a result, configuration for call parking was also moved to res_parking.conf . Configuration for call parking through features.conf for versions of Asterisk 12 and beyond, is no longer supported. Additionally, support for the ParkAndAnnounce application was relocated to the res_parking module and the app_parkandannounce module was removed.

Before we move any further, there is one more rather important detail to address regarding configuration for res_parking :


res_parking uses the configuration framework. If an invalid configuration is  supplied, res_parking will fail to load or fail to reload. Previously,  invalid configurations would generally be accepted, with certain errors  resulting in individually disabled parking lots.

Now that we've covered all of that, let's look at some examples of how all this works.

titleOn This Page

Table of Contents
excludeTable of Contents


Example Configurations

Basic Call Parking/Retrieval Scenario