| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 28, 2009.
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 extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. This document discusses requirements and approaches and recommends a new header field be standardized. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is in an Automatic Call Distributor (ACD) in a contact center.
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.
Possible Mechanisms
5.1.
Why INFO is Not Used
5.2.
MIME body Approach
5.3.
URI Parameter
5.4.
Header Field Approach
6.
Recommendation
7.
Appendix - Syntax for UUI Header Field
7.1.
IANA Considerations
7.1.1.
Registration of Header Field
7.1.2.
Registration of Header Field Parameter
7.1.3.
Registration of SIP Option Tag
8.
Security Considerations
9.
Acknowledgements
10.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| 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),” .) data in SIP. Q.931 UUI is widely used in the PSTN today in contact center 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 not able or 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. 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 discussed. Then, three mechanisms are discussed and compared. The Appendix contains a header field definition which meets all the requirements.
| 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 that 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 (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 will allow the UUI to be transported directly in the SIP message.
Passing a pointer or link to the UUI information will not meet the real-time processing considerations.
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.
| TOC |
This section discusses four uses 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 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.
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.
| 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 |
Three possible mechanisms for transporting UUI will be described: MIME body, URI parameter, and header field transport.
| TOC |
Since the INFO method [RFC2976] (Donovan, S., “The SIP INFO Method,” October 2000.)., was developed for ISUP interworking of user-to-user information, it might seem to be the logical choice here. For non-call control user-to-user information, INFO can be utilized for end to end transport. However, for transport of call control user-to-user information, INFO can not be used. As the call flows in the previous section show, the information is related to an attempt to establish a session and must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases.
| TOC |
One method of transport is to transport the UUI information as a MIME body. This is in keeping with the SIP-T architecture [RFC3372] (Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” September 2002.) in which MIME bodies are used to transport ISUP information. Since the INVITE will normally have an SDP message body, the resulting INVITE with SDP and UUI will be multipart MIME. The insertion of a UUI message body by a redirect server or in a REFER is difficult. The body would need to be encoded in the Contact URI of the 3xx response or the Refer-To URI of a REFER. For example:
<allOneLine> Contact: <sip:+12125551212@gateway.example.com?Content-Type= application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs> </allOneLine>
Note that the <allOneLine> tag convention from SIP Torture Test Messages (Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, “Session Initiation Protocol (SIP) Torture Test Messages,” May 2006.) [RFC4475] is used to show that there are no line breaks in the actual message syntax.
The MIME body approach meets REQs 1-5. However, it does not meet REQ-6 as support for Multipart MIME and escaped bodies in URIs is uncommon in SIP UAs.
| TOC |
Another proposed approach is to encode the UUI as a URI parameter into the Contact or Refer-To URI.
<allOneLine> Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6 F5iJ90m6mvuTS4OK05M0vDk0Q4Xs> </allOneLine>
An INVITE sent to this Contact URI would contain UUI in the Request-URI of the INVITE. The URI parameter has a drawback in that a URI parameter will not survive retargeting by a proxy as shown in Figure 2. That is, if the URI is included with an Address of Record instead of a Contact URI, the URI parameter will not be copied over to the Contact URI, resulting in the loss of the information. As a result, this approach does not meet REQ-4.
| TOC |
Another approach that has been proposed is to use a header field to transport the UUI information. The header field would be included in INVITE requests and responses and BYE requests and responses, and would pass transparently through proxies. For redirection, the header field would be escaped into the Contact or Refer-To URI. This is commonly supported in UAs due to call transfer use cases. As a result, the header field approach supports REQs 1-6. In order to meet REQ-7, a SIP feature tag is needed which can be included in Supported and Require header fields.
The Call-Info header field is related to the UUI information. However, there are a number of important differences:
Call-Info is typically used for rendering to the user. While some of the UUI information may ultimately be rendered to the user, most of the UUI information will be consumed by the end device.
Call-Info usually contains a URI pointer the information instead of the actual information itself which does not REQ-5. It could be possible to use a data URI to carry the UUI directly in this header field.
The use of Call-Info for interworking to and from ISDN networks seems problematic.
Overall, the overloading of the Call-Info header field for carrying interworked UUI does not seem like a good idea. A separate header field allows for clear policy and authorization rules to be used. For these reasons, a separate header field needs to be defined, described here as User-to-User. For example, here is an example User-to-User header field from message F1 in Figure 1:
User-to-User: 56a390f3d2b7310023a;encoding=hex
For example, here is an escaped User-to-User header field from the redirection response F2 of Figure 3:
<allOneLine> Contact: <sip:+12125551212@gateway.example.com?User-to-User= 56a390f3d2b7310023a%3Bencoding%3Dhex> </allOneLine>
The resulting INVITE F5 would contain the User-to-User header field of the previous example.
An escaped User-to-User header field from the REFER message response F1 of Figure 4:
<allOneLine> Refer-To: <sip:+12125551212@gateway.example.com?User-to-User= 56a390f3d2b7310023a%3Bencoding%3Dhex> </allOneLine>
This would result in the INVITE F4 containing the User-to-User header field of the first example.
| TOC |
The recommendation is to define a new SIP header field "User-to-User" to transport UUI information in ISDN interworking applications since this mechanism best supports the requirements. A SIP feature tag "uui" also needs to be defined so that it can be used in Supported and Require header fields to meet REQ-6.
The format of the UUI information is a topic of future standardization. Currently, UUI is proprietary, requiring coordinated configuration between servers. Standardizing the format or providing content tags would provide additional benefits.
| TOC |
Editor's Note: Eventually this text will move to a SIP Working Group document to define the new header field.
The User-to-User header field can be present in INVITE requests and responses only and in BYE requests and responses.
Current usage is to interoperate with ISDN User to User Signaling (UUS), a supplementary service in which manufacturer specific information is transported via the codeset 0 User-user Information IE. Three services are defined: service 1, service 2, and service 3. This draft only addresses the SIP equivalent of service 1 although it could easily be expanded later to address services 2 and 3. UUS Service 1 involves user to user signaling exchanged during call setup and clearing within the following Q.931 call control messages: SETUP, ALERT, CONNECT, DISCONNECT, RELEASE, and RELEASE COMPLETE. UUS Service 2 involves user to user signaling exchanged during call establishment (between ALERT and CONNECT) via the USER INFORMATION message. This service usually has a maximum of 2 USER INFORMATION messages in each direction. UUS Service 3 involves user to user signaling exchanged on an active call via the USER INFORMATION message.
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 and extends RFC 3261.
UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
uui-data = token
uui-param = enc-param | generic-param
enc-param = "encoding=" ("hex" | token)
Only one User-to-User header field may be present in a request or response.
The only defined parameter for the User-to-User header field is the encoding parameter. "encoding=hex" is used to indicate that the UUI information is encoded as hex digits per the ISDN specification. The first octet is the protocol discriminator). Other encoding methods of encoding MAY also be standardized.
The UUI data MUST be less than 129 octets in length. This is because ISDN limits UUI to 128 octets in length plus the single octet protocol discriminator. Transporting UUI longer than 128 octets will result in interoperability failures when interworking with ISDN.
| TOC |
| TOC |
This document defines a new SIP header field named "User-to-User".
The following row shall be added to the "Header Fields" section of the SIP parameter registry:
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [RFCXXXX] |
+------------------+--------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of the eventual SIP Working Group document.
| TOC |
This document defines a parameter for the header field defined in the preceding section. The header field "User-to-User" can contain the parameter "encoding".
The following rows shall be added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:
+------------------+----------------+-------------------+-----------+ | Header Field | Parameter Name | Predefined Values | Reference | +------------------+----------------+-------------------+-----------+ | User-to-User | encoding | No | [RFCXXXX] | +------------------+----------------+-------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of the eventual SIP Working Group document.
| TOC |
This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
This document defines the SIP option tag "uui".
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
+------------+------------------------------------------+-----------+ | Name | Description | Reference | +------------+------------------------------------------+-----------+ | uui | This option tag is used to indicate that | [RFCXXXX] | | | a UA supports and understands the | | | | User-to-User header field. | | +------------+------------------------------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of the eventual SIP Working Group document.
| 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 contain private information that would require confidentiality and message integrity. Standard SIP security mechanisms can be used to secure this header field. For example, TLS transport can provide these properties over a single hop. For multiple hop or end-to-end confidentiality and integrity protection, S/MIME can be utilized.
Received User-to-User information should only be trusted if it is authenticated or 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, appropriate policy should be applied based on the PSTN trust domain.
| TOC |
The authors wish to thank Francois Audet, Denis Alexeitsev, Keith Drage, Paul Kyzivat, 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 . |
| [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). |
| [RFC4475] | Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, “Session Initiation Protocol (SIP) Torture Test Messages,” RFC 4475, May 2006 (TXT). |
| TOC |
| Alan Johnston (editor) | |
| Avaya | |
| St. Louis, MO 63124 | |
| Email: | alan@sipstation.com |
| Joanne McMillen | |
| Avaya | |
| Email: | joanne@avaya.com |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.