SIP is an interesting technology; very much replicates the traditional phone architecture of separated control/data planes, call setup and so on. But there's so many pieces to it that it ends up rather inaccessible to people looking to get started with it.
I don't know that it can be said to replicate traditional phone architecture at all, for two reasons:
1) Unlike H.323 and friends, SIP is the product of rather purely Internet-orientated/IETF thinking, not ITU. It was initially designed to set up multimedia "sessions" of various kinds (few prescriptions as to what kind) over the Internet in a rather generic sense.
Aspects of "traditional phone architecture" have been painstakingly grafted onto SIP, with mixed results. Certain things that have been taken for granted for decades are extraordinarily complex to do with SIP, such as bridged/shared line appearances on office PBX systems, because ...
2) ... SIP decentralises a lot of intelligence and state, taking it out of the phone switch (or PBX) and putting it in the endpoint/handset itself.
A traditional PBX system or Class 5 subscriber switch is very all-knowing, in the way that SCCP-based Call Manager is all-knowing. SIP puts a lot more responsibility on the endpoints, leading to distributed systems challenges.
Shared line appearance is a big feature missing from SIP based systems that I find frustrates a lot of users, particularly medical clinics. Nurses are used to the putting a call on hold on line 1, then telling the doctor or whoever to answer the call on line 1.
Not just clinics, of course. It's common practice in many businesses of all sizes.
But yes, this has been a feature of Key systems since before many HN readers were born. It was easy because the PBX knew all and controlled all; it knew the calls going through itself, and just told the corresponding phone to illuminate this lamp.
With SIP, it requires an elaborate presence (SUBSCRIBE/NOTIFY) song and dance, often implemented using competing methods, and even when you get the lamps working, cross-connecting a caller to a different phone to simulate "picking up a line" is no mean feat, since the new destination was not previously a party to the dialog. This gymnastics is usually implemented underneath using "call parking", which means users must remember to "park" calls rather than merely place them on hold, and intelligence must be devised to get line keys to map to correct "parking numbers" and so forth.
It's certainly not impossible, it just becomes an incredibly overcomplicated feat of technical jujitsu for something that worked fine for ages under the old regime.
That's because SIP was very much _not_ designed for traditional telephony. :-)
I implemented a very simple SIP and RTP stack using Ruby. At first it ran terribly, but with some tweaking, and I think running a newer version of Ruby, I got it so that the sound quality was very legible. Not perfect, but good enough. Ruby certainly isn't the best language for it, but it was a good learning experiencing in understanding how the protocol works. For example, I quickly learned what the "tag" parameter does.
However, out in industry, a good rule of thumb is that if it hasn't been around for at least ten years, it's not a usable SIP stack. SIP interoperability is incredibly fragile.
The basics look easy. Here are some minimally required headers, looks a lot like HTTP, send a message, get a reply, bam, done. I remember when I first started working with SIP at age 19 or 20 (ten years ago), I had the conceit that one could just read RFC 3261 and whip up a little SIP stack real quick. "Looks pretty easy".
Little. Did. I. Know. It took me several more jobs and three or four years of consulting beyond that to get to the point where I would say I had anything remotely resembling commercially valuable SIP expertise to offer. These days I have a consulting business around that premise, but that's ten years and a whole specialist career down the road. All for a little HTTP-like protocol with human-readable headers.
There are only a handful of viable commercial and FOSS SIP stacks out there. All painstakingly evolved to get there. For any serious endeavour you should use one of them. :-)
Interesting. Sounds like you were going for quality over bandwidth efficiency. Maybe a feature request, but it'd be awesome to be able to chose G.711 or G.729 based on bandwidth requirements. :)
Almost all things that run on a Raspberry Pi will run on just about any other Linux machine, but not all things that run on other Linux machines will run on a Raspberry Pi.
I run RasPBX (Asterisk + FreePBX) on my Raspberry Pi and it works quite well. The distro itself is also pretty easy to manage and update. I mainly use it to record my phone calls and works well for that purpose.
