Hi Henning, according to 3GPP TS 24.229 wathcer have following functionality . 1 -Subscription for presence information state changes and notification acceptance When the watcher intends to subscribe for presence information state changes of a presentity, it shall generate a SUBSCRIBE request in accordance with RFC 3265 [19] and RFC 3856 [27]. The watcher shall implement the "application/pidf+xml" content type as described in RFC 3863 [21] , the PIDF extensions defined in RFC 4480 [26]. The watcher may implement the PIDF extensions defined in RFC 4482 [32]. The watcher may implement location information according to the format defined in RFC 4119 [37]. The watcher shall implement draft-ietf-simple-prescaps-ext [25] if it wants to make use of SIP user agent capabilities extensions included in the presence document. The extension may be used by the watcher for interpreting the type of the service described by the presence tuple. The watcher may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661 [30] and RFC 4660 [31]. The watcher may indicate its support for partial notification using the Accept header field in accordance with draft-ietf-simple-partial-notify [24]. The watcher shall interpret the received presence information according to RFC 4479 [44] and the following: a) a <person> element as defined in RFC 4479 [44] means information about the presentity; b) a tuple including a <relationship> element defined in RFC 4480 [26] means information about an alternate contact to the presentity; c) a tuple contains communication means specific information. The communication means described by the tuple is deduced from the URI scheme of the contact address information present in the <contact> element as defined in RFC 3863 [21]. If the URI scheme of the contact address information provides ambiguous information about the communication means, the watcher shall further examine other elements of the tuple to decide the communication mean. Such elements can be the <methods> element, any of the different media type specific elements as defined in draft-ietf-simple-prescaps-ext [25]. d) a <device> element as defined in RFC 4479 [44] means information about a device. Additional extensions can be used to express application specific attributes, but their usage is outside the scope of this version of the specification. 2 Subscription for presence information state changes of presentity collections When the watcher intends to subscribe for presence information state changes of a presentity collection, it shall generate a SUBSCRIBE request in accordance with RFC 4662 [22], additionally to the procedures described in subclause 5.3.2.2. 3 Subscription for the watcher information event template package Upon activation of the presence service, the watcher may subscribe recursively for the watcher information state changes in accordance with RFC 3857 [28] and RFC 3858 [29]. The watcher may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661 [30] and RFC 4660 [31]. 4 Subscription for notification of state changes in XML document In order to get notifications of changes to XML documents manipulated via the Ut reference point the watcher may generate a SUBSCRIBE request in accordance with draft-ietf-simple-xcap-diff [39] and draft-ietf-sipping-config-framework [43]. Thanks ~Suresh ----- Original Message ----- From: "Henning Westerholt" &lt;henning.westerholt(a)1und1.de&gt; To: &lt;users(a)lists.openser.org&gt; Cc: "sureshkumar.jaiswal" &lt;suresh.jaiswal(a)info-spectrum.com&gt; Sent: Monday, July 07, 2008 5:28 PM Subject: Re: [OpenSER-Users] Regarding Wathcer Application