like to build a freeswitch compatibility backend, advice?

[bobbymc]

if im not wrong all the magic happens mostly in vicidial_manager and thats what the perl script do when they run in the background and other misc tables used by the AGI scripts.

If both the AGI and the perl scritps are made compatible with freeswitch would it requite at all to touch any of the php? (i know it also generates the asterisk configs but that is very easy to convert.)

[mflorell]

Looked at it several years ago, would take a lot of work to make it happen, including rewriting many parts of the AGI scripts as well.

We tried using FreeSWITCH as part of our hosted service and it kept crashing under high loads, so we stopped trying to use it all together.

[bobbymc]

how long ago did you guys try to use it last? (much has changes sicne a few years ago when it wasnt as stable) we use it as our backend LCR engine and it performs very well.. maybe we can give it another shot?

[williamconley]

You certainly can, but what portion of the system do you want to pass through FreeSwitch? Are you trying to solve a problem or just use time in a creative fashion?

[mflorell]

It was 2 years ago that we last tried FreeSWITCH. It is good for some functions, but not the high-capacity callerID filtering passthru that we were trying to use it for. The poor documentation, smaller community, rapid and drastic changes to the codebase and supported modules without much notice are all problems that we would have to deal with moving to FreeSWITCH from Asterisk. Perhaps if we were building Vicidial from scratch we would build in FreeSWITCH support, but at this point there just wouldn't be enough payoff for the tremendous resources needed to make that change.

[williamconley]

I can certainly see using it as an LCR engine if it can support a higher load than asterisk, though. And if someone wanted to try creating a "trunk server" inside the Vicidial system framework (to ease it into the family, as it were ...), I could see that. We've had good success installing FreeSwitch on the Vicibox platform (after shutting off asterisk/vicidial, of course). Which helps, since the environment is already similar for testing.

[bobbymc]

i will keep a close eye on this and once i have enough time i will rewrite this to be fully compatible with freeswitch.. the only issue i foresee is that this project is a moving target so as i convert all the code, several releases might have been done and now its going to be hard to backport the updates/fixes

[mflorell]

As a side note, we use OpenSIPS as an LCR engine, it's capacity and speed are FAR beyond what FreeSWITCH can handle, and it is much more stable.

[bobbymc]

Can it do tone detection to check calls for early audio incase the provider sends early audio messages stating the call is disconnected? we currently have freeswitch handle that and send us a proper sip code back that the call is disconnected. If OpenSIPS can analz earl emia and do tone detection to see if its a disconnect call tn 2 thumbs up i'll get rid of freeswitch

[Vince-0]

Freeswitch just announced a corporate sponser for the new 1.2 branch so it is very much alive.
I do prefer Freeswitch from an ideals point of view - community development, great integration interfaces. It has come a long way recently but I'm not sure there will be many advantages of using it to replace Asterisk in a Vicidial dialer server. Perhaps there would be more advantages to using a newer version of Asterisk 1.8 latest?

[mcargile]

Asterisk 1.8 support is under development. It is unpaid development however so it is a lower priority than our paid development. It is also going to require literally testing every single feature in Vicidial to verify that everything is working properly. It is also still quite buggy. Some bugs cause errors at such a fantastic rate that the logs could fill the hard drive in a day.

As for FreeSwitch, I personally view adding support for it in Vicidial like trying to convert a Ferrari to use a turbine instead of a four stroke engine. It will take a ton of time, require massive engineering problems to be overcome, and when all is said and done it could just blow up in your face. I personally do not see it worth the time and effort to get it working til Asterisk is no longer a viable option.

[seaq]

ohh well, but we need to move to an asterisk supported version, don't we?

Is there any way we can help supporting this effort?

[mcargile]

Yes. When Asterisk 1.8 support reaches beta stage, beta test it. But please note, I am not kidding when I say Asterisk 1.8 is not ready for call center use yet. One of the reasons Asterisk 1.8 is taking so long is we are having to program around major issues in 1.8.

[mercutioviz]

Just to chime in here...

FreeSWITCH has made many improvements over the past few years. Matt's description of the rapid development and occasional seismic shift when doing a "git pull" has been felt by more than a few people. That's why we were ecstatic when Star2Star Communications gave us the resources we needed to hire a full time person to handle maintaining branches, stable releases, etc.

As far as OpenSIPS scaling higher than FreeSWITCH as an LCR engine... of course it does! That's the kind of thing a SIP proxy is supposed to be good at. ("Use the right tool for the job" and all that.)

As far as using FreeSWITCH with Vicidial... is there *really* a need for this? Yes, it would be nice, but Matt is correct - re-writing Vicidial to be FreeSWITCH-ready (or agnostic to the back-end telephony engine so that you could use YATE, Lync, etc. etc.) is a HUGE undertaking. My questions are: who needs this? How badly? Are they willing to finance the development process? I'd really like to know the answers because I believe that will dictate when - or even if - we'll ever see Vicidial on FreeSWITCH.

Thanks for your time.
Michael S Collins
FreeSWITCH Community Liaison

[bobbymc]

i would like to support freeswitch as the backend and will be more then happy to fund it. The question is do people out there exist that have time to do it and what is the price.

[mcargile]

Let me give you the primary reason Vicidial will never be ported to FreeSWITCH. It would be cheaper and more effective to write something from the ground up around FreeSWITCH than to port Vicidial.

Vicidial is designed around Asterisk. In order to get it to work with FreeSWITCH you would have to rewrite the entire back end, most of the agent interface, considerably modify the admin interface, and test every single feature within Vicidial. If you have not noticed Vicidial has quite a few settings. Every single one of them would have to be tested in just about every combination you can think of to ensure the system was stable. Also quite a few settings would have to be completely rethought out because they will either simply not work with FreeSWITCH or they will behave completely differently.

The problem is that when Vicidial was originally written it was not designed to have the back end switched out. If that was a concern at the time Matt would have written an abstraction layer. At which point porting Vicidial to FreeSWITCH would be just a matter of writing another abstraction layer for FreeSWITCH. As is Vicidial is directly controlling Asterisk.

If someone wants to write an open source call center sweet for FreeSWITCH go right ahead, just seriously Vicidial is not the answer.

[chrismervyn20]

Hi
I completely agree with Michael on this last bit of observation. But, however, there are certain considerations that force me to think otherwise.
Let's assume that here is a developer who really wants to add value to good ol' vici. Now, before delving into the unforgiving code-base, choosing to tread softly, how would he go about?
I would imagine, that, numero uno on his platter would be vicidial.php. Picture this: Vicidial.php works by checking certain conditions and then echoing the outcomes. Where as with a little touch of MVC as-in say, Smarty, we could have vicidial.php write to a Smarty Template and then in Wordpress (or just about anything else) fashion, handle the interface with some really beautiful interface which would be W3C validated.
Instead of Ajax, we could add reverse-ajax a.k.a Comet.
As for FS integration, lets argue the necessity- Why FS? To answer this, comes a legacy question of whether FS beats Asterisk or not? Now, there are two perspectives to this. Number one, CPC and number two is of course Evolution Arithmetic or how evolved is FS (read how many features...)
Number One: As of today, i.e. October 5th 2012, FS has more CPC.
Number Two: Asterisk defeats FS.
So, it is a tie. Now, when you consider Vicidial and the way it leverages Asterisk, you would know that it is the CPC that can only limit Vicidial otherwise it is capable of etching out a living, stand-alone, as complete. So, I know that it is a lot of hard work but it is worth the time. If the Vici-Asterisk Love Affair can be abstracted it would be a true MVC(a little more deviant as-in MVC + Tele-Abstraction) architecture and liberation of Vicidial. So, what say? bring on the abstraction, bring on Smarty and let Vici be what it should be: World's Best Contact Center Solution!

[Vince-0]

There are existing dialer type projects that use Freeswitch but they do not have nearly the same level of functionality that Vicidial has with campaign,list,agent and recording management:

http://www.ictdialer.org/
http://www.newfies-dialer.org/

These are based on the Plivo framework to control the Freeswitch soft-switch and CMS/web frameworks. I am watching them closely - perhaps your efforts will be more suited to those?

