[asterisk-bugs] [JIRA] (ASTERISK-23939) ARI: Allow for channel subscriptions on originate

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-23939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan closed ASTERISK-23939.
----------------------------------

    Resolution: Fixed

> ARI: Allow for channel subscriptions on originate
> -------------------------------------------------
>
>                 Key: ASTERISK-23939
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23939
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_ari
>    Affects Versions: 12.3.2
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)