ISO/IEC TR 22767:2005

TECHNICAL ISO/IEC
REPORT TR
First edition
2005-08-15
Information technology —
Telecommunications and information
exchange between systems — Using
CSTA for SIP phone user agents
(uaCSTA)
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Utilisation de CSTA pour agents
d'utilisateurs de téléphone de SIP (uaCSTA)

Reference number
©
ISO/IEC 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2005 – All rights reserved

Contents Page
Foreword. vii
Introduction . viii
1 Scope .1
2 Purpose.1
3 Normative references .2
4 Terminology .2
4.1 General terms.2
4.2 SIP/CSTA Terminology Mappings.3
5 Example Environments for uaCSTA .3
5.1 Controlling and Observing a SIP Phone .3
5.2 Controlling and Observing a SIP Phone by Augmenting B2BUA Functionality .4
5.3 Controlling a PBX Phone .4
6 Example User Agent Configurations .5
6.1 Single Line Phone UA .5
6.2 Multi Line Phone UA.6
6.3 Bridged Appearance Phone and other Advanced UA Configurations.6
7 SIP Transport Mechanism for CSTA Messages.7
7.1 Establishing a CSTA Application Session .7
7.2 Transporting CSTA Service Requests and Responses.8
7.3 Starting a Monitor and Transporting CSTA Events.9
8 uaCSTA Profiles.9
8.1 Minimal uaCSTA Call Control Profile.10
8.1.1 Services .10
8.1.2 Events .10
8.2 Basic uaCSTA Call Control Profile.10
8.2.1 Services .10
8.2.2 Events .11
8.3 Advanced uaCSTA Call Control Profile.11
8.3.1 Services .11
8.3.2 Events .12
8.4 Conferencing uaCSTA Call Control Feature Profile.12
8.4.1 Services .12
8.4.2 Events .13
8.5 Basic uaCSTA Device Feature Profile .13
8.5.1 Services .13
8.5.2 Events .13
8.6 Speaker uaCSTA Device Feature Profile.13
8.6.1 Services .13
8.6.2 Events .13
9 CSTA Calls and Connections .13
9.1 CSTA Connection State Model.14
9.2 Connection State Transitions for CSTA Calls .14
9.2.1 Incoming Call .14
9.2.2 Outgoing Call .15
10 Call Control.15
10.1 Alternate Call.15
10.1.1 Service Request.16
© ISO/IEC 2005 – All rights reserved iii

10.1.2 Positive Service Response . 16
10.1.3 Negative Service Response . 16
10.2 Answer Call. 17
10.2.1 Service Request . 17
10.2.2 Positive Service Response . 18
10.2.3 Negative Service Response . 18
10.3 Clear Connection . 19
10.3.1 Service Request . 19
10.3.2 Positive Service Response . 19
10.3.3 Negative Service Response . 19
10.4 Consultation Call. 20
10.4.1 Service Request . 20
10.4.2 Positive Service Response . 21
10.4.3 Negative Service Response . 21
10.5 Deflect Call. 22
10.5.1 Service Request . 22
10.5.2 Positive Service Response . 22
10.5.3 Negative Service Response . 23
10.6 Generate Digits. 23
10.6.1 Service Request . 24
10.6.2 Positive Service Response . 24
10.6.3 Negative Service Response . 24
10.7 Hold Call. 25
10.7.1 Service Request . 25
10.7.2 Positive Service Response . 25
10.7.3 Negative Service Response . 26
10.8 Make Call. 26
10.8.1 Service Request . 26
10.8.2 Positive Service Response . 27
10.8.3 Negative Service Response . 27
10.9 Reconnect Call . 28
10.9.1 Service Request . 28
10.9.2 Positive Service Response . 29
10.9.3 Negative Service Response . 29
10.10 Retrieve Call. 30
10.10.1 Service Request . 30
10.10.2 Positive Service Response . 30
10.10.3 Negative Service Response . 30
10.11 Single Step Transfer Call. 31
10.11.1 Service Request . 31
10.11.2 Positive Service Response . 32
10.11.3 Negative Service Response . 32
10.12 Transfer Call . 33
10.12.1 Service Request . 33
10.12.2 Positive Service Response . 34
10.12.3 Negative Service Response . 34
11 Physical Phone Features. 35
11.1 Get Message Waiting Indicator. 35
11.1.1 Service Request . 36
11.1.2 Service Response . 36
11.2 Set Message Waiting Indicator . 36
11.2.1 Service Request . 36
11.2.2 Service Response . 37
11.3 Get Speaker Mute. 37
11.3.1 Service Request . 37
11.3.2 Service Response . 37
11.4 Set Speaker Mute . 38
11.4.1 Service Request . 38
11.4.2 Service Response . 38
iv © ISO/IEC 2005 – All rights reserved

