SIST ES 202 504-14 V1.1.1:2008

• Abstract:

  New edition of ParlayX specification based on requirements in EG 201 988-4, corresponding to 3GPP TS 29.199 Rel-7.The present document is part 14 of the Stage 3 Parlay X 3 Web Services specification for Open Service Access (OSA).; The OSA specifications define an architecture that enables application developers to make use of network functionality through an open standardized interface, i.e. the OSA APIs.; The present document specifies the Presence Web Service. The following are defined here:; • Name spaces.; • Sequence diagrams.; • Data definitions.; • Interface specification plus detailed method descriptions.; • Fault definitions.; • Service Policies.; • WSDL Description of the interfaces.

• Status: Published
• Publication Date: 02-Jul-2008
• ICS: 35.100.01 - Open systems interconnection in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 12-Jun-2008
• Due Date: 17-Aug-2008
• Completion Date: 03-Jul-2008
• Ref Project: ETSI ES 202 504-14 V1.1.1 (2008-05) - Open Service Access (OSA); Parlay X Web Services; Part 14: Presence (Parlay X 3)

SIST ES 202 504-14 V1.1.1:2008 is the ETSI standard for Open Service Access (OSA) Parlay X Web Services, Part 14: Presence (Parlay X 3). It specifies the Presence Web Service, which exposes presence information and subscription management through standardized application programming interfaces (APIs). It is meant for watcher and presentity applications, including instant messaging and other service applications that need to publish, query, subscribe to, or receive presence updates.

What does SIST ES 202 504-14 V1.1.1:2008 specify?

SIST ES 202 504-14 V1.1.1:2008 specifies the Presence Web Service as part 14 of the Stage 3 Parlay X 3 Web Services specification for OSA. In practice, it defines how a service platform models presence data, how a watcher requests access, how a presentity publishes data, and how notifications are exchanged.

The document is organized into clauses for scope, references, definitions and abbreviations, detailed service description, namespaces, sequence diagrams, XML Schema data type definitions, web service interface definitions, fault definitions, and service policies. Annex A gives the normative WSDL for the Presence service, and Annex B provides the bibliography.

Annex	What it covers
Annex A	Normative WSDL for Presence
Annex B	Informative bibliography

The scope also makes clear that the service/protocol for managing presence policies is out of scope. That matters because the standard defines how clients use presence data, but not the separate policy-management system behind those decisions.

What are the key requirements of SIST ES 202 504-14 V1.1.1:2008?

The service model centers on watcher and presentity roles

Clause 4 describes the service as a way to obtain presence information about one or more users and to register presence for those same users. A typical client is either a supplier or consumer of presence information, and the document uses watcher and presentity as the two roles on the client side.

This matters in implementation because the same application may need to act as a presence consumer, a presence supplier, or both. The document also shows two deployment paths: through Parlay/OSA PAM, or directly toward IMS presence network elements using ISC and SIP/SIMPLE.

Presence data is typed and structured

Clause 7 defines the data model around PresenceAttribute and PresenceAttributeType. The main attribute families are Activity, PlaceType, Privacy, Sphere, Communication, Mood, PlaceIs, TimeOffset, StatusIcon, and Other.

For a developer or integrator, this means presence data is not free text. Each published item has to fit one of the defined structures, which makes filtering, display, and policy decisions predictable. The service also defines supporting structures such as CommunicationValue, PrivacyValue, PlaceIsValue, TimeOffsetValue, StatusIconValue, Watcher, and SubscriptionRequest.

Watchers subscribe before they read presence data

Clause 8.1 defines the watcher-side interface, PresenceConsumer. The main flow is subscribePresence to request access, getUserPresence to read authorized presence data, startPresenceNotification to turn on event delivery, and endPresenceNotification to stop it.

This is important in practice because access is not automatic. The watcher first asks for authorization, and only after approval can it poll or receive notifications. The subscription request can target one presentity or a group, and the request can cover selected attribute types or all types.

Notifications are asynchronous and correlated

Clause 8.2 defines the callback interface, PresenceNotification. statusChanged carries changed attributes, statusEnd tells the watcher that a notification run has completed, notifySubscription reports the authorization decision, and subscriptionEnded reports that access has been terminated.

This matters because a watcher application must handle delayed responses and asynchronous state changes. The service uses correlators for the notification path, so implementations must keep track of which notification request each callback belongs to.

Presentities control access and publishing

Clause 8.3 defines PresenceSupplier, the interface used by the presentity side. The key operations are publish, getOpenSubscriptions, updateSubscriptionAuthorization, getMyWatchers, getSubscribedAttributes, and blockSubscription.

In practice, this is where presence data is published and where access is approved, blocked, or filtered. The politeBlock option is significant because it lets the presentity block a watcher without revealing that the watcher has been blocked, while still allowing the service to decide what presence information, if any, should be shown.

Service policies constrain notification and group behavior

Clause 10 lists service policies that control notification frequency, notification duration, default duration, maximum count, whether unlimited count is allowed, group support, nested group support, and the maximum number of identifiers in a request.

These policies matter because they define what an implementation may accept. A client can request notifications for many users or groups, but the service may reject requests that exceed the configured limits or violate group rules.

Fault handling is part of the interface contract

Clause 9 defines the Presence-specific ServiceException values SVC0220 and SVC0221. SVC0220 covers the case where there is no pending subscription request, and SVC0221 covers the case where a URI is not a watcher.

This is useful for integration and testing because it tells implementers which Presence-specific errors they must recognize and handle. The interface descriptions also reference common service and policy faults from ES 202 504-1.

What terms does SIST ES 202 504-14 V1.1.1:2008 define?

• Watcher - The client role that requests access to another party’s presence information and may receive it by polling or notification.
• Presentity - The user, group, or organization whose presence is published and managed by the service.
• Presence information - The set of attributes that describe the presentity, such as activity, environment, communication means, and contact addresses.
• Presence attributes - Named pieces of presence information, each with a type and a value, that watchers can subscribe to after authorization.
• Subscription - The access relationship that must be established before a watcher can see presence data.
• Open Service Access (OSA) - The architecture used to expose network functionality through standardized APIs.
• Session Initiation Protocol (SIP) - The protocol family referenced by the service model for presence event handling and notification behavior.

Who uses SIST ES 202 504-14 V1.1.1:2008?

SIST ES 202 504-14 V1.1.1:2008 is used by application developers, service platform architects, and telecom integrators who need a standardized presence interface. It is relevant for instant messaging, push-to-talk, call control, and similar applications that consume or publish presence data.

It also matters to operators and suppliers of presence-capable platforms because it defines how watcher authorization, subscription management, and callbacks are handled. Teams testing presence services use it to validate request and response messages, WSDL bindings, fault handling, and policy behavior.

Which standards are used with SIST ES 202 504-14 V1.1.1:2008?

• ETSI ES 202 504-1 - Supplies the common Parlay X 3 definitions and shared interface conventions used by this part.
• ETSI TR 121 905 - Provides the 3GPP vocabulary used for terms that appear in the standard.
• W3C Recommendation: XML Schema Part 2: Datatypes - Provides the XML Schema datatypes used in the schema definitions.
• ETSI ES 202 915-14 - Gives the related Parlay/OSA Presence and Availability Management SCF model.
• IETF RFC 3856 - Defines the SIP presence event package that this service aligns with.
• IETF RFC 3265 - Defines SIP-specific event notification, which supports the notification model.
• ETSI ES 202 504-13 - Provides Address List Management, used when presence is handled for groups.
• ETSI ES 202 504-8 - Provides Terminal Status, whose information can overlap with presence data.
• ETSI ES 202 504-9 - Provides Terminal Location, another related source of user status information.

The foreword also states that this standard is equivalent to 3GPP TS 29.199-14 V7.4.0 (Release 7).

What does the SIST ES 202 504-14 V1.1.1:2008 document contain?

The document contains a detailed service description, a sequence diagram showing watcher and presentity message flow, and a large XML Schema section that defines presence-related enumerations and structures. It also contains interface definitions for PresenceConsumer, PresenceNotification, PresenceSupplier, PresenceSupplierNotificationManager, and PresenceSupplierNotification.

For implementation work, the most useful parts are the request and response message descriptions, the referenced faults for each operation, and the service policy table. Annex A then gives the document/literal WSDL files needed for system integration and service binding.

Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 14: Presence
(Parlay X 3)
�
2 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)

