[asterisk-app-dev] Channel indications

[Matthew Jordan]

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>