Anybody remember Lily Tomlin’s telephone operator shtick, or am I just betraying my age?
The bit, which began on the 1960s sketch comedy Laugh-In and was carried on through her standup career, had Tomlin as a chatty, gossipy telephone operator from the days when telephone exchanges were manually switched. She’d answer the phone, make some kind of witty remark, then patch the call as requested with a cable.
Analogue PBXs are like that, sans the humour. They’re doing it in an automated fashion, but they’re still dependent on the physical location of the phone on the other end. Move the phone, and you can’t make the connection.
The promise—in fact, largely the point—of unified communications (UC) and Voice-over-IP (VoIP) is that physical location and device are immaterial, as long as the device is connected to the network. Take your video phone to a quiet boardroom for a call; log into the PBX from a softphone at home. In an analogue environment, what’s important is where the device is; in a UC environment, what’s important is who the user is.
The acronym SIP gets thrown around a lot in the context of UC—SIP-enabled, SIP phone, SIP trunking—and often, it’s not clearly understood what exactly it means (or what it stands for, for that matter). Simply put, session initiation protocol is the Lily Tomlin of UC.
SIP negotiates the connection of two communications devices. That’s its only function. It doesn’t do voice quality; it doesn’t do video compression; there are other protocols for that. SIP finds the requested device and connects it with the requesting device.
A SIP-controlled call might work something like this (we’ll use a simple voice conversation as an example). Bob’s calling Amanda. He dials the number. Since Bob’s desk phone doesn’t know where Amanda is, or what device she’s using, it sends an INVITE request to a proxy server. If proxy server 1 doesn’t know where Amanda is, it forwards the request to another proxy server. If server 2 doesn’t know where Amanda is, it forwards it to a third. Let’s say, in this case, server 2 does know Amanda’s IP address. It forwards the request to Amanda’s softphone.
Amanda’s phone responds by ringing. This sends a RINGING message back through the proxy server chain to Bob’s handset. When Amanda picks up the phone, an OK message is sent; Bob’s phone responds with an ACK message.
At this point, with the connection made, SIP goes hands-off. The control of the voice content going back and forth is handled by other protocols; for example, VoiP or real-time transport protocol (RTP). When Amanda hangs up, her softphone sends a BYE message; Bob’s phone sends an OK and the call—the session—is terminated.
There are a few other SIP commands worth knowing about:
CANCEL: Does what it says on the tin. If you hang up before a connection is made, your device sends a CANCEL message.
OPTIONS: Queries the server about its capabilities.
REGISTER: Registers a device with the network so proxy servers can find it when an INVITE request is made.
SIP is an application level protocol, sitting at the top of the networking stack. Together with other application level protocols that perform streaming, compress audio or video, indicate presence, and allow desktop sharing, it creates the foundation of a full-fledged UC solution.