Reference
DES/TISPAN-01034-14-OSA
Keywords
API, OSA, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.8
2 References.8
2.1 Normative references.8
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations.10
4 Detailed service description .10
5 Namespaces.11
6 Sequence diagrams.12
6.1 Interface flow overview.12
7 XML Schema data type definition .13
7.1 PresenceAttributeType enumeration.13
7.2 ActivityValue enumeration.13
7.3 PlaceTypeValue enumeration.14
7.4 PrivacyType enumeration.15
7.5 SphereValue enumeration.15
7.6 CommunicationMeansType enumeration.15
7.7 CommunicationMeans structure.15
7.8 CommunicationValue structure.16
7.9 OtherValue structure.16
7.10 PresenceAttribute structure.16
7.10a AttributeTypeAndValue union.16
7.11 SubscriptionRequest structure.16
7.12 PresencePermission structure.17
7.13 CommunicationStatusType enumeration.17
7.14 PrivacyValue structure.17
7.15 MoodValue enumeration.17
7.16 PlaceIsValue structure.18
7.17 PlaceIsAudioValue enumeration.19
7.18 PlaceIsVideoValue enumeration.19
7.19 PlaceIsTextValue enumeration.19
7.20 RelationshipValue enumeration.19
7.21 TimeOffsetValue structure.20
7.22 StatusIconValue structure.20
7.23 Watcher structure.20
7.24 WatcherSubscriptionStatus enumeration.20
8 Web Service interface definition.20
8.1 Interface: PresenceConsumer.20
8.1.1 Operation: subscribePresence.21
8.1.1.1 Input message: subscribePresenceRequest.21
8.1.1.2 Output message: subscribePresenceResponse.21
8.1.1.3 Referenced faults.21
8.1.2 Operation: getUserPresence.22
8.1.2.1 Input message: getUserPresenceRequest .22
8.1.2.2 Output message: getUserPresenceResponse.22
8.1.2.3 Referenced faults.22
8.1.3 Operation: startPresenceNotification.22
8.1.3.1 Input message: startPresenceNotificationRequest.23
8.1.3.2 Output message: startPresenceNotificationResponse.23
ETSI
4 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
8.1.3.3 Referenced faults.23
8.1.4 Operation: endPresenceNotification.24
8.1.4.1 Input message: endPresenceNotificationRequest.24
8.1.4.2 Output message: endPresenceNotificationResponse.24
8.1.4.3 Referenced faults.24
8.2 Interface: PresenceNotification.24
8.2.1 Operation: statusChanged.24
8.2.1.1 Input message: statusChangedRequest.24
8.2.1.2 Output message: statusChangedResponse.25
8.2.1.3 Referenced faults.25
8.2.2 Operation: statusEnd.25
8.2.2.1 Input message: statusEndRequest .25
8.2.2.2 Output message: statusEndResponse.25
8.2.2.3 Referenced faults.25
8.2.3 Operation: notifySubscription.25
8.2.3.1 Input message: notifySubscriptionRequest .25
8.2.3.2 Output message: notifySubscriptionResponse .25
8.2.3.3 Referenced faults.25
8.2.4 Operation: subscriptionEnded.26
8.2.4.1 Input message: subscriptionEndedRequest .26
8.2.4.2 Output message: subscriptionEndedResponse.26
8.2.4.3 Referenced faults.26
8.3 Interface: PresenceSupplier.26
8.3.1 Operation: publish.26
8.3.1.1 Input message: publishRequest.26
8.3.1.2 Output message: publishResponse.26
8.3.1.3 Referenced faults.27
8.3.2 Operation: getOpenSubscriptions.27
8.3.2.1 Input message: getOpenSubscriptionsRequest.27
8.3.2.2 Output message: getOpenSubscriptionsResponse.27
8.3.2.3 Referenced faults.27
8.3.3 Operation: updateSubscriptionAuthorization.27
8.3.3.1 Input message: updateSubscriptionAuthorizationRequest .28
8.3.3.2 Output message: updateSubscriptionAuthorizationResponse .28
8.3.3.3 Referenced faults.28
8.3.4 Operation: getMyWatchers.28
8.3.4.1 Input message: getMyWatchersRequest .29
8.3.4.2 Output message: getMyWatchersResponse.29
8.3.4.3 Referenced faults.29
8.3.5 Operation: getSubscribedAttributes.29
8.3.5.1 Input message: getSubscribedAttributesRequest .29
8.3.5.2 Output message: getSubscribedAttributesResponse .29
8.3.5.3 Referenced faults.29
8.3.6 Operation: blockSubscription.30
8.3.6.1 Input message: blockSubscriptionRequest.30
8.3.6.2 Output message: blockSubscriptionResponse.30
8.3.6.3 Referenced faults.30
8.4 Interface: PresenceSupplierNotificationManager.30
8.4.1 Operation: startSubscriptionNotification .30
8.4.1.1 Input message: startSubscriptionNotificationRequest.31
8.4.1.2 Output message: startSubscriptionNotificationResponse.31
8.4.1.3 Referenced Faults.31
8.4.2 Operation: endNotification.31
8.4.2.1 Input message: endNotificationRequest.31
8.4.2.2 Output message: endNotificationResponse.32
8.4.2.3 Referenced Faults.32
8.5 Interface: PresenceSupplierNotification.32
8.5.1 Operation: notifyOpenSubscription.32
8.5.1.1 Input message: notifyOpenSubscriptionRequest.32
8.5.1.2 Output message: notifyOpenSubscriptionResponse.32
8.5.1.3 Referenced faults.32
8.5.2 Operation: notifyError.32
ETSI
5 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
8.5.2.1 Input message: notifyErrorRequest.32
8.5.2.2 Output message: notifyErrorResponse.33
8.5.2.3 Referenced faults.33
8.5.3 Operation: notifyEnd.33
8.5.3.1 Input message: notifyEndRequest.33
8.5.3.2 Output message: notifyEndResponse.33
8.5.3.3 Referenced faults.33
9 Fault definitions.33
9.1 ServiceException.33
9.1.1 SVC0220: No subscription request.33
9.1.2 SVC0221: Not a watcher .33
10 Service policies .34
Annex A (normative): WSDL for Presence .35
Annex B (informative): Bibliography.36
History .37

ETSI
6 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN), and is now submitted for the ETSI standards
Membership Approval Procedure.
The present document is part 14 of a multi-part deliverable covering Open Service Access (OSA); Parlay X 3 Web
Services, as identified below:
Part 1: "Common";
Part 2: "Third Party Call";
Part 3: "Call Notification";
Part 4: "Short Messaging";
Part 5: "Multimedia Messaging";
Part 6: "Payment";
Part 7: "Account Management";
Part 8: "Terminal Status";
Part 9: "Terminal Location";
Part 10: "Call Handling";
Part 11: "Audio Call";
Part 12: "Multimedia Conference";
Part 13: "Address List Management";
Part 14: "Presence";
Part 15: "Message Broadcast";
Part 16: "Geocoding";
Part 17: "Application-driven Quality of Service (QoS)";
Part 18: "Device Capabilities and Configuration";
Part 19: "Multimedia Streaming Control";
Part 20: "Multimedia Multicast Session Management".
ETSI
7 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP.
The present document forms part of the Parlay X 3.0 set of specifications.
The present document is equivalent to 3GPP TS 29.199-14 V7.4.0 (Release 7).
ETSI
8 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
1 Scope
The present document is part 14 of the Stage 3 Parlay X 3 Web Services specification for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardized interface, i.e. the OSA APIs.
The present document specifies the Presence Web Service. The following are defined here:
• Name spaces.
• Sequence diagrams.
• Data definitions.
• Interface specification plus detailed method descriptions.
• Fault definitions.
• Service Policies.
• WSDL Description of the interfaces.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)".
ETSI
9 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
[2] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
[3] ETSI ES 202 504-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 3)".
[4] ETSI ES 202 915-14: "Open Service Access (OSA); Application Programming Interface (API);
Part 14: Presence and Availability Management SCF (Parlay 4)".
[5] IETF RFC 3856: "A Presence Event Package for the Session Initiation Protocol (SIP)".
http://www.ietf.org/rfc/rfc3856.txt.
[6] Void.
[7] ETSI ES 202 504-13: "Open Service Access (OSA); Parlay X Web Services; Part 13: Address List
Management (Parlay X 3)".
[8] IETF RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification".
[9] Void.
[10] ETSI ES 202 504-8: "Open Service Access (OSA); Parlay X Web Services; Part 8: Terminal
Status (Parlay X 3)".
[11] ETSI ES 202 504-9: "Open Service Access (OSA); Parlay X Web Services; Part 9: Terminal
Location (Parlay X 3)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 504-1 [3] and the following apply:
applications: For Instant Messaging, Push to Talk, or call control and other purposes may become clients of the
presence Web Service. We assume that these applications belong to a watcher and authenticate to the services in the
name of the watcher.
identity: represents a user in the real world
NOTE: See Parlay/OSA PAM identities [4], clause 4.4.1.
presence attributes: Contain information about a presentity. An attribute has a name and a value and can be supplied
by any device, application or network module that can be associated to the presentity's identity. A watcher can obtains
attributes only after he has successfully subscribed to them. Examples for attributes are activity, location type,
communication means, etc.
presence information: Consists of a set of attributes that characterize the presentity such as current activity,
environment, communication means and contact addresses. Only the system and the presentity have direct access to this
information, which may be collected and aggregated from several devices associated to the presentity.
subscription: Before a watcher can access presence data, he has to subscribe to it. One possibility the API provides is
an end-to-end subscription concept, in which only identities that have accepted a subscription to their presence can be
addressed. Subscriptions can be also automatically handled by server policies edited by the presentity or other
authorized users. The service/protocol to manage those policies is out of the scope of the present document.
NOTE: This definition is not related to the term "subscription" in TR 121 905 [1].
watcher and presentity: We use these names to denote the role of the client connected to the presence services.
As in Parlay/OSA PAM [4] the watcher and the presentity have to be associated to identities registered to the system,
i.e. users, groups of users or organizations.
ETSI
10 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 202 504-1 [3] and the following apply:
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
ISC IP multimedia subsystem Service Control interface
MMS Multimedia Message Service
PAM Presence and Availability Management
SCF Service Capability Feature
SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions
SIP Session Initiation Protocol
SMS Short Message Service
XCAP XML Configuration Access Protocol
XML eXtensible Markup Language
XMPP eXtensible Messaging and Presence Protocol
XSD XML Schema Definition
4 Detailed service description
The presence service allows for presence information to be obtained about one or more users and to register presence
for the same. It is assumed that the typical client of these interfaces is either a supplier or a consumer of the presence
information. An Instant Messaging application is a canonical example of such a client of this interface.
Figure 1 shows the architecture of the Presence Web Service and the underlying services. The Parlay/OSA PAM SCF is
the straightforward option and implements the presence server with extended identity, device capability, and presence
agent management. Parlay/OSA PAM allows aggregation of presence information from internet, mobile and enterprise
users, etc. using a presence transport network of SIP or XMPP servers. The Presence Web Service can however
communicate directly for example with IMS presence network elements (presence and resource list servers) using the
ISC (SIP/SIMPLE) protocol interface.

