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

[Matt Jordan (JIRA)]

Matt Jordan created ASTERISK-23939:
--------------------------------------

             Summary: 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


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)