Skip to main content

Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7434.
Authors Keith Drage , Alan Johnston
Last updated 2012-03-12
Replaces draft-drage-cuss-sip-uui-isdn
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7434 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-cuss-sip-uui-isdn-03
Network Working Group                                      K. Drage, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                             A. Johnston
Expires: September 14, 2012                                        Avaya
                                                          March 13, 2012

        Interworking ISDN Call Control User Information with SIP
                    draft-ietf-cuss-sip-uui-isdn-03

Abstract

   The motivation and use cases for interworking and transporting ITU-T
   DSS1 User-user information element data in SIP are described in the
   "Problem Statement and Requirements for Transporting User to User
   Call Control Information in SIP" document.  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
   defines a usage of the User-to-User header field to enable
   interworking with this ISDN service.

   This document covers the interworking with both public ISDN and
   private ISDN capabilities, so the potential interworking with QSIG
   will also be addressed.

Status of this Memo

   This Internet-Draft is submitted 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 September 14, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Drage & Johnston       Expires September 14, 2012               [Page 1]
Internet-Draft              SIP UUI for ISDN                  March 2012

   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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Summary of the ISDN User-to-User Service . . . . . . . . . . .  3
     3.1.  The service  . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Impacts of the ISDN service on SIP operation . . . . . . .  5
   4.  Relation to SIP-T  . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Transition away from ISDN  . . . . . . . . . . . . . . . . . .  6
   6.  ISDN Usage of the User-to-User Header Field  . . . . . . . . .  7
   7.  UAC requirements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  UAS requirements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10
   10. Considerations for ISDN interworking gateways  . . . . . . . . 11
   11. Coding requirements  . . . . . . . . . . . . . . . . . . . . . 11
   12. Media Feature Tag  . . . . . . . . . . . . . . . . . . . . . . 12
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   16. Changes since previous versions  . . . . . . . . . . . . . . . 14
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     17.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

Drage & Johnston       Expires September 14, 2012               [Page 2]
Internet-Draft              SIP UUI for ISDN                  March 2012

1.  Terminology

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

2.  Overview

   This document describes a usage of the User-to-User header field
   defined in [I-D.ietf-cuss-sip-uui] to enable the transport of User to
   User Information (UUI) in ISDN interworking scenarios using SIP
   [RFC3261].  Specifically, this document discusses the interworking of
   call control related ITU-T DSS1 User-user information element [Q931],
   [Q957.1] 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 usage is not limited to scenarios where interworking will occur.
   Rather it describes a usage where interworking is possible if
   interworking is met.  That does not preclude its usage directly
   between two SIP terminals.

3.  Summary of the ISDN User-to-User Service

3.1.  The service

   ISDN defines a number of related services.  Firstly there is a user
   signalling bearer service, which uses the information elements /
   parameters in the signalling channel to carry the data, and does not
   establish a related circuit-switched connection.  For DSS1, this is
   specified in ITU-T Recommendation Q.931 section 3.3 and section 7
   [Q931].  It also defines a user-to-user signalling supplementary
   service, which uses the information elements / parameters in the
   signalling channel to carry additional data, but which is used in
   conjunction with the establishment of a related circuit-switched
   connection.  This reuses the same information elements / parameters
   as the user signalling bearer service, with the addition of other
   signalling information, and for DSS1 this is specified in ITU-T
   Recommendation Q.957.1 [Q957.1].

   ISDN defines three variants of the user-to-user signalling
   supplementary service as follows:

Drage & Johnston       Expires September 14, 2012               [Page 3]
Internet-Draft              SIP UUI for ISDN                  March 2012

   UUS1:  User-to-user information exchanged during the setup and
      clearing phases of a call, by transporting User-to-user
      information element within call control messages.  This in itself
      has two subvariants, UUS1 implicit and UUS1 explicit.  UUS1
      explicit uses additional supplementary service control information
      to control the request and granting of the service, as in UUS2 and
      UUS3.  In UUS1 implicit, it is the presence of the user signalling
      data itself that constitutes the request for the service.  UUS1
      explicit as a result also allows the requester to additionally
      specify whether the parallel circuit-switched connection should
      proceed if the UUS1 service cannot be provided (preferred or
      required);

   UUS2:  User-to-user information exchanged from the sender's point of
      view during call establishment, between the DSS1 ALERTING and DSS1
      CONNECT messages, within DSS1 USER INFORMATION messages; and

   UUS3:  User-to-user information exchanged while a call is in the
      Active state, within DSS1 USER INFORMATION messages.

   The service is always requested by the calling user.

   This document defines only the provision of the ISDN UUS1 implicit
   supplementary service to interworking scenarios, this being the most
   widely deployed and used of the various ISDN user-to-user services,
   and indeed the one that matches the requirements specified in
   draft-ietf-cuss-sip-uui-reqs [I-D.ietf-cuss-sip-uui-reqs].

   The above come from the ISDN specifications defined for public
   networks.  There are a parallel set of ISDN specifications defined
   for private networks (QSIG}.  These specifications do not define a
   UUS1 implicit supplementary service.  However, implementation of such
   a UUS1 implicit supplementary service for private networks can
   readily be constructed in a proprietary fashion based on the
   specifications for public networks, and evidence suggests that some
   vendors have done so.  On this basis, there is no reason why this
   package cannot also be used to support interworking with such a
   private network service, on the assumption that the constraints are
   exactly the same as those for the public network.

   The ISDN UUS1 service has the following additional characteristics as
   to the data that can be transported:

      The maximum number of octets of user information that can be
      transported in 128 octets plus a protocol discriminator.  It is
      noted that some early ISDN implementations had a limitation of 32
      octets, but it is understood that these are not currently
      deployed.  While this package does not prohibit longer data

Drage & Johnston       Expires September 14, 2012               [Page 4]
Internet-Draft              SIP UUI for ISDN                  March 2012

      fields, the mechanism at any interworking point is to discard data
      elements that are too long to handle.  The handled length can
      normally be assumed to be 128 octets.

      The content of the user information octets is described by a
      single octet protocol discriminator (see table 4-26 of ITU-T
      Recommendation Q.931) [Q931].  That protocol descriminator may
      describe the protocol used within the user data, the structure of
      the user data, or leave it entirely open.  Note that not all
      values within the protocol discriminator necessarily make sense
      for use in the user to user service, as the content is aligned
      with the protocol discriminator that appears at the start of all
      DSS1 messages (see table 4-1 of ITU-T Recommendation Q.931)
      [Q931].  The protocol discriminator value has no impact on the
      interworking capability.

      Only a single user information can be transported in each message.

      The ISDN service works without encryption or integrity protection.
      The user trusts the intermediate network elements, and therefore
      the operator of those elements, not to modify the data, and to
      deliver all the data to the remote user.  On a link by link basis,
      message contents are protected at layer 2 by standard CRC
      mechanisms - this allows loss on a link level basis to be
      detected, but does not guard against fraudulent attacks on the
      link itself.  This does not prevent the use of additional
      encryption or integrity protection within the UUI data itself,
      although the limit on the size of the UUI data (protocol
      discriminator plus 128 octets) will restrict this.

3.2.  Impacts of the ISDN service on SIP operation

   The ISDN service has the following impacts that need to be understood
   within the SIP environment.

   Call transfer  ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.

   Conference  ISDN conferencing allows the user to still exchange user-
      to-user data after the conference is created.  As far as UUS1 is
      concerned, it is not permitted.

Drage & Johnston       Expires September 14, 2012               [Page 5]
Internet-Draft              SIP UUI for ISDN                  March 2012

      The ISDN three-party supplementary service is similar in many ways
      to conferencing, but is signalled using a different mechanism.
      This means that on clearing, the controller using UUS1 implicit
      does have the choice of sending data to either or both remote
      users.  Because SIP conferencing cannot completely emulate the
      ISDN three-party supplementary service at the served user, UUS1
      implicit is not possible.

   Diversion  When ISDN diversion occurs, any UUS1 user-to-user data is
      sent to the forwarded-to-user (assuming that the call meets
      requirements for providing the service - this is impacted by the
      explicit service only).  If the type of diversion is such that the
      call is also delivered to the forwarding user, they will also
      receive any UUS1 user-to-user data.

