SIP Subscribe, Notify, and Publish

Today, I want to write about three of the most important messages in SIP – Subscribe, Publish, and Notify.  You may be surprised that none of these have anything to do with making phone calls, video calls, sending instant messages, or the things that most people think about when they think about SIP.  Instead, these three messages create the foundation for a nearly infinite number of business transforming applications.

Subscribe

Let’s begin with Subscribe.  As you would expect, Subscribe is used to create a subscription between a client application that desires information from a service and the service that delivers that information.  For example, a SIP phone might subscribe to a voicemail service in order to light its red message waiting indicator when a message is waiting and turn that indicator off after all messages have been read.  Another example might be a first responder subscribing to an E-911 system to learn when someone in need dials 9-1-1.  Finally, an application on a doctor’s smart phone might subscribe to an electrocardiogram machine to know when a patient’s EKG reading indicates a significant patient problem.

Publish

The next most important message is Publish.  Publish is used when a service has something to report.  In our previous example, a SIP phone subscribes to a voicemail service.  When that voicemail service wants to report a new voicemail, it sends a Publish message that contains information about the voicemail and the caller who left it.  Similarly, that E-911 service would send a Publish message when someone dialed 9-1-1.  That Publish message would contain basic E-911 information like the caller’s telephone number, but it might also contain the GPS coordinates of the caller along with the location of a closed circuit video camera near the caller.  A Publish message for the electrocardiogram might contain the patient’s name, room number, and EKG reading.

Notify

This brings us to Notify.  When a user, device, or application subscribes it doesn’t send the Subscribe to the service it is subscribing to.  Instead, it sends it to a broker (e.g. a Presence Server) that manages the subscriptions that all users, devices, or applications might create for that or any other service.  Consequently, when a SIP entity sends a Publish message, it doesn’t send that message directly to the subscriber.  It too speaks to the subscription broker.  It is the broker’s responsibility to accept Subscribe messages to create bindings between the subscribers and the services.  Now, when the broker receives a Publish, it searches its table of bindings to learn who is interested in the information that the Publish message contains and sends Notify messages to those users, applications, or devices.  This allows for a single Publish message to generate multiple Notify messages when more than one subscription exists to that service.

Building SIP Services

Returning to our previous examples, the subscription service would send a Notify messages to the SIP phones when a voicemail is left, the emergency responder when someone dials 9-1-1, and to the doctor when the EKG reading indicates a significant problem.  This loose coupling between subscriber and service allows for significant scalability.  It also permits the service to focus on the services it provides without having to be concerned with subscriber authentication, blocked lists, distribution of Notify messages, etc.

I want you to think of all the things that you as a user might be interested in subscribing to.  Imagine that you are a supplier of electronic circuit boards.  Would you be interested in being asynchronously informed when the inventory for the raw components for those circuits falls too low? Imagine that you work in a warehouse and want to know when a delivery truck is nearby.  Would it improve performance if you could be subscribed to the GPS coordinates of that truck and be notified when it is within ten miles of your location?

With SIP Subscribe, Publish, and Notify, the possibilities are endless as to the kinds of integrations and “Business Communications Mashups” you can create.

Advertisement

Tags: SIP, Unified Communications, VoIP