On Mon, Oct 21, 2013 at 11:53 AM, Paul Belanger < paul.belanger at polybeacon.com> wrote: <snip> > >>>> >>>> Before we decide to obliterate /indicate, do we foresee a need for >>> other >>> indications, e.g., /busy, /congestion, etc.? These are more in the >>> "telephony" concepts subdomain, and are really different ways to destroy >>> a >>> channel. I'd prefer to not have them at all, honestly - the fact that you >>> are disposing of a channel is all you should really care about through >>> the >>> API. Playing a particular tone when that occurs feels more like an >>> optional >>> detail, and not a true separate operation. But I'd hate to have a >>> proliferation of similar concepts as separate operations when they make >>> more sense grouped together. >>> >>> This was one of the reason I was trying to suggest, if we do expose > more / all, I'd have to have /congestion /ring. /noanswer for each one. > But if /indicate was alive, it would just be a reason varaible passed. > > > >>> <snip> > >> I've been trying to find a solution to this issue too. I can't really > find a best pratice for it either. Unless there is a specific reason NOT to > add parameters to a DELETE, I'm fine with passing them. > > After this discussion, it feels like we have the following path forward for indications (and Josh's code review https://reviewboard.asterisk.org/r/2916/ ) * No explicit /indications * Add /ringing * Add /progress * Add generic, non-technology specific hangup cause reasons to the DELETE /channels/{id} operation. * Include busy as a reason * Include congestion as a reason * Keep /hold, /answer as they are The only one I'd prefer to debate further is /progress, as it feels like that can be inferred from performing a media operation on an unanswered channel. I'm not sure, however, if there's value in keeping it as an explicit operation. Thoughts? Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131022/6a265419/attachment.html>
