![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
boggyb's laws of IP phones
Nov. 16th, 2012 08:38 pmBonus post!
I would like to proposeboggyb'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.
( Media FAIL )
The fail is not limited to handling audio - some clients can't even cope with the SIP signalling!
( Extra FAIL )
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.
( Media FAIL )
The fail is not limited to handling audio - some clients can't even cope with the SIP signalling!
( Extra FAIL )
