On 18/01/14 21:29, Kevin Fenzi wrote:
Yeah, as Bruno says, we used to run a asterisk server setup (talk.fedoraproject.org), but it was used about 1-3 times a month, which really didn't make it worth maintaining.
I've used Asterisk, FreeSWITCH (soft PBXes) and many of the SIP proxies (SER, Kamailio, OpenSIPS)
The soft PBXes in particular are more CPU intensive and support intensive and I fully understand why you would not want to run them - it is not what I have been suggesting here though. ; In fact, that is exactly what we decided not to do with Debian: no soft PBX, we just have a SIP proxy. Users can run their own private Asterisk servers with conference facilities and they can register those to the debian.org SIP proxy and host conferences in their own infrastructure. However, the Debian System Administrators only have to look after the proxy itself as that is the only essential component to connect all those private systems and individual users together. This is the bare minimum approach.
Something thats used more and has less maint costs might be possible.
Have you folks looked at sipwhich?
https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony http://www.gnu.org/software/sipwitch/
My understanding is that this would allow for a decentralized setup for peer to peer sip stuff, but I could be missing something.
It is almost the same as a SIP proxy (they say it is not a "router", but the behavior is a lot more like a SIP proxy than like Asterisk)
You could well choose between any of the proxies like this, e.g.
a) repro SIP proxy from reSIProcate (we chose this in Debian) - it is configured from a simple key=value text file, here is an example:
https://github.com/resiprocate/resiprocate/blob/master/repro/repro.config
b) Kamailio - this is probably the most powerful SIP proxy, the config scripts are more powerful but also require slightly more effort to learn
c) SIP Witch - I would have to review this more closely to see if it will fully interoperate with other domains (as per RFC 5922)
In my opinion, all three options require a similar effort to support. There are good communities behind them. If you were to give repro a trial run for example (maybe for a small group of 10-20 users) I would be happy to provide you with a list of
a) firewall ports b) DNS entries c) sample repro.config (based on what we run at Debian)
In order to prepare those things for you, you would need to provide
a) some machine with suitable IPs and bandwidth b) let me know about what authentication options you have (users should probably not use their main FAS passwords, Debian chose to create separate SIP passwords accessed through a RADIUS server) c) install the packages and copy the config file into place
Regards,
Daniel