11.5 Get Speaker Volume.39
11.5.1 Service Request.39
11.5.2 Service Response.39
11.6 Set Speaker Volume .40
11.6.1 Service Request.40
11.6.2 Service Response.40
12 Logical Phone Features .41
12.1 Get Do Not Disturb.41
12.1.1 Service Request.41
12.1.2 Service Response.41
12.2 Set Do Not Disturb.41
12.2.1 Service Request.42
12.2.2 Service Response.42
12.3 Get Forwarding .42
12.3.1 Service Request.42
12.3.2 Service Response.42
12.4 Set Forwarding.43
12.4.1 Service Request.43
12.4.2 Service Response.44
13 Monitoring Services and Events .44
13.1 Monitor Start.44
13.1.1 Service Request.44
13.1.2 Positive Service Response .45
13.1.3 Negative Service Response.45
13.2 Monitor Stop.46
13.2.1 Service Request.46
13.2.2 Positive Service Response .47
13.2.3 Negative Service Response.47
13.3 Events .47
14 Snapshot Services.48
14.1 Snapshot Device.48
14.1.1 Service Request.48
14.1.2 Positive Service Response .48
14.1.3 Negative Service Response.51
15 Discovery and System Status Services .51
15.1 Get CSTA Features .51
15.1.1 Service Request.52
15.1.2 Service Response.52
15.1.3 Negative Service Response.53
15.2 Request System Status.53
15.2.1 Service Request.53
15.2.2 Service Response.53
15.2.3 Negative Service Response.54
15.3 System Status .54
15.3.1 Service Request.54
15.3.2 Positive Service Response .55
15.3.3 Negative Service Response.55
16 ECMA-323 Illustrative Examples .55
16.1 Controlling a SIP UA.55
16.1.1 Creating an Application Session, Establishing a Monitor for a SIP Phone.56
16.1.2 Creating a Call from a SIP UA, Clearing a Call at a SIP UA .58
16.1.3 Answering and Clearing an Incoming Call at a UA .63
16.1.4 Answering an Incoming Call at a UA (no CSTA monitor or CSTA events).65
16.1.5 Examples of Exception Conditions at a SIP UA .67
16.2 Controlling a PBX Phone .68
16.2.1 Creating an Application Session, Establishing a Monitor for a PBX Phone .69
16.2.2 Creating a Call from a PBX Phone, Clearing a Call at a PBX Phone .71
© ISO/IEC 2005 – All rights reserved v

16.2.3 Answering and Clearing an Incoming Call at a PBX Phone . 75
16.2.4 Examples of Exception Conditions at a PBX Phone . 78
Annex A (informative) Example use of SIP and TEL URIs. 80

vi © ISO/IEC 2005 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report
of one of the following types:
— type 1, when the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts;
— type 2, when the subject is still under technical development or where for any other reason there is the
future but not immediate possibility of an agreement on an International Standard;
— type 3, when the joint technical committee has collected data of a different kind from that which is
normally published as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether
they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to
be reviewed until the data they provide are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 22767, which is a Technical Report of type [3], was prepared by Ecma International (as
ECMA TR/87) and was adopted, under a special “fast-track procedure”, by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommitte SC 6, Telecommunications and information exchange
between systems, in parallel with its approval by national bodies of ISO and IEC.
© ISO/IEC 2005 – All rights reserved vii

