<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 25, 2013 at 9:01 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A further follow-up on answer/progress...<br>
<br>
There's really 3 options we can do and people have differing views so let's hash it out.<br>
<br>
The options are as follows:<br>
<br>
1. Media operations implicitly answer but have an option not to.<br>
<br>
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.<br>
<br>
3. Media operations send progress if unanswered and not already sent. Answering requires explicit call to /answer<br>
<br>
We need to pick one of those and stick with it.<div class="im HOEnZb"><br></div></blockquote><div><br></div><div style>My preference is number 3.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div><div style><br></div><div style>
Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>