| TOC |
|
Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. 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.
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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
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 BSD License.
1.
Overview
2.
Terminology
3.
Requirements
4.
Use Cases
4.1.
User Agent to User Agent
4.2.
Proxy Retargeting
4.3.
Redirection
4.4.
Referral
5.
Security Considerations
6.
Acknowledgements
7.
Informative References
§
Authors' Addresses
| TOC |
This document describes the transport of User to User Information (UUI) in ISDN interworking scenarios using SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). Specifically, we discuss the transport of call control related ITU-T Q.931 User to User Information Element (UU IE) [Q931] (, “ITU-T Q.931 User to User Information Element (UU IE),” .) and ITU-T Q.763 User to User Information Parameter [Q763] (, “ITU-T Q.763 Signaling System No. 7 - ISDN user part formats and codes,” .) data in SIP. UUI is widely used in the PSTN today in contact centers and call centers which are transitioning away from ISDN to SIP. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services.
Part of the definition of this ISDN service is that the UUI information is not known and understood by the ISDN network that transports it. This is for two reasons. Firstly, this supports a strict layering of protocols and data. Providing information and understanding of the data to the transport layer would not provide any benefits and instead could create cross layer coupling and increase the complexity of the system. Secondly, either the originator or terminator of the service might be a simple PSTN gateway designed for scalability and lowest cost. As a result, it is neither feasible nor desirable for this device to understand the information but instead the goal is to pass the information as efficiently as possible to another application which does understand the data. Both of these arguments still apply to SIP, especially when one or both endpoints are gateways.
In the future, where both endpoints are intelligent SIP user agents, it may be possible for them to understand and interpret the UUI data. There may be some cases where the UUI information is relevant to SIP. In this case, it might be worthwhile attempting to map UUI data to an appropriate SIP header field or to standardize a new header field, or to mark the UUI data as to the content and purpose. However, the requirements and use cases for this are different enough from those described in this document that these two situations should be examined separately. This document looks only at the requirements and mechanisms for replicating the existing, widely used and deployed ISDN UUI service.
First, the requirements are discussed with use cases. Five different use case call flows are then discussed.
The goal of this document is to generate discussions within the DISPATCH Working Group for a charter for a new RAI area Working Group to define a mechanism to meet these requirements and use cases.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
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 ISDN Provides in the PSTN. Non-call control UUI can be sent using the INFO method and not using the extensions described in this specification.
REQ-1: The mechanism will allow user agents (UAs) to insert and receive ITU-T Q.931 User to User Information Element and Q.763 User to User Information Parameter (referred to as 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 ITU-T Q.931 User to User Information Element (referred to as 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 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 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.
| TOC |
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 help explain the requirements from the previous section.
| TOC |
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, it might render the information to the user, or use it for 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.
This call flow utilizes REQ-1.
| TOC |
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.
This call flow utilizes REQ-1 and REQ-4.
| TOC |
In this scenario, UUI is inserted by a 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] (, “ANSI T1.643-1995, Telecommunications-Integrated Services Digital Network (ISDN)-Explicit Call Transfer Supplementary Service,” .) and [ETSI] (, “ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services Digital Network (ISDN); Diversion supplementary services,” .).
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.
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
This call flow utilizes REQ-1 and REQ-3.
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.
| TOC |
In this scenario, a Referrer UA causes an INVITE to be generated between the Originator and Terminator with UUI information inserted by the Referrer UA. Note that this REFER [RFC3515] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) 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.
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.
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.
| TOC |
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, 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] (Watson, M., “Short Term Requirements for Network Asserted Identity,” November 2002.) 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.
| TOC |
Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura Liess for their review of the document. The authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments.
| TOC |
| [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 (TXT). |
| [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 (TXT, HTML, XML). |
| [RFC3372] | Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” BCP 63, RFC 3372, September 2002 (TXT). |
| [RFC2976] | Donovan, S., “The SIP INFO Method,” RFC 2976, October 2000 (TXT). |
| [RFC3515] | Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, April 2003 (TXT). |
| [RFC3324] | Watson, M., “Short Term Requirements for Network Asserted Identity,” RFC 3324, November 2002 (TXT). |
| TOC |
| Alan Johnston (editor) | |
| Avaya | |
| St. Louis, MO 63124 | |
| Email: | alan.b.johnston@gmail.com |
| Joanne McMillen | |
| Avaya | |
| Email: | joanne@avaya.com |