[asterisk-app-dev] Channel indications

[Paul Belanger]

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