Unlike some of the previous optimizations that I have written about, partial notification is not designed for SIP Events in general. Instead, partial notification only works with the Presence event package. The reason for that should become apparent shortly.
In a SIP Presence system that doesn’t support partial notification, each time a presentity changes state, the presence server must send the full presence document to every watcher for that presentity. Given that presence documents can get large and complex, and that a presentity could have a large number of watchers, this can consume a fair amount of bandwidth. This could be particularly troublesome in mobile data networks, where bandwidth is relatively scarce–and potentially expensive to the end user.
With partial notification, rather than sending the entire presence document to each watcher, the presence agent only sends the parts of the presence document that actually changed. RFC 5262 describes a data format for expressing a “patch” or “diff” between two different versions of a presence document. This patch mechanism is specific to PIDF, the data format used to express presence information. (This is the reason that partial notify is specific to the presence event package.)
A user agent advertises support of partial notify by putting the diff format (“application/pidf-diff+xml”) in the Accept header field of a SUBSCRIBE request. Assuming the presence server also supports the partial notify, it can initially invoke the extension by using the pidf-diff format to send the entire presence document, along with a version number. When changes occur to the presence state, the presence server sends just those changes in a new pidf-diff document, along with an incremented version number. The pidf-diff format allows the presence server to include elements to be added to or removed from the presence state, as well as elements to replace existing ones.
When the user agent receives a partial notification, it compares the version number in the notification to the last version number it received. If the new version number is less than or equal to the old number, the user agent assumes an error, and ignores the change. If the new version skips a number since the last version, the user agent assumes it missed an update, and requests a full-state refresh. If the new version is exactly one more than old version, then the user agent applies the changes to its cached version of the presence document.
Like with any optimization, the designers of the partial notification extension made some assumptions. One is that changes to a presence document are usually smaller than the document itself. This a pretty safe assumption in presence systems that generate any but the most trivial presence documents.
They also assumed that the cost of the saved bandwidth between the presence server and the watchers’ user agents would be large compared to the cost of the added complexity at the presence server. This may not always be true, given that determining the difference between two large presence documents is anything but trivial. And if the presence server supports presence rules that can result in sending different presence state to one watcher than to another, for the same presentity, then the effort required to calculate the difference between documents may be multiplied by the number of watchers. This assumption is more likely to be true in mobile data networks (and in all fairness, partial notification was designed for mobile networks), where the cost of bandwidth is usually high compared to wireline services–although this might change with the deployment of 4G mobile data networks.