Here is our basic outline for a GNU SIP Witch service portal, which looks simple enough to do quickly, and using limonade-php. If anyone has a better idea, that would be great!
First, we need a login/registration page. Clearly, there is a GNU SIP Witch userid and password. The password is actually a md5 hash which includes the realm, and will be in the sipwitch xml provisioning file for that user. This way sipwitch sip identity and portal user authentication will be the same. But for the moment, lets talk about the new user.
The registration page should ask for a user id, a name, an email address, a secret, and have a captcha. Perhaps there needs to be email validation as well, but this is a low ambition first draft.
In any case, the information can then be written directly as a sipwitch xml provisioning file. Of course, already existing users cannot be overwritten. At some point I will add a mysql plugin to sipwitch and the portal would use a real db rather than provisioning file. But this is for getting a 0.1 thing out early.
If the user logs in, they can see and change their profile, which consists of basically the above and then modifying the xml provisioning file. At some point there will be speed dials one can add to a profile. Things like adding time zone, fancy location maps, additional contact info, etc, might be nice, but certainly not initially needed.
They also should be able to request a page that shows them/gives them basic instructions on how to configure several different existing user agents based on their id and the portal location.
I think, from the perspective of users, that is all that is minimally required :).
An admin page which lets an admin add/modify/remove provisioning files, review logs, and maybe change things like the realm, reset passwords, etc, could be useful also.
Some thoughts about the above
Drupal (http://www.drupal.org/ ) has a lot of this ability built in. I doubt much would have to change in core at all, though the password aspect of the api (http://api.drupal.org/api/drupal/includes--password.inc/7/source ) might have to be scrutinized a bit. Drupal's GPL of course, and can add its own functionality to the portal as well. So, maybe a sipwitch module for Drupal may also be an idea.
If you can compartmentalize the functions that are not actually in CMS's (of which there are few above), you could proceed with any framework you desire and thus allow code implementations with specific CMS's to simply create modules with the additional functionality, reinventing the wheel could be avoided.
There is nothing in the design that says it could not be prototyped as a pure db/web application and then have sipwitch support added afterwards regardless of what it is done in. There are only three things needed for that; the ability to produce an XML provisioning file, the particular computation of sip compatible hashes from the user's password (it's basically a hash of the user's secret and the sip authentication realm), and sending control messages to the FIFO. It should be easy enough for example to do a PHP, Perl, or Python module to do these three functions, and then tie them in once the site itself is done.
There are a few additional sipwitch features that it may be useful to expose to users through the web site. One is a list of active online users. This would be best to tie together with a personal list of contacts that can show on the user's speed dial page, so you can see who is currently available to call.
If you would like to volunteer to help make that happen, that would be very excellent. We are planning releases within the next few weeks, and could need some help.