On Fri, Oct 25, 2013 at 10: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. > So, my logic is the following. If somebody issues /playback, do a play back, if somebody does /answer, do answer. Don't have asterisk guess or pass flags into other functions to try and handle each situation. That said, I guess you indicate progress explicitly if answer has not been called? -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