watcher
client
presentity
watcher
client
application
Parlay X API
Parlay X Address List
Management Web Parlay X Presence Web Service
Service
Parlay/OSA API
Policy
Parlay/OSA PAM
Network protocols
rules SCF
(e.g. SIP)
Network elements
(e.g. SIP)
Figure 1: The Presence web service environment
ETSI
11 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
Relationship to Similar or Supplanted Specifications
The most important relations are to:
• Parlay X 3 Terminal Status Web Service [10] and Parlay X 3 Terminal Location Web Service [11]: Both
services deal with information that could be considered part of the user's presence information.
Communication abilities can be derived from terminal status information, and the user's placetype can be
derived from his location.
• Parlay/OSA PAM [4]: The Parlay/OSA Presence and Availability specification can be considered the big
brother of the present document. While Parlay X 3 Presence stays behind Parlay/OSA PAM in terms of
flexibility and power - especially concerning attributes and management interfaces - it also extends PAM by
introducing end-to-end authorization. The present document aims to be mappable to Parlay/OSA PAM.
• SIP SIMPLE [5]: The present document aims to be mappable to the SIP/SIMPLE architecture.
• XMPP (Jabber) (see bibliography): Many principles of XMPP have been adopted, especially the end-to-end
authorization.
• IETF Rich Presence(see bibliography). The set of attributes the present document specifies is closely aligned
with the IETF's Rich Presence ideas.
• Group Management [7]: Presence of groups is supported by the present document, however their creation and
manipulation has to be done using the Parlay X 3 Address List Management Web Service. In the 3GPP
presence context, contact lists and group manipulation is done with the XCAP protocol (see bibliography).
5 Namespaces
The PresenceConsumer interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/consumer/v3_2
The PresenceNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/notification/v3_2
The PresenceSupplier interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/supplier/v3_2
The PresenceSupplierNotificationManager interfaces use the namespace:
http://www.csapi.org/wsdl/parlayx/presence_supplier/notification_manager/v3_0
The PresenceSupplierNotification interfaces use the namespace:
http://www.csapi.org/wsdl/parlayx/presence_supplier/notification/v3_0
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/presence/v3_2
The 'xsd' namespace is used in the present document to refer to the XML Schema data types defined in
XML Schema [2]. The use of the name 'xsd' is not semantically significant.
ETSI
12 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
6 Sequence diagrams
6.1 Interface flow overview
The sequence diagram shows the interactions in case both watcher application and presentity are Web Service clients.
Compared to the SIP interactions, the subscription notification is separated from the delivery of presence information
itself. Based on the subscription result, the watcher can select the polling or notification mode for presence events.
Changes in the authorization of presence attributes are propagated to the watchers via the notifySubscription()
operation, the blocking of a subscription by the presentity is propagated via a subscriptionEnded operation.
The sequence diagram does not show the internal communication within the presence server. It is assumed that the
Presence Consumer and Supplier interfaces are implemented by the same instance. If an implementer of the API find
other solutions preferable, he has to take care of the internal communication himself.
Watcher Application : Presence Web Service : Presence Web Service :
Presentity Application
PresenceConsumerNotifications PresenceConsumer PresenceSupplier
:
subscribePresence
check subscription policies
after a while the
user logs on
notifySubscription
getOpenSubscriptions
if there is a policy for this
get user answer
subscription request, no
interaction with the
presentity is necessary.
updateSubscriptionAuthorization
notifySubscription
publish
the watcher can access
presence data by polling.
getUserPresence
determine presence
... or through notifications
user status changes (for
whatever reason)
startPresenceNotification
publish
statusChanged
endPresenceNotification
subscription timeout
subscriptionEnded
getMyWatchers
a subscription can either
time out; or the presentity
can cancel it
getSubscribedAttributes
blockSubscription
subscriptionEnded
Figure 2: Message interaction overview
ETSI
13 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
7 XML Schema data type definition
Presence attributes are inspired by the IETF's Rich Presence ideas (see Bibliography).
7.1 PresenceAttributeType enumeration
The different types of attributes. For each entry in this enumeration there is a separate value type.
Enumeration value Description
Activity The presentity's activity (available, busy, lunch, etc.)
PlaceType At what kind of place the presentity is (home, office, etc.)
Privacy The amount of privacy the user wants (public, quiet, etc.)
Sphere The user's current environment (work, home)
Communication The user's means of communication (phone, mail, etc.)
Mood The user’s mood (angry, confused, happy, etc.)
PlaceIs Describes the properties of the place the user is currently at.
TimeOffset Describes the number of minutes of offset from UTC that the user is currently at.
StatusIcon Depicts the current status of the user.
Other A name - value pair for arbitrary presence information

7.2 ActivityValue enumeration
This enumeration shows the user's current activity. If the activity is unknown, the attribute value will be ActivityNone,
meaning the attribute was not set. If the user is doing something not in this list, the value will be set to ActivityOther.
Enumeration value Description
ActivityNone Not set.
Appointment The user has an appointment.
Available The user is available for communication.
Busy The user is busy and is only available for urgent matters.
DoNotDisturb The user is very busy and does not wish to be disturbed.
OnThePhone The user is on the phone.
Steering The user is driving a car / train / airplane, etc.
Meeting The user is in a meeting.
Away No idea what the user is doing, but he is away.
Meal The user is eating.
Breakfast The user is having breakfast.
Lunch The user is having lunch.
Dinner The user is having dinner.
PermanentAbsence The user is away and will not return for an extended period.
Vacation The user is on vacation.
Holiday A scheduled national or local holiday.
Performance The user is in a theatre / concert.
InTransit The user is in the transit area of an (air)port.
Travel The user is travelling.
Sleeping The user is sleeping.
LookingForWork The user is looking for (paid) work.
Playing The user is occupying him- or herself in amusement, sport, or other recreation.
Presentation The user is giving a presentation, lecture, or participating in a formal round-table
discussion.
Shopping The user is visiting stores in search of goods or services.
Spectator The user is observing an event, such as a sports event.
TV The user is watching television.
Working The user is engaged in, typically paid, labor, as part of a profession or job.
Worship The user is participating in religious rites.
ActivityOther The user is doing something not in this list.

ETSI
14 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
7.3 PlaceTypeValue enumeration
This enumeration shows the type of the user's current location. If the place type is unknown, the attribute value will be
PlaceNone, meaning the attribute was not set. If the user in a place not in this list, the value will be set to PlaceOther.
Enumeration value Description
PlaceNone Not set.
Arena The user is at an enclosed area used for sports events.
Home The user is at home.
Office The user is in an office.
PublicTransport The user is on public transport.
Street Walking on the street.
Outdoors Generally outdoors.
PublicPlace The user is in a public place.
Hotel The user is in a hotel.
Theatre The user is in a theatre or concert.
Restaurant The user is in a restaurant, coffee shop or, other public dining establishment.
School The user is at school.
Industrial The user is in an industrial building.
Quiet The user is in a quiet area.
Noisy The user is in a noisy area.
Aircraft The user is on an aircraft.
Watercraft The user is on a vessel for travel on water, such as a boat or a ship.
Automobile The user is in a car.
Bus The user is in a bus.
BusStation The user is in a bus station.
TrainStation The user is in a train station.
ShoppingArea The user is in a shopping mall or shopping center.
Airport The user is in an airport.
Train The user is in a train.
Bank The user is in a bank.
Bar The user is in a bar.
Bicycle The user is on a bicycle.
Café The user is in a café; usually a small and informal establishment that serves various
refreshments (such as coffee); coffee shop.
Classroom The user is in an academic classroom or lecture hall.
Club The user is in a dance club, nightclub, or discotheque.
Construction The user is at a contstruction site.
ConventionCenter The user is in a convention center or exhibition hall.
Government The user is in a government building, such as those used by the legislative,
executive, or judicial branches of governments, including court houses, police
stations, and military installations.
Hospital The user is in a hospital, hospice, medical clinic, mental institution, or doctor's office.
Library The user is in a library.
Motorcycle The user is on a motorcycle.
Outdoors The user outside a building, in or into the open air, such as a park or city streets.
Parking The user is in a parking lot or parking garage.
PlaceOfWorship The user is at a religious site where congregations gather for religious observances,
such as a church, chapel, meetinghouse, mosque, shrine, synagogue, or temple.
Prison The user is in a prison, penitentiary, jail or a    brig.
Residence The user is in a private or residential setting.
Stadium The user is in a stadium.
Store The user is in a shop or store.
Truck The user is in a truck.
Underway The user is in a land-, water-, or aircraft that is underway (in motion).
Warehouse The user is in a warehouse.
Water The user is in, on, or above bodies of water, such as an ocean, lake, river, canal, or
other waterway.
PlaceOther The user is in a kind of place not listed here.

