One document matched: draft-johnston-cuss-sip-uui-reqs-00.txt
CUSS WG A. Johnston, Ed.
Internet-Draft Avaya
Intended status: Informational J. McMillen
Expires: March 19, 2011 Unaffiliated
L. Liess
Deutsche Telekom AG
September 15, 2010
Problem Statement and Requirements for Transporting User to User Call
Control Information in SIP
draft-johnston-cuss-sip-uui-reqs-00
Abstract
This document introduces the transport of call control related User
to User Information (UUI) in 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 ITU-T Q.931 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. This 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."
Johnston, et al. Expires March 19, 2011 [Page 1]
Internet-Draft SIP UUI Reqs September 2010
This Internet-Draft will expire on March 19, 2011.
Copyright Notice
Copyright (c) 2010 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.
Johnston, et al. Expires March 19, 2011 [Page 2]
Internet-Draft SIP UUI Reqs September 2010
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 5
3.2. Proxy Retargeting . . . . . . . . . . . . . . . . . . . . 5
3.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Johnston, et al. Expires March 19, 2011 [Page 3]
Internet-Draft SIP UUI Reqs September 2010
1. Overview
This document describes the transport of User to User Information
(UUI) during session setup. This section will introduce UUI and
explain 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 applicaiton 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, the application needs 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
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 would not provide any
benefits and instead could create cross layer coupling. Secondly, it
is neither feasible nor desirable for a SIP User Agent to understand
the information but instead the goal is for the User Agent to pass
the information as efficiently as possible to an application which
does understand the information.
An important application is the interworking with User to User
Information (UUI) in ISDN, specifically, the transport of 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.
In the rest of this document, the requirements are discussed with use
cases. Five different use case call flows are then discussed.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Johnston, et al. Expires March 19, 2011 [Page 4]
Internet-Draft SIP UUI Reqs September 2010
"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 Q.931 or Q.763 element. 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 |
| |------------------->|
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.
Johnston, et al. Expires March 19, 2011 [Page 5]
Internet-Draft SIP UUI Reqs September 2010
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.
In redirection scenarios, 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.
Johnston, et al. Expires March 19, 2011 [Page 6]
Internet-Draft SIP UUI Reqs September 2010
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
A common 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.
3.4. Referral
In this scenario, application uses a UA 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, but where immediately upon answer, the REFER
is sent. This scenario is shown in Figure 4.
Johnston, et al. Expires March 19, 2011 [Page 7]
Internet-Draft SIP UUI Reqs September 2010
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 transfer after answer.
Some scenarios involving referral have been proposed to use a REFER
sent during an early dialog. This NOT RECOMMENDED call flow is shown
in Figure 5. This flow is not recommended due to the number of
messages exchanged (due to the REFER, CANCEL, and 487 responses) and
the sending of the REFER in the early dialog. Also, there are race
conditions that can occur if a 200 OK to the INVITE is received by
the Originator while the REFER is in progress.
Johnston, et al. Expires March 19, 2011 [Page 8]
Internet-Draft SIP UUI Reqs September 2010
Originator Referrer Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 180 Ringing F2 | |
|<-------------------| |
| REFER (UUI) F3 | |
|<-------------------| |
| 202 Accepted F4 | |
|------------------->| |
| NOTIFY (100 Trying) F5 |
|------------------->| |
| 200 OK F6 | |
|<-------------------| |
| INVITE (UUI) F7 | |
|---------------------------------------->|
| 200 OK F8 |
|<----------------------------------------|
| ACK F9 |
|---------------------------------------->|
| NOTIFY (200 OK) F10| |
|------------------->| |
| 200 OK F11 | |
|<-------------------| |
| CANCEL F12 | |
|------------------->| |
| 200 OK F13 | |
|<-------------------| |
| 487 Request Terminated F14 |
|<-------------------| |
| ACK F15 | |
|------------------->| |
Figure 5. NOT RECOMMENDED call flow showing REFER prior to answer.
4. Requirements
This section discusses the requirements for the transport of call
control related user to user information (UUI). We define call
control UUI as information that is generated, transported, and
consumed at the time of call setup (i.e. during a pending INVITE
transaction). The information can be used for call routing,
alerting, call distribution, or simply rendering. The exact usage
and semantics of call control UUI is out of scope - SIP is simply
providing the transport function for this, in the same manner as the
ISDN service provides in the PSTN. Non-call control UUI can be sent
using the INFO method, and is outside the scope of this work.
Johnston, et al. Expires March 19, 2011 [Page 9]
Internet-Draft SIP UUI Reqs September 2010
REQ-1: The mechanism will allow user agents (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 call teardown requests and responses.
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 to INVITEs.
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.
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 to retrieve the UUI information.
Passing a pointer or link to the UUI information will not meet the
real-time processing considerations and will complicate
interworking with the PSTN.
REQ-6: The mechanism will minimize reliance on SIP extensions or
uncommon SIP behavior.
REQ-7: The mechanism will support interworking with 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].
REQ-8: The mechanism will allow the inserter of UUI to be sure that
the recipient understands the call control UUI mechanism.
Understanding the mechanism means that the UAS will extract and
utilize the UUI information transported. Understanding the
protocol, format, and nature of the actual UUI data is not covered
by this requirement. Note that this requirement is not strictly
needed to implement the UUS 1 implicit service, but maps more
accurately to the UUS 1 explicit service. However, having an
Johnston, et al. Expires March 19, 2011 [Page 10]
Internet-Draft SIP UUI Reqs September 2010
option tag is good design for high reliability systems, and the
dynamic and heterogeneous nature of SIP interconnection (as
opposed to the PSTN's static trunking) makes this option tag much
more important and hence relevant to even the UUS 1 implicit
service.
REQ-9: The mechanism will allow proxies to remove a particular type
of UUI information from a request or response, or to block requests
based on the presence of a particular type of UUI.
This is a common security function provided by border elements to
header fields such as Alert-Info or Call-Info URIs.
5. Security Considerations
User to user information can be exchanged over SIP on a hop-by-hop or
end-to-end basis. In some cases, UUI may carry privacy information
that would require confidentiality and message integrity. Standard
SIP security mechanisms, viz., based on TLS, offer these properties
per-hop. To preserve multi-hop or end-end confidentiality and
integrity, an S/MIME profile MUST be utilized. Since the security
requirements and key management of the UUI information are likely to
be quite different from the SIP signaling transport, another approach
would be for the UUI information to be encrypted before being passed
to SIP for transport.
Received User-to-User information should only be trusted if it is
authenticated or if it is received within a trust domain. For
example, Spec-T, defined in [RFC3324] could be used to define a trust
domain. When utilized by a gateway to map information to or from
ISDN Q.931 and ISUP Q.763, appropriate policy should be applied based
on the PSTN trust domain.
6. Acknowledgements
Thanks to Spencer Dawkins, Keith Drage, and Vijay Gurbani for their
review of earlier versions of this document. The authors wish to
thank 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,
Johnston, et al. Expires March 19, 2011 [Page 11]
Internet-Draft SIP UUI Reqs September 2010
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.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000.
[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 (editor)
Avaya
St. Louis, MO 63124
Email: alan.b.johnston@gmail.com
Joanne McMillen
Unaffiliated
Email: c.joanne.mcmillen@gmail.com
Johnston, et al. Expires March 19, 2011 [Page 12]
Internet-Draft SIP UUI Reqs September 2010
Laura Liess
Deutsche Telekom AG
Email: laura.liess.dt@gmail.com
Johnston, et al. Expires March 19, 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 07:38:26 |