On Fri, Oct 25, 2013 at 10:19 AM, Scott Griepentrog <sgriepentrog at digium.com> wrote: > > +1 on #3 > > The web api should not be as cumbersome as telephony signalling, but enforcing an explicit answer is still the right call because of it's implications. You could also add an answer option to a playback to reduce api interaction steps and delay - as in, I want to play this greeting, but answer the call first. Or even the other way around - answer with a playback option. Answer must be "signalled", but there could be an advantage to doing both answer in playback in one operation because 90% of the time that's the first thing you're going to do. > I don't think we want to go down this path. Honestly, I don't really see people consuming the ARI REST api directly, there is going to be some sort of middleware around it. For example, people are going to build apps on adhesion or they are going to build there own library. I think is it perfectly acceptable for people to add in this additional logic there. Going down the rabbit hole of adding switches to playback for answer / no answer is going to be line to walk. Keep ARI simple, if you need additional functionality, extend it on top. Don't try to embed every possible outcome with Asterisk. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