[williamconley]

Hi
I completely agree with Michael on this last bit of observation. But, however, there are certain considerations that force me to think otherwise. ...
I would imagine, that, numero uno on his platter would be vicidial.php. ...

But the problem here is that "vicidial.php" is merely the "agent client". It is not the product, it is a window into the product. Vicidial itself is a whole other "Machine".

Vicidial.php is merely a (very complex) web page that interacts with MySQL. Vicidial.php is not in any way related to asterisk itself. It makes no connection to asterisk directly, but does store information in the MySQL tables that is interpreted by other scripts which often results in a command being issued to Asterisk.

Revamping the agent interface will provide no means to port anything towards FreeSwitch.

That being said, the likely true way to port Vicidial to FreeSwitch would be a framework/diagram of the functionality provided by Vicidial followed by the selection of the "core services" required to make the first version "viable". (perhaps the Vicidial 2.0.4 branch would represent those core functions?)

At that point, porting each function may be possible. But none of that is likely to be done without rewriting the code from the ground up to take advantage of lessons learned since the Vicidial code was written AND the likely advantages of features available in FreeSwitch (and I won't talk about how to "work around" anything that may not be found in FreeSwitch that is already available in Asterisk, but that is likely to happen a few times as well).

No matter how you look at it, it's not going to be easy. But it's going to be about the perl scripts and agi scripts that manage and control asterisk. Not related to Vicidial.php at all.

[mcargile]

Vicidial.php is not in any way related to asterisk itself.

While it is true that vicidial.php is only interacting with MySQL, that does not mean that it is not sending commands to Asterisk. When Vicidial wants to take an action in Asterisk it places an entry into the vicidial_manager table. The AST_manager_send.pl script is checking for records in that table hundreds of times per second. When an entry gets placed in there, AST_manager_send.pl forks a process that connects to the AMI and issues a manager command. Vicidial.php places AJAX calls to vdc_db_query.php which then places records into the vicidial_manager table. vdc_db_query.php also checks several other tables in MySQL for channel information which is passed on to vicidial.php. Those tables are updated by the AST_manager_listen.pl script. Much of the logic of how the web interface interacts with Asterisk is built directly into vicidial.php. For instance starting and stopping recordings, placing manual dial calls, transfers, etc. Not only would the manager scripts need to be changed, vdc_db_query.php would have to be changed as the commands would be different, and vicidial.php would need to be changed as the logic is different.

As for the predictive dialers built on FreeSITCH, the reason they do not have the functionality of Vicidial is because they are less mature. Adding to them the functionality that is in Vicidial would be considerably easier than trying to decouple Vicidial from Asterisk and port every single feature over to FreeSWITCH.

[williamconley]

I'm not as sure about that as you are. I think that the finite list of "these are commands we send to asterisk" could be ported (one at a time) to send the equivalent command to FreeSwitch. The next challenge would be to ensure the responses were received and understood by the system as well.

If these two categories of items were purposely separated from the system and modularized for future upgrades, that would probably improve the ability to upgrade/modify Asterisk integration as well (sort of a side benefit). Maybe that'll help with Asterisk 2.X ...?

And the only reason that might happen ... is that this could allow Vicidial to exist with either engine without reinventing Vicidial on the new platform.

To a certain degree. LOL (After all, I'm sure there would be "some" compatibility issues that would not be easily ported in that fashion that would have to be dealt with ...).

Add to that the fact that the last time we tested it FreeSwitch ran nicely in Vicibox (after turning off Asterisk, of course) ... it could actually happen at some point.

[chrismervyn20]

And the only reason that might happen ... is that this could allow Vicidial to exist with either engine without reinventing Vicidial on the new platform."

-Exactly!
When I first cited the example of Vicidial.php, what I had in mind was the workflow devoid of the actual instance of change. It was in no way connected to the actual porting. But, in it you would find the strains of the real requirements.
Case: Vicidial.php outputs direct to a page. A two-tier architecture. Enter Smarty (or for that matter anything else). Vicidial.php would write to Smarty and then Smarty would take the form of the current active template, changing the interface. This would ease future interface re-edits(separating the Business Logic with the Design Logic).
Case:Vicidial right now connects to asterisk and Mysql. Now, enter Translator X (like Smarty in the first case). Translator X has multiple modules viz., FS, Astreisk, Yate etc. Depending on the core Switching used in realtime implementation, Translator X would translate abstracted Vicidial Commands to the native switch. Switch works independently and so does Vicidial.
I repeatedly see suggestions for writing something from scratch. That is like re-inventing the wheel, isn't it? Vicidial has proven track record, complete feature-list and growing... So, Translator X can be a simple answer, wouldn't it?

[williamconley]

Case: Vicidial.php outputs direct to a page. A two-tier architecture. Enter Smarty (or for that matter anything else). Vicidial.php would write to Smarty and then Smarty would take the form of the current active template, changing the interface. This would ease future interface re-edits(separating the Business Logic with the Design Logic).

Actually, what I'm saying is that the need for any templating of Vicidial.php is not related to FreeSwitch integration. Vicidial.php makes NO contact with Asterisk. It does have a couple sql queries that write data that would then be grabbed by another process and sent to asterisk ... but NOT from Vicidial.php.

So templating Vicidial.php would serve only to complicate matters in my opinion.

The only thing that would need to change in Vicidial.php is a fairly simple "if FreeSwich write this query ... if Asterisk write that query". Not really gonna need Smarty for that. Make that change during the initial load of the page via php and Vicidial.php is FreeSwitch Ready.

[chrismervyn20]

Hi William!
I guess, I didn't make myself clear in my post. I apologize. What I was trying to say is that, if we needed templating of the Interface, we would have done that(as-in what I said). But, our mutual goal is the FS porting. So, I am obviously interested in that. When I was talking about Smarty, I was just only talking about the way it works. Like, it does abstract the Presentation from the Business, right? Similarly, I was suggesting that, if we were to port vici to FS, we could attempt the same plan. Vici -> Translator X -> (either FS or Asterisk) == What you need!!
I hope that now, you are in tune with what I was intending to say.
Footnote:-> Needed a suggestion:: I am working on an HTML5 Vicidial Interface with Templating Features. I want to showcase it here, to everybody and get your comments. Please advise on how should I give the demo to everybody here... can I post links to my own server?? and also, how can many users simultaneously use it??
Any help would be appreciated...

[williamconley]

You would simply post a link to the code in use on either your server or a public system (github ... sourceforge ...) where a "demo" could be observed and the source code could be downloaded for personal testing.

[chrismervyn20]

perfect, I am at it now

[rizwankh]

Any update on this porting?

[mflorell]

It's very doubtful that this will ever happen. Freeswitch has a tiny community to help foster adoption of this compared to Asterisk, and developing something that has to deal with Freeswitch's rapid changing environment would be much more difficult than it was for me to use Asterisk as the PBX core. I certainly wouldn't spend the huge amount of time it would take to do it because there is so little to gain from it.

[chrismervyn20]

I actually tried doing the porting. But, the problem is that FreeSwitch, though growing is extremely fickle. So, it is like keeping tabs on a jumping jack. And unfortunately, as a single developer, I didn't get sponsored

I am working on something else at the moment. You can find it in my recent post under Development in this forum.

[williamconley]

It actually wouldn't be that hard to accomplish, but the caveat is: You'd not be able to get ALL Vicidial features online immediately. The first (BIG) hump is to get the basic autodial package online (to make the client happy ... presumably). Then continued sponsorship to link all the rest of Vicidial. That's where it falls apart: There's A LOT of Vicidial. It's a mature project with a huge amount of code, and a lot of it is related to Asterisk.

That being said, it would still be possible IF it had a sponsor.

I look at Asterisk and FreeSwitch just like VHS and BetaMax. BetaMax was better ... but died because VHS was ensconced. But now both are defunct and it didn't (in the end) matter that BetaMax was superior. Eventually asterisk will fall by the wayside (another 10 years?) and neither asterisk nor freeswitch will matter. Until then if there's no sponsor willing to pay, even for a slow "prototype" or "proof-of-concept", it'll never happen. Those who CAN do this are too busy to play.