
Implementing SIP Telephony in Python (2008) [pdf] - moises_silva
http://39peers.net/download/doc/report.pdf
======
godsongera
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/](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.

~~~
devxpy
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](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...

~~~
godsongera
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.

~~~
devxpy
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.

------
ksaxena
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?

~~~
moises_silva
>>> (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](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.

------
mrkstu
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.

~~~
snuxoll
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.

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

~~~
moises_silva
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.

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

