[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-johnston-cuss-sip-uui-reqs) 00 01 02 03 04 05 06 07 08 09 RFC 6567

CUSS WG                                                 A. Johnston, Ed.
Internet-Draft                                                     Avaya
Intended status: Informational                               J. McMillen
Expires: May 13, 2011                                       Unaffiliated
                                                                L. Liess
                                                     Deutsche Telekom AG
                                                        November 9, 2010


 Problem Statement and Requirements for Transporting User to User Call
                       Control Information in SIP
                    draft-ietf-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 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.
   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."

   This Internet-Draft will expire on May 13, 2011.



Johnston, et al.          Expires May 13, 2011                  [Page 1]

Internet-Draft                SIP UUI Reqs                 November 2010


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.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  User Agent to User Agent . . . . . . . . . . . . . . . . .  4
     3.2.  Proxy Retargeting  . . . . . . . . . . . . . . . . . . . .  4
     3.3.  Redirection  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Referral . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Informative References . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





















Johnston, et al.          Expires May 13, 2011                  [Page 2]

Internet-Draft                SIP UUI Reqs                 November 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 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, 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 May 13, 2011                  [Page 3]

Internet-Draft                SIP UUI Reqs                 November 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 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  |
                   |                    |------------------->|

   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 May 13, 2011                  [Page 4]

Internet-Draft                SIP UUI Reqs                 November 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 May 13, 2011                  [Page 5]

Internet-Draft                SIP UUI Reqs                 November 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 May 13, 2011                  [Page 6]

Internet-Draft                SIP UUI Reqs                 November 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.


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.

   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 dialog terminating requests and responses.






Johnston, et al.          Expires May 13, 2011                  [Page 7]

Internet-Draft                SIP UUI Reqs                 November 2010


      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 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 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.

      OPEN ISSUE: Does this requirement need to be reworked, or does it
      not provide any useful value?

   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 the inserter of UUI to be sure that
   the UAS understands the call control UUI mechanism.

      This could be useful in ensuring that a request destined for the
      PSTN is routed to a gateway that supports the ISDN UUI service.
      This mechanism is related to 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
   which types or application usages of UUI another UA understands or



Johnston, et al.          Expires May 13, 2011                  [Page 8]

Internet-Draft                SIP UUI Reqs                 November 2010


   supports.

      OPEN ISSUE: For the ISDN Service, is there value in extending this
      down the protocol discriminator, which is the first octet of the
      ISDN UUI information?

   REQ-11: The solution MUST provide a mechanism of transporting at
   least 128 octets of user data and a one octet protocol discriminator,
   i.e. 129 octets in total.

   REQ-12: The recipient of UUI MUST 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.


5.  Security Considerations

   UUI information can contain sensitive information.  UUI transported
   over SIP may need integrity protection, confidentiality, and the
   ability to determine the identity of the source of the UUI.

   Since the security requirements and key management of the UUI
   information are likely to be quite different from the SIP signaling
   transport, applications using this mechanism to transport information
   requiring confidentiality will likely perform their own encryption at
   the application layer before being passed to SIP for transport.


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 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 .



Johnston, et al.          Expires May 13, 2011                  [Page 9]

Internet-Draft                SIP UUI Reqs                 November 2010


   [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


   Laura Liess
   Deutsche Telekom AG

   Email: laura.liess.dt@gmail.com




Johnston, et al.          Expires May 13, 2011                 [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/