Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Asterisk 13 is the next Long Term Support (LTS) release of Asterisk. As such, the focus of development for this release of Asterisk was on improving the usability and features developed in the previous Standard release, Asterisk 12. Beyond a general refinement of end user features, development focussed heavily on the Asterisk APIs - the Asterisk Manager Interface (AMI) and the Asterisk REST Interface (ARI) - and the PJSIP stack in Asterisk. Some highlights of the new features include:

  • Asterisk security events are now provided via  AMI, allowing end users to monitor their Asterisk system in real time for security related issues.
  • External control of Message Waiting Indicators (MWI) through both AMI and ARI.
  • Reception/transmission of out of call text messages using any supported channel driver/protocol stack through ARI.
  • Resource List Server support in the PJSIP stack, providing subscriptions to lists of resources and batched delivery of NOTIFY requests.
  • Inter-Asterisk distributed device state and mailbox state using the PJSIP stack.

And much more!

It is important to note that Asterisk 13 is built on the architecture developed during the previous Standard release, Asterisk 12. Users upgrading to Asterisk 13 should read about the new features documented in New in 12, as well as the notes on upgrading to Asterisk 12. In particular, users upgrading to Asterisk 13 from a release prior to Asterisk 12 should read the specifications on AMI, CDRs, and CEL, as these also apply to Asterisk 13:

Finally, all users upgrading to Asterisk 13 should read the notes on upgrading to Asterisk 13.


titleAsterisk 12 was different

Some of the new features listed below were released in point releases of Asterisk 12. Per the Software Configuration Management Policies laid out for Asterisk 12, new features were periodically merged and released in that branch of Asterisk. This was done to help users of Asterisk migrating to the new platform develop features in preparation for Asterisk 13.

While some of the features listed below were released under an Asterisk 12 release, they are all listed here as "new in 13", for two reasons:

  1. If you are upgrading from a previous LTS release (such as Asterisk 11), all of these features are new.
  2. If you are upgrading from some version of Asterisk 12, some of the previously released features may be new (as they may not have been in your version of Asterisk 12).



  • The application will now return a new AGENT_STATUS value of NOT_CONNECTED if the agent fails to connect with an incoming caller after being alerted to the presence of the incoming caller. The most likely reason this would happen is the agent did not acknowledge the call in time.


  • ChanSpy now accepts a channel uniqueid or a fully specified channel name as the chanprefix parameter if the 'u' option is specified.


  • The ConfBridge dialplan application now sets a channel variable, CONFBRIGE_RESULT, upon exiting. This variable can be used to determine how a channel exited the conference. Valid values upon exiting are:

    The channel encountered an error and could not enter the conference.
    The channel exited the conference by hanging up.
    The channel was kicked from the conference.
    The channel left the conference as a result of the last marked user leaving.
    The channel pressed a DTMF sequence to exit the conference.
  • Added conference user option 'announce_join_leave_review'. This option implies 'announce_join_leave' with the added effect that the user will be asked if they want to confirm or re-record the recording of their name when entering the conference.


  • The module app_dahdibarge was deprecated and has been removed. Users of DAHDIBarge should use ChanSpy instead.


  • At exit, the Directory application now sets a channel variable DIRECTORY_RESULT to one of the following based on the reason for exiting:

    user requested operator by pressing '0' for operator
    user requested assistant by pressing '*' for assistant
    user pressed nothing and Directory stopped waiting
    user's channel hung up
    user selected a user from the directory and is routed
     user pressed '#' from the selection prompt to exit
    directory failed in a way that wasn't accounted for. Dang.
titleOn this Page

