[asterisk-bugs] [JIRA] (ASTERISK-24870) ARI: Subscriptions to bridges generally not super useful

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-24870:
-----------------------------------

    Status: Open  (was: Triage)

> ARI: Subscriptions to bridges generally not super useful
> --------------------------------------------------------
>
>                 Key: ASTERISK-24870
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24870
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_ari_applications, Resources/res_ari_bridges
>            Reporter: Matt Jordan
>
> Consider the following use case:
> {quote}
> I would like to build a 'monitor' of the calls in my Asterisk system, and display them in a pretty fashion on some awesome web-page
> {quote}
> Today, if you wanted to do that using ARI, you'd run into a few challenges:
> # ARI is all about the Stasis dialplan application. Loves it. If you want to know anything about what is occurring outside of that, you have to subscribe to those things. Okay, fair enough.
> # Subscriptions are managed and created through the {{applications}} resource. Using that, you can subscribe to all {{endpoints}} of certain technology types. This will create a subscription to each {{endpoint}} in a technology, which in turn creates implicit subscriptions to all channels created for a particular endpoint. That doesn't get you _all_ channels, but it gets you most of them (SIP, PJSIP, IAX, and Motif).
> # Unfortunately, that doesn't get you the bridges that a channel may create. So while you can see the channels, you can't tell who is talking to whom.
> Now, we can subscribe to a bridge using the {{applications}} resource - but how do we know what bridges to subscribe to? We aren't told when they exist. Even if we are told when they exist, we would still have to subscribe to the bridge, at which point a channel has probably already popped into it.
> Nuts.
> I've been trying to think of how the existing subscription model is useful for bridges, and I really can't think of how it would work in a useful fashion.
> The problem with the subscription model that we have is that for things that are relatively static (endpoints!) it works quite well. For things that are ephemeral - channels and bridges being the two obvious folks - it ... doesn't. At the same time, showing everyone everything all the time in all applications leads to the world of pain that is AMI filtering, and I don't think we want to visit that again.
> The root cause of the issues with bridges is that they don't _really_ exist in an application - they're an independent construct that is its own thing. Channels exist in applications; bridges just sort of "are". They have to exist this way: channels can get shoved into/pulled out of bridges by things outside of ARI (such as an externally initiated attended transfer).
> Thus, we end up with potentially needing something slightly different for this use case: the ability to subscribe to _all_ things and just filter them out on the client. This can still be initiated by the client using the {{applications}} resource - at least in that case it is saying it wants to see the world - and it doesn't really change the ownership semantics of channels.



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