4.  Relation to SIP-T

   A method of transport of ISDN UUI is to use SIP-T [RFC3372] and
   transport the UUI information end-to-end, as part of an ISUP message
   or QSIG message) as a MIME body.  If the SIP-T method of
   encapsulation of ISDN instead of interworking is used, this is a
   reasonable mechanism and does not require any extensions to existing
   SIP-T.  However, if true ISDN interworking is being done, this
   approach is not reasonable.  Instead, the better approach is to
   interwork the ISDN UUI using the native SIP UUI transport mechanism,
   the User-to-User header field.  The rest of this document describes
   this approach.

5.  Transition away from ISDN

   This interworking usage of the SIP UUI mechanism will likely begin
   with one User Agent being an ISDN gateway while the other User Agent
   is a native SIP endpoint.  As networks transition away from ISDN, it
   is possible that both User Agents could become native SIP endpoints.
   In this case, there is an opportunity to transition away from this
   ISDN usage to a more general usage of [I-D.ietf-cuss-sip-uui].

   The SIP UUI mechanism provides a way to achieve this transition.  As
   an endpoint moves from being an ISDN gateway to a native SIP
   endpoint, and a package for some form of enhanced UUI has been
   standardized, the endpoint can carry the UUI data both as ISDN and as
   some other package in parallel, and in the same messages or in
   different messages depending on the needs of the application.  This
   will permit the other endpoint to use the UUI according to the ISDN
   package if it is an ISDN gateway or the enhanced package if it is a
   native SIP endpoint.

Drage & Johnston       Expires September 14, 2012               [Page 6]
Internet-Draft              SIP UUI for ISDN                  March 2012

6.  ISDN Usage of the User-to-User Header Field

   This document defines the package for the ISDN interworking of UUI
   which is to interoperate with ISDN User to User Signaling (UUS), a
   supplementary service in which the user is able to send/receive a
   limited amount of information to/from another ISDN user over the
   signalling channel in association with a call to the other ISDN user.

   Two examples of ISDN UUI with redirection (transfer and diversion)
   are defined in [ANSII] and [ETSI].

   One objective of the design of this package has been to keep the
   functionality at the interworking point as simple as possible.
   Therefore responsibility for respecting the limits has been
   transferred to the end UA.  If an interworking point is reached, and
   the limitations are not met, then the UUI data will not be
   transferred, although the SIP request will otherwise be interworked.
   As a result there is also only one encoding value specified.

   The general principals of this package of the UUI mechanism are
   therefore as follows:

      That the sending application is expected to limit their sending
      requirements to the subset provided by the ISDN UUI service.

      That the SIP UA will not allow the reception of more that one
      User-to-User header field of the "isdn-uui" package in the same
      SIP request or response, and will only allow it in a request or
      response of the appropriate method (INVITE or BYE).  What happens
      to User-to-User header fields relating to different packages is
      outside the scope of this document.

      That an interworking point trying to interwork UUI data that is
      too long will discard the UUI data, but proceed with the
      interworking.  There is no notification of such discard back to
      the sending user.  If the SIP user knows that it is interworking
      with the ISDN, then the UUI application at the SIP endpoint should
      limit its communication to 128 octet packets plus the protocol
      discriminator, in the knowledge that discard will occur if it does
      not.  The UUI application at the SIP endpoint has complete control
      over what occurs.  It should be noted that this was exactly the
      envisaged operation when early ISDN implementations that only
      supported 32 octets interworked with those supporting 128 octets.
      It also corresponds to the interworking with ISDNs that do not
      support the supplementary service at all, as discard will occur in
      these circumstances as well.  Note that failure to include the
      user-user data into the ISDN SETUP message (when discard occurs)
      will result in the service being unavailable for the remainder of

