CUSS WG A. Johnston
Internet-Draft Avaya
Intended status: Informational L. Liess
Expires: November 29, 2011 Deutsche Telekom AG
May 28, 2011
Problem Statement and Requirements for Transporting User to User Call
Control Information in SIP
draft-ietf-cuss-sip-uui-reqs-02
Abstract
This document introduces the transport of call control related User
to User Information (UUI) using the Session Initiation Protocol
(SIP), and develops several requirements for a new SIP mechanism.
Some SIP sessions are established by or related to a non-SIP
application. This application may have information that needs to be
transported between the SIP User Agents during session establishment.
A common example in another protocol is the ISDN User to User
Information Service. As networks move to SIP it is important that
applications requiring this data can continue to function in SIP
networks as well as the ability to interwork with this ISDN service
for end-to-end transparency. This document discusses requirements
and approaches to achieve this. In addition, the extension will also
be used for native SIP endpoints implementing similar services and
interworking with ISDN services. Example use cases include an
exchange between two user agents, retargeting by a proxy, and
redirection. An example application is an Automatic Call Distributor
(ACD) in a contact center.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2011.
Johnston & Liess Expires November 29, 2011 [Page 1]
Internet-Draft SIP UUI Reqs May 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 4
3.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 5
3.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Johnston & Liess Expires November 29, 2011 [Page 2]
Internet-Draft SIP UUI Reqs May 2011
1. Overview
This document describes the transport of User to User Information
(UUI) during session setup. This section introduces UUI and explains
how it relates to SIP.
We define SIP UUI information as application-specific information
that is related to a session being established using SIP. It is
assumed that the application is running in both the originator of the
session and the terminator of the session. That is, the application
interacts with the User Agent Client (UAC) and User Agent Server
(UAS). In order to function properly, the application needs a small
piece of information, the UUI, to be transported at the time of
session establishment. This information is essentially opaque data
to SIP - it is unrelated to SIP routing, authentication, or any other
SIP function. This application can be considered to be operating at
a higher layer on the protocol stack. As a result, SIP should not
interpret, understand, or perform any operations on the UUI. Should
this not be the case, then the information being transported is not
considered UUI, and another SIP-specific mechanism will be needed to
transport the information (such as a new header field).
UUI is defined this way for two reasons. Firstly, this supports a
strict layering of protocols and data. Providing information and
understanding of the UUI to the transport layer (SIP in this case)
would not provide any benefits and instead could create cross layer
coupling. Secondly, it is neither feasible nor desirable for a SIP
User Agent (UA) to understand the information; instead the goal is
for the UA to simply pass the information as efficiently as possible
to the application which does understand the information.
An important application is the interworking with User to User
Information (UUI) in ISDN, specifically, the transport of the call
control related ITU-T Q.931 User to User Information Element (UU IE)
[Q931] and ITU-T Q.763 User to User Information Parameter [Q763] data
in SIP. ISDN UUI is widely used in the PSTN today in contact centers
and call centers. These applications are currently transitioning
away from using ISDN for session establishment to using SIP. Native
SIP endpoints will need to implement a similar service and be able to
interwork with this ISDN service.
Note that the distinction between call control UUI and non-call
control UUI is very important. SIP already has a mechanism for
sending arbitrary UUI information between UAs during a session or
dialog - the SIP INFO [RFC2976] method. Call control UUI, in
contrast, must be exchanged at the time of setup and needs to be
carried in the INVITE and a few other methods and responses.
Applications that exchange UUI but do not have a requirement that it
Johnston & Liess Expires November 29, 2011 [Page 3]
Internet-Draft SIP UUI Reqs May 2011
be transported and processed during call setup can simply use SIP
INFO and do not need a new SIP extensions.
In this document, four different use case call flows are discussed.
Next, the requirements for call control UUI transport are discussed.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Use Cases
This section discusses four use cases for the transport of call
control related user to user information. What is not discussed here
is the transport of non-call control UUI which can be done using the
SIP INFO method. These use cases will help motivate the requirements
for SIP call control UUI.
3.1. User Agent to User Agent
In this scenario, the originator UA includes UUI in the INVITE sent
through a proxy to the terminating UA. The terminator can use the
UUI in any way. If it is an ISDN gateway, it could map the UUI into
the appropriate DSS1 information element or QSIG information element
or ISUP parameter. Alternatively, the using application might render
the information to the user, or use it during alerting or as a lookup
for a screen pop. In this case, the proxy does not need to
understand the UUI mechanism, but normal proxy rules should result in
the UUI being forwarded without modification. This call flow is
shown in Figure 1.
Originator Proxy Terminator
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Johnston & Liess Expires November 29, 2011 [Page 4]
Internet-Draft SIP UUI Reqs May 2011
Figure 1. Call flow with UUI exchanged between Originator and
Terminator.
3.2. Proxy Retargeting
In this scenario, the originator UA includes UUI in the INVITE sent
through a proxy to the terminating UA. The proxy retargets the
INVITE, sending it to a different termination UA. The UUI
information is then received and processed by the terminating UA.
This call flow is shown in Figure 2.
Originator Proxy Terminator 2
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 2. Call flow with Proxy Retargeting.
The UUI in the INVITE needs to be passed unchanged through this proxy
retargeting operation.
3.3. Redirection
In this scenario, UUI is inserted by an application which utilizes a
SIP redirect server. The UUI is then included in the INVITE sent by
the Originator to the Terminator. In this case, the Originator does
not necessarily need to support the UUI mechanism but does need to
support the SIP redirection mechanism used to include the UUI
information. Two examples of UUI with redirection (transfer and
diversion) are defined in [ANSII] and [ETSI].
Note that this case may not precisely map to an equivalent ISDN
service use case. This is because there is no one-to-one mapping
between elements in a SIP network and elements in an ISDN network.
Also, there is not an exact one-to-one mapping between SIP call
control and ISDN call control. However, this should not prevent the
usage of SIP call control UUI in these cases. Instead, these slight
differences between the SIP UUI service and the ISDN service need to
be carefully noted and discussed in an interworking specification.
Figure 3 shows this scenario, with the Redirect inserting UUI which
Johnston & Liess Expires November 29, 2011 [Page 5]
Internet-Draft SIP UUI Reqs May 2011
is then included in the INVITE F4 send to the Terminator.
Originator Redirect Server Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
Figure 3. Call flow with UUI exchanged between Redirect Server and
Terminator.
If the Redirect Server is not in the same administrative domain as
the Terminator, the Redirect Server must not remove or replace any
UUI in the initial INVITE. In Figure 3, this means that if F1
included UUI, the Redirect Server could not modify or replace the UUI
in F2. However, if the Redirect Server and the Terminator are part
of the same administrative domain, they may have a policy allowing
the Redirect Server to modify or rewrite UUI information. In fact,
many UUI uses within an Enterprise rely on this feature to work today
in ISDN.
A common example application of this call flow is an Automatic Call
Distributer (ACD) in a PSTN contact center. The originator would be
a PSTN gateway. The ACD would act as a Redirect Server, inserting
UUI based on called number, calling number, time of day, and other
information. The resulting UUI would be passed to the agent's
handset which acts as the Terminator. The UUI could be used to
lookup information rendered to the agent at the time of call
answering.
This redirection scenario, and the referral scenario in the next
section, are the most important scenarios for contact center
applications. Incoming calls to a contact center almost always are
redirected or referred to a final destination, sometimes multiple
times, based on collected information and business logic. The
ability to maintain UUI in these scenarios is critical.
Johnston & Liess Expires November 29, 2011 [Page 6]
Internet-Draft SIP UUI Reqs May 2011
3.4. Referral
In this scenario, the application uses a UA to initiate a referral,
which causes an INVITE to be generated between the Originator and
Terminator with UUI information inserted by the Referrer UA. Note
that this REFER [RFC3515] could be part of a transfer operation or it
might be unrelated to an existing call, such as out-of-dialog REFER
call control. In some cases, this call flow is used in place of the
redirection call flow where immediately upon answer, the REFER is
sent. This scenario is shown in Figure 4.
Originator Referrer Terminator
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| NOTIFY (100 Trying) F3 |
|------------------->| |
| 200 OK F4 | |
|<-------------------| |
| INVITE (UUI) F5 | |
|---------------------------------------->|
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
Figure 4. Call flow with Referral and UUI.
4. Requirements
This section discusses the requirements for the transport of call
control related user to user information (UUI).
REQ-1: The mechanism will allow UAs to insert and receive UUI data in
SIP call setup requests and responses.
SIP messages covered by this include INVITE requests and end-to-
end responses to the INVITE, which includes 18x and 200 responses.
REQ-2: The mechanism will allow UAs to insert and receive UUI data in
SIP dialog terminating requests and responses.
Johnston & Liess Expires November 29, 2011 [Page 7]
Internet-Draft SIP UUI Reqs May 2011
Q.931 UUI supports inclusion in release and release completion
messages. SIP messages covered by this include BYE and 200 OK
responses to a BYE.
REQ-3: The mechanism will allow UUI to be inserted and retrieved in
SIP redirects and referrals.
SIP messages covered by this include 3xx responses to INVITE and
REFER requests.
REQ-4: The mechanism will allow UUI to be able to survive proxy
retargeting or any other form of redirection of the request.
Retargeting is a common method of call routing in SIP, and must
not result in the loss of user to user information.
REQ-5: The mechanism should not require processing entities to
dereference a URL in order to retrieve the UUI information.
Passing a pointer or link to the UUI information will not meet the
real-time processing considerations and would complicate
interworking with the PSTN.
REQ-6 has been deleted. To avoid confusion, the number will not be
reused.
REQ-7: The mechanism will support interworking with call control
related DSS1 information elements or QSIG information elements or
ISUP parameters.
REQ-8: The mechanism will allow a UAC to learn or request that a UAS
understands the call control UUI mechanism and permit routing of
requests based on this.
This could be useful in ensuring that a request destined for the
PSTN is routed to a gateway that supports the ISDN UUI service
rather than an otherwise equivalent PSTN gateway that does not
support the ISDN UUI service. Note that support of the UUI
mechanism does not, by itself, imply that a particular user
application is supported - see REQ-10.
REQ-9: The mechanism will allow proxies to remove a particular type
of UUI information from a request or response.
This is a common security function provided by border elements to
header fields such as Alert-Info or Call-Info URIs.
REQ-10: The mechanism will provide the ability for a UA to discover
Johnston & Liess Expires November 29, 2011 [Page 8]
Internet-Draft SIP UUI Reqs May 2011
which types or application usages of UUI another UA understands or
supports.
The creation of a registry of application usages for the SIP UUI
mechanism is implied by this requirement. For the ISDN Service,
there could be value in utilizing the protocol discriminator,
which is the first octet of the ISDN UUI information, for this
purpose.
REQ-11: The solution will provide a mechanism of transporting at
least 128 octets of user data and a one octet protocol discriminator,
i.e. 129 octets in total.
There is the potential for non-ISDN services to allow UUI to be
larger than 128 octets. However, users of the mechanism will need
be cognizant of the size of SIP messages and the ability of
parsers to handle extremely large values.
REQ-12: The recipient of UUI will be able to determine the entity
that inserted the UUI. It is acceptable that this is performed
implicitly where it is known that there is only one other end UA
involved in the dialog. Where that does not exist, some other
mechanism will need to be provided.
This requirement comes into play during redirection, retargeting,
and referral scenarios.
REQ-13: The mechanism will allow integrity protection of the UUI.
This allows the UAS to be able to know that the UUI has not been
modified or tampered with by intermediaries. This property is not
guaranteed by the protocol in the ISDN application.
REQ-14: The mechanism will allow end-to-end privacy of the UUI.
Some UUI may contain private or sensitive information and may
require different security handling from the rest of the SIP
message. Note that this property is not available in the ISDN
application. In some cases, this requirement could be met by a
SIP privacy mechanism. In other cases, the application may
provide this service, encrypting the UUI before passing to the SIP
layer and decrypting upon receipt after receiving the UUI from the
SIP layer. In no cases should an intermediary element assume that
it will be able to read or interpret the UUI, as it only has end-
to-end significance.
Johnston & Liess Expires November 29, 2011 [Page 9]
Internet-Draft SIP UUI Reqs May 2011
5. Security Considerations
The security requirements for the SIP UUI mechanism are described in
REQ-13 and REQ-14, providing integrity protection and/or privacy. In
addition, there is an identity requirement in REQ-12, which relates
to the ability for the UAS to know who inserted the UUI.
It is important to note that UUI security is jointly provided at the
application layer and at the SIP layer. As such, is important for
application users of SIP UUI to know the realistic level of security
used and deployed in SIP, and not assume that some rarely deployed
SIP level security mechanism is in place.
6. Acknowledgements
Thanks to Joanne McMillen who was a co-author of earlier versions of
this specification. Thanks to Spencer Dawkins, Keith Drage, and
Vijay Gurbani for their review of earlier versions of this document.
The authors wish to thank Christer Holmberg, Frederique Forestie,
Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and
Mahalingam Mani for their comments on this topic.
7. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
formats and codes",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services
Digital Network (ISDN)-Explicit Call Transfer
Supplementary Service".
[ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
Digital Network (ISDN); Diversion supplementary services".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Johnston & Liess Expires November 29, 2011 [Page 10]
Internet-Draft SIP UUI Reqs May 2011
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
Authors' Addresses
Alan Johnston
Avaya
St. Louis, MO 63124
Email: alan.b.johnston@gmail.com
Laura Liess
Deutsche Telekom AG
Email: laura.liess.dt@gmail.com
Johnston & Liess Expires November 29, 2011 [Page 11]