ETSI
15 Final draft ETSI ES 202 504-14 V1.1.1 (2008-02)
7.4 PrivacyType enumeration
This enumeration shows the amount of privacy a user currently has. If the privacy is unknown, the attribute value will
be PrivacyNone, meaning the attribute was not set. If none of the values apply, the value will be set to PrivacyOther.
Enumeration value Description
PrivacyNone Not set.
PrivacyPublic The user is surrounded by other people and cannot discuss openly.
PrivacyPrivate The user is alone and able to talk openly.
PrivacyQuiet The user is in a quiet environment and cannot talk at all.
PrivacyOther None of the other values applies.
PrivacyAudio Inappropriate individuals are not likely to overhear audio communications.
PrivacyText Inappropriate individuals are not likely to see text communications.
PrivacyVideo Inappropriate individuals are not likely to see video communications.

7.5 SphereValue enumeration
This enumeration shows the sphere within which the user acts. If the sphere is unknown, the attribute value will be
SphereNone, meaning the attribute was not set. If the sphere is not in this list (neither work nor home), the value will
be set to SphereOther.
Enumeration value Description
SphereNone Not set.
SphereWork The user is acting within his work sphere, i.e. as a member of his company.
SphereHome The user is acting within his home sphere, i.e. as a private person.
SphereOther The user is acting neither within his work nor within his home sphere.

7.6 CommunicationMeansType enumeration
This enumeration lists communication means. If the communication attribute refers to a means not in this list, it will
point to MeansOther.
Enumeration value Description
Phone The communication attribute refers to a phone (fixed line or mobile or SIP).
Chat The communication attribute refers to a chat client.
SMS The communication attribute refers to an SMS client.
Video The communication attribute refers to a video phone (fixed line or mobile or SIP).
Web The communication attribute refers to a web client.
EMail The communication attribute refers to an e-mail client.
MMS The communication attribute refers to an MMS client.
MeansOther The communication attribute refers to any other client.
...

ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 14: Presence
(Parlay X 3)
�
2 ETSI ES 202 504-14 V1.1.1 (2008-05)

Reference
DES/TISPAN-01034-14-OSA
Keywords
API, OSA, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 202 504-14 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.8
2 References.8
2.1 Normative references.8
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations.10
4 Detailed service description .10
5 Namespaces.11
6 Sequence diagrams.12
6.1 Interface flow overview.12
7 XML Schema data type definition .13
7.1 PresenceAttributeType enumeration.13
7.2 ActivityValue enumeration.13
7.3 PlaceTypeValue enumeration.14
7.4 PrivacyType enumeration.15
7.5 SphereValue enumeration.15
7.6 CommunicationMeansType enumeration.15
7.7 CommunicationMeans structure.15
7.8 CommunicationValue structure.16
7.9 OtherValue structure.16
7.10 PresenceAttribute structure.16
7.10a AttributeTypeAndValue union.16
7.11 SubscriptionRequest structure.16
7.12 PresencePermission structure.17
7.13 CommunicationStatusType enumeration.17
7.14 PrivacyValue structure.17
7.15 MoodValue enumeration.17
7.16 PlaceIsValue structure.18
7.17 PlaceIsAudioValue enumeration.19
7.18 PlaceIsVideoValue enumeration.19
7.19 PlaceIsTextValue enumeration.19
7.20 RelationshipValue enumeration.19
7.21 TimeOffsetValue structure.20
7.22 StatusIconValue structure.20
7.23 Watcher structure.20
7.24 WatcherSubscriptionStatus enumeration.20
8 Web Service interface definition.20
8.1 Interface: PresenceConsumer.20
8.1.1 Operation: subscribePresence.21
8.1.1.1 Input message: subscribePresenceRequest.21
8.1.1.2 Output message: subscribePresenceResponse.21
8.1.1.3 Referenced faults.21
8.1.2 Operation: getUserPresence.22
8.1.2.1 Input message: getUserPresenceRequest .22
8.1.2.2 Output message: getUserPresenceResponse.22
8.1.2.3 Referenced faults.22
8.1.3 Operation: startPresenceNotification.22
8.1.3.1 Input message: startPresenceNotificationRequest.23
8.1.3.2 Output message: startPresenceNotificationResponse.23
ETSI
4 ETSI ES 202 504-14 V1.1.1 (2008-05)
8.1.3.3 Referenced faults.23
8.1.4 Operation: endPresenceNotification.24
8.1.4.1 Input message: endPresenceNotificationRequest.24
8.1.4.2 Output message: endPresenceNotificationResponse.24
8.1.4.3 Referenced faults.24
8.2 Interface: PresenceNotification.24
8.2.1 Operation: statusChanged.24
8.2.1.1 Input message: statusChangedRequest.24
8.2.1.2 Output message: statusChangedResponse.25
8.2.1.3 Referenced faults.25
8.2.2 Operation: statusEnd.25
8.2.2.1 Input message: statusEndRequest .25
8.2.2.2 Output message: statusEndResponse.25
8.2.2.3 Referenced faults.25
8.2.3 Operation: notifySubscription.25
8.2.3.1 Input message: notifySubscriptionRequest .25
8.2.3.2 Output message: notifySubscriptionResponse .25
8.2.3.3 Referenced faults.25
8.2.4 Operation: subscriptionEnded.26
8.2.4.1 Input message: subscriptionEndedRequest .26
8.2.4.2 Output message: subscriptionEndedResponse.26
8.2.4.3 Referenced faults.26
8.3 Interface: PresenceSupplier.26
8.3.1 Operation: publish.26
8.3.1.1 Input message: publishRequest.26
8.3.1.2 Output message: publishResponse.26
8.3.1.3 Referenced faults.27
8.3.2 Operation: getOpenSubscriptions.27
8.3.2.1 Input message: getOpenSubscriptionsRequest.27
8.3.2.2 Output message: getOpenSubscriptionsResponse.27
8.3.2.3 Referenced faults.27
8.3.3 Operation: updateSubscriptionAuthorization.27
8.3.3.1 Input message: updateSubscriptionAuthorizationRequest .28
8.3.3.2 Output message: updateSubscriptionAuthorizationResponse .28
8.3.3.3 Referenced faults.28
8.3.4 Operation: getMyWatchers.28
8.3.4.1 Input message: getMyWatchersRequest .29
8.3.4.2 Output message: getMyWatchersResponse.29
8.3.4.3 Referenced faults.29
8.3.5 Operation: getSubscribedAttributes.29
8.3.5.1 Input message: getSubscribedAttributesRequest .29
8.3.5.2 Output message: getSubscribedAttributesResponse .29
8.3.5.3 Referenced faults.29
8.3.6 Operation: blockSubscription.30
8.3.6.1 Input message: blockSubscriptionRequest.30
8.3.6.2 Output message: blockSubscriptionResponse.30
8.3.6.3 Referenced faults.30
8.4 Interface: PresenceSupplierNotificationManager.30
8.4.1 Operation: startSubscriptionNotification .30
8.4.1.1 Input message: startSubscriptionNotificationRequest.31
8.4.1.2 Output message: startSubscriptionNotificationResponse.31
8.4.1.3 Referenced Faults.31
8.4.2 Operation: endNotification.31
8.4.2.1 Input message: endNotificationRequest.31
8.4.2.2 Output message: endNotificationResponse.32
8.4.2.3 Referenced Faults.32
8.5 Interface: PresenceSupplierNotification.32
8.5.1 Operation: notifyOpenSubscription.32
8.5.1.1 Input message: notifyOpenSubscriptionRequest.32
8.5.1.2 Output message: notifyOpenSubscriptionResponse.32
8.5.1.3 Referenced faults.32
8.5.2 Operation: notifyError.32
ETSI
5 ETSI ES 202 504-14 V1.1.1 (2008-05)
8.5.2.1 Input message: notifyErrorRequest.32
8.5.2.2 Output message: notifyErrorResponse.33
8.5.2.3 Referenced faults.33
8.5.3 Operation: notifyEnd.33
8.5.3.1 Input message: notifyEndRequest.33
8.5.3.2 Output message: notifyEndResponse.33
8.5.3.3 Referenced faults.33
9 Fault definitions.33
9.1 ServiceException.33
9.1.1 SVC0220: No subscription request.33
9.1.2 SVC0221: Not a watcher .33
10 Service policies .34
Annex A (normative): WSDL for Presence .35
Annex B (informative): Bibliography.36
History .37

