[asterisk-app-dev] Channel indications

[Paul Belanger]

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