Hey Mark, 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? 2. Would there be a different bridge tech for early media? Just trying to understand the setup. 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. > > 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. > > 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
