Since there are more than two people working on wikipbx codebase, I think that we should stick to a bit more disciplined approach for commits. There are various ways to organize workflows, I'm thinking about something inbetween "Decentralized with shared mainline" and "Decentralized with human gatekeeper". Unless it's a trivial change that can be committed directly to trunk by anyone, it should go through the following stages:

1. Create or select existing bug or blueprint. If it's been created, wait for some feedback.
2. Make a branch for this task. Link the related bug/blueprint to it in LP interface.
3. Hack, hack, hack.
4. When it's ready, it should be reviewed by someone (not the person who wrote the code). If there's something to be improved, go to #3.
5. Merge with trunk and/or stable branch.

Things to look for during code review:

1. Python coding style violations.
2. Things that can be improved.
3. Errors, typos.
4. Possible unexpected effects from the new code.

 Each sip profile is its own ip/port bindings, so yes, you must use different ip or port for each profile. 

Looks like it's sufficient for each profile to listen on its own socket. It's rather uncommon to have such configuration as most people just use different port numbers for different profiles, but it's not hard to implement.

But we can get another issue here. After adding multi-tenancy to wikipbx Traun noticed that that one of the gateways was using his server's IP instead of domain name for making incoming calls. We've got a workaround for authenticating such calls - domain name is specified in SIP request parameters that are received in SIP invite later. However, we won't be able to use that parameters for filtering channels as they aren't available in freeswitch command's response. In this case, it's still better to be too restrictive than too permissive, but I'd prefer to have something that always works correctly. One thing I haven't thought before is replacing IP with domain in channel variable after applying domain hack - this could work in theory.

uuid,direction,created,created_epoch,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,dialplan,context,read_codec,read_rate,write_codec,write_rate,secure,hostname,presence_id,presence_data

41b249f8-7a0f-11df-971d-674148912bd7,inbound,2010-06-17 15:52:58,1276779179,sofia/DCext/13.1.861.291|101#13.1.861.291|101,CS_EXECUTE,Dimaa M 1234,101,192.168.1.13,103,bridge,sofia/gateway/My_DC_gw/441,XML,enum,default,PCMU,8000,PCMU,8000_ast

41c6b1c2-7a0f-11df-971f-674148912bd7,outbound,2010-06-17 15:52:59,1276779179,sofia/DCext/441,CS_EXCHANGE_MEDIA,Dimaa M 1234,101,192.168.1.13,441,playback,local_stream://moh,XML,enum,default,PCMU,8000,PCMU,8000_ast

4c05a792-7a0f-11df-9725-674148912bd7,outbound,2010-06-17 15:53:16,1276779196,sofia/DCext/441,CS_REPORTING,Dimaa M 1234,101,192.168.1.13,441_{,XML,enum,default,PCMU,8000,PCMU,8000}ast,,

5796698e-7a0f-11df-9728-674148912bd7,inbound,2010-06-17 15:53:35,1276779215,sofia/DCext/13.1.861.291|101#13.1.861.291|101,CS_EXECUTE,Dimaa M 1234,101,192.168.1.13,106,echo_{XML,enum,default,PCMU,8000,PCMU,8000}ast,,

4 total.

It seems to me the only common part in these channels is DCext profile name. So if every tenant has its own profile, channels can be filtered by profile.

Channels 1 and 4 can be filtered by domain name, but then channels 2 and 3 wont be visible in any Account.

Probably the same approach should be applied to CDRs for the cases where right now we raise an error:
"Cannot associate this CDR with an account. Did not find either a valid account_id or domain_name channel variable"

<profile>
<name>TestProf</name>
<type>profile</type>
<data>sip:53.1.861.291|aifos_dom#53.1.861.291|aifos_dom:5080</data>
<state>RUNNING (0)</state>
</profile>

<profile>
<name>external</name>
<type>profile</type>
<data>sip:13.1.861.291|aifos_dom#13.1.861.291|aifos_dom:5080</data>
<state>RUNNING (0)</state>
</profile>

On a serious note, github is intended for hosting code rather than developing software projects, so it doesn't offer much besides a fancy UI for forking git repos. What's missing: release planning and localization. This also leads to oversimplified issue tracker that most people don't use.

As a bonus, you can host packaged software in PPA, which I'll probably do for 0.9.

I mean github has a ton of momentum, it seems like a better time investment to learn git/github.. what do you think? What are the major benefits of launchpad over github?

I've already created a branch there a few days ago, although I was going to use it only for translations initially. I'll post a message with more details in this forum when it'll be ready for development, stay tuned.

Is there any particular targets set for the new version?
What new functionality are planed for the new version?

The next version will work with a recent version of Django plus some other minor tweaks like UI improvements

How far are the project right now from the next release?

Its about 90% there

What is the best way to contribute to wikipbx project?

There's currently not really a good way .. if you have code patches send me a private message and we can discuss over email. Eventually I think DVCS might be the best approach.

How stable is the current trunk version? Can it be used in production, if not what areas are not stable yet.

Its stable, I can't think of any areas where it will blow up on you..

I'm also thinking that DVCS is much more appropriate, because that way people don't have to send in patches which puts pressure on us to review .. with DVCS people who want to submit patches can just fork it and we will pull the (good) changes.

I think it makes sense to move everything somewhere else :)

Someplace that ..

• Free for open source projects
• provides DVCS, ideally git IMO
• Nice issue tracker
• Forum / Wiki

As there are just two developers and we work on it in our free time, we don't have any deadlines except "when it's ready".

The primary goal for the next release was to get wikipbx running on modern version of django and it's been completed. However, we don't consider trunk production ready yet as it hasn't been extensively tested and there are some more features planned.

However, there must be other less obvious ways for malicious user to exploit freeswitch server as he has direct access to generated dialplan. We plan to have a WYSIWYG interface for editing dialplan extensions in the future that would let user to use only safe commands.

 sofia/gateway/<gateway_name>/<dialstring> 

Note that gateway name doesn't have to be the host name for the SIP gateway. It can be any string identifier. The host name is taken from the "realm" field that is set to gateway name by default. In your case, every user should have unique gateway name, but they can have the same realm name with different username/password.

There's some chance that freeswitch docs are incorrect and it requires a unique socket rather than port as you suggest. You could test it by removing "unique=True" from wikipbx.wikipbxweb.models.SipProfile.sip_port, creating a new database with wikipbx models and running freeswitch with multiple SIP profiles sharing the same port number but with different IPs.

I'm new to this project and would like to find more about its development.
Could developers share the current status of wikipbx development. I'm interested in the following aspects:

Is there any particular targets set for the new version?
What new functionality are planed for the new version?

How far are the project right now from the next release?

What is the best way to contribute to wikipbx project?

How stable is the current trunk version? Can it be used in production, if not what areas are not stable yet.

Thanks!