Table of Contents


  • Anchor
    Added a new module that provides AMI control over MWI within Asterisk, res_mwi_external_ami. Note that this module depends on res_mwi_external; for more information on enabling this module, see res_mwi_external. This module provides the MWIGet/MWIUpdate/MWIDelete actions, as well as the MWIGet/MWIGetComplete events.


  • New DeviceStateChanged and PresenceStateChanged AMI events have been added. These events are emitted whenever a device state or presence state change occurs. The events are controlled by and If the high frequency of these events is problematic for you, do not load these modules.
  • New events have been added for the TALK_DETECT function. When the function is used on a channel, ChannelTalkingStart/ChannelTalkingStop events will be emitted to connected AMI clients indicating the start/stop of talking on the channel.
  • The DialStatus field in the DialEnd event can now contain additional statuses that convey how the dial operation terminated. This includes ABORT, CONTINUE, and GOTO.


  • Operations that create a resource can now provide the unique identifier as a parameter to the creation request. This includes:
  • Bridges: the bridge type used when creating a bridge is now a comma separated list of bridge properties. Valid options are: mixing, holding, dtmf_events, and proxy_media.
  • The LiveRecording object in recording events now contains a target_uri field which contains the URI of what is being recorded.
  • Stored recordings now support a new operation, copy. This will take an existing stored recording and copy it to a new location in the recordings directory.
  • LiveRecording objects now have three additional fields that can be reported in a RecordingFinished ARI event:
    • total_duration: the duration of the recording.
    • talking_duration: optional. The duration of talking detected in the recording. This is only available if max_silence_seconds was specified when the recording was started.
    • silence_duration: optional. The duration of silence detected in the recording. This is only available if max_silence_seconds was specified when the recording was started.
    Note that all duration values are reported in seconds.
  • Anchor
    Users of ARI can now send and receive out of call text messages. Messages can be sent using a sendMessage operation either directly to a particular endpoint or to the endpoints resource directly. In the latter case, the destination is derived from the URI scheme. Text messages are passed to ARI clients as TextMessageReceived events. ARI clients can choose to receive text messages by subscribing to the particular endpoint technology or endpoints that they are interested in.
  • The applications resource now supports subscriptions to all endpoints of a particular channel technology. For example, subscribing to an eventSource of endpoint:PJSIP will subscribe to all PJSIP endpoints.
  • New event models have been added for the  TALK_DETECT function. When the function is used on a channel, ChannelTalkingStarted/ChannelTalkingFinished events will be emitted to connected WebSockets subscribed to the channel, indicating the start/stop of talking on the channel.
  • A new Playback URI tone has been added. Tones are specified either as an indication name, e.g., tone:busy , from indications.conf or as a tone pattern, e.g., tone:240/250,0/250. Tones differ from normal playback URIs in that they must be stopped manually and will continue to occupy a channel's ARI control queue until they are stopped. They also can not be rewound or fast-forwarded.
  • User events can now be generated from ARI. Events can be signalled with arbitrary JSON variables, and include one or more of channel, bridge, or endpoint snapshots.  An application must be specified which will receive the event message (other applications can subscribe to it). If a channel is specified, the message will also be delivered to connected AMI clients. Dialplan generated user event messages are still transmitted via the channel, and will only be received by a Stasis application they are attached to or if something is subscribed to the channel.
  • The Bridge data model now contains the additional fields name and creator. The name field conveys a descriptive name for the bridge; the creator field conveys the name of the entity that created the bridge. This affects all responses to HTTP requests that return a Bridge data model as well as all event derived data models that contain a Bridge data model. The POST /bridges operation may now optionally specify a name to give to the bridge being created.
  • Anchor
    Added a new ARI resource mailboxes which allows the creation and modification of mailboxes managed by external MWI. Modules res_mwi_external and res_stasis_mailbox must be enabled to use this resource. For more information on external MWI control, see res_mwi_external.
  • Added new events for externally initiated transfers. The event BridgeBlindTransfer is now raised when a channel initiates a blind transfer of a bridge in the ARI controlled application to the dialplan; the BridgeAttendedTransfer event is raised when a channel initiates an attended transfer of a bridge in the ARI controlled application to the dialplan.
  • Channel variables may now be specified as a body parameter to the POST /channels operation. The variables key in the JSON is interpreted as a sequence of key/value pairs that will be added to the created channel as channel variables. Other parameters in the JSON body are treated as query parameters of the same name.


  • A new module, res_mwi_external, has been added to Asterisk. This module acts as a base framework that other modules can build on top of to allow an external system to control MWI within Asterisk. For implementations that make use of res_mwi_external, see the res_mwi_external_ami notes under the AMI changes and res_ari_mailboxes notes under the ARI changes. Note that res_mwi_external conflicts with other modules that may produce MWI themselves, such as app_voicemailres_mwi_external and other modules that depend on it cannot be built or loaded with app_voicemail present.


  • Subscriptions can now be persisted via the subscription_persistence object in pjsip.conf. Note that it is up to the configuration in sorcery.conf to determine how the subscription is persisted.
  • The publish/subscribe core module has been updated to support RFC 4662 Resource Lists, allowing Asterisk to act as a Resource List Server (RLS). Resource lists are configured in pjsip.conf under a new object type, resource_list. Resource lists can contain either message-summary or presence events, can be composed of specific resources that provide the event, or other resource lists.
  • Inbound publication support is provided by a new object, inbound-publication. This configures res_pjsip_pubsub to accept PUBLISH requests from a particular resource. Which events are accepted is constructed dynamically; see res_pjsip_publish_asterisk for more information and Exchanging Device and Mailbox State Using PJSIP for examples on configuring this feature.