[asterisk-app-dev] Channel indications

[Matthew Jordan]

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>