\
SIPPING WG                                              A. Johnston, Ed.
Internet-Draft                                               J. McMillen
Intended status: Informational                                     Avaya
Expires: August 16, 2009                               February 12, 2009


   Transporting User to User Call Control Information in SIP for ISDN
                              Interworking
                    draft-johnston-sipping-cc-uui-07

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), 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 August 16, 2009.

Copyright Notice

   Copyright (c) 2009 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.

Abstract

   Several approaches to transporting the ITU-T Q.931 User to User



Johnston & McMillen      Expires August 16, 2009                [Page 1]


Internet-Draft               SIP UUI for CC                February 2009


   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 and recommends a
   new header field be standardized.  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.


Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  User Agent to User Agent . . . . . . . . . . . . . . . . .  5
     4.2.  Proxy Retargeting  . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Redirection  . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  Referral . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Possible Mechanisms  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Why INFO is Not Used . . . . . . . . . . . . . . . . . . .  9
     5.2.  MIME body Approach . . . . . . . . . . . . . . . . . . . . 10
     5.3.  URI Parameter  . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  Header Field Approach  . . . . . . . . . . . . . . . . . . 11
   6.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Appendix - Syntax for UUI Header Field . . . . . . . . . . . . 12
     7.1.  IANA Considerations  . . . . . . . . . . . . . . . . . . . 13
       7.1.1.  Registration of Header Field . . . . . . . . . . . . . 13
       7.1.2.  Registration of Header Field Parameter . . . . . . . . 14
       7.1.3.  Registration of SIP Option Tag . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. Informative References . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16













Johnston & McMillen      Expires August 16, 2009                [Page 2]


Internet-Draft               SIP UUI for CC                February 2009


1.  Overview

   This document describes the transport of User to User Information
   (UUI) in ISDN interworking scenarios using SIP [RFC3261].
   Specifically, we discuss 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.  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.
   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.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Johnston & McMillen      Expires August 16, 2009                [Page 3]


Internet-Draft               SIP UUI for CC                February 2009


   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].


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



Johnston & McMillen      Expires August 16, 2009                [Page 4]


Internet-Draft               SIP UUI for CC                February 2009


      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.


4.  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 help explain the requirements from
   the previous section.

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









Johnston & McMillen      Expires August 16, 2009                [Page 5]


Internet-Draft               SIP UUI for CC                February 2009


              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.

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

              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.

4.3.  Redirection

   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



Johnston & McMillen      Expires August 16, 2009                [Page 6]


Internet-Draft               SIP UUI for CC                February 2009


   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.

              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.




Johnston & McMillen      Expires August 16, 2009                [Page 7]


Internet-Draft               SIP UUI for CC                February 2009


4.4.  Referral

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










Johnston & McMillen      Expires August 16, 2009                [Page 8]


Internet-Draft               SIP UUI for CC                February 2009


              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.


5.  Possible Mechanisms

   Three possible mechanisms for transporting UUI will be described:
   MIME body, URI parameter, and header field transport.

5.1.  Why INFO is Not Used

   Since the INFO method [RFC2976], 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



Johnston & McMillen      Expires August 16, 2009                [Page 9]


Internet-Draft               SIP UUI for CC                February 2009


   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.

5.2.  MIME body Approach

   One method of transport is to transport the UUI information as a MIME
   body.  This is in keeping with the SIP-T architecture [RFC3372] 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 [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.

5.3.  URI Parameter

   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 carried in a Request-URI 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 in the
   Reqeuest-URI 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.  Note that if this same URI was present in a Refer-To



Johnston & McMillen      Expires August 16, 2009               [Page 10]


Internet-Draft               SIP UUI for CC                February 2009


   header field, the same loss of information would occur.

5.4.  Header Field Approach

   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 or
      by an application server.

      Call-Info usually contains a URI pointer to the information
      instead of the actual information itself which does not meet
      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:



Johnston & McMillen      Expires August 16, 2009               [Page 11]


Internet-Draft               SIP UUI for CC                February 2009


   User-to-User: 56a390f3d2b7310023a;encoding=hex

   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:

   User-to-User: 56a390f3d2b7310023a;encoding=hex


6.  Recommendation

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

   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.


7.  Appendix - Syntax for UUI Header Field

   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-to-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.  For SS7,
   user-to-user information may be exchanged within the following Q.763
   messages: INITIAL ADRESS MESSAGE, ADDRESS COMPLETE MESSAGE, CALL



Johnston & McMillen      Expires August 16, 2009               [Page 12]


Internet-Draft               SIP UUI for CC                February 2009


   PROGRESS, CONNECT, ANSWER, and RELEASE.  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.

7.1.  IANA Considerations

7.1.1.  Registration of Header Field

   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.




Johnston & McMillen      Expires August 16, 2009               [Page 13]


Internet-Draft               SIP UUI for CC                February 2009


7.1.2.  Registration of Header Field Parameter

   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.

7.1.3.  Registration of SIP Option Tag

   This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of [RFC3261].

   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.


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



Johnston & McMillen      Expires August 16, 2009               [Page 14]


Internet-Draft               SIP UUI for CC                February 2009


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


9.  Acknowledgements

   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.


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

   [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",



Johnston & McMillen      Expires August 16, 2009               [Page 15]


Internet-Draft               SIP UUI for CC                February 2009


              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.

   [RFC4475]  Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
              and H. Schulzrinne, "Session Initiation Protocol (SIP)
              Torture Test Messages", RFC 4475, May 2006.


Authors' Addresses

   Alan Johnston (editor)
   Avaya
   St. Louis, MO  63124

   Email: alan@sipstation.com


   Joanne McMillen
   Avaya

   Email: joanne@avaya.com






















Johnston & McMillen      Expires August 16, 2009               [Page 16]