[asterisk-app-dev] Channel indications

[Paul Belanger]

On 13-10-21 11:54 AM, Daniel Jenkins wrote:
> 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.
>>
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.

>> 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
>
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.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger