[asterisk-app-dev] Expected Early Bridge Behavior

Wed Mar 9 10:41:54 CST 2016

On 03/09/2016 03:03 AM, Ben Merrills wrote:
> Hey Mark,
Hi Ben, in addition to answering your questions, I have some comments 
below your answers down below.

>
> Firstly let me say it's great news to hear this is being addressed! Early media has been a thorn in my side for ARI (as much as I love it). I'll be following this very closely. This has been an active discussion often in #asterisk-ari.
>
> Couple of questions.
> 1. Do you intend to add a channel state event for Progress (like with ringing)? Simply returning the channel doesn't mean there's early media on it, could it be useful to know when early media is being provided? (Currently ARI has no facility for this either). Having an event raised as well on the channel would let app writers decide, do I add the channel to the bridge, do I maybe just ignore the early media and do something like play ringing indications to the other party?

This certainly could be done, I suppose. It sounds like your intended 
use case would be to create a channel, call it, and then if early media 
is present, place that outbound channel into a bridge. My thinking had 
been more along the lines of, create a channel, place it into a bridge 
while it is still "down", and then call it. That way, the inbound caller 
hears whatever the outbound channel sends back (ringing, early media, 
etc.). If you want to be able to conditionally add an "early" channel to 
the bridge though, then events like you suggest would be useful.

> 2. Would there be a different bridge tech for early media? Just trying to understand the setup.
So when you say "bridge tech", are you referring to the ARI options for 
bridges (currently "mixing," "holding," etc.)? if so, then from the ARI 
writer's point of view, it's expected that there will be nothing new. 
Bridges will automatically operate in "early" mode whether you state 
they are a mixing bridge or holding bridge. It will likely operate based 
on channel states and roles assigned to channels that enter the bridge.

Internally, it's still up for debate about whether an early bridging 
ast_bridge_technology will be written. What we know right now is that 
the bridge will have to understand which channels are "inbound" channels 
and which are "outbound" channels in order to know how to pass the 
media. For one-to-one bridges, the bridge_simple technology likely will 
"just work" already. We would need to alter bridge_softmix to be able to 
understand inbound and outbound channels so that it can properly send 
media where it should (e.g. when multiple outbound channels are present, 
block their media. When one outbound channel is present, send its early 
media to all inbound channels). However, if altering existing bridge 
technologies proves to be infeasible for some reason, then writing a 
separate bridge technology for early bridges would likely be done instead.

>
> See my comments to your questions below. (hope they make sense)
> Ben/Skrusty
>
>> Hello List,
>>
>> One thing that ARI lacks at the moment is a way to enable early media from
>> an outbound channel be sent to an inbound channel.
>>
>> The way we intend to fix this is to provide an alternate means of dialing
>> outbound channels. Currently, when you dial an outbound channel from ARI,
>> Asterisk creates the channel and then calls it. As the ARI application writer,
>> you are handed that channel once it has been answered. With some changes
>> in Asterisk, we intend to allow the application writer to break outbound
>> dialing into two stages. First, the application can request for Asterisk to
>> create a channel. Asterisk will give the application the channel immediately.
>> Next, the application can request Asterisk to call the channel. This allows for
>> the application to create the channel, place it into a bridge, and then call the
>> channel.
>> The result is that if there is early media present, then anyone in that bridge
>> will hear the early media. Victory!
>>
>> Now, the "fun" part is defining the expected behavior when multiple
>> outbound parties are dialed. Let's say that an ARI application creates
>> outbound channels for Alice, Bob, and Charlie. It places these three channels
>> into a bridge with other participants and then calls them.
>>
>> Question 1: What is the expected behavior regarding early media in this
>> state?
> [ben]
> As with app_dial (from what I know speaking to mjordan) the behaviour of app_dial is to accept media on the first channel that's bridged (with early media) and not the others. Again however, I feel this is down to the application writer, why make this an implicit feature of ARI and early media? What we need as an application writer is to know the state of the channel, from there we should be able to decide what to do with any media coming into it.

