Skip to end of metadata
Go to start of metadata


The Hangup Cause family of functions and dialplan applications allow for inspection of the hangup cause codes for each channel involved in a call. This allows a dialplan writer to determine, for each channel, who hung up and for what reason(s). Note that this extends the functionality available in the HANGUPCAUSE channel variable, by allowing a calling channel to inspect all called channel's hangup causes in a variety of dialling situations.

Note that this feature replaces the technology specific mechanism of using the MASTER_CHANNEL function to access a SIP channel's SIP_CAUSE, as well as extends similar functionality to a variety of other channel drivers.

Dialplan Functions and Applications


Used to obtain a comma separated list of all channels for which hangup causes are available.


The following example shows one way of accessing the channels that have hangup cause related information after a Dial has completed. In this particular example, a parallel dial occurs to both SIP/foo and SIP/bar. A hangup handler has been attached to the calling channel, which executes the subroutine at handler,s,1 when the channel is hung up. This queries the HANGUPCAUSE_KEYS function for the channels with hangup cause information and prints the information as a Verbose message. On the CLI, this would look something like:


Used to obtain hangup cause information for a specific channel. For a given channel, there are two sources of hangup cause information:

  1. The channel technology specific hangup cause information
  2. A text description of the Asterisk specific hangup cause

Note that in some cases, the hangup causes returned may not be reflected in Hangup Cause Mappings. For example, if a Dial to a SIP UA is cancelled by Asterisk, the SIP UA may not have returned any final responses to Asterisk. In these cases, the last known technology code will be returned by the function.


This example illustrates obtaining hangup cause information for a parallel dial to SIP/foo and SIP/bar. A hangup handler has been attached to the calling channel, which executes the subroutine at handler,s,1 when the channel is hung up. This queries the hangup cause information using the HANGUPCAUSE_KEYS function and the HANGUPCAUSE function. The channels returned from HANGUPCAUSE_KEYS are parsed out, and each is queried for their hangup cause information. The technology specific cause code as well as the Asterisk cause code are printed to the CLI.


Used to remove all hangup cause information currently stored.


The following example clears the hangup cause information from the channel if SIP/foo fails to answer and execution continues in the dialplan. The hangup handler attached to the channel will thus only report the the name of the last channel dialled.

  • No labels


  1. [handler]
    same => s,1,NoOp()
    same => n,Verbose(0, Channels with hangup cause information: ${HANGUPCAUSE_STRING})
    same => n,Return()
    May be 'exten => s,1,NoOp()' ?
  2. Why start every context with an empty NoOp? Aren't NoOps mostly useful for debugging when you have them print the value of some variable?

    1. François Beaulieu Most people do that so they can use n and switch things around later. For Instance say I have now:

      Exten => s,1,Answer
      Exten => s,n,PlayBack(Some-file)

      And now I want to test with no answer I need to edit it and do:
      ;Exten => s,1,Answer
      Exten => s,1,PlayBack(Some-file)

      If I have:
      Exten => s,1,Noop()
      Exten => s,n,Answer
      Exten => s,n,PlayBack(Some-file)

      I can easily comment out any line I want as I work without having to worry about the first priority needing to be set.