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>
