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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131025/5ac708a9/attachment.html>
