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.

O'RLY? :-)

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..

There are three people that are involved now, two core python developers and another guy who is a web developer, sysadmin, and runs a dialtone provider hosted PBX company.

There will be a big new release with lots of improvements.. stay tuned. No exact date but probably on the order or 2 to 4 months if the momentum keeps up.

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.

I think that the problem of slowing down on heavy load may be caused by the small default thread pool size. If you can test it with default thread pool size and increased as described in twisted threading docs, that may give interesting numbers.

But decoupling django and twisted is still a better solution here.

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.

Moreover, looks like instead of XML tree we should be able to use dialplan template here to make it more customizable.

Done - svn revision 76

Freeswitch docs tell that variables should be resolved normally in this case.

Yeah, I just tested it against freeswitch revision 13223 and it worked. So it was fixed somewhere between freeswitch revision 10359 snd 13223.

Thanks for the link to the freeswitch docs .. it sounds like that variable resolution might actually work. I will test it on a later version of freeswitch and see what happens.

Also, looks like dialplanbuilder.build_xml function has some incostintencies. First we create an XML tree starting with context tag, then check if current extension has condition tag and if it does we use string substitution with another string. So in the latter case there was no need to create XML tree here. Moreover, looks like instead of XML tree we should be able to use dialplan template here to make it more customizable. This would let the users to easily change all dialplans easily, e.g. could be used for setting some variables, silence detection, authorization checks.

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.

I guess the following would have been better:

• mv /usr/src/wikipbx /usr/src/wikipbx.OLD
• cd /usr/src; svn co .. to create a new /usr/src/wikipbx with latest code
• cp /usr/src/wikipbx.OLD/settings.py /usr/src/wikipbx

Then if the new version was broken, it would be easy to rollback ..

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