Drage & Johnston       Expires September 14, 2012               [Page 7]
Internet-Draft              SIP UUI for ISDN                  March 2012

      the call when UUS1 implicit operation is used.

7.  UAC requirements

   The UAC MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
   addition to the requirements defined in this document.

   The UAC MUST only use this package of the UUI mechanism extension in
   association with the initial INVITE method and the BYE method
   relating to an INVITE dialog.  Usage on transactions associated with
   any other type of dialog, or on methods not associated with a dialog
   is precluded.  Usage on other methods within the INVITE dialog, and
   on re-INVITE transactions with the INVITE dialog, is also precluded.

   If the UAC wishes to use or permit the sending of UUI data at any
   point in the dialog, the UAC MUST include in the INVITE request for
   that dialog a User-to-User header field.  The UAC SHOULD set the
   "package" header field parameter to "isdn-uui".  Non-inclusion of the
   "package" header field parameter is permitted, but this is primarily
   to allow earlier implementations to support this package.  This
   initial header field constitutes the implicit request to use the UUI
   service, and is therefore included even when there is no data except
   the protocol discriminator octet to send at that point in time.

   The UAC MUST NOT include the User-to-User header field with a
   "package" header field parameter set to "isdn-uui", or with no
   "package" header field parameter", in any message of an INVITE dialog
   if the original INVITE request did not include the User-to-User
   header field, either with a "package" header field parameter set to
   "isdn-uui", or with no "package" header field parameter included.

   When sending UUI for the ISDN package, if the "package" header field
   is included, the UAC MUST set the User-to-User "package" header field
   parameter to "isdn-uui".  The UAC MUST NOT include more than one
   User-to-User header field for this package in any SIP request or
   response.

   When receiving UUI, when multiple User-to-User header fields are
   received in the same response with the "package" header field
   parameter to "isdn-uui", or with no "package" header field parameter,
   or with some combination of these, the UAS MUST discard all these
   header fields.  There are no mechanisms for determining which was the
   intended data packet so all are discarded.

   The application designer will need to take into account the ISDN
   service restrictions; failure to do so can result in information
   being discarded at any interworking point with the ISDN.  This

