3.2 Presence Extensions Details

Session Initiation Protocol Extensions introduces several extensions to enhance presence. These include the new Presence Document Format, msrtc.pidf (see text/xml+msrtc.pidf Presence Document Format (section 2.2.1), SIP Extensions to XPIDF Presence Document Format (section 2.2.2), a new SIP method, SERVICE, to set and get presence information, and the setPresence and getPresence SOAP requests.

SIP allows SIP endpoints to communicate in a P2P mode without requiring a SIP server. The endpoints can also subscribe for presence information and send notifications carrying such information in a P2P manner. Session Initiation Protocol (SIP) extensions use the XPIDF format to exchange presence information when the endpoints are acting in P2P mode. The msrtc.pidf format is used in the client/server mode.

The client can publish its presence to the server by sending a setPresence SOAP request inside the body of a SERVICE method. The client can use the setPresence request only to set the logged in user's presence. A user cannot publish presence on behalf of another user. The server sends a 200 OK SIP response to indicate that the setPresence request was successful.

There are two ways for the client to obtain another user's presence information. If the client just needs a one-time snapshot of the presence information, it SHOULD send a getPresence SOAP request to the server to do so. This can be useful for web pages that need to show the presence state of a user on a transient basis. The advantage of using a getPresence request is that it does not consume a lot of resources on the server.

If the client wants to continue getting updates when the presence information changes, it SHOULD subscribe for it by sending a SUBSCRIBE request to the server. The SUBSCRIBE request creates a dialog, and as long as the dialog is kept alive, the server MUST send presence updates in NOTIFY or BENOTIFY requests. This mode of operation can be useful for getting presence information of the users in the client's contact list.

In the P2P mode, no server is used to exchange presence information, and clients can directly create subscriptions between themselves. The setPresence and getPresence requests are not valid in P2P mode. The client can send a SUBSCRIBE request to the user it wants to subscribe to create a subscription. The other client can send NOTIFY with Presence Documents in XPIDF format to send initial presence information and any updates.

SIP Proxies and Registrars send an immediate 200 response status code to any SUBSCRIBE messages before forwarding the message, and don't forward responses to any SUBSCRIBE messages. The 200 status code MUST only indicate successful receipt of the request, instead of acceptance of the subscription. The response MUST be sent immediately to ensure that no state information about a SIP client can be derived from any delays in the process. A SUBSCRIBE request SHOULD then be sent to the requested client for processing.

If a SIP client is offline, the SIP Proxy or Registrar MUST immediately send a 200 status code in response and queue the SUBSCRIBE request for a suitable time-out period. A recommended value of this time-out is 180 seconds. Further SUBSCRIBE requests SHOULD update the time-out value. If the end node comes online before the time-out period expires, then the SUBSCRIBE request is forwarded to it.

A SIP Proxy or Registrar must never send a 600 status code in response to a SUBSCRIBE request.

When a SIP client receives a SUBSCRIBE request, it MUST immediately respond with a 200 status code that only indicates successful receipt of the request, not any presence information. If the request is accepted, then a NOTIFY transaction is created and sent. Otherwise, no message is sent in response.

These extensions are optional. An implementation may support them.