|boggyb's laws of IP phones
||[Friday 16th November 2012 at 8:38 pm]
I would like to propose boggyb's laws of IP phones:
Law 1: Every IP phone will contain an easy-to-hit bug that makes it completely unusable for a common call flow.
Law 2: No two IP phones have the same bug.
Law 2a: Different versions of the same IP phone will have different bugs.
A bit of background: in SIP (which is what every IP phone that isn't Skype uses), you start a call by sending a request to the callee along with a SDP offer, which contains a list of media streams and codecs you support along with the IP address/port to send them to. The callee replies with a SDP answer containing the codec(s) that it has chosen for the call, along with where the callee expects to receive media on. Usually the answer contains a single codec which both ends will then use. The offer/answer process can be repeated during a call, for example to add a video stream. It's all deceptively simple but full of pitfalls for the unwary.
Anyway, on with the fail! Naming no names, because I can't remember which one has which bug.
When updating the media during a call, you're supposed to use the same session identifier but increase the version number. One client just comes up with a completely new session identifier. Most stuff seems to cope with this, if only because there's not much reason to pay any attention to those fields (though at least one system *does* check it and gets unhappy if the version isn't incremented when the SDP changes).
Several clients completely fail at handling being placed on-hold. Now, what happens when you press the hold button is your phone sends an updated offer with a flag saying "don't send me anything". To take your phone off-hold, it then sends another offer without that flag. The other end is supposed to send an answer with some codecs to use... except several clients send an on-hold answer. At least one does this intentionally.
One softphone will start if you don't have any audio devices present, but then segfaults when it receives a call.
Some clients get things wrong when trying to work out which IP address to list in their SDP, and pick unhelpful things like "127.0.0.1".
A common client doesn't cope well with a particular click-to-call scenario, which starts by sending it a request with no media in it. It replies correctly, but later when it gets sent a request with no SDP at all in it (this is because the server has called two different phones and is now trying to get them to speak to each other - to do this it has to get an offer out of one of them) it just drops the request on the floor.
Another client thinks that the media will never ever change, and so pays no attention to the content of later offers. This breaks anything more complicated than "A makes an audio call to B".
The fail is not limited to handling audio - some clients can't even cope with the SIP signalling!
A phone which I've ranted about before fails to send NOTIFY messages if it receives a REFER, and the phone it is transferred to redirects it to another destination.
A load testing program doesn't quite understand that retransmissions exist, and so gets rather surprised when it receives one. This is... unhelpful when using it for a load test.