SIP-Pi: SIP Answering Machine on Raspberry Pi
github.com
github.com
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.
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. :-)
Just a question, not trying to degrade what you've done here which is really cool by the way.
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. :-)