Build System

• The location of the sample configuration files delivered with Asterisk have been moved from configs to configs/samples. This allows for other sample configuration sets to be defined in the future. The action of make samples is exactly the same as previous versions of Asterisk.
• The menuselect tool has been pulled into the Asterisk repository. Generally, this change is transparent to those using tarballs of Asterisk; to those working directly with the Asterisk repository, there is no accessing of the menuselect or mxml external repositories.
• The menuselect tool no longer uses a bundled mxml library. Instead, it now uses libxml2. As a result, libxml2 is now a required dependency for Asterisk.

Core

Account Codes

• Support for peeraccount was vastly improved in this version of Asterisk. Except for Queue, an accountcode is now consistently propagated to outgoing channels before dialing. A channel's accountcode can change from its original non-empty value on channel creation for the following specific reasons:
  1. The dialplan sets it using CHANNEL(accountcode).
  2. An originate method specifies an accountcode value.
  3. The calling channel propagates its peeraccount or accountcode to the outgoing channel's accountcode before dialing.
  This change has two visible effects. One, Local channels now cross accountcode and peeraccount codes across the special bridge between the ;1 and ;2 channels just like channels between normal bridges. Two, the CHANNEL(peeraccount) value can now be set before Dial and FollowMe to set the accountcode on the outgoing channel(s).
• For Queue, an outgoing channel's non-empty accountcode will not change unless explicitly set by CHANNEL(accountcode). The change has three visible effects:
  1. As previously mentioned, Local channels now cross accountcode and peeraccount across the special bridge between the ;1 and ;2 channels just like channels between normal bridges.
  2. The queue member will get an accountcode if it doesn't have one and one is available from the calling channel's peeraccount.
  3. accountcode propagation includes Local channel members where the accountcodes are propagated early enough to be available on the ;2 channel.

AMI

• Anchor
  res_mwi_external_ami res_mwi_external_ami

  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 res_manager_device_state.so and res_manager_presence_state.so. 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.

• Anchor
  ami_security_events ami_security_events

  AMI will now emit security events. A new class authorization has been added in manager.conf for the security events, security. The new events are:

...

• Operations that create a resource can now provide the unique identifier as a parameter to the creation request. This includes:
  • Channels:
    • A channelId can now be provided when creating a channel, either in the request URI (POST channels/my-channel-id) or as a query parameter. A Local channel will suffix the second channel id with ;2 unless the otherChannelId is provided as a query parameter.
    • A snoop channel can be started with a snoopId, in the request URI (POST channels/my-channel-id/snoop/my-snoop-id) or as a query parameter.
  • Bridges: A bridgeId can now be provided when creating a bridge, either in the request URI (POST bridges/my-bridge-id) or as a query parameter.
  • Playbacks: A playbackId can be provided when starting a playback, either in the request URI (POST channels/my-channel-id/play/my-playback-id or POST bridges/my-bridge-id/play/my-playback-id) or as a query parameter.
• 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
  ari_text_message ari_text_message

  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
  res_ari_mailboxes res_ari_mailboxes

  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 set of Alembic scripts has been added for CDR tables. This will create a 'create a cdr' table with the default schema that Asterisk expects.
• Numerous updates have been made to the database schemas for several tables. See the Upgrading to Asterisk 13 notes for more information.

TLS

• The TLS core in Asterisk now supports Perfect Forward Secrecy (PFS). Enabling PFS is attempted by default, and is dependent on the configuration of the module using TLS.

  • Ephemeral ECDH (ECDHE) is enabled by default. To disable it, do not specify a ECDHE cipher suite in sip.conf, for example:

    Code Block
    tlscipher=AES128-SHA:DES-CBC3-SHA

  • Ephemeral DH (DHE) is disabled by default. To enable it, add DH parameters into the private key file, e.g., sip.conf tlsprivatekey. For example, the default dh2048.pem - see http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-35.1/src/apps/dh2048.pem?txt

  • Because clients expect the server to prefer PFS, and because OpenSSL sorts its cipher suites by bit strength, see openssl ciphers -v DEFAULT. Consider re-ordering your cipher suites in the respective configuration file. For example:
    
    

    Code Block
    tlscipher=AES128+kEECDH:AES128+kEDH:3DES+kEDH:AES128-SHA:DES-CBC3-SHA:-ADH:-AECDH

    will use PFS when offered by the client. Clients which do not offer PFS fall-back to AES-128 (or even 3DES, as recommended by RFC 3261).

...

