Re: Handling Inbound Calls with ARI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you very much for your quick reply.

> Generally instead of doing that people have been replacing the Queue application with their own ARI application instead. Since the channel is then always in Stasis they can do what they need to connect it to the right place. It also makes it easier to implement different strategies and business logic.

I have read about this solutions before and I am very interested in it. Just to ensure I understand this properly.

If I want to write my own Queue application, I would do as follows:

1. I send all incoming calls to stasis by using Stasis(appname) in my dialplan

2. I have a websocket connection always listening for event and connected to this application, since the "Stasis()" command fails if the application is not registered on asterisk.

3. I would write my own business logic to handle incoming calls and manipulate them however i want.

I assume that I can move a channel from one stasis application to another, is that correct?

Thank you very much.

Timothy Bott

-----Ursprüngliche Nachricht-----
Von: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx] Im Auftrag von Joshua Colp
Gesendet: Dienstag, 14. Juli 2015 13:06
An: Asterisk Application Development discussion
Betreff: Re:  Handling Inbound Calls with ARI

Timothy Bott wrote:
> I'm struggling to find a suitable solution for me to handle incoming 
> calls to my asterisk 13 Server using ARI.
>
> I'm writing a Callcenter Webapplication in which call agents should be 
> able to answer calls by using their webbrowser and a soft phone 
> installed on their computers.
>
> I am already able to receive events for incoming calls by subscribing 
> the sip trunk endpoint to my 'Stasis' Application as an event source.
> The Webbrowser displays a list of all incoming calls and the agent 
> should now be able to pick one of those and answer it.
>
> What I'm trying to do is if a Call Center Agent clicks on the 'answer'
> button of an incoming call:
>
> 1. I create a new websocket connection with a new stasis application 
> for this call
>
> 2. asterisk calls the agents sip phone
>
> 3. the Agent Answers the call form asterisk
>
> 4. I create a bridge by using a POST to ARI.
>
> 5. Add these two channels to the bridge.
>
> If I try to add the the incoming channel to the bridge, I always get 
> the error message: "Channel not in Stasis Application".
>
> Is there any other way how i can move this channel into that bridge, 
> without using the dialplan command Stasis(appname)?

No, the channel has to be in Stasis to control it. The ability to move a channel into Stasis arbitrarily is on the feature wish-list[1].

>
> All inbound Calls are redirected to a queue by my dialplan, I would 
> like to take the channel out there and put it in my Stasis Application 
> to take over control.
>
> If you have a better solution, how to handle incoming calls, please 
> let me know.

Generally instead of doing that people have been replacing the Queue application with their own ARI application instead. Since the channel is then always in Stasis they can do what they need to connect it to the right place. It also makes it easier to implement different strategies and business logic.

[1] https://wiki.asterisk.org/wiki/display/AST/ARI+Feature+Wish-list

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org

_______________________________________________
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




[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux