Next will be to fix the underlying cause of why the CDRs are not matched in the first place. In my case it was happening with a call that went out of a gateway, and maybe other situations.

Fixed on *trunk only*, revision 248

You will need to apply the DB patch called patch_2010_02_11.sql in the sqlpatches subdirectory.

Additionally, the multi-tenancy has been changed from sip profile based multi-tenancy, which is not really "the normal way" to do this .. to the standard approach of domain based multi-tenancy. Along with that comes the ability to manage sip profiles from the GUI.

A lot of security enhancements have been added, it is possible to force sip profile wide authorization, as well as per-extension dialplan security — checking a flag in the dialplan will make it public (for anyone to access) or private (only registered users). The dialplan security is overlayed on top of the sip profile security .. and sip profile security takes precedence. (sip profile security is done by freeswitch whereas per-extension dialplan security is done by wikipbx)

Gateways can now be per-tenant or shared among all tenants, and can be assigned to any sip profile on the system.

Mod_voicemail now works with wikipbx, and is easy to configure. No GUI support yet in terms of visual voicemail.

A really simple XML export / import has been added for existing users using version 0.5 to upgrated to version 0.8.

Documentation has been completely re-written to reflect all changes in this release.

What's still missing? The configuration XML that is served up to FreeSWITCH is really, really old. The only upshot is that they are served from static template files, so you can hack stuff in without having to look at any code. We are planning to fix this by the 1.0 release, slated for November of 2018.

See release-notes-0-8 for more details on this release and how to install it.

• Domain based multi-tenancy
• Dialplan security (public / auth'd on an extension by extension basis)
• Runs as mod_wsgi app
• Works with mod_voicemail (before there were some issues)
• Improved registration status
• Etc..

The "standard" way for people to do multi-tenants with freeswitch is to let all tenants use the same profile(s), such as the default config internal and external profiles, and have everything partitioned by domain. So if a call comes in on foo.com on port 5060, then it will go into a dialplan for the "foo.com" tenant. Likewise if a call comes in on bar.com on port 5060, it will go into the dialplan for the "bar.com" tenant. The point is that they both live on the same port (and therefore profile), but have completely different dialplans. These two tenants could also live on more profiles, such as the external profile on port 5080.

The way WikiPBX does it is much differently. Every tenant gets their own SIP Profile and the partitioning of dialplans and so forth is done based on profile. When freeswitch asks WikiPBX what to do for a particular extension, WikiPBX checks the sip port, which is uniquely mapped to a profile, and then knows which tenant to use, and looks up that tenant's dialplan in the database. So the "foo.com" tenant gets port 5060 and a profile named "foo.com", the "bar.com" tenant gets port 5061 and a profile named "bar.com", and so on for each tenant ..

The consequences is that in certain things, like mod_voicemail, WikiPBX cannot integrate nicely with freeswitch.

The long-term plan is to switch everything over to domain-based multi-tenancy, and either offer an option to stick with profile based multi-tenancy, or just throw that approach away altogether.

Details here: http://wikipbx.subwiki.com/forum/t-163001/problems-transferring-live-calls

This is basically a scalability bug that can have a negative impact when the server runs under a heavy load. The bug will be more apparent if there are long running queries or the database is slow for whatever reason.

The problem is that the webserver is running in a non-blocking io environment (eg, twisted web2), but the code makes blocking database calls in many places. So if a database call takes a long time, the whole server will "lock up" for new requests until the long running database call unblocks.

The best solution is to move away from using twisted and non-blocking io and use a more traditional multi-threaded/multi-process webserver, eg, mod_wsgi running under Apache2 or nginx.

Now it should be much easier to customize the configuration to your specific needs when that customization is not supported in the web interface / database.

The templates are still outdated compared to the current config, and will be brought up to date soon. But it should be fairly easy since it is just a matter of merging in new parameters to the xml template. (all templates are located in the freeswitchxml subdirectory).

WARNING: don't try to use default variables like $${foo} that are defined in vars.xml in the static freeswitch config. This will be passed verbatim to freeswitch, which will not resolve the variable. Not sure if this is a bug in freeswitch or by design. Only tested against an old version of freeswitch (10300) so your mileage may vary.

The fix was simple, just return the appropriate "not found" xml rather than an HTTP 404.

After these planned changes, all configuration will be stored in Django templates based on the latest freeswitch default XML configuration files, and it will be straightforward to modify the templates and change any parameters or merge in new parameters.