Skip to end of metadata
Go to start of metadata

Overview

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 :

Icon

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.

On This Page

 

 

Example Configurations

Basic Call Parking/Retrieval Scenario

This is a basic scenario that only requires minimal adjustments to the following configuration files: res_parking.conf , features.conf , and extensions.conf .

In this scenario, our dialplan contains an extension to accept calls from the outside. Let's assume that the extension the caller dialed was: 5555001 . The handler will then attempt to dial the alice extension, using the k option.

Sadly for our caller, the alice extension answers the call and immediately after saying, "Hello world!", sends the DTMF digits to invoke the call parking feature without giving the caller a chance to speak. The alice extension quickly redeems itself by using the GoTo application to navigate to the 701 extension in the parkedcalls context to retrieve the parked call. But, since the next thing the alice extension does is hangup on our caller, I am beginning to think the alice extension doesn't want to be bothered.

In summary:

  • Outside caller dials 5555001
  • Alice picks up the device and says "Hello World!"
  • Alice presses the one touch parking DTMF combination
  • Alice then dials the extension that the call was parked to ( 701 ) to retrieve the call
  • Alice says, "Goodbye", and disconnects the caller
res_parking.conf
features.conf
extensions.conf

Basic Handling for Call Parking Timeouts

Next we will move on to explain how to handle situations where a call is parked but is not retrieved before the value specified as the parkingtime option elapses. Just like the scenario above, this is a basic scenario that only requires minimal adjustments to the following configuration files: res_parking.conf , features.conf , and extensions.conf .

Like before, our dialplan contains an extension to accept calls from the outside. Again, let's assume that the extension the caller dialed was: 5555001 . The handler will then attempt to dial the alice extension, using the k option.

Sadly for our caller, the alice extension answers the call and immediately sends the DTMF digits to invoke the call parking feature without giving the caller a chance to speak. Unlike in the previous scenario, however, the alice extension does not retrieve the parked call. Our sad caller is now even more sad.

After a period of 300 seconds , or 5 minutes (as defined in the parkingtime option in res_parking.conf ), the call will time out. Because we told Asterisk to return a timed-out parked call to the party that originally parked the call ( comebacktoorigin=yes ), Asterisk will attempt to call alice using an extension automagically created in the special context, park-dial .

Unfortunately, the alice extension has no time to be bothered with us at this moment, so the call is not answered. After a period of 20 seconds elapses (the value specified for the comebackdialtime option in res_parking.conf ), Asterisk finally gives up and the t extension in the park-dial context is executed. Our caller is then told "Goodbye" before being disconnected.

In summary:

  • Outside caller dials 5555001
  • Alice picks up the device and says "Hello World!"
  • Alice presses the one touch parking DTMF combination
  • The parked call times out after 300 seconds
  • Asterisk sends the call to the origin, or the alice extension
  • A period of 20 seconds elapses without an answer
  • Asterisk sends the call to t extension in the park-dial context
  • Our caller hears, "Goodbye", before being disconnected
res_parking.conf
features.conf
extensions.conf

Custom Handling for Call Parking Timeouts

Finally, we will move on to explain how to handle situations where upon a parked call session timing out, it is not desired to return to the parked call to the device from where the call was originally parked. (This might be handy for situations where you have a dedicated receptionist or service desk extension to handle incoming call traffic.) Just like the previous two examples, this is a basic scenario that only requires minimal adjustments to the following configuration files: res_parking.conf , features.conf , and extensions.conf .

Like before, our dialplan contains an extension to accept calls from the outside. Again, let's assume that the extension the caller dialed was: 5555001 . The handler will then attempt to dial the alice extension, using the k option.

Sadly for our caller, the alice extension answers the call and immediately sends the DTMF digits to invoke the call parking feature without giving the caller a chance to speak. Just like in the previous scenario, the alice extension does not retrieve the parked call. Maybe the alice extension is having a bad day.

After a period of 300 seconds , or 5 minutes (as defined in the parkingtime option in res_parking.conf ), the call will time out. Because we told Asterisk to send a timed-out parked call to the parkedcallstimeout context ( comebacktoorigin=no ), we are able to bypass the default logic that directs Asterisk to returning the call to the person who initiated the park. In our example, when a parked call enters our s extension in our parkedcallstimeout context, we only play a sound file to the caller and hangup the call, but this is where you could do any custom logic like returning the call to a different extension, or performing a lookup of some sort.

In summary:

  • Outside caller dials 5555001
  • Alice picks up the device and says "Hello World!"
  • Alice presses the one touch parking DTMF combination
  • The parked call times out after 300 seconds
  • Asterisk sends the call to the s extension in our parkedcallstimeout
  • Our caller hears, "Goodbye", before being disconnected
res_parking.conf
features.conf
extensions.conf
  • No labels