fedoraproject.org SIP service?

Daniel Pocock daniel at pocock.com.au
Sat Jan 18 22:19:27 UTC 2014

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

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



More information about the infrastructure mailing list