A Deep Dive into the SIP PUBLISH Method

Last week in what turned out to be a surprisingly popular article, I walked you through the joys of the SIP SUBSCRIBE request. You saw a typical SUBSCRIBE and I explained the most important headers. You also saw how NOTIFY messages are used to convey changes in the subscribed-to entity.


If you missed it, be sure to read A Deep Dive into SIP Subscriptions.


PUBLISH is the third leg of the subscription stool and is used by the subscribed-to entity to convey status change information back to the subscription server. For example, let’s imagine a scenario where Andrew subscribes to Linda’s presence.

1. Andrew sends a SUBSCRIBE to the Presence Server. The To header contains Linda’s SIP address, the From header contains Andrew’s SIP address, and the Event header contains “presence.”

2. The Presence Server sends an initial NOTIFY message to Andrew. The To header contains Andrew’s SIP address, the From header contains Linda’s SIP address, and the Event header contains “presence.” The message body will contain Linda’s current presence state. As you saw in my article on SUBSCRIBE, this data is commonly formatted as application/pidf+xml.

3. This brings us to PUBLISH. Let’s say that Linda sets her presence to “busy.” This causes Linda’s SIP client to send a PUBLISH message to the Presence Server. The To header contains Linda’s SIP address, the From header also contains Linda’s SIP address, and the Event header contains “presence.”

You may be wondering why the From header does not contain Andrew’s SIP address. That’s because Linda has no idea that Andrew subscribed to her presence updates. Only the Presence Server knows that.

4. When the Presence Server receives the PUBLISH message, it sends a NOTIFY message to Andrew. It will also send similar NOTIFY messages to every other SIP entity that subscribed to Linda’s presence. This idea of fanning out, or one-to-many, is what makes presence scalable. Imagine how much work would be required if every client had to send its own NOTIFY messages.

To demonstrate a PUBLISH call flow, I started up Avaya Communicator on my PC and used traceSM to capture the SIP messages generated when I set my presence to “busy.”

Publish1

Note the PUBLISH message is sent to the Avaya Session Manager which then sends it to mncopres01aaps. This goofy name is the DNS address of our Avaya Presence Server.

It’s necessary to understand that I did this from home and only had one SIP client to work with. Since my client subscribed to its own presence updates, all NOTIFY messages will reflect me (To header equals 4563516) receiving presence updates about me (From header equals 4563516). If I had the ability to run a second client, the From header would contain a different SIP address.


To understand what is happening with the 407 Proxy Authentication Required response, please see my article, Understanding SIP Authentication.


Expanding the PUBLISH message, we see the following:

Publish3

Things to take note of:

  • The To and From headers are the same. Again, this is because my client subscribed to its own presence updates.
  • The Event header is “presence.”
  • The Content-Type header is application/pidf+xml.
  • The message body is formatted as application/pidf+xml.

At this point, the Avaya Presence Server will send NOTIFY messages to every client subscribed to my presence. Again, there is only one client.

Publish4

Things to take note of:

  • The To and From headers are the same. Again, this is because my client subscribed to its own presence updates.
  • The Event header is “presence.”
  • The Content-Type header is application/pidf+xml.
  • The message body is formatted as application/pidf+xml.

The Avaya Communicator soft client allows me to add notes to my presence status. For grins, I set mine to “Adding a note to my PUBLISH message” and then screen-captured the appropriate part of the PUBLISH message body. Note the “<note>” field.

Publish5

Mischief Managed

This is pretty much all I need to say about PUBLISH. Combined with my article about SIP subscriptions, you should be armed with enough information to call yourself dangerous. Use that power wisely.

Advertisements

5 comments

  1. Hi Andrew,
    Thanks for the great article… Could you please explain about RTP headers in your future article???

      1. Thank you so much for the links… :)…

  2. Absolutely perfect, this is what i was looking for a long time. Thanks much

    1. You’re welcome.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: