[Home]

Summary:ASTERISK-23939: ARI: Allow for channel subscriptions on originate
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2014-06-25 16:55:09Date Closed:2014-07-06 21:16:26
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_ari
Versions:12.3.2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Currently, ARI allows for channel origination in two forms:

# Originate to an application
# Originate to an extension in the dialplan

When originating a channel to an application, a user can choose to originate directly to their Stasis application. When this occurs, the channel enters into the Stasis app and a {{StasisStart}} event is emitted. This implicitly creates a subscription for the channel, as channels that enter into a Stasis application always get a subscription created for them.

However, when originating to the dialplan, a subscription is not automatically created (since it doesn't go into Stasis). The user _can_ create a subscription to the channel via the {{applications}} resource, however, since the channel is already off and running, it may already be doing things that you care about and want to know about.

The way people have worked around this thus far is to use a separate Stasis application in the dialplan that creates the subscription - and then the channel is released again. This is something of a kludge, and is a workaround to not having a subscription on the channel.

Instead, when the channel is originated, an option should be provided that allows the ARI app to create a subscription to the channel. This should be optional for backwards compatibility purposes.

Note that this will take some minor tweaks to the PBX core - in order to safely make sure that we get a subscription to a channel, we want to pass this into the origination routines - but those routines are getting extremely clunky. Since 99% of what users of that API have to do is modify a channel after it is created (but before dialing occurs), we should provide a callback parameter (with an option void data pointer) that will be called after {{ast_request}} but before the {{dial}} API takes over.
Comments:By: Matt Jordan (mjordan) 2014-07-03 15:42:56.809-0500

Turns out this was much easier than the description implied. No changes should be necessary to the API: we already implicitly subscribe a channel that is heading off to a Stasis application. As a result, this is really more of a bug: if you pop a channel off to Stasis, you should get a subscription on both halves of the Local channel.