Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Session Initiation Protocol Extensions is an extension of the original Session Initiation Protocol (SIP), as specified in [RFC3261].
Session Initiation Protocol Extensions defines NTLM/Kerberos authentication extensions to support client/server authentication and message signatures. See NTLM/Kerberos Authentication Extensions Details (section 3.1).
Session Initiation Protocol Extensions also adds a number of extensions to SIMPLE-based presence, as specified in [RFC3261], [RFC3265], and [RFC3863]. These extensions are briefly described below and are defined further in section 3.
Many of the extensions have been designed to reduce the number of subscription and notification messages exchanged between the client and the server. One such extension is the capability to subscribe for the presence of a number of contacts in a single subscription. The client can send a batched SUBSCRIBE request to create such a subscription. The server sends the presence information of all the contacts in the batched subscription in a single NOTIFY request. This is useful when a client needs to subscribe for presence of all the contacts in the user's contact list.
Another extension that helps reduce the number of messages between the server and client is the piggyback notification. The server can send the presence information immediately in the final response to the SUBSCRIBE request, thus obviating the need to send a separate NOTIFY. Any further changes are conveyed using a NOTIFY.
A BENOTIFY request is similar to a NOTIFY request and is used by the server to send updates about any changes to the presence state. The only difference is that the client does not need to send a SIP response to a BENOTIFY request. Because the server does not need to wait for a response, the load on the server can be reduced.
Auto-Extension of subscriptions is an extension defined to reduce the frequency of the client refreshing a subscription. The client refreshes a subscription after an interval negotiated with the server. With this extension, any notification sent by the server to the client resets the subscription refresh timer. After a notification, the client needs to wait for the negotiated interval before it can refresh the subscription. Another notification during this time can again reset the timer. This extension reduces the number of SUBSCRIBE requests sent by the client to refresh a subscription.
Microsoft also has made extensions to the Presence Information Data Format (PIDF). The enhanced format is called msrtc.pidf and is documented in text/xml+msrtc.pidf Presence Document Format (section 2.2.1). The msrtc.pidf format is used only in the client/server mode. The client uses a setPresence SOAP request carried in the body of a SERVICE request to set or update its own presence information. For more information on the SOAP protocol, see [SOAP1.1], [SOAP1.2-1/2007], and [SOAP1.2-2/2007]. The counterpart to the setPresence SOAP request is a getPresence SOAP request. This acts as a means to poll for presence rather than subscribing to presence. It is meant as a lightweight alternative to a presence SUBSCRIBE request when only presence for a single entity is needed and only that presence information for a one-time immediate purpose is needed.
Session Initiation Protocol Extensions uses the XPIDF format to exchange presence information when the endpoints are acting in peer-to-peer (P2P) mode. The XPIDF format was introduced in an IETF draft but was never standardized as an RFC. The details of the format and the schema are included in Appendix B: XPIDF Presence Document Format (section 7). Session Initiation Protocol Extensions also has made some extensions to the XPIDF format (see section 2.2.2).
Finally, Session Initiation Protocol Extensions includes protocol enhancements for contact management operations such as adding or deleting a contact or a group, and setting access control lists (ACLs) for viewing and establishing communication with a presence. All of these operations can be done by sending SOAP requests carried within the body of a SERVICE request.