Introduction
This Technical Report illustrates how CSTA can be used over a SIP session to control and observe SIP user
agents (uaCSTA).
This Technical Report is part of a suite of Ecma CSTA Phase III Standards and Technical Reports.
All of the Standards and Technical Reports in this suite are based upon the practical experience of Ecma
member companies and each one represents a pragmatic and widely based consensus.
viii © ISO/IEC 2005 – All rights reserved

TECHNICAL REPORT ISO/IEC TR 22767:2005(E)

Information technology — Telecommunications and information
exchange between systems — Using CSTA for SIP phone user
agents (uaCSTA)
1 Scope
The Session Initiation Protocol (SIP) is a control (signalling) protocol for creating, modifying, and terminating
sessions with one or more participants. These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences.
CSTA standardizes a very powerful and flexible set of application services to observe and control voice and
non-voice media calls as well as control and observe non-call related features.
This Technical Report describes how CSTA can be used to provide a subset of CSTA call control functionality,
st
called 1 party call control, for SIP user agents. The term uaCSTA (for user agent CSTA) refers to
transporting ECMA-323 (CSTA XML) messages over a SIP session.
uaCSTA leverages SIP mechanisms to provide a highly featured, robust, and extensible set of features to
support applications in the Enterprise environment.
uaCSTA can be implemented by several different types of SIP user agents:
• directly by a SIP user agent on a SIP phone
• uaCSTA can also be implemented by a SIP B2BUA to augment 3PCC functionality
• by a proxy server that is front-ending a PBX.
2 Purpose
• Describe the relevant portions of the CSTA Standards – The two primary CSTA Standards, Services for
Computer Supported Telecommunications Applications (ECMA-269) and the XML Protocol for CSTA
(ECMA-323), are relatively large standards (combined over 1100 pages). Due to their size it is sometimes
difficult for SIP developers without prior knowledge of CSTA standards to quickly find the relevant parts of
the CSTA standards needed to implement basic features. This TR shows the relevant CSTA concepts and
how they can be used to implement a CSTA-based application protocol without having to read all of the
CSTA Standards.
• Terminology – Although many of the concepts are similar, different terms are used in SIP and CSTA to
describe the same concepts. Since CSTA is designed to be protocol independent, it is helpful to show
how the abstract terminology of CSTA is mapped to SIP specific terminology.
• Extensibility - A SIP phone that is being developed to support a specific application may initially need to
only support a small subset of the features standardized in CSTA. As the types and complexity of
applications using these devices increase, it is expected that these devices will need to support additional,
more advanced, features standardized by CSTA, similar to features supported by other types of phones in
Enterprise environments. This TR shows how basic features can be extended to support a rich standards-
based feature set for applications.
© ISO/IEC 2005 – All rights reserved 1

• Interoperability - In order to encourage interoperability of applications and phones supporting this
application protocol, additional CSTA Profiles, which include minimal sets of CSTA functionality, are
described. These profiles can be extended by implementations to provide a more complete set of call and
devices features commonly used by Enterprise applications.
3 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
This TR provides informative examples of how to use CSTA concepts as an application protocol for SIP user
agents. The following Ecma Standards should be used as the definitive references for CSTA.
th
ECMA-269, Services for Computer Supported Telecommunications Applications (CSTA) Phase III, 6 edition,
June 2004 (International Standard ISO/IEC 18051)
rd
ECMA-323, XML Protocol for Computer Supported Telecommunications Applications (CSTA) Phase III, 3
edition, June 2004 (International Standard ISO/IEC 18056)
The following IETF references provide information on the SIP features referenced in this TR:
RFC 3261, SIP: Session Initiation Protocol, Rosenberg, J. et al, IETF, June 2002
4 Terminology
4.1 General terms
The following table summarizes some of the commonly used terminologies used in this Technical Report.
application Refers to all components that control and observe uaCSTA instances
that may be present in an application/computing domain such as an
application residing on any type of computing device (desktop PC,
mobile computing device, CTI middleware, SIP B2BUA, SIP UA, etc.).
uaCSTA user agent CSTA – This refers the mechanism to transport CSTA
st
messages over a SIP session, and the type of call control, called 1
party call control, that allows an application to control and observe
only the device or devices it is directly involved with. A desktop
application controlling its associated phone, for example.
uaCSTA device Refers to a SIP UA, such as a SIP or PBX phone, that supports the
CSTA features over SIP as described in this TR.
phone A SIP UA that supports calls. It is also a PBX device that supports
calls. Examples of the types of phones that can be supported by this
application protocol are described in clause 6.
B2BUA A back-to-back-user-agent is a type of user agent that acts both as a
user agent server (receives requests) and acts as a user agent client
(generates requests). B2BUA is used to implement SIP third party call
control (3PCC) features. uaCSTA could be used to augment the
existing B2BUA functionality for enhanced call control.

2 © ISO/IEC 2005 – All rights reserved

4.2 SIP/CSTA Terminology Mappings
The following table shows some of the common SIP terms and how they are referenced using CSTA and vice
versa.
SIP Term CSTA Term Notes
User Agent or UA device A SIP UA can be modelled as a type of CSTA
device.
Whenever the term device is used in this TR, it is
referring to a SIP UA.
SIP URI device identifier A SIP URI can be used to address a SIP UA or a
or deviceID PBX phone in the same way that a CSTA device
identifier can be used to address a CSTA device.
One of the formats of a Device Identifier is URI.
Whenever the term DeviceID is used in this TR, it is
referring to a URI format of CSTA deviceID.
Refer to Annex A for a description of the ways to
represent a user and a user’s device with a URI.
TEL URI device identifier A TEL URI can be used to address a device or a
or deviceID dialled number in the same way that a CSTA device
identifier can be used to address a CSTA device.
Refer to Annex A for a description of the ways to
represent a device and a dialled number with a TEL
URI.
5 Example Environments for uaCSTA
The following figures illustrate how uaCSTA is used to pass ECMA-323 messages between an application and
a user agent that supports this protocol. uaCSTA provides a standards-based protocol for applications to use
to request a UA to invoke features.
The term uaCSTA device refers to a SIP UA, such as a SIP phone, that supports the ECMA-323 messages
over SIP as described in this Technical Report.
5.1 Controlling and Observing a SIP Phone
In this environment, a PC-based application can use uaCSTA to directly control and observe its associated
SIP UA phone.
© ISO/IEC 2005 – All rights reserved 3

PC-based CSTA
client application
uaCSTA
SIP
protocol
uaCSTA
Other SIP
enabled SIP
phone
Phone
5.2 Controlling and Observing a SIP Phone by Augmenting B2BUA Functionality
In this environment, uaCSTA is used to augment existing B2BUA functionality to invoke features on the SIP
phone not possible with standard SIP.
CSTA client
CSTA
application
XML
SIP
Application
uaCSTA
Server
(B2BUA)
SIP
protocol
uaCSTA
Other SIP
enabled SIP
phone
Phone
5.3 Controlling a PBX Phone
In this environment, a PC-based application can use uaCSTA to control its associated PBX phone that is part
of a PBX/IP Switch. A SIP/CSTA Gateway is a type SIP UA that terminates SIP and converts ECMA-323
messages to/from an application to/from PBX dependent protocols. The uaCSTA Gateway allows an
st
application to control only its associated device(s) – (1 party call control).
4 © ISO/IEC 2005 – All rights reserved

