[asterisk-app-dev] Channel indications

[Daniel Jenkins]

On Mon, Oct 21, 2013 at 4:47 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
> On Mon, Oct 21, 2013 at 10:05 AM, Daniel Jenkins <dan.jenkins88 at gmail.com>wrote:
>
>>
>> On Mon, Oct 21, 2013 at 3:55 PM, Joshua Colp <jcolp at digium.com> wrote:
>>
>>> Daniel Jenkins wrote:
>>>
>>>> Is this to put a channel on hold/answer etc or to find out what state
>>>> the channel is in?
>>>>
>>>
>>> It's to put a channel on hold, instruct it to indicate ringing, etc.
>>>
>>>
>>> --
>>> Joshua Colp
>>> Digium, Inc. | Senior Software Developer
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> Check us out at:  www.digium.com  & www.asterisk.org
>>>
>>> ______________________________**_________________
>>> asterisk-app-dev mailing list
>>> asterisk-app-dev at lists.digium.**com <asterisk-app-dev at lists.digium.com>
>>> http://lists.digium.com/cgi-**bin/mailman/listinfo/asterisk-**app-dev<http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev>
>>>
>>
>>
>> Oh right OK, I would agree with Paul on this one,
>>
>> One, the api is being designed partially so that non telephony people can
>> get into this, I didn't know what indicate meant in this context
>>
>> I would have this as a PUT (you're updating the state of that channel as
>> such) and have /ari/channel/{id}/hold (or whatever the prefix is) etc
>>
>> This is very clear, you're updating a channel to be in a hold state/
>> you're telling the channel to answer etc.
>>
>> so +1 to Paul
>>
>>
> 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.
>
> Follow up: how ugly is it to have a parameter passed to DELETE?
>

Not ugly at all!

Especially when the BODY issue gets worked on, you'd have a JSON object
with the extra params

This is definitely how I'd deal with the many iterations of how you could
hangup

+1

>
> --
> 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131021/13f2e7a3/attachment.html>