On Tue, Oct 22, 2013 at 11:52 AM, Matthew Jordan <mjordan at digium.com> wrote: > > > 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? > I like consistency! One comment, it should be: /ring to keep the suffix in check. Otherwise, it should be /answering /busying -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
