Presence Server supports the content indirection standard, allowing a SIP message to contain an indirect reference to the desired content. The receiving party then uses this indirect reference to retrieve the content by means of a non-SIP transfer channel such as HTTP. An alternative transport mechanism is provided for SIP body parts.
Content indirection support is defined by IETF RFC 4483 and implemented by the Presence Server product as follows: the subscriber indicates in the SUBSCRIBE request that content indirection should be supported. The Accept header includes the content indirection content type, for example: Accept: message/external-body. As a result, Presence Server marks the subscription to indicate that it supports content indirection.
Note that this mechanism will always generate a unique notification ID for each outgoing notification, even if the notification content has not changed.
The content indirection servlet handles HTTP GET requests for the indirect content. It extracts the content ID from the request and uses it to retrieve the document from the content indirection database. Assuming that the document is found and authorization tests are successful, the response with the full body is sent.
The authorization tests are based on the sender's identity, which is extracted from the HTTP request and translated to a WebSphere® Application Server principal. The WebSphere Application Server principal is compared to the subscriber identity as stored in the database. If the identities are different, the servlet sends a 403 "Forbidden" response. Unauthenticated users are supported for Subscribe requests for Presence Server and for HTTP GET requests. Assuming that the same identity was used for both operations (Subscribe and the HTTP GET), the response with the document is sent back to the sender.
For each incoming subscription, Presence Server stores the accepted types as indicated in the Subscribe request on the SIP application session. In case of failover, the SIP application session is migrated to another server in the cluster, and this information is used to determine whether content indirection support is required for the subscription.
For HTTP GET requests, the content indirection HTTP URL (as specified in the notify request) routes the request by the HTTP proxy. The HTTP proxy address is configurable. When one of the Presence Server instances in the cluster fails, the proxy directs the HTTP request to an active Presence Server instance. Because the indirected information is stored in the database, all servers can handle the HTTP requests.