RE: [asterisk-users] asterisk manager interface stability
Do you have any specific experience with astmanproxy? Can anyone give me an idea on number of simultaneous connections this can legitimately handle with ease? This has been around for a while by the looks of it but I haven't heard about it before. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Martin Smith Sent: Wednesday, 16 May 2007 1:09 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [asterisk-users] asterisk manager interface stability You guys all sound like you're talking about AstManProxy. See: http://www.voip-info.org/tiki-index.php?page=AstManProxy I'm not saying it is the solution to your problem per se, but I can't help but think of it when I read the descriptions of what people want (you even use the word proxy!). Figured I'd send this out in case someone hadn't seen it. Martin Smith, Systems Developer [EMAIL PROTECTED] Bureau of Economic and Business Research University of Florida (352) 392-0171 Ext. 221 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Jenkins Subject: Re: [asterisk-users] asterisk manager interface stability The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
Matt Florell wrote: On 5/16/07, Lee Jenkins [EMAIL PROTECTED] wrote: Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. I've been considering writing something like this for a project that I'm thinking about doing that would require potentially high number of concurrent clients to consume AMI services. From your experience, does the software that you wrote require significant CPU to cache and then doll out the kind of volume of messages that AMI can send? One of the great parts about removing the broadcasting of AMI events outside of the Asterisk process is that the broadcast server process can exist on a separate physical server removing any kind of overhead on the Asterisk server. In my experience doing the proxy on the same machine uses less CPU resources than the same number of AMI connected clients, and doesn't have any of the deadlock issues that can happen with a lot of direct AMI connections. For my application(ACQS) I use MySQL as a storage engine for all of the recent events received and sent so that they can be independantly queried by any client apps that need to see them. MATT--- Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? -- Warm Regards, Lee ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
On 5/18/07, Lee Jenkins [EMAIL PROTECTED] wrote: Matt Florell wrote: On 5/16/07, Lee Jenkins [EMAIL PROTECTED] wrote: Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. I've been considering writing something like this for a project that I'm thinking about doing that would require potentially high number of concurrent clients to consume AMI services. From your experience, does the software that you wrote require significant CPU to cache and then doll out the kind of volume of messages that AMI can send? One of the great parts about removing the broadcasting of AMI events outside of the Asterisk process is that the broadcast server process can exist on a separate physical server removing any kind of overhead on the Asterisk server. In my experience doing the proxy on the same machine uses less CPU resources than the same number of AMI connected clients, and doesn't have any of the deadlock issues that can happen with a lot of direct AMI connections. For my application(ACQS) I use MySQL as a storage engine for all of the recent events received and sent so that they can be independantly queried by any client apps that need to see them. MATT--- Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] asterisk manager interface stability
-Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Matt Florell Sent: Friday, 18 May 2007 4:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk manager interface stability Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- ___ Wouldn't that make it highly inefficient? Is there no two way dialog or am I missing something? Basically if I have 100 end user clients that needed real time interaction with astproxy are you saying that each client would need to poll once per second (eg 100 polls per second) in order to see if something happened that second that was relevant to them?) Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
On 5/18/07, Dean Collins [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Matt Florell Sent: Friday, 18 May 2007 4:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk manager interface stability Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- ___ Wouldn't that make it highly inefficient? Is there no two way dialog or am I missing something? It is inefficient, but it is non-blocking which the AMI is not. having a separate listen and separate send processes removes the problems with AMI locking up on high volume Asterisk systems. Basically if I have 100 end user clients that needed real time interaction with astproxy are you saying that each client would need to poll once per second (eg 100 polls per second) in order to see if something happened that second that was relevant to them?) Not a problem for MySQL, that's what it does best. The astguiclient application can do 20+ queries per second per client depending on the application. I currently have one company with over 200 client applications(AJAX) sending 3000-4000 queries per second to the MySQL server, and it handles it just fine. On the client side, the load is not very high either, even on a PIII 700MHz machine. MATT--- Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] asterisk manager interface stability
Sweet thanks Matt. If there are any developers in Manhattan (or very nearby) who have experience with Astproxy and are looking for sweat equity ownership in a new Asterisk application get in touch. Also looking for someone with ROR UI skills but I might already have that role filled. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph http://click.mexuar.com/webuser/click/7/userurl/Cognation http://click.mexuar.com/webuser/nojs/7/userurl/Cognation -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Matt Florell Sent: Friday, 18 May 2007 6:46 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk manager interface stability On 5/18/07, Dean Collins [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Matt Florell Sent: Friday, 18 May 2007 4:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk manager interface stability Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- ___ Wouldn't that make it highly inefficient? Is there no two way dialog or am I missing something? It is inefficient, but it is non-blocking which the AMI is not. having a separate listen and separate send processes removes the problems with AMI locking up on high volume Asterisk systems. Basically if I have 100 end user clients that needed real time interaction with astproxy are you saying that each client would need to poll once per second (eg 100 polls per second) in order to see if something happened that second that was relevant to them?) Not a problem for MySQL, that's what it does best. The astguiclient application can do 20+ queries per second per client depending on the application. I currently have one company with over 200 client applications(AJAX) sending 3000-4000 queries per second to the MySQL server, and it handles it just fine. On the client side, the load is not very high either, even on a PIII 700MHz machine. MATT--- Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph +1-917-207-3420 Mb +61-2-9016-5642 (Sydney in-dial). ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users image001.gif___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
Matt Florell wrote: On 5/18/07, Lee Jenkins [EMAIL PROTECTED] wrote: Matt Florell wrote: On 5/16/07, Lee Jenkins [EMAIL PROTECTED] wrote: Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. I've been considering writing something like this for a project that I'm thinking about doing that would require potentially high number of concurrent clients to consume AMI services. From your experience, does the software that you wrote require significant CPU to cache and then doll out the kind of volume of messages that AMI can send? One of the great parts about removing the broadcasting of AMI events outside of the Asterisk process is that the broadcast server process can exist on a separate physical server removing any kind of overhead on the Asterisk server. In my experience doing the proxy on the same machine uses less CPU resources than the same number of AMI connected clients, and doesn't have any of the deadlock issues that can happen with a lot of direct AMI connections. For my application(ACQS) I use MySQL as a storage engine for all of the recent events received and sent so that they can be independantly queried by any client apps that need to see them. MATT--- Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- Cool. I hadn't thought of doing it that way. My idea was to somehow keep an in memory cache for client connections. As events were received from the AMI, poll a hash table in memory and forward the event to client connections who have registered interest in that event. -- Warm Regards, Lee ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
Matt Florell wrote: On 5/18/07, Dean Collins [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Matt Florell Sent: Friday, 18 May 2007 4:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk manager interface stability Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- ___ Wouldn't that make it highly inefficient? Is there no two way dialog or am I missing something? It is inefficient, but it is non-blocking which the AMI is not. having a separate listen and separate send processes removes the problems with AMI locking up on high volume Asterisk systems. Basically if I have 100 end user clients that needed real time interaction with astproxy are you saying that each client would need to poll once per second (eg 100 polls per second) in order to see if something happened that second that was relevant to them?) Not a problem for MySQL, that's what it does best. The astguiclient application can do 20+ queries per second per client depending on the application. I currently have one company with over 200 client applications(AJAX) sending 3000-4000 queries per second to the MySQL server, and it handles it just fine. On the client side, the load is not very high either, even on a PIII 700MHz machine. Nice. And using a DB to cache events no doubt simplifies the mechanics of the application making it easier to develop and maintain. -- Warm Regards, Lee ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
Dean Collins wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Matt Florell Sent: Friday, 18 May 2007 4:22 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] asterisk manager interface stability Neat. So the clients use a polling model? Individual clients then query only for events that are interesting? Warm Regards, Lee Yes, the clients only connect to the MySQL database and can query the events as they need to for their display. MATT--- ___ Wouldn't that make it highly inefficient? Is there no two way dialog or am I missing something? Basically if I have 100 end user clients that needed real time interaction with astproxy are you saying that each client would need to poll once per second (eg 100 polls per second) in order to see if something happened that second that was relevant to them?) Although I would lean toward an in-memory cache/handling of events, you could have a another app or thread pool that queries the database on behalf of the clients and notifies clients accordingly, which might negate the need of clients to poll the database and reduce network traffic. -- Warm Regards, Lee ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] asterisk manager interface stability
There are many past posts stating that AMI is not stable when multiple client computers are allowed to connect, particularly when connections are dropped. Has much progress been made on this? Is it more stable now than in the past? As of what versions were these issues improved? Is it feasible to connect a large number of windows computers directly to AMI for the purpose of initiating calls from software? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] asterisk manager interface stability
If it's not stable what needs to be done to improve this? What are the issues? What are the alternatives (eg is Adhearsion an alternative here) I am about to start looking into a project that requires every user to have AMI access so looking to fund development in this space. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph http://click.mexuar.com/webuser/click/7/userurl/Cognation http://click.mexuar.com/webuser/nojs/7/userurl/Cognation From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Damon Estep Sent: Wednesday, 16 May 2007 7:32 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] asterisk manager interface stability There are many past posts stating that AMI is not stable when multiple client computers are allowed to connect, particularly when connections are dropped. Has much progress been made on this? Is it more stable now than in the past? As of what versions were these issues improved? Is it feasible to connect a large number of windows computers directly to AMI for the purpose of initiating calls from software? image001.gif___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. http://astguiclient.sourceforge.net/acqs.html MATT--- On 5/16/07, Dean Collins [EMAIL PROTECTED] wrote: If it's not stable what needs to be done to improve this? What are the issues? What are the alternatives (eg is Adhearsion an alternative here) I am about to start looking into a project that requires every user to have AMI access so looking to fund development in this space. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph [image: Call Button]http://click.mexuar.com/webuser/click/7/userurl/Cognation -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Damon Estep *Sent:* Wednesday, 16 May 2007 7:32 AM *To:* Asterisk Users Mailing List - Non-Commercial Discussion *Subject:* [asterisk-users] asterisk manager interface stability There are many past posts stating that AMI is not stable when multiple client computers are allowed to connect, particularly when connections are dropped. Has much progress been made on this? Is it more stable now than in the past? As of what versions were these issues improved? Is it feasible to connect a large number of windows computers directly to AMI for the purpose of initiating calls from software? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
why not do it via an snmp interface? If you spend the time building an solid snmp base you would open up for an easier world of custom gui's as well as possibly some cleaner ties into an nms infrastructure. On May 16, 2007, at 10:14 AM, Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100 + clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. http://astguiclient.sourceforge.net/acqs.html MATT--- On 5/16/07, Dean Collins [EMAIL PROTECTED] wrote: If it's not stable what needs to be done to improve this? What are the issues? What are the alternatives (eg is Adhearsion an alternative here) I am about to start looking into a project that requires every user to have AMI access so looking to fund development in this space. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph From: [EMAIL PROTECTED] [mailto:asterisk- [EMAIL PROTECTED] ] On Behalf Of Damon Estep Sent: Wednesday, 16 May 2007 7:32 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] asterisk manager interface stability There are many past posts stating that AMI is not stable when multiple client computers are allowed to connect, particularly when connections are dropped. Has much progress been made on this? Is it more stable now than in the past? As of what versions were these issues improved? Is it feasible to connect a large number of windows computers directly to AMI for the purpose of initiating calls from software? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bryan Laird, Sr. Manager CM Operations Phone: 703-944-9909 -+- Cablemodems are the gateway to the Internet. The Internet is a gateway to some things that are better left un-seen. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
Quoting Bryan Laird [EMAIL PROTECTED]: why not do it via an snmp interface? If you spend the time building an solid snmp base you would open up for an easier world of custom gui's as well as possibly some cleaner ties into an nms infrastructure. you have my vote on that implementation method. snmp really is simple, but it seems to be a neglected protocol that has been around for a long time. On May 16, 2007, at 10:14 AM, Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100 + clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. http://astguiclient.sourceforge.net/acqs.html MATT--- On 5/16/07, Dean Collins [EMAIL PROTECTED] wrote: If it's not stable what needs to be done to improve this? What are the issues? What are the alternatives (eg is Adhearsion an alternative here) I am about to start looking into a project that requires every user to have AMI access so looking to fund development in this space. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] +1-212-203-4357 Ph From: [EMAIL PROTECTED] [mailto:asterisk- [EMAIL PROTECTED] ] On Behalf Of Damon Estep Sent: Wednesday, 16 May 2007 7:32 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] asterisk manager interface stability There are many past posts stating that AMI is not stable when multiple client computers are allowed to connect, particularly when connections are dropped. Has much progress been made on this? Is it more stable now than in the past? As of what versions were these issues improved? Is it feasible to connect a large number of windows computers directly to AMI for the purpose of initiating calls from software? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bryan Laird, Sr. Manager CM Operations Phone: 703-944-9909 -+- Cablemodems are the gateway to the Internet. The Internet is a gateway to some things that are better left un-seen. Jon Pounder _/_/_/ _/_/ _/ _/_/_/ _/_/ _/_/_/_/ _/_/_/ _/ _/ _/_/_/ _/ _/_/ _/_/ _/_/ _/ _/_/ _/_/ _/ _/_/_/ _/_/ _/_/_/_/ _/_/_/ _/_/ _/_/_/_/ Inline Internet Systems Inc. Thorold, Ontario, Canada Tools to Power Your e-Business Solutions www.inline.net www.ihtml.com www.ihtmlmerchant.com www.opayc.com This message was sent using IMP, the Internet Messaging Program. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. I've been considering writing something like this for a project that I'm thinking about doing that would require potentially high number of concurrent clients to consume AMI services. From your experience, does the software that you wrote require significant CPU to cache and then doll out the kind of volume of messages that AMI can send? If I end up writing something myself, I'll release it as OS... -- Warm Regards, Lee ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
On Wednesday 16 May 2007 11:43, Lee Jenkins wrote: Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. I've been considering writing something like this for a project that I'm thinking about doing that would require potentially high number of concurrent clients to consume AMI services. From your experience, does the software that you wrote require significant CPU to cache and then doll out the kind of volume of messages that AMI can send? If I end up writing something myself, I'll release it as OS... You might be interested in a python server script I wrote (called ProxyMan) that does this kind of thing. It is part of my EventMonitor package but runs fine on its own. #A multi-threaded server which connects to an Asterisk Manager #and logs all events # #Connects to the Asterisk Manager and listens for all events #Optionally listens on socket and accepts client connections # proxies all client commands to the Asterisk Manager Interface # sends all data received from the manager to all connected clients #Optionally prints data as received (also in optional hex dump format) #Optionally logs all data to a MySQL database table You can get it here: http://www.micpc.com/eventmonitor earl ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [asterisk-users] asterisk manager interface stability
You guys all sound like you're talking about AstManProxy. See: http://www.voip-info.org/tiki-index.php?page=AstManProxy I'm not saying it is the solution to your problem per se, but I can't help but think of it when I read the descriptions of what people want (you even use the word proxy!). Figured I'd send this out in case someone hadn't seen it. Martin Smith, Systems Developer [EMAIL PROTECTED] Bureau of Economic and Business Research University of Florida (352) 392-0171 Ext. 221 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Jenkins Subject: Re: [asterisk-users] asterisk manager interface stability The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
On 5/16/07, Lee Jenkins [EMAIL PROTECTED] wrote: Matt Florell wrote: The issue has more to do with the sheer amount of data passed to the client from within the Asterisk application when you have 50-100+ clients connected to the AMI on full output mode. Running a system with FreePBX/Trixbox especially generates vast amounts of output that has to be generated on every AMI connection for every client. This is not trivial and can result in lockups very easily, although this has gotten much better since the early 1.0 versions. The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. As for how to go about doing this, I can't help you there. I did build a very specialized version of something like this 4 years ago for the astGUIclient project called the Asterisk Central Queue System(ACQS) It is based on 1.0 Asterisk but it still works with 1.2 and 1.4. It is limited in what it does, but it does scale much better than using direct AMI connections. I've been considering writing something like this for a project that I'm thinking about doing that would require potentially high number of concurrent clients to consume AMI services. From your experience, does the software that you wrote require significant CPU to cache and then doll out the kind of volume of messages that AMI can send? One of the great parts about removing the broadcasting of AMI events outside of the Asterisk process is that the broadcast server process can exist on a separate physical server removing any kind of overhead on the Asterisk server. In my experience doing the proxy on the same machine uses less CPU resources than the same number of AMI connected clients, and doesn't have any of the deadlock issues that can happen with a lot of direct AMI connections. For my application(ACQS) I use MySQL as a storage engine for all of the recent events received and sent so that they can be independantly queried by any client apps that need to see them. MATT--- If I end up writing something myself, I'll release it as OS... -- Warm Regards, Lee ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk manager interface stability
How does the Events cache in AstManProxy work?(is there a cache?) MATT--- On 5/16/07, Martin Smith [EMAIL PROTECTED] wrote: You guys all sound like you're talking about AstManProxy. See: http://www.voip-info.org/tiki-index.php?page=AstManProxy I'm not saying it is the solution to your problem per se, but I can't help but think of it when I read the descriptions of what people want (you even use the word proxy!). Figured I'd send this out in case someone hadn't seen it. Martin Smith, Systems Developer [EMAIL PROTECTED] Bureau of Economic and Business Research University of Florida (352) 392-0171 Ext. 221 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Jenkins Subject: Re: [asterisk-users] asterisk manager interface stability The new Asterisk Manager web API in 1.4 is a good step where sending of Actions does not require an actual Telnet conneciton to the AMI, but I think to be able to handle larger numbers of concurrent connections that a separate send-only and a separate receive-only type of interface be built where Asterisk would just output all AMI data to a single server-like application that would then broadcast it to all connected clients. This would remove the burden of so many connections going directly into Asterisk and would allow for much larger scaling of AMI-type applications that require real-time output of AMI events. I definitely agree here personally. Clients could connect to this proxy and subscribe to only the events that are interesting or applicable. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
