Channel indications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

-- 
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/20131021/f30cc221/attachment.html>


[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux