ARI: Re-implement the ARI dial command, allowing for early bridging.
authorMark Michelson <mmichelson@digium.com>
Mon, 9 May 2016 19:48:51 +0000 (14:48 -0500)
committerMark Michelson <mmichelson@digium.com>
Fri, 27 May 2016 14:08:49 +0000 (09:08 -0500)
commit88d997913faabe81f8b9e7bdaa56742be0d669b9
treedde0bb91e5840514d684887bb8e5e10864e3dcc3
parentf6c33771f660c3ad15bc554b355cb21e83c85e36
ARI: Re-implement the ARI dial command, allowing for early bridging.

ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.

The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.

This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.

This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.

ASTERISK-25925

Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb
include/asterisk/stasis_app.h
res/ari/resource_channels.c
res/res_stasis.c
res/stasis/control.c