Anchor
TALK_DETECT TALK_DETECT

TALK_DETECT

• A new function, TALK_DETECT, has been added. When set on a channel, this function causes events indicating the starting/stopping of talking on said channel to be emitted to both AMI and ARI clients.

Resources

res_config_pgsql

• Added the ability to support PostgreSQL application_name on connections. This allows PostgreSQL to display the configured name in the pg_stat_activity view and CSV log entries. This setting is configurable for res_config_pgsql via the dbappname configuration setting in res_pgsql.conf.

res_hep

• A new module, res_hep, has been added that acts as a generic packet capture agent for the Homer Encapsulation Protocol (HEP) version 3. It can be configured via hep.conf. Other modules use res_hep to send message traffic to a HEP capture server.

res_hep_pjsip

• A new module, res_hep_pjsip, has been added that will forward PJSIP message traffic to a HEP capture server. See res_hep for more information.

res_hep_rtcp

• A new module, res_hep_rtcp, has been added that will forward RTCP call statistics to a HEP capture server. See res_hep for more information.

res_mwi_external

• 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_voicemail. res_mwi_external and other modules that depend on it cannot be built or loaded with app_voicemail present.

res_parking

• Manager action Park now takes an additional argument AnnounceChannel which can be used to announce the parked call's location to an arbitrary channel in a bridge. If Channel and TimeoutChannel are the two parties in a two-party bridge, TimeoutChannel is treated as having parked Channel (in the same manner as the Park Call DTMF feature) and will receive announcements prior to being hung up.

res_pjsip

• The endpoint configuration object now supports accountcode. Any channel created for an endpoint with this setting will have its accountcode set to the specified value.
• transport and endpoint ToS options (tos, tos_audio, and tos_video) may now be set as the named set of ToS values ( cs0 - cs7, af11 - af43, ef).
• Added the following new CLI commands:
  • pjsip show contacts - list all current PJSIP contacts.
  • pjsip show contact - show specific information about a current PJSIP contact.
  • pjsip show channel - show detailed information about a PJSIP channel.
• Path support has been added with the support_path option in registration and aor sections. This functionality is provided by a new module, res_pjsip_path.so.
• A debug option has been added to the globals section that will allow sip messages to be logged.
• A set_var option has been added to endpoints that will automatically set the desired variable(s) on a channel created for that endpoint.
• DNS functionality will now automatically be enabled if the system configured nameservers can be retrieved. If the system configured nameservers can not be retrieved the functionality will resort to using basic system resolution. Functionality such as SRV records and fail-over will not be available if the basic system resolution is in use.
• Several new tables and columns have been added to the realtime schema for the res_pjsip related modules. See the UPGRADE notes for updating the database schema.

...

Anchor
res_pjsip_pubsub res_pjsip_pubsub

res_pjsip_pubsub

• 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.

res_pjsip_pidf_digium_body_supplement

...

res_pjsip_outbound_publish

...

• A new module, res_pjsip_outbound_publish provides the mechanisms for sending PUBLISH requests for specific event packages to another SIP User Agent. See Exchanging Device and Mailbox State Using PJSIP for examples on configuring this feature.

res_pjsip_outbound_registration

• A new CLI command has been added: pjsip show registrations, which lists all configured PJSIP registrations.

Anchor
res_pjsip_publish_asterisk

asdf

res_

...

• A new module, res_hep, has been added that acts as a generic packet capture agent for the Homer Encapsulation Protocol (HEP) version 3. It can be configured via hep.conf. Other modules can use res_hep to send message traffic to a HEP capture server.

res_hep_pjsip

• A new module, res_hep_pjsip, has been added that will forward PJSIP message traffic to a HEP capture server. See res_hep for more information.

res_hep_rtcp

pjsip_publish_asterisk

res_pjsip_publish_asterisk

• A new module, res_hep_rtcp, has been added that will forward RTCP call statistics to a HEP capture server. See res_hep for more information.

...

res_mwi_external

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 res_mwi_external_ami and res_ari_mailboxes. Note that res_mwi_external canflicts with other modules that may produce MWI themselves, such as app_voicemail. res_mwi_external and other modules that depend on it cannot be built or loaded with app_voicemail present.

res_parking

...

• pjsip_publish_asterisk adds support for PUBLISH requests of Asterisk information to other Asterisk servers. This module is intended only for Asterisk to Asterisk exchanges of information. Currently, this includes both mailbox state and device state information. See Exchanging Device and Mailbox State Using PJSIP for examples on configuring this feature.