If you are like most people in the communications industry, you will tell me that SIP is used to make telephone calls. Some of you might also mention point-to-point or multiparty video, but in general, most people think of SIP as a way to make some sort of call -- SIP for physical, soft, and mobile telephones and telephone-like devices.
While these are certainly valid uses of SIP, the notion of making calls only scratches the surface of what it can do. I often wonder how different our impressions would be if the inventors of SIP had chosen to pioneer a different use case. Would we still think of it as a replacement for TDM telephony if the first SIP-enabled devices had been electrocardiogram monitors?
If you have been following my articles, you may have picked up that for many years I was a software developer working on SIP endpoints and backend services. During that time, I wrote thousands of lines of Java and C++ code that established and managed SIP calls. However, I also wrote just as many lines that had nothing to do with calling.
For instance, I once worked on a project that used SIP to create a shared whiteboard/drawing space. Think of extending the Microsoft Paint program across the Internet; two people could play with the same drawing canvas at the same time. SIP was used to send commands and graphics coordinates to draw lines, curves, points, and write text.
Around the same time, I did something similar for a network chess program. This application used SIP to convey chess moves from one PC to another across a LAN or WAN.
One of my more interesting creations was a method to pass clipboard data between different PCs. A user was able to do a copy (Ctrl+C) on one PC, and another user could paste (Ctrl+V) that data on a different PC. How did that data get from one machine to the other? With SIP, of course.
The point is that SIP can be used for things far beyond dial tone. While it's certainly true that telephony is currently the largest user of SIP, there may come a day when voice traffic has been dwarfed by other forms of media.
I divide the major uses of SIP into three different camps. First, there are the session management aspects. These involve creating SIP sessions in order to pass data between endpoints. My chess game is an example of this. A SIP INVITE message is used to establish a session between two players. Contained within that INVITE is Session Description Protocol (SDP) information that defines the IP address, port, and protocol used to transmit chess moves and control signals. The game ends with a SIP BYE message. These are the same messages you would use for any voice or video session.
I also lump instant messaging into this form of communication, but instead of an INVITE request, SIP employs the MESSAGE request. Within the body of a MESSAGE request is the IM text. However, unlike the previous form of conversations, no session is established, yet data is passed between two users.
The next big class of SIP applications do not rely on INVITE or MESSAGE requests. Here, SIP SUBCRIBE, PUBLISH, and NOTIFY requests are used to create a client/server relationship between different entities. This bond informs the server of who is interested in something and notifies the client when that something has changed. For example, a SIP telephone subscribes to the voice mail status of its registered user. When a new voice mail arrives for the user, the SIP client is notified and the device can display informative text, or in the case of an old school SIP telephone, illuminate a red light.
SIP subscriptions are amazingly powerful and allow you to go well beyond dial tone and media streams. I've seen SIP used to subscribe to a user's class-of-service options. This allowed an administrator to set permissions and capabilities for a user (e.g. this user has the ability to create six-party conference calls) and have that user's end point visually display the change (e.g. un-gray the conference button on a soft phone). Users can also subscribe to address books to be informed of new entries. A SIP-based alarm system might notify first responders that an emergency condition has gone into effect.
You are undoubtedly familiar with the most popular use of subscriptions. Those presence jellybeans on your Lync or Skype for Business client turn different colors based upon SIP SUBSCRIBE and NOTIFY messages.
How about using SIP to remote control your house? As far-fetched as that might sound, someone created a design to do just that. If you want to see just how far you can move SIP away from telephone calls, take a look at this proposal. A quick glance through the document will show you clever uses of MESSAGE, SUBSCRIBE, and NOTIFY.
I've done extensive work with Avaya SIP telephones and discovered that they use different subscriptions to enable traditional PBX functionality not currently defined within SIP. Lamps are lit, features enabled, and soft key labels are changed because of NOTIFY messages. A typical Avaya SIP telephone subscribes to at least five different events. A contact center telephone adds yet another subscription for agent-specific activities. If you were to trace the packets in and out of busy Avaya Session Manager, you might see as many NOTIFY messages as you see INVITE requests.
My third and final class of SIP-enabled applications use the INFO message. INFO is used to carry application level information along a SIP signaling path. For example, some older SIP telephones use INFO to send DTMF digits. INFO is also used to carry mid-call signaling messages between PSTN gateways.
The biggest user of INFO may be a SIP offshoot protocol called TR-87. TR-87 enables first- and third-party call control of SIP entities. Back in the day, I used TR-87 between a Microsoft Office Communications Server (OCS) and a Nortel CS1000. The OCS client sent INFO messages to instruct the Nortel IP telephone to make a call and the Nortel system used INFO messages to tell the OCS client that the call had been placed. These back-and-forth command and status messages implemented what was referred to as Remote Call Control (RCC).
TR-87 was still available in Microsoft Lync 2013, but the story is more complicated with Skype for Business. From the Microsoft website:
Remote call control was a feature in previous versions of Lync Server which enabled users to control their PBX phones with their Lync. In Skype for Business Server, this feature has been replaced with Call Via Work.
Remote call control users in your organization who are homed on Front End Servers running Lync Server can continue to use remote call control, even if they are using a Skype for Business client. However, for any users homed on Skype for Business Server, remote call control is not supported.
I hope this helps you see that the power and reach of SIP extends past that of simple telephone calls. Transformational technologies are constantly evolving, and I expect SIP to do the same. There are old problems that still need to be tackled and new challenges that must be met. SIP won't be the answer to everything, but it will continue to play a big part in the world of real-time, unified communications.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
