3.3.4.1 Sending a Batched SUBSCRIBE Request
The client can subscribe to presence information of a list of contacts by sending a batched SUBSCRIBE request to the server. This is typically done after the client has logged in to the server by sending a REGISTER request. The batched SUBSCRIBE request is a SUBSCRIBE request with the body of the request containing the contact URIs of interest. A typical batched SUBSCRIBE is constructed similar to the following example.
-
SUBSCRIBE sip:watcher@tradewind.com SIP/2.0 Via: SIP/2.0/TLS 157.56.65.142:3485 Max-Forwards: 70 From: "Bob" <sip:watcher@tradewind.com>; tag=4dcbf313b0ee4d;epid=a892397901 To: <sip:watcher@tradewind.com> Call-ID: dba8c92428b241ccb233e5d1a59135e2 CSeq: 1 SUBSCRIBE Contact: <sip:watcher@tradewind.com:3485; maddr=157.56.65.142; transport="tls">; proxy=replace User-Agent: RTC/1.3 Event: presence Accept: application/rlmi+xml, text/xml+msrtc.pidf, multipart/related Supported: com.microsoft.autoextend Supported: ms-benotify Proxy-Require: ms-benotify Supported: ms-piggyback-first-notify Require: adhoclist Supported: eventlist Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="bfaf9a7c", crand="8c93c137", cnum="5", targetname="tradewind.com", response="0100000066333133cfcfdde1d2994f63" Content-Type: application/adrl+xml Content-Length: … <adhoclist uri="sip:watcher@tradewind.com" name="sip:watcher@tradewind.com"> <create> <resource uri="sip:contact1@tradwind.com"/> <resource uri="sip:contact2@tradwind.com"/> <resource uri="sip:contact3@tradwind.com"/> <resource uri="sip:contact4@tradwind.com"/> <resource </create> </adhoclist>
Refer to the adhoclist node in the preceding example. The Supported, Require, and Proxy-Require headers indicate support for a variety of presence extensions that are described in the following sections. The Accept header indicates that the client is capable of receiving (in response to the SUBSCRIBE) a multipart MIME (for more information, see [RFC1341]) specification that contains a list of users (application/rlmi+xml) and their associated Presence Documents (text/xml+msrtc.pidf).
The Require: adhoclist and Supported: eventlist headers indicate support specifically for the batched SUBSCRIBE mechanism (both are needed to enable this feature).
The Content-Type (application/adrl+xml) indicates that this SUBSCRIBE request carries an XML body that contains the list of contacts of interest.
Note that the Request-URI as well as the To and From headers all carry the SIP URI of the watcher.
The content of the SUBSCRIBE request itself is straightforward. It is described by the following XML schema. The schema allows the client to define a list as well as modify an existing list established by a previous SUBSCRIBE request in the same SIP dialog. The list is flat, containing one entry per contact that the watcher receives presence updates for. The size of the list SHOULD be bounded by the maximum number of contacts per user setting on the server. The server can limit the maximum number of contacts that a user can have. The implementation SHOULD permit an administrator to configure this limit based on the needs of the users in a deployment, by some means outside of this specification. A reasonable value for this limit is between a range of 100 and 250. The server SHOULD reject any batched SUBSCRIBE request that contains more contacts than this limit.
-
<?xml version="1.0" ?> <xs:schema id="batch subscribe" version="2.0" elementFormDefault="qualified" targetNamespace="urn:ietf:params:xml:ns:adrl" xmlns:tns="urn:ietf:params:xml:ns:adrl" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ct="http://schemas.microsoft.com/sip/types"> <xs:annotation> <xs:documentation> Live Communications Server 2005 supports an extension to the SIP SUBSCRIBE request to allow subscribing to the presence of multiple users at the same time. This is called the Batch Subscribe request. The body of the Batch Subscribe request conforms to the schema specified here. Note that this schema is different from the adhoclist schema specified in the internet draft. </xs:documentation> </xs:annotation> <xs:import namespace="http://schemas.microsoft.com/sip/types" schemaLocation="common.xsd" /> <xs:complexType name="resource"> <xs:attribute name="uri" type="ct:sipURI" use="required" /> <xs:anyAttribute namespace="##any" processContents="lax" /> </xs:complexType> <xs:complexType name="roster"> <xs:sequence> <xs:element name="resource" type="tns:resource" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax" /> </xs:complexType> <xs:complexType name="adhoclist"> <xs:sequence> <xs:choice> <xs:annotation> <xs:documentation> A Batch Subscribe request can specify one of three operations: create, add or delete. - A create operation creates a new batch subscription on the server - An add operation adds entries to an existing batch subscription - A delete operation deletes entries from a batch subsription Entries in a batch subscription consist of SIP URIs of users to whom presence subscriptions are created. </xs:documentation> </xs:annotation> <xs:element name="create" type="tns:roster" /> <xs:element name="add" type="tns:roster" /> <xs:element name="delete" type="tns:roster" /> </xs:choice> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="uri" type="ct:sipURI" use="required" /> <xs:anyAttribute namespace="##any" processContents="lax" /> </xs:complexType> <xs:element name="adhoclist" type="tns:adhoclist" /> </xs:schema>