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@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
