Implementing SIP Telephony in Python (2008) [pdf] | Hacker News Reader

Implementing SIP Telephony in Python (2008) [pdf]

39peers.net

64 pointsmoises_silva13 comments

The SIP stack implementation in Python is good. But RTP part - Python can't keep up with real time requirement of RTP, bursting out packets every few milliseconds. Even after depending on C code for encoding/decoding. There once was an attempt to code softphone (shtoom - https://sourceforge.net/projects/shtoom/files/ ) in pure python by Anthony Baxter and was later abandoned. There are some jobs that python can't cut it.

The most common implementation of Python can't cut it.

But other implementations might, such as PyPy. Cython almost certainly could, but it's a super-set of the Python language so maybe it shouldn't count.

I am thinking of

Oh boy, I just wrote a 100 line client and another 100 line server that is able to do real time voice communication, comparable to the likes of telegram. (In python)

Albeit it uses portaudio (python-soundevice) for the audio IO which is not written in python, and opus which isn't written in Python either. But all the glue and udp communication is pure python.

And P.S. - pulseaudio uses more CPU than my thingy.

Talking about production, I suspect the guys at OnBeep are making use of python a lot, just looking at their GitHub repo

https://github.com/OnBeep

(The python opus bindings are created by them)

I'm just tired of people underestimating the speed of python. Its often a matter of not using it correctly...

This is different than doing pure python implementation. Python acting as glue is most suitable solution when heavy lifting is done by C code. I have used pjsip/pjsua lib with python bindings which performs beautifully.

Maybe "pure" python can't do fast sound processing, I can accept that. You have to at least use scipy/numpy. But his claim of "Python can't keep up with real-time requirement of RTP, bursting out packets every few milliseconds" seems bogus to me.

Oh, and ftr - I'm "bursting out packets" at 10ms intervals. I have tried 5 and the problem still wasn't speed, it was the cracking noise caused by such small samples

First of all, thanks for sharing this - it's a very thorough guide to implementing SIP.

Second, the author says that he has implemented a SIP client in JS as well. But my experience with open-source JS SIP clients (WebRTC) has been that their performance is significantly worse than the free version of xlite. (Both SipML and JSSIP have more frequent packet drops on the same systems than xlite).

Are there better JS implementations that are at least as robust as xlite?

>>> (Both SipML and JSSIP have more frequent packet drops on the same systems than xlite)

What kind of packet drops are you talking about? if this is about media/audio that's entirely on the webrtc browser engine which is C++. SIP signaling on the browser goes over websockets (https://tools.ietf.org/html/rfc7118), so I'd not expect any kind of 'packet drops' on signaling either.

In short, I doubt your problems were due to the SIP stack in JS.

I remember browsing the directories of a Broadsoft Broadworks application and network servers back in the early 2000s and being shocked at just how much of the product was implemented in Perl. Many fortunes have been made on the back of interpreted code.

There's not much in the SIP protocol itself (I'm not talking the RTP streams here, just SIP) that can't be handled with adequate performance in higher level languages (whether interpreted or not). At the end of the day it's a bunch of XML over TCP sockets, a lot of your function/method calls are going to be into libc (networking), something like sax (xml), and likely database access (libpq/whatever), the coordination of these with perl is going to cost you some CPU time but likely not enough to justify the extra expensive (man hours) doing it in C or something similar.

The RTP streams, that you may want to handle in a lower level language since you're talking soft real time being a must.

UDP sockets, not TCP ones. And don't forget about the bunch of MIME and Internet Message format that precedes the XML. (-:

SIP works over a variety of transports, both TCP and UDP are used. You can tell UDP is certainly more common but any RFC-compliant stack is supposed to support both because large UDP packets (> MTU) are supposed to be sent using TCP.

The bulk of the protocol doesn't require XML at all actually, it's the SIP SIMPLE and presence extensions that do. But for the core SIP spec and your run of the mill VoIP call setup, no XML is needed.

Apparently I was being too subtle with the gentle reminder not to forget the MIME and Internet Message stuff.

Reply on news.ycombinator.com