This seems to align with what you were asking about with regards to 
getting a "Progress" channel state for outbound channels. It sounds like 
something that would fit your needs would be to call multiple channels, 
and based on their states, add them to the bridge as desired. This would 
allow you to pick a "winner" so to speak and place that in the bridge 
early if you want that channel's early media played to the callers. You 
could then potentially wait for the others to be answered before adding 
them to the bridge. Or if you wanted, you could add multiple "progress" 
channels to the bridge if you wanted their early media mixed and played 
to callers.

My question is more for the people that place multiple down channels 
into the bridge without having dialed them yet. At this point, the 
channels being already in the bridge means that you're going to have to 
have some sort of in-built behavior. It may be that if you've written 
things that way, you are fully prepared for callers to hear multiple 
mixed streams of early media from all outbound channels. It may be, 
though, that if you're used to app_dial's behavior, that you expect the 
inbound caller to continue hearing whatever you are already playing to 
that caller (ringing, music, or whatever it may be).

>
>> My proposal is that we behave similarly to app_dial. In other words, we block
>> any incoming media from the outbound channels. If there are already
>> multiple participants, they can talk amongst themselves. If you have a single
>> participant, then you as the application writer can play a ringing indication to
>> them or music on hold while you wait for an answer.
>>
>> Now let's continue and say that Alice answers her phone.
>>
>> Question 2: Should there be any implicit behavior from Asterisk in this
>> scenario? For instance, should Asterisk hang up Bob and Charlie's channel
>> and remove them from the bridge?
> [ben]
> I am with your first instinct. Let's not make this complicated by adding unexpected behaviour. At the end of the day, application writer might not want to do that, they may want full control. By adding some implicit behaviour you're taking that away from them.

This and all your replies below are excellent feedback, thank you very 
much. It sounds like the attitude is "bring on the possible weirdness. 
I'll deal with it myself." This just makes things easier for me, so I'm 
more than happy to do it that way :)

>
>> On this one, I'm a bit torn. My immediate reaction upon hearing this question
>> is "No. ARI is meant to be controlled 100% by the application writer. There
>> should be no implicit behavior." However, when thinking about the user
>> experience, I start to reconsider. If Alice answers, then the bridge will shift to
>> a typical mixing bridge, allowing Alice to talk with any of the previous
>> participants in the bridge. However, they will also hear ringing, early media,
>> or even congestion from Bob and Charlie's channels, making it a nasty
>> experience for the bridge participants.
>>
> [ben] This is down to the application writer to handle. They should know the state of channels, and be able to decide if they should be added or dropped from a bridge. Muted or unmuted, etc etc.
>
>> You might get around this by having the mixing bridge block media from
>> channels that have not been answered. But now, what happens when Bob
>> and Charlie's phones both go to voicemail? They're technically "answered" at
>> this point, so now the participants are hearing weird mixed voicemail from
>> Bob and Charlie's devices and they're not in a position to be able to leave any
>> sort of coherent messages.
> [ben] Again, if you've called multiple participants then you need to expect edge cases. Just because it was answered by voicemail really makes no difference, it's still answered. The logic I want to employ should determine how that experience unfolds.
>> What I just described may be exactly what you want. However, it may be
>> that what you actually want is to just use what ARI already provides.
>> Originate calls to Alice, Bob, and Charlie, and as they answer, place them in
>> the bridge.
>>
>> So folks, if you can provide some feedback for these two questions, that
>> would be super-handy.
>>
>> Thanks,
>> Mark Michelson
>>
>> _______________________________________________
>> asterisk-app-dev mailing list
>> asterisk-app-dev at lists.digium.com
>> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2016.0.7442 / Virus Database: 4537/11725 - Release Date: 03/01/16
>> Internal Virus Database is out of date.
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev