[Asterisk-code-review] res/res_ari_channels.c: Added new ARI /ari/channels/<channelId>/dump (...asterisk[master])

[sungtae kim]

sungtae kim has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/11162 )

Change subject: res/res_ari_channels.c: Added new ARI /ari/channels/<channelId>/dump
......................................................................


Patch Set 1:

> Patch Set 1:
> 
> > Patch Set 1:
> 
> <snip>
> 
> > 
> > Hi Joshua,
> > 
> > Thank you for your kind reviewing. :)
> > I'm totally agree with you. Changing something without context or detail use-case, it makes easy to loosing the direction.
> > 
> > I expect the ARI user can get a detail/debug info for ARI programming(channel) with this change.
> > 
> > It was little bit hard to obtaining the Channel's detail info using ARI. To getting detail info, it has to be done by the AMI or dialplan.
> > 
> > But for the ARI user, it's not an easy to use another interface for that. As an ARI user point of view, I want to stick to the ARI as long as possible(I love AMI, AGI, and Dialplan, but the ARI makes every problem so easy).
> > 
> > For example, in the situation of start/restart the stasis application(which is connected
> > to the Asterisk), I needed to follow up the existed channel's detail information. And also I want to get these information (answered time, application, application data, format and so on) throught ARI, to checking the status time to time.
> 
> For what purpose though? How is the information actually used? What I'm trying to determine is what the real usage/problem it solves is - not what the addition of the route adds. This is important to ensure that this is indeed the best way to solve the problem, and that it's not just working around some other core thing.
>  
> > That was the reason why I want to add this feature.
> > 
> > p.s.
> > This would be different story, but I think if the ARI working as AMI, it will gives more flexibility to the Asterisk in the long long after future. :)


> For what purpose though? How is the information actually used?
Ah! Here's actual usage.
If the our application goes down and up again, we losing the ARI events while it was down. So it makes losing the call. 

Btw, after our application is going up, it access to the Asterisk through the ARI, and getting exiting channels info. At this moment, I would like to know which channels are in the Stasis() with what arguments. Because with arguments, we could figure out channel's detail purposes(why it created, where this call goes to and so on..)

Hm... Now I can see it.

I thought, replication channel dump would be fine, because it covers most of channel's info. But looks like adding app_name, app_data would be good enough for this purpose...

I will abandon this MR. If you agree I would like to make a patch for adding the app_name, app_data item into channel. Is it OK?


> I understand you want to use ARI instead of AMI/AGI/Dialplan, and it would certainly be nice if it could take that place. It's a big project though - and it's something that would require a lot of thought. Something to keep in mind with all of these things - and part of the reason why I posted my comment initially - is that they generally can't change once they go in except for extreme cases. We have to support them, and they have to remains backwards compatible.
-> Yes, I can see your point. I didn't think that could be done within few days as well. I will keep in mind what you said.


-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/11162
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: Ie5b6c8b20a2bda5168ea56114f4241bc818cab10
Gerrit-Change-Number: 11162
Gerrit-PatchSet: 1
Gerrit-Owner: sungtae kim <pchero21 at gmail.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: sungtae kim <pchero21 at gmail.com>
Gerrit-Comment-Date: Tue, 19 Mar 2019 23:56:02 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20190319/317fc925/attachment-0001.html>