PC-based CSTA
uaCSTA
client application
uaCSTA
Gateway
PBX
Phones
PBX Specific
Protocol (could
be CSTA)
PBX
6 Example User Agent Configurations
CSTA defines two elements that are relevant for user agents:
• A logical element – the set of attributes/features/services that have an association with the control and/or
observation of calls at a UA. For example (line) appearances and attributes such as forwarding. Some
phones provide more than one addressable logical elements (e.g. multi line phones). Some phones share
a logical element among multiple physical devices (e.g. bridged appearance phones).
• A physical element – the set of attributes/features/services that have any association with the control or
observation of the physical components (speaker, microphone, display, etc.) of a UA.
Some UAs provide a single address which can be used to address all of its (logical and physical) elements
while other UAs provide multiple addresses so that requests can be directed to a specific logical element on
the UA (e.g. a specific line on a multi-line phone).
This chapter discusses the typical types of phones that can be supported by this application protocol, the
types of elements supported by phone type, and how applications can address each element.
6.1 Single Line Phone UA
A single line phone is a type of user agent that supports only one logical element (addressable line) not
shared with any other device and a single physical element (see 6.1.3.3.2 of ECMA-269). The single line can
support one or more calls at the same time.
For a single line phone, a single CSTA deviceID (e.g. SIP URI) is used to reference both the phone’s logical
and physical elements.
For example if the phone has registered with the contact address of sip:1234@domain1, the various elements
of the phone could be addressed via CSTA services as follows:
• phone’s logical element with a call control feature: To originate a call from the single line, an application
would provide sip:1234@domain1 as the callingDevice in the CSTA Make Call service.
© ISO/IEC 2005 – All rights reserved 5

• phone’s logical element with a logical device feature: To control the forwarding feature for the single line,
an application would provide sip:1234@domain1 as the deviceID in the CSTA Set Forwarding service.
• phone’s physical element with a physical device feature: To set the speaker mute for the device, an
application would provide sip:1234@domain1 as the deviceID in the CSTA Set Speaker Mute service.
6.2 Multi Line Phone UA
A multi line phone is a type of user agent that supports more than one addressable line (see 6.1.3.3.3 of
ECMA-269). Each line can support one or more calls at the same time.
For a multi line phone, there are multiple logical elements (lines) and a single physical element.
For a multi line phone, each logical element (line) is addressed with a unique CSTA deviceID (e.g. SIP URI).
CSTA services that reference a phone’s logical element use the deviceID (e.g. SIP contact URI) associated
with the desired line. CSTA services that apply to the physical element address it via any one of the SIP
contact URIs since they all, in this phone configuration, refer to the same device.
For example if the phone has registered with the contacts of sip:1234@domain1 and sip:5678@domain1, the
various elements of the phone could be addressed via CSTA services as follows:
• phone’s logical component with a call control feature:
⎯ To originate a call from the line addressed via sip:1234@domain1, an application would provide
sip:1234@domain1 as the callingDevice in the CSTA Make Call service.
⎯ To originate a call from the line addressed via sip:5678@domain1, an application would provide
sip:5678@domain1 as the callingDevice in the CSTA Make Call service.
• phone’s logical element with a logical device feature:
⎯ To control the forwarding feature for the line addressed via sip:1234@domain1, an application would
provide sip:1234@domain1 as the deviceID in the CSTA Set Forwarding service.
⎯ To control the forwarding feature for the line addressed via sip:5678@domain1, an application would
provide sip:5678@domain1 as the deviceID in the CSTA Set Forwarding service.
• phone’s physical element with a physical device feature: To set the speaker mute for the device, an
application would provide either one of the following:
⎯ sip:1234@domain1 as the deviceID in the CSTA Set Speaker Mute service. Since this contact is only
associated with one physical device, it would be unambiguous.
⎯ sip:5678@domain1 as the deviceID in the CSTA Set Speaker Mute service. Since this contact is only
associated with one physical device, it would be unambiguous.
6.3 Bridged Appearance Phone and other Advanced UA Configurations
A bridged-appearance phone is a type of user agent that contains a logical element (e.g. a line) shared with
another phone (see 6.1.3.3.5 of ECMA-269).
CSTA specifies many different kinds of bridged appearances that reflect the different behaviours and different
capabilities for calls at shared appearances. (See bridged calls in section of ECMA-269.)
uaCSTA does not specify (nor preclude) the behaviour or the addressing of bridged appearances and other
advanced UA configurations.
6 © ISO/IEC 2
...