ETSI
6 ETSI ES 202 504-14 V1.1.1 (2008-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
The present document is part 14 of a multi-part deliverable covering Open Service Access (OSA); Parlay X 3 Web
Services, as identified below:
Part 1: "Common";
Part 2: "Third Party Call";
Part 3: "Call Notification";
Part 4: "Short Messaging";
Part 5: "Multimedia Messaging";
Part 6: "Payment";
Part 7: "Account Management";
Part 8: "Terminal Status";
Part 9: "Terminal Location";
Part 10: "Call Handling";
Part 11: "Audio Call";
Part 12: "Multimedia Conference";
Part 13: "Address List Management";
Part 14: "Presence";
Part 15: "Message Broadcast";
Part 16: "Geocoding";
Part 17: "Application-driven Quality of Service (QoS)";
Part 18: "Device Capabilities and Configuration";
Part 19: "Multimedia Streaming Control";
Part 20: "Multimedia Multicast Session Management".
ETSI
7 ETSI ES 202 504-14 V1.1.1 (2008-05)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP.
The present document forms part of the Parlay X 3.0 set of specifications.
The present document is equivalent to 3GPP TS 29.199-14 V7.4.0 (Release 7).
ETSI
8 ETSI ES 202 504-14 V1.1.1 (2008-05)
1 Scope
The present document is part 14 of the Stage 3 Parlay X 3 Web Services specification for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardized interface, i.e. the OSA APIs.
The present document specifies the Presence Web Service. The following are defined here:
• Name spaces.
• Sequence diagrams.
• Data definitions.
• Interface specification plus detailed method descriptions.
• Fault definitions.
• Service Policies.
• WSDL Description of the interfaces.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)".
ETSI
9 ETSI ES 202 504-14 V1.1.1 (2008-05)
[2] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
[3] ETSI ES 202 504-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 3)".
[4] ETSI ES 202 915-14: "Open Service Access (OSA); Application Programming Interface (API);
Part 14: Presence and Availability Management SCF (Parlay 4)".
[5] IETF RFC 3856: "A Presence Event Package for the Session Initiation Protocol (SIP)".
http://www.ietf.org/rfc/rfc3856.txt.
[6] Void.
[7] ETSI ES 202 504-13: "Open Service Access (OSA); Parlay X Web Services; Part 13: Address List
Management (Parlay X 3)".
[8] IETF RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification".
[9] Void.
[10] ETSI ES 202 504-8: "Open Service Access (OSA); Parlay X Web Services; Part 8: Terminal
Status (Parlay X 3)".
[11] ETSI ES 202 504-9: "Open Service Access (OSA); Parlay X Web Services; Part 9: Terminal
Location (Parlay X 3)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 504-1 [3] and the following apply:
applications: For Instant Messaging, Push to Talk, or call control and other purposes may become clients of the
presence Web Service. We assume that these applications belong to a watcher and authenticate to the services in the
name of the watcher.
identity: represents a user in the real world
NOTE: See Parlay/OSA PAM identities [4], clause 4.4.1.
presence attributes: Contain information about a presentity. An attribute has a name and a value and can be supplied
by any device, application or network module that can be associated to the presentity's identity. A watcher can obtains
attributes only after he has successfully subscribed to them. Examples for attributes are activity, location type,
communication means, etc.
presence information: Consists of a set of attributes that characterize the presentity such as current activity,
environment, communication means and contact addresses. Only the system and the presentity have direct access to this
information, which may be collected and aggregated from several devices associated to the presentity.
subscription: Before a watcher can access presence data, he has to subscribe to it. One possibility the API provides is
an end-to-end subscription concept, in which only identities that have accepted a subscription to their presence can be
addressed. Subscriptions can be also automatically handled by server policies edited by the presentity or other
authorized users. The service/protocol to manage those policies is out of the scope of the present document.
NOTE: This definition is not related to the term "subscription" in TR 121 905 [1].
watcher and presentity: We use these names to denote the role of the client connected to the presence services.
As in Parlay/OSA PAM [4] the watcher and the presentity have to be associated to identities registered to the system,
i.e. users, groups of users or organizations.
ETSI
10 ETSI ES 202 504-14 V1.1.1 (2008-05)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 202 504-1 [3] and the following apply:
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
ISC IP multimedia subsystem Service Control interface
MMS Multimedia Message Service
PAM Presence and Availability Management
SCF Service Capability Feature
SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions
SIP Session Initiation Protocol
SMS Short Message Service
XCAP XML Configuration Access Protocol
XML eXtensible Markup Language
XMPP eXtensible Messaging and Presence Protocol
XSD XML Schema Definition
4 Detailed service description
The presence service allows for presence information to be obtained about one or more users and to register presence
for the same. It is assumed that the typical client of these interfaces is either a supplier or a consumer of the presence
information. An Instant Messaging application is a canonical example of such a client of this interface.
Figure 1 shows the architecture of the Presence Web Service and the underlying services. The Parlay/OSA PAM SCF is
the straightforward option and implements the presence server with extended identity, device capability, and presence
agent management. Parlay/OSA PAM allows aggregation of presence information from internet, mobile and enterprise
users, etc. using a presence transport network of SIP or XMPP servers. The Presence Web Service can however
communicate directly for example with IMS presence network elements (presence and resource list servers) using the
ISC (SIP/SIMPLE) protocol interface.

watcher
client
presentity
watcher
client
application
Parlay X API
Parlay X Address List
Management Web Parlay X Presence Web Service
Service
Parlay/OSA API
Policy
Parlay/OSA PAM
Network protocols
rules SCF
(e.g. SIP)
Network elements
(e.g. SIP)
Figure 1: The Presence web service environment
ETSI
11 ETSI ES 202 504-14 V1.1.1 (2008-05)
Relationship to Similar or Supplanted Specifications
The most important relations are to:
• Parlay X 3 Terminal Status Web Service [10] and Parlay X 3 Terminal Location Web Service [11]: Both
services deal with information that could be considered part of the user's presence information.
Communication abilities can be derived from terminal status information, and the user's placetype can be
derived from his location.
• Parlay/OSA PAM [4]: The Parlay/OSA Presence and Availability specification can be considered the big
brother of the present document. While Parlay X 3 Presence stays behind Parlay/OSA PAM in terms of
flexibility and power - especially concerning attributes and management interfaces - it also extends PAM by
introducing end-to-end authorization. The present document aims to be mappable to Parlay/OSA PAM.
• SIP SIMPLE [5]: The present document aims to be mappable to the SIP/SIMPLE architecture.
• XMPP (Jabber) (see bibliography): Many principles of XMPP have been adopted, especially the end-to-end
authorization.
• IETF Rich Presence(see bibliography). The set of attributes the present document specifies is closely aligned
with the IETF's Rich Presence ideas.
• Group Management [7]: Presence of groups is supported by the present document, however their creation and
manipulation has to be done using the Parlay X 3 Address List Management Web Service. In the 3GPP
presence context, contact lists and group manipulation is done with the XCAP protocol (see bibliography).
5 Namespaces
The PresenceConsumer interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/consumer/v3_2
The PresenceNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/notification/v3_2
The PresenceSupplier interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/supplier/v3_2
The PresenceSupplierNotificationManager interfaces use the namespace:
http://www.csapi.org/wsdl/parlayx/presence_supplier/notification_manager/v3_0
The PresenceSupplierNotification interfaces use the namespace:
http://www.csapi.org/wsdl/parlayx/presence_supplier/notification/v3_0
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/presence/v3_2
The 'xsd' namespace is used in the present document to refer to the XML Schema data types defined in
XML Schema [2]. The use of the name 'xsd' is not semantically significant.
ETSI
12 ETSI ES 202 504-14 V1.1.1 (2008-05)
6 Sequence diagrams
6.1 Interface flow overview
The sequence diagram shows the interactions in case both watcher application and presentity are Web Service clients.
Compared to the SIP interactions, the subscription notification is separated from the delivery of presence information
itself. Based on the subscription result, the watcher can select the polling or notification mode for presence events.
Changes in the authorization of presence attributes are propagated to the watchers via the notifySubscription()
operation, the blocking of a subscription by the presentity is propagated via a subscriptionEnded operation.
The sequence diagram does not show the internal communication within the presence server. It is assumed that the
Presence Consumer and Supplier interfaces are implemented by the same instance. If an implementer of the API find
other solutions preferable, he has to take care of the internal communication himself.
Watcher Application : Presence Web Service : Presence Web Service :
Presentity Application
PresenceConsumerNotifications PresenceConsumer PresenceSupplier
:
subscribePresence
check subscription policies
after a while the
user logs on
notifySubscription
getOpenSubscriptions
if there is a policy for this
get user answer
subscription request, no
interaction with the
presentity is necessary.
updateSubscriptionAuthorization
notifySubscription
publish
the watcher can access
presence data by polling.
getUserPresence
determine presence
... or through notifications
user status changes (for
whatever reason)
startPresenceNotification
publish
statusChanged
endPresenceNotification
subscription timeout
subscriptionEnded
getMyWatchers
a subscription can either
time out; or the presentity
can cancel it
getSubscribedAttributes
blockSubscription
subscriptionEnded
Figure 2: Message interaction overview
ETSI
13 ETSI ES 202 504-14 V1.1.1 (2008-05)
7 XML Schema data type definition
Presence attributes are inspired by the IETF's Rich Presence ideas (see Bibliography).
7.1 PresenceAttributeType enumeration
The different types of attributes. For each entry in this enumeration there is a separate value type.
Enumeration value Description
Activity The presentity's activity (available, busy, lunch, etc.)
PlaceType At what kind of place the presentity is (home, office, etc.)
Privacy The amount of privacy the user wants (public, quiet, etc.)
Sphere The user's current environment (work, home)
Communication The user's means of communication (phone, mail, etc.)
Mood The user’s mood (angry, confused, happy, etc.)
PlaceIs Describes the properties of the place the user is currently at.
TimeOffset Describes the number of minutes of offset from UTC that the user is currently at.
StatusIcon Depicts the current status of the user.
Other A name - value pair for arbitrary presence information

