+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. On Fri, Oct 25, 2013 at 9:10 AM, Matthew Jordan <mjordan at digium.com> wrote: > > On Fri, Oct 25, 2013 at 9:01 AM, Joshua Colp <jcolp at digium.com> wrote: > >> A further follow-up on answer/progress... >> >> There's really 3 options we can do and people have differing views so >> let's hash it out. >> >> The options are as follows: >> >> 1. Media operations implicitly answer but have an option not to. >> >> 2. Media operations do not implicitly answer or send progress indication. >> The /answer or /progress operations must be invoked or the behavior is less >> than defined. >> >> 3. Media operations send progress if unanswered and not already sent. >> Answering requires explicit call to /answer >> >> We need to pick one of those and stick with it. >> >> > My preference is number 3. > > Answering should usually be explicit, as the act of answering usually > indicates to billing systems to start billing. It is also an indication > that bidirectional audio should now be possible. Implicitly answering - > unless there's no other options - feels like it should be avoided when > possible to avoid confusion with other external systems. > > Progress as a concept is a signalling implementation detail. If you're in > a Stasis application, you've clearly established some connection with > Asterisk; the fact that a progress indication is necessary for some channel > drivers to update media information is a leaky abstraction from multiple > signalling protocols up through the API. You could design a signalling > protocol that never needed a progress indication when media is sent from > Asterisk to the device prior to being answered. That's why I'm not a giant > fan of Progress in the API - it feels like it's a somewhat necessary evil > for things like SIP, but completely unnecessary for other potential > signalling schemes. > > And if I'm not a telephony guy and I want to make use of Asterisk to power > my business communications, do I really want to know that I have to call > /progress before I issue a /playback on a channel that I haven't answered > yet? To me, that just feels cumbersome. > > I don't feel so strongly about this that I would be unhappy with /progress > being present, but I'd love to find a way for it to not be necessary. > > Matt > > -- > 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 > > -- [image: Digium logo] *Scott Griepentrog* Digium, Inc ? Software Developer 445 Jan Davis Drive NW ? Huntsville, AL 35806 ? US direct/fax: +1 256 428 6239 ? mobile: +1 317 507 4029 Check us out at: http://digium.com <http://www.digium.com> ? http://asterisk.org <http://www.asterisk.org> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131025/711f2ec7/attachment.html>
