Asterisk standard extensions

Standard extensions

  • a: Called when user presses '*' during a voicemail greeting
  • h: Hangup extension
  • i: invalid extension
  • o: Operator extension, used for operator exit by pressing zero in voicemail
  • s: Start extension in context
  • t: Timeout extension
  • T: AbsoluteTimeout() extension
  • failed: used if an auto-dial out call fails (that had context, priority and extension specified)
  • fax: used for fax detection on Zap channels
  • talk: used in conjuction with BackgroundDetect


  • s: Start. Used primarily for dialplans that enter a context with no other extension information. Think of a non DID phone line, call comes in, and we may only know that the line is ringing and nothing else. Even if you knew callerid, you have to still have a place to start. You can also think about s as a place to place part of the dialplan that you don't want callers to get back to unless they have passed through other functions.
  • t: Timeout. Used for when calls have been inactive after a prompt was played. Also used to hang up a line that has been idle.
  • T: AbsoluteTimeout. Used for calls that have been hung up due to an AbsoluteTimeout() being reached. For example useful to play a notification with Playback().
  • h: Hangup. Used to clean up a call. Could be used to play a goodbye message before hanging up. Also seemingly used by the calling card people to record end of call for billing purposes. h won't run if the call is parked. More...
  • i: Used when dialling an unknown extension in a context or unknown input in an IVR menu

Impact on CDR

Using these extensions may change the content of your CDR billing records in a way you do not want: In particular the dst field will not contain the dialed number anymore! As a workaround you could look into Dial() with the 'g' option ("go on in context") and consider using ResetCDR(w) and / or NoCdr().

Standard Priorities

  • hint: The 'hint' priority associates an extension with an Asterisk channel for the purpose of mapping the state of the channel to a state of the extension.

In asterisk, a channel (technology/device) can have several states (unavailable, in-use, busy, ringing, etc) but an extension is just a label for a sequence of applications. However, when communicating the state of the channel to an external device, such as a receptionist console, you cannot use the Asterisk internal channel names, but must use an externally identifiable resource name, typically the extension number.

A device would then subscribe to the state of the extension of interest and receive status notifications from the supporting technology channel. This is used in the SIP channel (implemented via the SUBSCRIBE/NOTIFY mechanism of RFC-3265) to light up the status lamps on SIP phones.
This is supported in SNOM phones (see also) with their programmable keys set to type "destination", as well as in Polycom (500/600), Aastra ( 480i, 9133i ), and Sayson phones.