7.2 ActivityValue enumeration
This enumeration shows the user's current activity. If the activity is unknown, the attribute value will be ActivityNone,
meaning the attribute was not set. If the user is doing something not in this list, the value will be set to ActivityOther.
Enumeration value Description
ActivityNone Not set.
Appointment The user has an appointment.
Available The user is available for communication.
Busy The user is busy and is only available for urgent matters.
DoNotDisturb The user is very busy and does not wish to be disturbed.
OnThePhone The user is on the phone.
Steering The user is driving a car / train / airplane, etc.
Meeting The user is in a meeting.
Away No idea what the user is doing, but he is away.
Meal The user is eating.
Breakfast The user is having breakfast.
Lunch The user is having lunch.
Dinner The user is having dinner.
PermanentAbsence The user is away and will not return for an extended period.
Vacation The user is on vacation.
Holiday A scheduled national or local holiday.
Performance The user is in a theatre / concert.
InTransit The user is in the transit area of an (air)port.
Travel The user is travelling.
Sleeping The user is sleeping.
LookingForWork The user is looking for (paid) work.
Playing The user is occupying him- or herself in amusement, sport, or other recreation.
Presentation The user is giving a presentation, lecture, or participating in a formal round-table
discussion.
Shopping The user is visiting stores in search of goods or services.
Spectator The user is observing an event, such as a sports event.
TV The user is watching television.
Working The user is engaged in, typically paid, labor, as part of a profession or job.
Worship The user is participating in religious rites.
ActivityOther The user is doing something not in this list.

ETSI
14 ETSI ES 202 504-14 V1.1.1 (2008-05)
7.3 PlaceTypeValue enumeration
This enumeration shows the type of the user's current location. If the place type is unknown, the attribute value will be
PlaceNone, meaning the attribute was not set. If the user in a place not in this list, the value will be set to PlaceOther.
Enumeration value Description
PlaceNone Not set.
Arena The user is at an enclosed area used for sports events.
Home The user is at home.
Office The user is in an office.
PublicTransport The user is on public transport.
Street Walking on the street.
Outdoors Generally outdoors.
PublicPlace The user is in a public place.
Hotel The user is in a hotel.
Theatre The user is in a theatre or concert.
Restaurant The user is in a restaurant, coffee shop or, other public dining establishment.
School The user is at school.
Industrial The user is in an industrial building.
Quiet The user is in a quiet area.
Noisy The user is in a noisy area.
Aircraft The user is on an aircraft.
Watercraft The user is on a vessel for travel on water, such as a boat or a ship.
Automobile The user is in a car.
Bus The user is in a bus.
BusStation The user is in a bus station.
TrainStation The user is in a train station.
ShoppingArea The user is in a shopping mall or shopping center.
Airport The user is in an airport.
Train The user is in a train.
Bank The user is in a bank.
Bar The user is in a bar.
Bicycle The user is on a bicycle.
Café The user is in a café; usually a small and informal establishment that serves various
refreshments (such as coffee); coffee shop.
Classroom The user is in an academic classroom or lecture hall.
Club The user is in a dance club, nightclub, or discotheque.
Construction The user is at a contstruction site.
ConventionCenter The user is in a convention center or exhibition hall.
Government The user is in a government building, such as those used by the legislative,
executive, or judicial branches of governments, including court houses, police
stations, and military installations.
Hospital The user is in a hospital, hospice, medical clinic, mental institution, or doctor's office.
Library The user is in a library.
Motorcycle The user is on a motorcycle.
Outdoors The user outside a building, in or into the open air, such as a park or city streets.
Parking The user is in a parking lot or parking garage.
PlaceOfWorship The user is at a religious site where congregations gather for religious observances,
such as a church, chapel, meetinghouse, mosque, shrine, synagogue, or temple.
Prison The user is in a prison, penitentiary, jail or a    brig.
Residence The user is in a private or residential setting.
Stadium The user is in a stadium.
Store The user is in a shop or store.
Truck The user is in a truck.
Underway The user is in a land-, water-, or aircraft that is underway (in motion).
Warehouse The user is in a warehouse.
Water The user is in, on, or above bodies of water, such as an ocean, lake, river, canal, or
other waterway.
PlaceOther The user is in a kind of place not listed here.

ETSI
15 ETSI ES 202 504-14 V1.1.1 (2008-05)
7.4 PrivacyType enumeration
This enumeration shows the amount of privacy a user currently has. If the privacy is unknown, the attribute value will
be PrivacyNone, meaning the attribute was not set. If none of the values apply, the value will be set to PrivacyOther.
Enumeration value Description
PrivacyNone Not set.
PrivacyPublic The user is surrounded by other people and cannot discuss openly.
PrivacyPrivate The user is alone and able to talk openly.
PrivacyQuiet The user is in a quiet environment and cannot talk at all.
PrivacyOther None of the other values applies.
PrivacyAudio Inappropriate individuals are not likely to overhear audio communications.
PrivacyText Inappropriate individuals are not likely to see text communications.
PrivacyVideo Inappropriate individuals are not likely to see video communications.

7.5 SphereValue enumeration
This enumeration shows the sphere within which the user acts. If the sphere is unknown, the attribute value will be
SphereNone, meaning the attribute was not set. If the sphere is not in this list (neither work nor home), the value will
be set to SphereOther.
Enumeration value Description
SphereNone Not set.
SphereWork The user is acting within his work sphere, i.e. as a member of his company.
SphereHome The user is acting within his home sphere, i.e. as a private person.
SphereOther The user is acting neither within his work nor within his home sphere.

7.6 CommunicationMeansType enumeration
This enumeration lists communication means. If the communication attribute refers to a means not in this list, it will
point to MeansOther.
Enumeration value Description
Phone The communication attribute refers to a phone (fixed line or mobile or SIP).
Chat The communication attribute refers to a chat client.
SMS The communication attribute refers to an SMS client.
Video The communication attribute refers to a video phone (fixed line or mobile or SIP).
Web The communication attribute refers to a web client.
EMail The communication attribute refers to an e-mail client.
MMS The communication attribute refers to an MMS client.
MeansOther The communication attribute refers to any other client.

7.7 CommunicationMeans structure
This structure describes one way of reaching the presentity or contacts of the presentity. If the presentity for example is
unavailable he/she may publish communication means for one of his/her contacts.
Element name E
...

SLOVENSKI STANDARD
01-september-2008
2GSUWLGRVWRSGRVWRULWYH26$6SOHWQHVWRULWYH3DUOD\;GHO1DY]RþQRVW
3DUOD\;
Open Service Access (OSA) - Parlay X Web Services - Part 14: Presence (Parlay X 3)
Ta slovenski standard je istoveten z: ES 202 504-14 Version 1.1.1
ICS:
35.100.01 Medsebojno povezovanje Open systems
odprtih sistemov na splošno interconnection in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI Standard
Open Service Access (OSA);
Parlay X Web Services;
Part 14: Presence
(Parlay X 3)
�
2 ETSI ES 202 504-14 V1.1.1 (2008-05)

Reference
DES/TISPAN-01034-14-OSA
Keywords
API, OSA, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 202 504-14 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.8
2 References.8
2.1 Normative references.8
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations.10
4 Detailed service description .10
5 Namespaces.11
6 Sequence diagrams.12
6.1 Interface flow overview.12
7 XML Schema data type definition .13
7.1 PresenceAttributeType enumeration.13
7.2 ActivityValue enumeration.13
7.3 PlaceTypeValue enumeration.14
7.4 PrivacyType enumeration.15
7.5 SphereValue enumeration.15
7.6 CommunicationMeansType enumeration.15
7.7 CommunicationMeans structure.15
7.8 CommunicationValue structure.16
7.9 OtherValue structure.16
7.10 PresenceAttribute structure.16
7.10a AttributeTypeAndValue union.16
7.11 SubscriptionRequest structure.16
7.12 PresencePermission structure.17
7.13 CommunicationStatusType enumeration.17
7.14 PrivacyValue structure.17
7.15 MoodValue enumeration.17
7.16 PlaceIsValue structure.18
7.17 PlaceIsAudioValue enumeration.19
7.18 PlaceIsVideoValue enumeration.19
7.19 PlaceIsTextValue enumeration.19
7.20 RelationshipValue enumeration.19
7.21 TimeOffsetValue structure.20
7.22 StatusIconValue structure.20
7.23 Watcher structure.20
7.24 WatcherSubscriptionStatus enumeration.20
8 Web Service interface definition.20
8.1 Interface: PresenceConsumer.20
8.1.1 Operation: subscribePresence.21
8.1.1.1 Input message: subscribePresenceRequest.21
8.1.1.2 Output message: subscribePresenceResponse.21
8.1.1.3 Referenced faults.21
8.1.2 Operation: getUserPresence.22
8.1.2.1 Input message: getUserPresenceRequest .22
8.1.2.2 Output message: getUserPresenceResponse.22
8.1.2.3 Referenced faults.22
8.1.3 Operation: startPresenceNotification.22
8.1.3.1 Input message: startPresenceNotificationRequest.23
8.1.3.2 Output message: startPresenceNotificationResponse.23
ETSI
4 ETSI ES 202 504-14 V1.1.1 (2008-05)
8.1.3.3 Referenced faults.23
8.1.4 Operation: endPresenceNotification.24
8.1.4.1 Input message: endPresenceNotificationRequest.24
8.1.4.2 Output message: endPresenceNotificationResponse.24
8.1.4.3 Referenced faults.24
8.2 Interface: PresenceNotification.24
8.2.1 Operation: statusChanged.24
8.2.1.1 Input message: statusChangedRequest.24
8.2.1.2 Output message: statusChangedResponse.25
8.2.1.3 Referenced faults.25
8.2.2 Operation: statusEnd.25
8.2.2.1 Input message: statusEndRequest .25
8.2.2.2 Output message: statusEndResponse.25
8.2.2.3 Referenced faults.25
8.2.3 Operation: notifySubscription.25
8.2.3.1 Input message: notifySubscriptionRequest .25
8.2.3.2 Output message: notifySubscriptionResponse .25
8.2.3.3 Referenced faults.25
8.2.4 Operation: subscriptionEnded.26
8.2.4.1 Input message: subscriptionEndedRequest .26
8.2.4.2 Output message: subscriptionEndedResponse.26
8.2.4.3 Referenced faults.26
8.3 Interface: PresenceSupplier.26
8.3.1 Operation: publish.26
8.3.1.1 Input message: publishRequest.26
8.3.1.2 Output message: publishResponse.26
8.3.1.3 Referenced faults.27
8.3.2 Operation: getOpenSubscriptions.27
8.3.2.1 Input message: getOpenSubscriptionsRequest.27
8.3.2.2 Output message: getOpenSubscriptionsResponse.27
8.3.2.3 Referenced faults.27
8.3.3 Operation: updateSubscriptionAuthorization.27
8.3.3.1 Input message: updateSubscriptionAuthorizationRequest .28
8.3.3.2 Output message: updateSubscriptionAuthorizationResponse .28
8.3.3.3 Referenced faults.28
8.3.4 Operation: getMyWatchers.28
8.3.4.1 Input message: getMyWatchersRequest .29
8.3.4.2 Output message: getMyWatchersResponse.29
8.3.4.3 Referenced faults.29
8.3.5 Operation: getSubscribedAttributes.29
8.3.5.1 Input message: getSubscribedAttributesRequest .29
8.3.5.2 Output message: getSubscribedAttributesResponse .29
8.3.5.3 Referenced faults.29
8.3.6 Operation: blockSubscription.30
8.3.6.1 Input message: blockSubscriptionRequest.30
8.3.6.2 Output message: blockSubscriptionResponse.30
8.3.6.3 Referenced faults.30
8.4 Interface: PresenceSupplierNotificationManager.30
8.4.1 Operation: startSubscriptionNotification .30
8.4.1.1 Input message: startSubscriptionNotificationRequest.31
8.4.1.2 Output message: startSubscriptionNotificationResponse.31
8.4.1.3 Referenced Faults.31
8.4.2 Operation: endNotification.31
8.4.2.1 Input message: endNotificationRequest.31
8.4.2.2 Output message: endNotificationResponse.32
8.4.2.3 Referenced Faults.32
8.5 Interface: PresenceSupplierNotification.32
8.5.1 Operation: notifyOpenSubscription.32
8.5.1.1 Input message: notifyOpenSubscriptionRequest.32
8.5.1.2 Output message: notifyOpenSubscriptionResponse.32
8.5.1.3 Referenced faults.32
8.5.2 Operation: notifyError.32
ETSI
5 ETSI ES 202 504-14 V1.1.1 (2008-05)
8.5.2.1 Input message: notifyErrorRequest.32
8.5.2.2 Output message: notifyErrorResponse.33
8.5.2.3 Referenced faults.33
8.5.3 Operation: notifyEnd.33
8.5.3.1 Input message: notifyEndRequest.33
8.5.3.2 Output message: notifyEndResponse.33
8.5.3.3 Referenced faults.33
9 Fault definitions.33
9.1 ServiceException.33
9.1.1 SVC0220: No subscription request.33
9.1.2 SVC0221: Not a watcher .33
10 Service policies .34
Annex A (normative): WSDL for Presence .35
Annex B (informative): Bibliography.36
History .37

