Why SIP Sucks
I have for many years blasted the SIP protocol as something that needs a “Version 2”. SIP is wildly and unnecessarily complicated and it does a bad job of ensuring reliable operation.
SIP is especially bad in that it leaves users with one-way connections (or zero-way connections).
I have written about this, and usually get a fair amount of hate mail back.
The essence of the counter-argument is that SIP is a Session Initiation Protocol and that it doesn’t actually participate in the media stream. It sets those streams up but it is not the function of SIP to intercede in them.
This makes me sigh.
This is like saying that a manager has no responsibility to make certain that their subordinates are actually doing the assigned tasks, or for tracking project progress. After all, once the manager has assigned work, the manager should have no more responsibility, right?
Then, I get the argument that there is no real way for SIP to know if there is a one-way or zero-way problem.
This makes me sign (again).
The solution is remarkably easy! Prior to starting up the media on the assigned ports a test message could be sent through the RTC media channel. Each end could be instructed by the SIP protocol to send a test string. Then, it could report back what was received, and once the working channel is confirmed the media can be started. Really this isn’t complicated stuff.
Actually, it isn’t necessary to conduct a test. The remote SIP clients know that they have started receiving the media stream and even if it looks compatible. Why can’t the clients just report back through the SIP protocol that the media has started and that receiving has been begun?
In case after case I see people struggle with SIP. There are so many variants and flavors out there that we really need a SIP2 protocol. It could look remarkably like the current SIP, but it could be tightened up and we could depreciate many of the variants in the settings.
Lets face it that SIP is a disaster and let’s tighten it up. In particular, let’s reduce the number of options and standardize the little things like DTMF payloads, timeouts, and how DTMF is to be sent.