For hints/BLF to work as expected in Asterisk 1.4 you need to ensure that the following configuration items are set in sip.conf:
  • Asterisk sip call-limit must be set for every extension. Usually set this to a large arbitrary number such as 100. (or 1 if you don't want another call to be received when the extension is on the phone)
  • Asterisk sip notifyringing should be set to "yes".
  • If you're using RealTime, ensure you have both rtcachefriends and rtupdate set to "yes".
  • limitonpeers must be set to "yes" - this is the most likely culprit since it's missing from the 1.4 default config files

Note: Up to and including Asterisk 1.4 Local channels do not support state information and can therefore not be watched with hint. Asterisk 1.6 changes this.

Asterisk 1.6.1.x: It is now possible to specify a pattern match as a hint. Once a phone subscribes to something that matches the pattern a hint will be created using the contents and variables evaluated.

Privacy considerations: In sip.conf you can define a subscribecontext= value that determines in which context Asterisk should search for the matching extension when a subscribe request is received from the phone; however, if the extension doesn't exist in that context Asterisk is going to look for it in the default context! In other words: Everyone can subscribe to a "hinted" extension that is defined in the default context. By the way, specifying an empty subscribecontext is also fine if the phone should not at all subscribe to _any_ context.

Likewise bug/patch 5515 (post Asterisk 1.2.0) adds devstate support also for MGCP (so far SIP, IAX and ZAP are supported; "show channeltypes" tell you which channels in your Asterisk support device status notification). Question: Does this patch only show a device which is unavailable (e.g. disconnected), or does it also show "busy"? Answer: Also "busy" (in use).

Also chan_capi-cm v0.6.2 and later comes with basic hint support. It appears, however, that the dynamic naming of CAPI channels that includes the called number makes monitoring of a CAPI line for outgoing calls practically impossible - at least for now.

Useful CLI commands for debugging are "SIP show subscriptions", "show hints", "show channeltypes" and "SIP show inuse".

Related CLI commands in asterisk 1.4: "sip show subscriptions", "sip show inuse", "core show hints", "core show channeltypes"
Related options in sip.conf: notifyringing, notifyhold, limitonpeers, subscribecontext, busy-level(1.6.x only), call-limit


The 3rd party Bristuff patches come with app_devstate that permits state manipulation through the dialplan.

New: While Asterisk 1.6 will include func_devstate natively there is now also a backport available for 1.4. This is quite similar to app_devstate as part of the bristuff patches.

At this little web page a small PHP utility is available that allows to transfer BLF/hint presence information across several Asterisk servers.
It appears that bristuff patches introduced a solution for the same aim in 0.3.0-PRE-1t with res_esel (Extension State Export Logic). In the meanwhile Russel Bryant of Digium is looking at a similar, native feature for Asterisk 1.6 (or 1.8) via res_ais using AIS

New in Asterisk 1.4

Deny subscriptions

If you don’t want you Asterisk server to accept any registrations, you can simply add “allowsubscribe=no” to your sip.conf and stop reading here. This can be done on a per-account basis, as well as in the [general] configuration section.

Display hold states

Asterisk can now display hold state in both XML-RPID (SIMPLE) mode and dialog-info subscriptions. On most phones, this will be shown as a slowly blinking lamp. To enable this, add “notifyhold=yes” to the sip.conf [general] section.

Show inbound and outbound calls

In 1.2, the subscription only applied to the peer part of a type=friend object. This meant that incoming calls from a phone did not turn on the lamp, indicating busy (??). In Asterisk 1.4, you can add “limitonpeers=yes” so that the call limit and counters always will apply on the peer part of a friend. Suddenly, you have blinking lamps for both inbound and outbound calls.

Subscribe to parking lots

With the “metermaid” subsystem, you can add a subscription to the state of a parking lot. You specify a hint like “exten => 6600,hint,park:701@parkedcalls” in your diaplan and then subscribe to the extension, in this case 6600. If you want to watch if there’s an active conference, you add “meetme:1234″ to the hint if you want to check conference number 1234.

Continue reading here.

New in Asterisk 1.6

Asterisk 1.6.1.x: It is now possible to specify a pattern match as a hint. Once a phone subscribes to something that matches the pattern a hint will be created using the contents and variables evaluated.

Read about how to transmit state information across Asterisk servers in Asterisk 1.6.

Asterisk 1.6.1.x: The event infrastructure in Asterisk got another big update to help support distributed events. It currently supports distributed device state and distributed Voicemail MWI (Message Waiting Indication). A new module has been merged, res_ais, which facilitates communicating events between servers. It uses the SAForum AIS (Service Availability Forum Application Interface Specification) CLM (Cluster Management) and EVT (Event) services to maintain a cluster of Asterisk servers, and to share events between them. For more information on setting this up, see doc/distributed_devstate.txt.

New in Asterisk 1.8

Event thogh this is a little off-topic it is still related: Distributed device state using XMPP and PubSub

exten => 12345,hint,confbridge:MyConfName ; requires Asterisk 1.8 with ConfBridge()


Example 1

exten => 200,hint,SIP/phone1 ; this is case sensitive (!) in 1.0.9 and 1.2.0
exten => 200,1,Macro(stdexten,SIP/phone1)

Example 2

If you want to monitor the state of multiple phones using one speeddial, you can do so:

exten => 200,hint,SIP/201&SIP/202&SIP/203

Asterisk provides a syntax for allowing more than one channel to be mapped to any particular extension with the hint system.

Example 3: Callpark indication (Asterisk 1.4 and newer):

include => parkedcalls
exten => 701,1,ParkedCall(701)
exten => 701,hint,park:701@parkedcalls

Example 4: Dynamic hints in Asterisk 1.6.1

Q: Is it possible to have something like

exten => _XXX,hint,SIP/${EXTEN}

in extensions.conf so that I don't have to add hint for each sip peer I create?

A:: Only in 1.6.1 and later. The hints will grow, as phones subscribe to them, one entry per hint, automatically.
When the phone unsubscribes the hint will continue to exist until a reload is performed. This is how dynamic hints work - they are created as needed and disappear on reload, if they are no longer being watched.

See also

Created by: oej, Last modification: Thu 26 of Apr, 2012 (03:59 UTC) by admin
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+