Subscribe, Notify, and Publish

Andrew Prokop

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.

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.

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.

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 (sometimes referred to as a Presence Server) that manages the subscriptions that all users, devices, or applications might create for that or any other service.  Consequently, when a service 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.

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.

To sum everything up 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 all these are possible and the sky is the limit to the kinds of integrations and “Business Communications Mashups” you can create.

Andrew’s technical expertise and attention to customer service are second to none. As a Certified SIP Application Architect (CSAA), he is uniquely qualified to engage in a business conversation with our clients and assess opportunities to deliver business transforming, SIP enabled solutions that answer customer challenges. Andrew’s experience includes:

  • Over 27 years of industry experience.
  • Author or co-author of United States patents 6,870,848, 7,403,607, and 7,463,619.
  • Microsoft Certified Systems Engineer (MCSE).
  • Winner of the 1999 CTI World Golden Award for Technology Innovation and Product Excellence.
  • Invited speaker at numerous communication technology tradeshows.
  • Past contributor to Computer Telephony magazine.
  • B.S. in Computer Science from Arizona State University.

Share this page:

1 Comments

    • Posted by - Test On Feb, 28 8:40AM
    Test post

Comment

About this page: