[asterisk-app-dev] Implementing app DIAL using ARI

Jan Svoboda jan at mluv.cz
Sat Mar 29 20:28:28 CDT 2014


Thanks for the reply ! Answers follow inline.


On Friday 28 March 2014 at 13:43, Joshua Colp wrote:

> Jan Svoboda wrote:
> > Hi,
> >  
> > I am currently trying to implement asterisk applications using ARI, and
> > came across few problems trying to recreate the DIAL app.
> >  
> > My current approach is the following:
> >  
> > 1. When StasisStart event is received, determine which endpoints to dial
> > and create new object, representing the DIAL application in my code,
> > passing it the endpoints to call and the originating channel.
> >  
> > 2. Create destination channels from all passed endpoints, listening to
> > various events.
> > - if at least one destination channel is created, indicate ring to
> > originating channel
> >  
> > 3. When one of the destination channels answers:
> > - hangup all other destination channels
> > - bridge the channel which answered with the originating one
> >  
> > This works and calls can be completed, but the problem is when dialled
> > destination channel indicates progress and starts early audio. This can
> > be for example in case of a call to mobile phone, which is switched off.
> > In this case, there is early audio saying “The called number is
> > unavailable at the moment.”.
> >  
> > As there is no other indication apart from the audio message, this leads
> > to the caller hearing only the ringing indication and then the call is
> > hung up, which makes the misleading impression, that the mobile phone is
> > switched on, but does not answer the call.
> >  
> > I have checked the source code of the DIAL app in app_dial.c, and
> > noticed, that this is handled specially when there is only one
> > destination channel, and that the way it is handled is with
> > ast_channel_early_bridge(in, c). Using the DIAL app, this works, and I
> > can hear the early audio.
> >  
>  
>  
> Not really. What actually happens is that since Dial has control of all  
> channels involved it can create a primitive bridge inside of itself,  
> allowing media to be exchanged back and forth even in an early state.  
> Once answer occurs the normal core bridging is invoked.
>  
> >  
> > Bridging the channel early in the app does not seem to be an option,
> > since in this case, the channel does not even enter stasis.
> >  
> > Is there any workaround or recommended way to achieve this ? Or is it
> > something that yet has to be added to ARI ?
> >  
>  
>  
> This hasn't been added to ARI yet and thus is not achievable. Until the  
> channel is answered you don't have enough control. Ideally what would  
> happen is that an early bridge technology would exist and you could then  
> throw them into a bridge. The early bridge would do the stuff required  
> in an unanswered state and then once answered a smart bridge operation  
> would occur and the bridge would transition to a normal simple bridge or  
> a native RTP bridge. Heck, it would probably even work in early state in  
> normal bridges.
>  
This seems to be an important and essential part to be able to fully use ARI. Early bridge would be nice, but there is also the problem, that the channel is not in Stasis at that time and attempts to add it to bridge fail with “Channel not in Stasis” error.
>  
> > Another problem is that it seems there is no way to indicate and play
> > early audio to the caller. Any attempt to do so seems to answer the
> > originating channel and generates ChannelStateChange event with state Up.
> >  
>  
>  
> This shouldn't happen. Behavior was changed months ago so stuff should  
> not explicitly answer. What operation were you doing?
>  
>  

This happens calling POST /channels/{channelId}/play  
>  
> > There is also a problem when playing music on hold to caller. The log
> > indicates "Started music on hold”, but there is no audio. This also
> > seems to be related to progress not being indicated (and lack of a way
> > to do so), because trying it with the PROGRESS app called from the
> > dialplan before Stasis works.
> >  
>  
>  
> Can you file an issue for this? The MOH code should be indicating progress.
No problem:
https://issues.asterisk.org/jira/browse/ASTERISK-23560
>  
> Cheers,
>  
> --  
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com (http://www.digium.com) & www.asterisk.org (http://www.asterisk.org)
>  
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com (mailto:asterisk-app-dev at lists.digium.com)
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>  
>  

     Jan Svoboda
     Software Architect

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140330/77bfbc6a/attachment.html>


More information about the asterisk-app-dev mailing list