ETSI
6 ETSI ES 202 504-14 V1.1.1 (2008-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
The present document is part 14 of a multi-part deliverable covering Open Service Access (OSA); Parlay X 3 Web
Services, as identified below:
Part 1: "Common";
Part 2: "Third Party Call";
Part 3: "Call Notification";
Part 4: "Short Messaging";
Part 5: "Multimedia Messaging";
Part 6: "Payment";
Part 7: "Account Management";
Part 8: "Terminal Status";
Part 9: "Terminal Location";
Part 10: "Call Handling";
Part 11: "Audio Call";
Part 12: "Multimedia Conference";
Part 13: "Address List Management";
Part 14: "Presence";
Part 15: "Message Broadcast";
Part 16: "Geocoding";
Part 17: "Application-driven Quality of Service (QoS)";
Part 18: "Device Capabilities and Configuration";
Part 19: "Multimedia Streaming Control";
Part 20: "Multimedia Multicast Session Management".
ETSI
7 ETSI ES 202 504-14 V1.1.1 (2008-05)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP.
The present document forms part of the Parlay X 3.0 set of specifications.
The present document is equivalent to 3GPP TS 29.199-14 V7.4.0 (Release 7).
ETSI
8 ETSI ES 202 504-14 V1.1.1 (2008-05)
1 Scope
The present document is part 14 of the Stage 3 Parlay X 3 Web Services specification for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardized interface, i.e. the OSA APIs.
The present document specifies the Presence Web Service. The following are defined here:
• Name spaces.
• Sequence diagrams.
• Data definitions.
• Interface specification plus detailed method descriptions.
• Fault definitions.
• Service Policies.
• WSDL Description of the interfaces.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Vocabulary for 3GPP Specifications (3GPP TR 21.905)".
ETSI
9 ETSI ES 202 504-14 V1.1.1 (2008-05)
[2] W3C Recommendation (2 May 2001): "XML Schema Part 2: Datatypes".
NOTE: Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
[3] ETSI ES 202 504-1: "Open Service Access (OSA); Parlay X Web Services; Part 1: Common
(Parlay X 3)".
[4] ETSI ES 202 915-14: "Open Service Access (OSA); Application Programming Interface (API);
Part 14: Presence and Availability Management SCF (Parlay 4)".
[5] IETF RFC 3856: "A Presence Event Package for the Session Initiation Protocol (SIP)".
http://www.ietf.org/rfc/rfc3856.txt.
[6] Void.
[7] ETSI ES 202 504-13: "Open Service Access (OSA); Parlay X Web Services; Part 13: Address List
Management (Parlay X 3)".
[8] IETF RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification".
[9] Void.
[10] ETSI ES 202 504-8: "Open Service Access (OSA); Parlay X Web Services; Part 8: Terminal
Status (Parlay X 3)".
[11] ETSI ES 202 504-9: "Open Service Access (OSA); Parlay X Web Services; Part 9: Terminal
Location (Parlay X 3)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 504-1 [3] and the following apply:
applications: For Instant Messaging, Push to Talk, or call control and other purposes may become clients of the
presence Web Service. We assume that these applications belong to a watcher and authenticate to the services in the
name of the watcher.
identity: represents a user in the real world
NOTE: See Parlay/OSA PAM identities [4], clause 4.4.1.
presence attributes: Contain information about a presentity. An attribute has a name and a value and can be supplied
by any device, application or network module that can be associated to the presentity's identity. A watcher can obtains
attributes only after he has successfully subscribed to them. Examples for attributes are activity, location type,
communication means, etc.
presence information: Consists of a set of attributes that characterize the presentity such as current activity,
environment, communication means and contact addresses. Only the system and the presentity have direct access to this
information, which may be collected and aggregated from several devices associated to the presentity.
subscription: Before a watcher can access presence data, he has to subscribe to it. One possibility the API provides is
an end-to-end subscription concept, in which only identities that have accepted a subscription to their presence can be
addressed. Subscriptions can be also automatically handled by server policies edited by the presentity or other
authorized users. The service/protocol to manage those policies is out of the scope of the present document.
NOTE: This definition is not related to the term "subscription" in TR 121 905 [1].
watcher and presentity: We use these names to denote the role of the client connected to the presence services.
As in Parlay/OSA PAM [4] the watcher and the presentity have to be associated to identities registered to the system,
i.e. users, groups of users or organizations.
ETSI
10 ETSI ES 202 504-14 V1.1.1 (2008-05)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 202 504-1 [3] and the following apply:
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
ISC IP multimedia subsystem Service Control interface
MMS Multimedia Message Service
PAM Presence and Availability Management
SCF Service Capability Feature
SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions
SIP Session Initiation Protocol
SMS Short Message Service
XCAP XML Configuration Access Protocol
XML eXtensible Markup Language
XMPP eXtensible Messaging and Presence Protocol
XSD XML Schema Definition
4 Detailed service description
The presence service allows for presence information to be obtained about one or more users and to register presence
for the same. It is assumed that the typical client of these interfaces is either a supplier or a consumer of the presence
information. An Instant Messaging application is a canonical example of such a client of this interface.
Figure 1 shows the architecture of the Presence Web Service and the underlying services. The Parlay/OSA PAM SCF is
the straightforward option and implements the presence server with extended identity, device capability, and presence
agent management. Parlay/OSA PAM allows aggregation of presence information from internet, mobile and enterprise
users, etc. using a presence transport network of SIP or XMPP servers. The Presence Web Service can however
communicate directly for example with IMS presence network elements (presence and resource list servers) using the
ISC (SIP/SIMPLE) protocol interface.

watcher
client
presentity
watcher
client
application
Parlay X API
Parlay X Address List
Management Web Parlay X Presence Web Service
Service
Parlay/OSA API
Policy
Parlay/OSA PAM
Network protocols
rules SCF
(e.g. SIP)
Network elements
(e.g. SIP)
Figure 1: The Presence web service environment
ETSI
11 ETSI ES 202 504-14 V1.1.1 (2008-05)
Relationship to Similar or Supplanted Specifications
The most important relations are to:
• Parlay X 3 Terminal Status Web Service [10] and Parlay X 3 Terminal Location Web Service [11]: Both
services deal with information that could be considered part of the user's presence information.
Communication abilities can be derived from terminal status information, and the user's placetype can be
derived from his location.
• Parlay/OSA PAM [4]: The Parlay/OSA Presence and Availability specification can be considered the big
brother of the present document. While Parlay X 3 Presence stays behind Parlay/OSA PAM in terms of
flexibility and power - especially concerning attributes and management interfaces - it also extends PAM by
introducing end-to-end authorization. The present document aims to be mappable to Parlay/OSA PAM.
• SIP SIMPLE [5]: The present document aims to be mappable to the SIP/SIMPLE architecture.
• XMPP (Jabber) (see bibliography): Many principles of XMPP have been adopted, especially the end-to-end
authorization.
• IETF Rich Presence(see bibliography). The set of attributes the present document specifies is closely aligned
with the IETF's Rich Presence ideas.
• Group Management [7]: Presence of groups is supported by the present document, however their creation and
manipulation has to be done using the Parlay X 3 Address List Management Web Service. In the 3GPP
presence context, contact lists and group manipulation is done with the XCAP protocol (see bibliography).
5 Namespaces
The PresenceConsumer interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/consumer/v3_2
The PresenceNotification interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/notification/v3_2
The PresenceSupplier interface uses the namespace:
http://www.csapi.org/wsdl/parlayx/presence/supplier/v3_2
The PresenceSupplierNotificationManager interfaces use the namespace:
http://www.csapi.org/wsdl/parlayx/presence_supplier/notification_manager/v3_0
The PresenceSupplierNotification interfaces use the namespace:
http://www.csapi.org/wsdl/parlayx/presence_supplier/notification/v3_0
The data types are defined in the namespace:
http://www.csapi.org/schema/parlayx/presence/v3_2
The 'xsd' namespace is used in the present document to refer to the XML Schema data types defined in
XML Schema [2]. The use of the name 'xsd' is not semantically significant.
ETSI
12 ETSI ES 202 504-14 V1.1.1 (2008-05)
6 Sequence diagrams
6.1 Interface flow overview
The sequence diagram shows the interactions in case both watcher application and presentity are Web Service clients.
Compared to the SIP interactions, the subscription notification is separated from the delivery of presence information
itself. Based on the subscription result, the watcher can select the polling or notification mode for presence events.
Changes in the authorization of presence attributes are propagated to the watchers via the notifySubscription()
operation, the blocking of a subscription by the presentity is propagated via a subscriptionEnded operation.
The sequence diagram does not show the internal communication within the presence server. It is assumed that the
Presence Consumer and Supplier interfaces are implemented by the same instance. If an implementer of the API find
other solutions preferable, he has to take care of the internal communication himself.
Watcher Application : Presence Web Service : Presence Web Service :
Presentity Application
PresenceConsumerNotifications PresenceConsumer PresenceSupplier
:
subscribePresence
check subscription policies
after a while the
user logs on
notifySubscription
getOpenSubscriptions
if there is a policy for this
get user answer
subscription request, no
interaction with the
presentity is necessary.
updateSubscriptionAuthorization
notifySubscription
publish
the watcher can access
presence data by polling.
getUserPresence
determine presence
... or through notifications
user status changes (for
whatever reason)
startPresenceNotification
publish
statusChanged
endPresenceNotification
subscription timeout
subscriptionEnded
getMyWatchers
a subscription can either
time out; or the presentity
can cancel it
getSubscribedAttributes
blockSubscription
subscriptionEnded
Figure 2: Message interaction overview
ETSI
13 ETSI ES 202 504-14 V1.1.1 (2008-05)
7 XML Schema data type definition
Presence attributes are inspired by the IETF's Rich Presence ideas (see Bibliography).
7.1 PresenceAttributeType enumeration
The different types of attributes. For each entry in this enumeration there is a separate value type.
Enumeration value Description
Activity The presentity's activity (available, busy, lunch, etc.)
PlaceType At what kind of place the presentity is (home, office, etc.)
Privacy The amount of privacy the user wants (public, quiet, etc.)
Sphere The user's current environment (work, home)
Communication The user's means of communication (phone, mail, etc.)
Mood The user’s mood (angry, confused, happy, etc.)
PlaceIs Describes the properties of the place the user is currently at.
TimeOffset Describes the number of minutes of offset from UTC that the user is currently at.
StatusIcon Depicts the current status of the user.
Other A name - value pair for arbitrary presence information

7.2 ActivityValue enumeration
This enumeration shows the user's current activity. If the activity is unknown, the attribute value will be ActivityNone,
meaning the attribute was not set. If the user is doing something not in this list, the value will be set to ActivityOther.
Enumeration value Description
ActivityNone Not set.
Appointment The user has an appointment.
Available The user is available for communication.
Busy The user is busy and is only available for urgent matters.
DoNotDisturb The user is very busy and does not wish to be disturbed.
OnThePhone The user is on the phone.
Steering The user is driving a car / train / airplane, etc.
Meeting The user is in a meeting.
Away No idea what the user is doing, but he is away.
Meal The user is eating.
Breakfast The user is having breakfast.
Lunch The user is having lunch.
Dinner The user is having dinner.
PermanentAbsence The user is away and will not return for an extended period.
Vacation The user is on vacation.
Holiday A scheduled national or local holiday.
Performance The user is in a theatre / concert.
InTransit The user is in the transit area of an (air)port.
Travel The user is travelling.
Sleeping The user is sleeping.
LookingForWork The user is looking for (paid) work.
Playing The user is occupying him- or herself in amusement, sport, or other recreation.
Presentation The user is giving a presentation, lecture, or participating in a formal round-table
discussion.
Shopping The user is visiting stores in search of goods or services.
Spectator The user is observing an event, such as a sports event.
TV The user is watching television.
Working The user is engaged in, typically paid, labor, as part of a profession or job.
Worship The user is participating in religious rites.
ActivityOther The user is doing something not in this list.

ETSI
14 ETSI ES 202 504-14 V1.1.1 (2008-05)
7.3 PlaceTypeValue enumeration
This enumeration shows the type of the user's current location. If the place type is unknown, the attribute value will be
PlaceNone, meaning the attribute was not set. If the user in a place not in this list, the value will be set to PlaceOther.
Enumeration value Description
PlaceNone Not set.
Arena The user is at an enclosed area used for sports events.
Home The user is at home.
Office The user is in an office.
PublicTransport The user is on public transport.
Street Walking on the street.
Outdoors Generally outdoors.
PublicPlace The user is in a public place.
Hotel The user is in a hotel.
Theatre The user is in a theatre or concert.
Restaurant The user is in a restaurant, coffee shop or, other public dining establishment.
School The user is at school.
Industrial The user is in an industrial building.
Quiet The user is in a quiet area.
Noisy The user is in a noisy area.
Aircraft The user is on an aircraft.
Watercraft The user is on a vessel for travel on water, such as a boat or a ship.
Automobile The user is in a car.
Bus The user is in a bus.
BusStation The user is in a bus station.
TrainStation The user is in a train station.
ShoppingArea The user is in a shopping mall or shopping center.
Airport The user is in an airport.
Train The user is in a train.
Bank The user is in a bank.
Bar The user is in a bar.
Bicycle The user is on a bicycle.
Café The user is in a café; usually a small and informal establishment that serves various
refreshments (such as coffee); coffee shop.
Classroom The user is in an academic classroom or lecture hall.
Club The user is in a dance club, nightclub, or discotheque.
Construction The user is at a contstruction site.
ConventionCenter The user is in a convention center or exhibition hall.
Government The user is in a government building, such as those used by the legislative,
executive, or judicial branches of governments, including court houses, police
stations, and military installations.
Hospital The user is in a hospital, hospice, medical clinic, mental institution, or doctor's office.
Library The user is in a library.
Motorcycle The user is on a motorcycle.
Outdoors The user outside a building, in or into the open air, such as a park or city streets.
Parking The user is in a parking lot or parking garage.
PlaceOfWorship The user is at a religious site where congregations gather for religious observances,
such as a church, chapel, meetinghouse, mosque, shrine, synagogue, or temple.
Prison The user is in a prison, penitentiary, jail or a    brig.
Residence The user is in a private or residential setting.
Stadium The user is in a stadium.
Store The user is in a shop or store.
Truck The user is in a truck.
Underway The user is in a land-, water-, or aircraft that is underway (in motion).
Warehouse The user is in a warehouse.
Water The user is in, on, or above bodies of water, such as an ocean, lake, river, canal, or
other waterway.
PlaceOther The user is in a kind of place not listed here.

ETSI
15 ETSI ES 202 504-14 V1.1.1 (2008-05)
7.4 PrivacyType enumeration
This enumeration shows the amount of privacy a user currently has. If the privacy is unknown, the attribute value will
be PrivacyNone, meaning the attribute was not set. If none of the values apply, the value will be set to PrivacyOther.
Enumeration value Description
PrivacyNone Not set.
PrivacyPublic The user is surrounded by other people and cannot discuss openly.
PrivacyPrivate The user is alone and able to talk openly.
PrivacyQuiet The user is in a quiet environment and cannot talk at all.
PrivacyOther None of the other values applies.
PrivacyAudio Inappropriate individuals are not likely to overhear audio communications.
PrivacyText Inappropriate individuals are not likely to see text communications.
PrivacyVideo Inappropriate individuals are not likely to see video communications.

7.5 SphereValue enumeration
This enumeration shows the sphere within which the user acts. If the sphere is unknown, the attribute value will be
SphereNone, meaning the attribute was not set. If the sphere is not in this list (neither work nor home), the value will
be set to SphereOther.
Enumeration value Description
SphereNone Not set.
SphereWork The user is a
...