Upgrade to Asterisk 13

[lpradovera]

This will be the home for the Asterisk 13 upgrade discussion.

• Basic compatibility
• Beep integrated with Monitor
• ControlPlayback to stop output vs redirect
• Specified channel ID for associating outbound calls

Asterisk 13 upgrade notes

The main changes seem to be from version 11 to version 12, which introduces the revamped bridging core, the Stasis bus and many AMI improvements. ARI was also added in 12.

Relevant documentation

• New in 12 Asterisk wiki page
• AMI v2 Specification
• CHANGES for Asterisk 12
• UPGRADE.txt for Asterisk 12

AsyncAGI changes

AGIExec is now AGIExecStart and AGIExecEnd. We probably only use this in adhearsion-asterisk.

AsyncAGI is now AsyncAGIStart, AsyncAGIExec, and AsyncAGIEnd. This will affect our basic connection handling.

AMI changes

For the most part, subtypes for events have been removed.

We should not need to track channel name changes any more.

DTMF

The combination of DTMFBegin/DTMFEnd events replaces the removed DTMF event.

Dial

The DialBegin/DialEnd events replace theDial event. Note that the Dial event signaling the end of dialing would not normally be sent until after bridging was complete; this operation will now occur when the dial operation has determined the status of a particular called channel.

The DialEnd event will now contain a Forward header if the dial is ending due to the call being forwarded. The contents of the Forward header is the extension in the number to which the call is being forwarded. (Asterisk 13).

Bridging

There seems to be an entirely new bridging lifecycle, consisting of a few new events.

• BridgeCreate when channels are about to enter a bridge
• BridgeEnter when a channel is put in a bridge
• BridgeLeave when a channel leaves a bridge
  All events are always emitted and Asterisk 12 makes sure they are in the correct order, so we can trust that to be true.

Masquerades

They do not exist any more.

Miscellaneous changes

MixMonitor

The AUDIOHOOK_INHERIT function is no longer needed to keep a MixMonitor running during a transfer. If a MixMonitor is started on a channel, the MixMonitor will continue to record the audio passing through the channel even in the presence of transfers.

New options to play a beep when starting a recording and stopping a recording have been added. The option "p" will play a beep to the channel that starts the recording. The option "P" will play a beep to the channel that stops the recording. Introduced in Asterisk 13.

ControlPlayback

New AMI action that should allow us to not have to redirect any more to stop audio.

The ControlPlayback action allows an AMI client to manipulate audio currently being played back on a channel. The supported operations depend on the application being used to send audio to the channel. When the audio playback was initiated using the ControlPlayback application or CONTROL STREAM FILE AGI command, the audio can be paused, stopped, restarted, reversed, or skipped forward. When initiated by other mechanisms (such as the Playback application), the audio can be stopped, reversed, or skipped forward.

BridgeWait

A new application in Asterisk, this will place the calling channel into a holding bridge, optionally entertaining them with some form of media. Channels participating in a holding bridge do not interact with other channels in the same holding bridge. Optionally, however, a channel may join as an announcer. Any media passed from an announcer channel is played to all channels in the holding bridge. Channels leave a holding bridge either when an optional timer expires, or via the ChannelRedirect application or AMI Redirect action.

Hold

The AMI Hold event has been moved out of individual channel drivers, into core, and is now two events: Hold and Unhold. The status field has been removed.

Other changes

• NewPeerAccount has been removed. NewAccountCode is raised instead.
• Reload events have been consolidated and standardized.
• ModuleLoadReport has been removed.
• FaxSent is now SendFAX; FaxReceived is now ReceiveFAX. This standardizes
  app_fax and res_fax events.
• MusicOnHold has been replaced with MusicOnHoldStart and MusicOnHoldStop.
• JabberEvent has been removed.
• Hold is now in the core and will now raise Hold and Unhold events.
• Join is now QueueCallerJoin.
• Leave is now QueueCallerLeave.
• Agentlogin/Agentlogoff is now AgentLogin/AgentLogoff, respectively.
• ChannelUpdate has been removed.
• Local channel optimization is now conveyed via LocalOptimizationBegin and
  LocalOptimizationEnd.
• BridgeAction and BridgeExec have been removed.
• BlindTransfer and AttendedTransfer events were added.
• Dial is now DialBegin and DialEnd.
• DTMF is now DTMFBegin and DTMFEnd.
• Bridge has been replaced with BridgeCreate, BridgeEnter, BridgeLeave, and
  BridgeDestroy
• MusicOnHold has been replaced with MusicOnHoldStart and MusicOnHoldStop
• AGIExec is now AGIExecStart and AGIExecEnd
• AsyncAGI is now AsyncAGIStart, AsyncAGIExec, and AsyncAGIEnd

[benlangfeld]

Work has started at #246

[lpradovera]

Notes on the new bridging API:

• BridgeExec is gone. This means we need to delete pending joins on BridgeEnter, I assume.
• BridgeAction is gone, but aside from a single mention in specs, we do not handle that anyways.
• Bridge with BridgeState is gone, and this is probably the messiest change. Bridge plus Link is now BridgeEnter, and Bridge plus Unlink is now BridgeLeave. The good news is that the AMI v2 docs state that alle events are mandatory and should come in predictable order.

[lpradovera]

For reference and comparison, this is an Asterisk 11 call: https://gist.github.com/polysics/b1f315e18456f34985e2 and this is an Asterisk 13 call: https://gist.github.com/polysics/dcbfa14ca96e36c6fb3d

[lpradovera]

The main change is that now the Bridge* events do not have a Channel1/Channel2 reference. This means we have to track channel/bridge state internally.

[benlangfeld]

We shouldn't need to track state, we just need to react to individual events for each call rather than a single event spanning both bridged legs. This is actually an improvement, because it needs no special handling of such spanning events compared to standard events which relate to a single call.

[benlangfeld]

Basic support for Asterisk 13 was released in 2.7.0. This release did not include any optimisations now possible because of AMIv2. I will list these above as a checklist.