Channel indications

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

 



On Mon, Oct 21, 2013 at 9:15 AM, Joshua Colp <jcolp at digium.com> wrote:
> Paul Belanger wrote:
>>
>> On to the next topic :D
>>
>> So, Josh has a patch up on reviewboard[1] that adds indication support
>> to /channels. After looking at the patch, it looks like we 2 basic
>> ways of controlling a channel with /channel/:id
>>
>> Either you can use:
>>
>> /answer
>> /hold
>>
>> or you can use:
>>
>> /indicate?name=busy
>>
>> For the sake consistency I'd like to see us pick one.  I can go either
>> way, but the more I think about it
>>
>> /indicate?name=answer
>> /indicate?name=hold
>> /indicate?name=busy
>>
>> would give us a cleaner API for channels.
>>
>> Thoughts?
>
>
> I agree that the hold stuff should go into indicate but I'm torn on moving
> answer there because having it separate makes the API more approachable by
> non-telephony developers. They probably don't know about indications and may
> not even ever need to. They do know what answer is though right off the bat.
>
> (That's personal preference, as I favor a balance of
> clean/approachable/logical when it comes to API design).
>
Fair enough, then I would propose dropping /indications and just
having /busy. /answer, /hold routes and move on.

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



[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