i9 Technologies, the creators of the iSymphony Operator Panel for Asterisk, is pleased to announce that we have been accepted as a Preferred Partner as the operator panel for the FreePBX ISO.
What does this mean? Put simply, it means we are excited to work more closely with the FreePBX, Bandwidth and Schmooze Teams and provide a level of integration between the iSymphony and FreePBX ecosystems that just haven’t existed in the past.
In short, We would like very much to begin creating a more seamless integration with FreePBX and would like the community’s input on the specific integration features you’d like to see!
As you may be aware, iSymphony currently has the “iSymphony FreePBX module” as a freely available add-on to the platform. As part of the larger process, we’re committing to take integrations such as these to “the next level”. Your input will help us in determining the features and integration items developed first and will assist in prioritization of development moving forward.
We are extremely excited to begin hearing all of your input, discussing them further and making the iSymphony product better for everyone by focusing on the issues the community is interested in.
In the past few days we have discussed this issue and have come up with a short term resolution.
The majority of the time spent in the iSymphony module is related to checking the current internal configuration of iSymphony and comparing it with the FreePBX database in order to formulate deltas. We have determined that this code does not need to run directly within the FreePBX reload process; therefore we have moved this code to an external script that is executed asynchronously from functions.inc.php. In short this will cause the FreePBX load times with or without the module installed to be roughly equal.
We have a build of this module available for download at
Sean’s response was related specifically to (re)load times and although your question may have been related to that, I’d like to augment his post regarding load times as asked in your post. (Although I believe the usage of the word “module” is what threw us off a bit – but if his post answered your question, there might be some useful information in this post for you as well!)
You’ll find some semi lengthy comments below, let me know if you’d like anything more specific.
Unfortunately, metrics that contribute to “system load” as used in a Unix-y nomenclature, on any specific system as you’re probably aware – are difficult to tie down simply because of the variables at hand; i.e. Processor Type / RAM / Disk I/O, Bus I/O, Socket I/O, etc. The load specifically that iSymphony would contribute to (and the time in which that load would be of any potential significant impact) would also directly correlate to the amount of processing that has to be done on a per event basis, generally triggered by AMI traffic.
This means that regardless of the amount of extensions, queues, etc, that might exist on a particular system, the processing requirements are largely based upon how much system traffic is occurring at any given time. Additionally, processing requirements will go up not solely based upon the amount of traffic but also connected clients and what processing needs to happen for each of those as well (such as permission schema, etc). We definitely have some metrics that we use internally for load testing, but unfortunately nothing that can be used as a “blanket” statement of sorts.
To answer your question a bit more directly, we would guess that on any modern hardware and 2-4 gigs of RAM, with approximately 200 users (and clients) and 60 queues, iSymphony may contribute up to 20% processor usage and would require 500-1G of ram – at this scale, we generally match with about what Asterisk would consume for the same load (with processor, RAM would be a bit higher as we cache a bit more meta-data).
This is something we’re asked for quite a bit, and rest assured, we’re doing a lot of things to augment this! It would be premature at this time for us to release all the specific details, but the first thing you’ll see is a JNLP (Java Web Start) mechanisms to launch the client – this means we should largely eliminate the requirement for installation packages for clients.
Thanks again for your input! We’ll definitely be speaking more about the details of our road map moving forward as time progresses.
I suppose it’s okay to release this now; Interesting you touch on this as we’re hard at work for implementing roaming profiles. We do have an internal proof of concept, so you’ll likely see something in the very – very near future.
Roaming profiles with web-based client startup should help alleviate some issues that people have had in the past, and, we agree – would be a great feature.
Additionally, we have looked long and hard at web-ifying the client and although would be premature to talk about the details – know that we’re working on it!
+1 for lightweight. How about something web based?
Also, moving as many configuration as posible to the server - i.e. a simple key + url to set up the (desktop) client, with all the extensions/tenant stuff, and even the layout of the different tabs pulled from the server (not saying a web based layout tool, just keeping a backup of the layout on the server).
I’ll try to post more ideas as they come in. In the mean time, welcome aboard (again) - looking forward to working together!
I don’t have a specific time frame that this will take as there’s some variables that will play a role in reload times. We’ve spent some time optimizing the module and it shouldn’t take long at all. We have some customers with even more than that using FreePBX and their reload times aren’t much longer.
The best thing I can suggest is to try the module yourself in your environment and see if it’s acceptable for you. Let me know if we can be of assistance.
I will post more ideas once I think about it, however my number one item would be a “lightweight” desktop client.
The one think Fonality got right was the look and feel of HUD. A little, small footprint (visually mainly) client would be so welcome.
It should work off the same iSymphony server with a 2 tier pricing model. Power users and operators would get the full blown client and all other users the “light” version.
Give it some thought I am always available to brain storm.
In the GUI if you contract the width of the agent cells, some buttons may get cut off. It would be handy if the little buttons wrapped. I’d presume there’s a way to take a call on my phone and drop that call into a queue.
I haven’t worked with customizing the agent displays, so bear with me:
We have two groups (sales and support) which together account for 80 agents (60 and 20 respectively). Each of those groups are further divided into territories or skillsets. Also, the sales “managers” needn’t ever see the support agents but the sales agents will need access to the support agents. The system admin needs to be able to define agents into logical groups. These groups can then be expanded or minimized based screen realestate and the user’s needs. I’d look at XMPP chat clients as an example of these groupings. In my example above, the “managers” need to be able to barge calls but they shouldn’t have administrative abilities to change the groupings.
Other queues on the systems need to be made available in a “queue” group as well. (So sales agents can transfer calls to support agents and such.)
Proper management of the new Time Conditions in FreePBX 2.9 from iSYmphony. Where it will show what mode the system is in and let me toggle it or toggle it with the new sticky flag.
Follow Me Management from inside iSymphony and having the cell phone icon actually be the follow me so I do not have to define a cell phone.
Second vote on tight Outlook integration and click to dial. These would add high value to the conductor version and make a much easier client up sell.
I also want to quantify my comment on a “lightweight” client. I keep mentioning HUD (the old one, not the new crap) because the actual desktop client “got it right” for the average user and not enough for the operators and call center managers.
iSymphony is the exact opposite. It is perfect for the call center managers and dedicated operators and way too much for the casual users.
I speak of light weight in terms of:
[list]
[] Screen Real Estate
[] Quick access to the dial, status and personal contacts being monitored
[*] Modern, colorful and fun looking.
[/list]
One more part. A branding module, not something that lets you de-brand it but a “co branding” that allows the customer or reseller to integrate a small logo or some type of watermark would be a great little add on to price in the $100 additional per license.
Ability to import contacts into isymphony for each click to dial and transfer calls to contacts. Maybe even tie this is with a simple CLI that we can push from other sources the contacts or the phonebook directory in FreePBX.
Ability to click with my mouse a transfer button and than type in the number I want to transfer the call to.
I think scott keeps referring to maybe the HUD toaster button that would display while a call was up who you were talking with and let you transfer, conference, park and hangup the call you were on without having to have the full fledge iSymphony up at all times on your screen.
Finally started testing iSymphony. First I do have to say that this is a great product with a lot of long sought features. It was easy to set up and worked instantly while allowing to fine tune all relevant settings.
For the question regarding future features:
I would like to see the trunk status of the system as well
I did test the “On Hold” feature which works great if initiated from the UI but did not work when initiated from the phone.
It would be great if there would be a possibility to set extension feature (like follow me / forwarding) from the UI.
It would be nice if “My Extension” could also show the voice mails and also allow to play the VM straight from the UI. Right now it calls the phone to play the VM.
Last but not least - The licensing model. I do see the value of the Conductor license in a large operation and I am always willing to pay for great software (which this is) but for a SOHO environment, the full Conductor is almost too expensive. I will however recommend it to some of my clients and stay with the free version in SOHO (minus the VM Display).
