| 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 July 18, 2008.
Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been implemented. 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 the information to/from ISDN for end-to-end transparency. This document discusses the approaches and recommends a new header field User-to-User be standardized. An example application of an Automatic Call Distributor (ACD) in a contact center is given.
1.
Overview
2.
Roles
3.
Approaches
3.1.
Why INFO is Not Used
3.2.
Call Flows
3.3.
MIME body Approach
3.4.
Header Field Approach
3.5.
URI Parameter
4.
Recommendation
5.
Appendix - Syntax for UUI Header Field
6.
IANA Considerations
7.
Security Considerations
8.
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. An example use case is interworking an Automatic Call Distributed (ACD) in a contact center.
| TOC |
There are three roles in a typical Call Center scenario:
Originator - The party generating the call destined for the contact
center.
ACD - The automatic call distributor which performs database
queries and determines proper routing for the call.
Terminator - The destination of the call as determined by the ACD.
| TOC |
Four approaches will be described: MIME body, header field, and URI parameter transport.
| TOC |
Since the INFO method 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 next 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 |
All three approaches use the same call flows, shown in Figures 1, 2, and 4 below. Figure 1 shows the ACD redirecting the call prior to it being answered using a 302 Moved Temporarily response. User to user information (UUI) is added by the ACD which is then included in the INVITE sent to the Terminator. The URI of the terminator is contained in the Contact header field of message F2.
Originator ACD Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
Figure 1. Call flow with redirection prior to answer.
Figure 2 shows a call flow in which the call is answered by the ACD and then the call is transferred using a REFER. If the ACD does not care to receive notification of the outcome of the transfer, the BYE could be sent immediately, or the Refer-Sub: false header field added to the REFER. If the REFER is sent out of dialog, the Target-Dialog header field will need to be present.
Originator ACD Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 200 OK F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| REFER (UUI) F4 | |
|<-------------------| |
| 202 Accepted F5 | |
|------------------->| |
| NOTIFY (100 Trying) F6 |
|------------------->| |
| 200 OK F7 | |
|<-------------------| |
| INVITE (UUI) F8 | |
|---------------------------------------->|
| 200 OK F9 |
|<----------------------------------------|
| ACK F10 |
|---------------------------------------->|
| NOTIFY (200 OK) F11| |
|------------------->| |
| 200 OK F12 | |
|<-------------------| |
| BYE F13 | |
|<-------------------| |
| 200 OK F14 | |
|------------------->| |
Figure 2. Call flow with transfer after answer.
Note that there have been some proposals to use REFER for scenario of Figure 1. In this case, a REFER is sent by the ACD during the early dialog. This NOT RECOMMENDED call flow is shown in Figure 3. 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.
Originator ACD 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 3. NOT RECOMMENDED call flow showing REFER prior to answer.
In Figure 4, the ACD is shown proxying the INVITE to the terminator instead of redirecting as in Figure 1.
Originator ACD Terminator
| | |
| INVITE F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 4. Call flow with proxying.
In Figure 5, the ACD is shown proxying the INVITE and modifying the UUI information provided by the Originator.
Originator ACD Terminator
| | |
| INVITE (UUI1) F1 | |
|------------------->| INVITE (UUI2) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 5. Call flow with proxy modifying the UUI.
| TOC |
One method of transport is to transport the UUI information as a MIME body. This is in keeping with the SIP-T architecture in which MIME bodies are used to transport ISUP information. However, in the SIP-T example, the body is added by the originator and used by the terminator. The insertion of the UUI by an intermediary, the ACD, is difficult. The body would need to be encoded in the Contact URI of Figure 1 or the Refer-To URI of Figure 2. For example, if the application/acd MIME type were defined:
Contact: <sip:+12125551212@gateway.example.com?Content-Type=application/acd&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
The resulting INVITE would then have two message bodies, one SDP, the other being the MIME object. In addition to the body, the escaped Content-Type header field should also be included in the resulting INVITE.
While the body approach would work with the redirection and REFER call flows, but does not work with the proxy call flow of Figure 4.
| TOC |
Another approach that has been proposed is to use a header field to tranport the UUI information. The header field would be excaped into the Contact or Refer-To URI. The header field approach will work with the redirection, REFER, and proxy call flows. The Call-Info header field is related to the UUI information. However, there are a number of important differences:
Call-Info is 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 contains a URI pointer the information instead of the actual information itself.
The use of the data URI scheme [RFC2397] (Masinter, L., “The "data" URL scheme,” August 1998.) could be used to overcome the second issue, i.e.:
Call-Info: <data:applicaton/acd,ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
For these reasons, a separate header field needs to be defined, described here as User-to-User:
Contact: <sip:+12125551212@gateway.example.com?User-to-User=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
The resulting INVITE would contain the User-to-User header field.
| TOC |
Another proposed approach is to encode the UUI as a URI parameter into the Contact or Refer-To URI.
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
The resulting INVITE 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. That is, if the URI is an Address of Record instead of a Contact URI, the URI parameter will not be copied over the Contact URI, resulting in the loss of the information.
| TOC |
The recommendation is to define a new SIP header field User-to-User to transport UUI information in ISDN interworking applications.
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.
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.
| 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.
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 (including the protocol discriminator). Other encoding methods of encoding may also be standardized.
| TOC |
TBD.
| TOC |
TBD.
| TOC |
| 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.