Drage & Johnston       Expires September 14, 2012               [Page 8]
Internet-Draft              SIP UUI for ISDN                  March 2012

   document makes no further normative requirements based on those
   constraints, because those constraints may vary from one ISDN to
   another.  It is reasonable to expect that a limitation of 128 octets
   (plus a protocol discriminator) can be imposed by the ISDN, and
   therefore UUI data longer than this will never reach the destination
   if such interworking occurs.  Note that the 128 octet limit (plus a
   protocol discriminator) applies before the encoding (or after the
   decoding) using the "hex" encoding.  The "hex" encoding is defined in
   [I-D.ietf-cuss-sip-uui].

   [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
   UUI mechanism extension.  Because for the ISDN UUI service, the
   service is service 1 implicit, the inclusion of the "uui" option tag
   in a Supported header field conveys no additional information over
   and above the presence of the User-to-User header field with the
   "package" header field parameter to "isdn-uui" in the INVITE request.
   While there is no harm in including the "uui" option tag, and
   strictly it should be included if the extension is supported, it
   performs no function.  The presence of the "uui" option tag in the
   Require header field of an INVITE request will cause the request to
   fail if it reaches a UAS or ISDN interworking gateway that does not
   support this extension; such a usage is not precluded although it
   does not form part of the package.

8.  UAS requirements

   The UAS MUST meet the requirements of [I-D.ietf-cuss-sip-uui] in
   addition to the requirements defined in this document.

   The UAS MUST only use this package of the UUI mechanism extension in
   association with the initial INVITE method and the BYE method
   relating to an INVITE dialog.  Usage on transactions associated with
   any other type of dialog, or on methods not associated with a dialog
   is precluded.  Usage on other methods within the INVITE dialog, and
   on re-INVITE transactions with the INVITE dialog, is also precluded.

   The UAS MUST NOT include the User-to-User header field with a
   "package" header field parameter set to "isdn-uui", or with no
   "package" header field parameter", in any message of an INVITE dialog
   if the original INVITE request did not include the User-to-User
   header field, either with a "package" header field parameter set to
   "isdn-uui", or with no "package" header field parameter included.

   The UAS MAY include the User-to-User header field in responses to the
   initial INVITE request, or the BYE requests or responses for the
   dialog, only where the original INVITE request included a User-to-
   User header field with the "package" header field parameter to "isdn-

Drage & Johnston       Expires September 14, 2012               [Page 9]
Internet-Draft              SIP UUI for ISDN                  March 2012

   uui", or where no "package" header field parameter was included.
   When sending UUI for the ISDN package, the UAS SHOULD set the User-
   to-User "package" header field parameter to "isdn-uui".  Non-
   inclusion of the "package" header field parameter is permitted, but
   this is primarily to allow earlier implementations to support this
   package.  The UAS MUST NOT include more than one User-to-User header
   field for this package in any SIP request or response.

   Where the UAS is acting as a redirect server, the UAS MUST NOT
   include the User-to-User header field in the header URI parameter in
   a 3xx response to an incoming request.

   When receiving UUI, when a User-to-User header field is received in a
   request that is not from the originating user with the "package"
   header field parameter to "isdn-uui", or with no "package" header
   field parameter, the UAC MUST discard this header field.

   When receiving UUI, when multiple User-to-User header fields are
   received from the originating user in the same request with the
   "package" header field parameter to "isdn-uui", or with no "package"
   header field parameter, or with some combination of these, the UAC
   MUST discard all these header fields.  There are no mechanisms for
   determining which was the intended data packet so all are discarded.

9.  UUI contents

   These requirements apply when the "package" header field parameter is
   set to "isdn-uui", or with no "package" header field parameter.
   Processing for User-to-User header fields sent or received with
   values other than this value are outside the scope of this document,
   and the appropriate package document for that value applies.

   The default and only content defined for this package is "isdn-uui".
   When sending UUI, the sending SIP entity MAY, but need not, include a
   "content" header field with a value set to "isdn-uui".  A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "content" header field parameter is present and the value is some
   other value that "isdn-uui".

   The default and only encoding defined for this package is "hex".
   When sending UUI, the sending SIP entity MAY, but need not, include
   an "encoding" header field with a value set to "hex".  A receiving
   SIP entity MUST ignore a received User-to-User header field if the
   "encoding" header field parameter is present and the value is some
   other value that "hex".

   When sending UUI, the sending application MUST include a protocol

Drage & Johnston       Expires September 14, 2012              [Page 10]
Internet-Draft              SIP UUI for ISDN                  March 2012

   discriminator octet, conforming to table 4-26 of ITU-T Recommendation
   Q.931 [Q931] as the first octet of the UUI data.  It is up to the
   receiving application what it does with this value.  This document
   places no other normative requirement on the use of the protocol
   discriminator; it is required at interworking gateways to allow
   mapping into the appropriate fields in the ISDN protocols, but
   otherwise the usage is entirely up to the application, and outside
   the scope of this document.  Valid values are identified and
   documented by ITU-T, and there is no IANA registry for these values.

10.  Considerations for ISDN interworking gateways

   ISDN interworking gateways MUST support the requirements defined for
   UAS and UAC operation.

   ISDN interworking gateways MUST support only the "isdn-uui" package
   on dialogs that are interworked.

   ISDN interworking gateways will take octet structured data from the
   ISDN side and encode it using the "hex" encoding scheme defined in
   [I-D.ietf-cuss-sip-uui] for inclusion as the uui-data in the User-to-
   User header field.  In the reverse direction, it will take valid uui-
   data according to the "hex" encoding scheme, and decode it to octet
   structured data for sending to the ISDN side.

   When mapping data content from the ISDN to the SIP signalling, or
   from SIP signalling to the ISDN, the gateway needs to assume that all
   content is octet structured binary, irrespective of the value of the
   received protocol discriminator.  There are no requirements in the
   ISDN to ensure that the content matches the value of the protocol
   discriminator, and it is for the application usage to sort out any
   discrepancy.  The same applies to the ISDN protocol discrimination
   defined table 4-26 of ITU-T Recommendation Q.931 [Q931] as the first
   octet of the UUI data; the interworking gateway will not perform any
   additional checking of this value.

   [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
   UUI mechanism extension.  The option tag is not interworked at an
   ISDN interworking gateway.  The ISDN interworking gateways MUST NOT
   take the omission of the "uui" option tag in a received INVITE
   request to indicate that interworking of a received header field is
   not to be performed.

11.  Coding requirements

   This document defines "isdn-uui" as a new value of the User-to-User

Drage & Johnston       Expires September 14, 2012              [Page 11]
Internet-Draft              SIP UUI for ISDN                  March 2012

   "package" header field parameter.

   This document defines "isdn-uui" as a new value of the User-to-User
   "content" header field parameter.  A content value of "isdn-uui"
   indicates that the contents have a first octet that is a protocol
   discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931]
   followed by uui-data that can be subject to a length limitation
   (before encoding or after decoding) that is generally 128 octets.

12.  Media Feature Tag

   This document defines a new media feature tag "sip.uui-isdn".  This
   feature tag indicates that this UUI package is supported by the
   sender, and its usage is entirely in accordance with RFC 3840
   [RFC3840].  This document makes no additional provisions for the use
   of this feature tag.

13.  IANA Considerations

   This document adds the following row to the "UUI packages" sub-
   registry of the SIP parameter registry:

      Value: isdn-uui

      Description: The associated application is being used with
      constraints suitable for interworking with the ISDN user-to-user
      service, and therefore can be interworked at ISDN gateways.

      Reference: RFCXXXX

      Contact:

   This document adds the following row to the "UUI content" subregistry
   of the SIP parameter registry:

      Value: isdn-uui

      Description: The associated contents conforms to the content
      associated with the ISDN user-to-user service.  In the presence of
      the "package" header field parameter set to "isdn-uui" this is the
      default meaning and therefore need not be included in this case.

      Reference: RFCXXXX

      Contact:

Drage & Johnston       Expires September 14, 2012              [Page 12]
Internet-Draft              SIP UUI for ISDN                  March 2012

   This document defines the following media feature tag which is added
   to the features.sip-tree of the Media Feature tags registry:

      Media feature-tag name: sip.uui-isdn

      ASN.1 Identifier: 1.3.6.1.8.4.x

      Summary of the media feature indicated by this tag: This media
      feature-tag when used in a Contact header field of a SIP request
      or a SIP response indicates that the entity sending the SIP
      message supports the UUI package "uui-isdn".

      Values appropriate for use with this feature-tag: none

      Examples of typical use: Indicating that a mobile phone supports
      SRVCC for calls in alerting phase.

      Related standards or documents: RFCXXXX

      Security Considerations: Security considerations for this media
      feature-tag are discussed in section 11.1 of RFC 3840 [RFC3840]

   Editor's Note: [RFCXXXX] should be replaced with the designation of
   this document.

14.  Security Considerations

   This document contains no specific requirements in regard to security
   over and above those specified in [I-D.ietf-cuss-sip-uui].  The
   overlying use case will define the security measures required.  The
   underlying user-to-user extension provides a number of tools that can
   meet certain security requirements.  As a level of guidance, data
   that is used to assist in selecting which SIP UA should respond to
   the call would not be expected to carry any higher level of security
   than a media feature tag.  Information that might otherwise reveal
   private information about an individual, or where a level of
   authenticity needs to be guaranteed, may need a higher level of
   protection, and may indeed not be suitable for this package,
   particularly taking into account the statement in the following
   paragraph.

   As this capability is defined to interwork with the ISDN, if the ISDN
   forms part of the route, any usage needs to assume that the security
   level of the ISDN is the highest level of security available.  As the
   ISDN security is itself not definable on an end-to-end basis, this
   can be an unknown quantity.  This is because ISDN security exists on
   a hop-by-hop basis, and is only as secure as the least secure

Drage & Johnston       Expires September 14, 2012              [Page 13]
Internet-Draft              SIP UUI for ISDN                  March 2012

   component.  This can be high in some places (e.g. it can require
   physical access to a secure building) and in other places it can be
   low (e.g. the point where an ISDN access enters a building).  If this
   level of security is not sufficient, then either a different user-to-
   user package, or indeed, a different method of data transfer, needs
   to be selected by the application user.

15.  Acknowledgements

   Joanne McMillen was a major contributor and co-author of earlier
   versions of this document.

   Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their
   review of earlier versions of this document.  The authors wish to
   thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
   Jennings, Mahalingam Mani and Celine Serrut-Valette for their
   comments.

16.  Changes since previous versions

   Note to RFC editor: This section is to be deleted before final
   publication.

   Changes since made in the creation of the
   draft-ietf-cuss-sip-uui-isdn-03 version from the
   draft-ietf-cuss-sip-uui-isdn-02 version.

      Clarification added that the default content is "isdn-uui".

      Clarification added that the default encoding is "hex".

      Changeout of "payload" terminology to "UUI data".

   Changes since made in the creation of the
   draft-ietf-cuss-sip-uui-isdn-02 version from the
   draft-ietf-cuss-sip-uui-isdn-01 version.

      The inclusion of the "package" header field parameter has be
      downgraded to "RECOMMENDED", with the purpose stated as being for
      interworking.  Changes have been made to the procedures at the
      receiving side to allow for the non-inclusion of the "package"
      header field parameter.  The effect of this is that the absence of
      the "package" header field parameter means by default the use of
      the "uui-isdn" package.

Drage & Johnston       Expires September 14, 2012              [Page 14]
Internet-Draft              SIP UUI for ISDN                  March 2012

      Clarification that the package is not to be used on re-INVITE
      transactions or on other transations within an INVITE dialog.

      Further clarification on using this package in conjunction with
      other packages.

      Closure of the remaining open issue relating to use of UUS1 in
      conjunction with the ISDN conference service - UUS1 is not
      possible after the conference is created.

      A number of editorial changes have been made.

   Changes since made in the creation of the
   draft-ietf-cuss-sip-uui-isdn-01 version from the
   draft-ietf-cuss-sip-uui-isdn-00 version.

      QSIG does not define a UUS service.  As such changes are made to
      indicate that it is possible to support a proprietary service on
      QSIG based on the public ISDN standards, and interworking with
      such proprietary versions is supported.  The associated
      contributors note regarding interactions with other QSIG services
      has therefore been removed with this amendment.

      Added additional paragraph above the objectives of the
      interworking design.

      Made clear that the 128 octets apply before encoding in "hex".
      Reference added to the generic UUI document for the ecoding of
      "hex".

      Indicated that it is the "content" header field parameter set to
      "isdn-uui" that defines the structure of the uui-data, with the
      first octet being a protocol discriminator and the remaining
      octets potentially being limited to 128 octets.

      Aligned the IANA registration section with the registries created
      by the generic UUI document.

      Added reference to the generic UUI document to the security
      considerations section.

   Changes since made in the creation of the
   draft-ietf-cuss-sip-uui-isdn-00 version from the
   draft-drage-cuss-sip-uui-isdn-01 version.

      Removed overburdening of the word "application".  Changed the name
      of the "app" header field parameter in the mechanism draft to
      "package" header field parameter.  This had a consequential impact

Drage & Johnston       Expires September 14, 2012              [Page 15]
Internet-Draft              SIP UUI for ISDN                  March 2012

      on the ISDN document.  The word "application" is now solely
      reserved for the name of the functionality that passes the UUI to
      the SIP functionality to send, and to which the UUI is delivered
      on receipt by the SIP functionality.  As well as the change of the
      name of the header field parameter, this resulted in a number of
      instances of the word "application" becoming "package".  A couple
      of instances relating to the coding of the "content" header field
      parameter have become "SIP entity".

      Section 5 needed substantial rewording as it no longer applied in
      this manner.  Modified the text to indicate that if one wants to
      use an enhanced UUI where both endpoints are SIP, but still work
      with the ISDN, then one will have to same information using two
      different packages, one the ISDN one, and the other some enhanced
      package.

      In section 8, a couple of requirements relating to the "content"
      header field parameter really related to the "package" header
      field parameter (formerly "app" header field parameter).  These
      are corrected.

      Updated references from "draft-johnston-cuss-sip-uui" to
      "draft-ietf-cuss-sip-uui".

      Made clear throughout the document that the UUI payload is a
      protocol discriminator plus 128 octets of data.

      Made clearer that it is the initial INVITE request and responses
      and the BYE request and responses only that carry the information
      in this package.

      Made clear that there are no normative requirements on the
      protocol discriminator.  In particular text is added to the end of
      section 9.

      Removed the following text from section 7, as it is a duplicate of
      the text in section 9:

      " When sending UUI, the sending application MUST include a
      protocol discriminator octet, conforming to table 4-26 of ITU-T
      Recommendation Q.931 [Q931] as the first octet of the payload
      information."

      Defined a media feature tag specific for the package.  It has been
      proposed to do this for all packages. "sip.uui-isdn" has been
      added.

Drage & Johnston       Expires September 14, 2012              [Page 16]
Internet-Draft              SIP UUI for ISDN                  March 2012

      Corrected the short title for the draft.

   Changes since made in the creation of the
   draft-drage-cuss-sip-uui-isdn-01 version from the
   draft-drage-cuss-sip-uui-isdn-00 version.

      Closure of a number of open issues identified in the -00 version
      and the creation of appropriate procedures for the UAC, the UAS,
      and the ISDN interworking gateway.

17.  References

17.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol
              for Telephones (SIP-T): Context and Architectures",
              BCP 63, RFC 3372, September 2002.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [I-D.ietf-cuss-sip-uui]
              Johnston, A. and J. Rafferty, "A Mechanism for
              Transporting User to User Call Control Information in
              SIP", draft-ietf-cuss-sip-uui-05 (work in progress),
              March 2012.

   [Q931]     "ITU-T Recommendation Q.931: Digital subscriber Signalling
              System No. 1 - Network layer; ISDN user-network interface
              layer 3 specification for basic call control",
              http://www.itu.int/rec/T-REC-Q.931-199805-I/en .

17.2.  Informative References

   [I-D.ietf-cuss-sip-uui-reqs]
              Johnston, A. and L. Liess, "Problem Statement and
              Requirements for Transporting User to User Call Control
              Information in SIP", draft-ietf-cuss-sip-uui-reqs-09 (work

Drage & Johnston       Expires September 14, 2012              [Page 17]
Internet-Draft              SIP UUI for ISDN                  March 2012

              in progress), January 2012.

   [Q957.1]   "ITU-T Recommendation Q.957.1: Digital subscriber
              Signalling System No. 1 - Stage 3 description for
              supplementary services using DSS 1; Stage 3 description
              for additional information transfer supplementary services
              using DSS 1: User-to-User Signalling (UUS)",
              http://www.itu.int/rec/T-REC-Q.957.1-199607-I .

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

Authors' Addresses

   Keith Drage (editor)
   Alcatel-Lucent
   Quadrant, Stonehill Green, Westlea
   Swindon
   UK

   Email: keith.drage@alcatel-lucent.com

   Alan Johnston
   Avaya
   St. Louis, MO  63124
   United States

   Email: alan.b.johnston@gmail.com

Drage & Johnston       Expires September 14, 2012              [Page 18]