CUSS
Internet Engineering Task Force (IETF)                     K. Drage, Ed.
Internet-Draft
Request for Comments: 7434                                Alcatel-Lucent
Intended status:
Category: Standards Track                                    A. Johnston
Expires: May 15, 2015
ISSN: 2070-1721                                                    Avaya
                                                       November 11,
                                                           December 2014

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

Abstract

   The motivation and use cases for interworking and transporting ITU-T
   DSS1
   Digital Subscriber Signalling System No. 1 (DSS1) User-user
   information element data in SIP are described in RFC 6567.  As
   networks move to SIP, it is important that applications requiring
   this data can continue to function in SIP networks as well as have
   the ability to interwork with this ISDN service for end-to-end
   transparency.  This document defines a usage (a new package called
   the ISDN UUI package) 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.

   The package is identified by a the new value "isdn-uui" of the
   "purpose" header field parameter.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 15, 2015.
   http://www.rfc-editor.org/info/rfc7434.

Copyright Notice

   Copyright (c) 2014 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  3   2
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3   2
   3.  Summary of the ISDN User-to-User Service  . . . . . . . . . . .   3
     3.1.  The service Service . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Impacts of the ISDN service Service on SIP operation . Operation  . . . . . .   5
   4.  Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . .  6   5
   5.  Transition away Away from ISDN . . . . . . . . . . . . . . . . . .   6
   6.  ISDN Usage of the User-to-User Header Field . . . . . . . . .  7   6
   7.  UAC requirements . Requirements  . . . . . . . . . . . . . . . . . . . . . .  8   7
   8.  UAS requirements . Requirements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  UUI contents . Contents  . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Considerations for ISDN internetworking gateways Interworking Gateways . . . . . . . .  11
   11. Coding requirements Requirements . . . . . . . . . . . . . . . . . . . . . 12  11
   12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . .  12
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   14. Security Considerations . . . . . . . . . . . . . . . . . . . 14  13
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     16.1.  14
     15.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     16.2.  14
     15.2.  Informative References . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses . . . . . .
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  16

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

2.  Overview

   This document describes a usage of the User-to-User header field
   defined in [I-D.ietf-cuss-sip-uui] [RFC7433] to enable the transport of User-
   to-User 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 Q.931
   [Q931], Q957.1 [Q957.1] Q.957.1 [Q957.1], and ITU-T Q.763 User-to-user information
   parameter [Q763] data in SIP.  Today, UUI is widely used in the PSTN today
   Public Switched Telephone Network (PSTN) in contact centers and call
   centers which that 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 Service

   ISDN defines a number of related services.  Firstly  Firstly, there is a user
   signalling bearer service, which service that uses the information elements /
   parameters in the signalling channel to carry the data, data and does not
   establish a related circuit-switched connection.  For DSS1, this is
   specified in ITU-T Recommendation Q.931 section Q.931, Sections 3.3 and section 7 of
   [Q931].  It also  Secondly, it defines a User-to-User signalling Signalling (UUS)
   supplementary
   service, which service that uses the information elements / parameters
   in the signalling channel to carry additional data, data but which that 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 UUS supplementary service as
   follows:

   UUS1:  User-to-User information exchanged during the setup and
      clearing phases of a call, call by transporting DSS1 User-user
      information elements within call control messages.  This in itself
      has two subvariants, UUS1 implicit and UUS1 explicit.  In UUS1
      implicit, it is the presence of the user signalling data itself
      that constitutes the request for the service.  UUS1 explicit uses
      additional supplementary service control information to control
      the request and granting of the service, as in UUS2 and UUS3.  As
      a result, 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:  DSS1 User-user information elements 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:  DSS1 User-user information elements 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 is indeed the one that matches the requirements specified in RFC6567
   [RFC6567].

   The above come comes from the ISDN specifications defined for public
   networks.  There are is a parallel set of ISDN specifications defined for
   private networks (QSIG}. (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 is 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
      fields, the mechanism at any interworking point is to discard discards 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 Table 4-26 of ITU-T
      Recommendation Q.931) [Q931].  That protocol descriminator discriminator 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 ISDN User-to-User service, as the content is
      aligned with the protocol discriminator that appears at the start
      of all DSS1 messages (see table 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 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, data and to
      deliver all the data to the remote user.  On a link by link link-by-link basis,
      message contents are protected at layer Layer 2 by standard CRC Cyclic
      Redundancy Check (CRC) mechanisms - -- this allows loss on a link link-
      level basis to be
      detected, 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 Service on SIP operation Operation

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

   Call transfer:  ISDN call transfer cancels all ISDN 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.  The ISDN three-party
      supplementary service is similar in many ways to conferencing, 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 User-to-User data is to use SIP-T
   [RFC3372] and transport the UUI information end-to-end, as 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, and
   therefore SIP-T would not otherwise be used, this approach is not
   reasonable,
   reasonable because then implementation of the many elements of the
   ISUP syntax would be required to understand one element of data.
   Instead, the better approach is to interwork the ISDN User-to-User
   data using the native SIP UUI transport mechanism, the User-to-User
   header field.  The rest of this document describes this approach.

5.  Transition away Away from ISDN

   This interworking usage of the SIP UUI mechanism will likely begin
   with one User Agent being UA as an ISDN gateway while the other User Agent UA is a native SIP
   endpoint.  As networks transition away from ISDN, it is possible that
   both User Agents UAs 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]. [RFC7433].

   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 future package for some form of enhanced UUI has been
   standardized, the endpoint can carry the UUI data both as ISDN and as
   the future package in parallel, 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
   UUI package if it is an ISDN gateway or according to the future
   package if it is a native SIP endpoint.

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
   that interoperates with ISDN User-to-User Signaling (UUS), UUS, a supplementary service in which
   the user is able to send/receive a limited amount of information to/from 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.  As a
   result
   result, there is also only one encoding value specified.
   Responsibility for respecting the limits has been transferred to the
   end UA.  If an interworking point is reached, and the limitations of
   the ISDN (see section Section 3.1) are not met, then the UUI data will not be
   transferred, although the SIP request will otherwise be interworked.

   This is rather than have the interworking point attempt to resolve
   the non- compliance non-compliance with the limitations of ISDN.

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

      That the

      The sending application is expected to limit their sending
      requirements to the subset provided by the ISDN User-to-User
      service.

      That the

      The SIP UA will not allow the reception of more that than one
      User-to-User header field relating to the "isdn-uui" package in
      the same SIP request or response, and response; it 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 other
      packages is outside the scope of this document.

      That an

      An interworking point trying to interwork UUI data that is too
      long will discard the UUI data, 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 128-octet packets plus the protocol
      discriminator, in with 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-to-User data into the ISDN SETUP message (when
      discard occurs) will result in the service being unavailable for
      the remainder of the call when UUS1 implicit operation is used.

7.  UAC requirements Requirements

   The UAC User Agent Client (UAC) MUST meet the requirements of [I-D.ietf-cuss-sip-uui] [RFC7433]
   in addition to the requirements defined in this document.

   The UAC MUST only use this package of the UUI mechanism extension package 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 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
   "purpose" header field parameter to "isdn-uui".  Non-inclusion of the
   "purpose" 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,
   service and is therefore 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
   "purpose" header field parameter set to "isdn-uui", or with no
   "purpose" 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 "purpose" header field parameter set to
   "isdn-uui",
   "isdn-uui" or with no "purpose" header field parameter included.

   When sending UUI for the ISDN UUI package, if the "purpose" header
   field is included, the UAC MUST set the User-to-User "purpose" 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 "purpose" header field
   parameter set to "isdn-uui", or with no "purpose" 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 ones are the intended UUI data data, 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
   document makes no further normative requirements based on those
   constraints,
   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 ISDN;
   therefore, UUI data longer than this will never reach the destination
   if such interworking occurs.  Note that the 128 octet 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
   [RFC7433].

   A "uui" option tag for use with the UUI mechanism extension. extension is
   defined in [RFC7433].  Because the service is UUS1 implicit for the
   ISDN User-to-User service, the service is UUS1 implicit, the inclusion of the "uui" option tag in a
   Supported header field conveys no additional information over and
   above the presence, in the INVITE request, of the User-to-User header
   field with the "purpose" header field parameter set to "isdn-
   uui". "isdn-uui".
   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 Requirements

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

   The UAS MUST only use this package of the UUI mechanism extension package 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 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
   "purpose" header field parameter set to "isdn-uui", or with no
   "purpose" 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 "purpose" header field parameter set to
   "isdn-uui",
   "isdn-uui" or with no "purpose" 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
   User-to-User header field with the "purpose" header field parameter
   set to
   "isdn-uui", "isdn-uui" or where no "purpose" header field parameter was
   included.  When sending UUI for the ISDN UUI package, the UAS SHOULD
   set the User-to-User "purpose" header field parameter to "isdn-uui".
   Non-inclusion of the "purpose" header field parameter is permitted,
   but this is primarily to allow earlier implementations to support
   this package.

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

   The "isdn-interwork" value for the "purpose" header field parameter
   was used in Internet-Drafts documents that have led to the publication of the present
   document.  Although these documents had no other status than
   "work "Work in progress",
   Progress", this value is implemented by some vendors.  While not
   defined by this document, implementations could find it useful for
   interoperability purposes to support parsing and interpreting "isdn-
   interwork" the same way as "isdn-uui" when receiving messages.

   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 "purpose"
   header field parameter set to "isdn-uui", or with no "purpose" header
   field parameter, the UAS 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
   "purpose" header field parameter set to "isdn-uui", or with no
   "purpose" 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 ones are the intended UUI data data, so
   all are discarded.

9.  UUI contents Contents

   These requirements apply when the "purpose" header field parameter is
   set to "isdn-uui", "isdn-uui" or with when there is no "purpose" 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 than "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 than "hex".

   When sending UUI, the sending application MUST include a protocol
   discriminator octet, conforming to table Table 4-26 of ITU-T Recommendation
   Q.931 [Q931] [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 protocols; otherwise,
   the usage is entirely up to the application, application and is outside the scope
   of this document.  Valid values are identified and documented by ITU-T, ITU-
   T, and there is no IANA registry for these values.

10.  Considerations for ISDN internetworking gateways 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 octet-structured data from the
   ISDN side and encode it using the "hex" encoding scheme defined in
   [I-D.ietf-cuss-sip-uui]
   [RFC7433] for inclusion as the UUI data in the User-to-
   User User-to-User header
   field.  In the reverse direction, it will take valid UUI data
   according to the "hex" encoding scheme, scheme and decode it to octet octet-
   structured data for sending to send 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 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
   discriminator; the application usage to sort sorts out any discrepancy.  The
   same applies to the ISDN protocol discrimination defined table 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

   A "uui" option tag for use with the UUI mechanism extension. extension is
   defined in [RFC7433].  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 Requirements

   This document defines "isdn-uui" as a new value of the User-to-User
   "purpose" header field parameter.  The following ABNF adds to the
   production in [I-D.ietf-cuss-sip-uui]: [RFC7433]:

          pkg-param-value =/ "isdn-uui"

   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 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.
   The following ABNF adds to the production in [I-D.ietf-cuss-sip-uui]. [RFC7433].

          cont-param-value =/ "isdn-uui"

12.  Media Feature Tag

   This document defines a the new media feature tag "sip.uui-isdn".  This
   feature tag indicates that this ISDN 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

   Per this document, the following row has been added to the "UUI packages" sub-
   registry
   Packages" subregistry 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 RFC 7434

      Contact: Keith Drage

   This document adds

   Per this document, the following row has been added to the "UUI content"
   Content" subregistry of the SIP parameter registry:

      Value: isdn-uui

      Description: The associated contents conforms conform to the content
      associated with the ISDN User-to-User service.  In the presence of
      the "purpose" header field parameter set to "isdn-uui" (or the
      absence of any "purpose" header field parameter) parameter), this is the
      default meaning and therefore need not be included in this case.

      Reference: RFCXXXX RFC 7434
      Contact: Keith Drage

   This document defines the following media feature tag tag, which is has been
   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 package "uui-isdn".

      Values appropriate for use with this feature tag: none

      Examples of typical use: Indicating that a mobile phone supports
      SRVCC
      Single Radio Voice call Continuity (SRVCC) for calls in the
      alerting phase.

      Related standards or documents: RFCXXXX RFC 7434

      Security Considerations: Security considerations for this media
      feature tag are discussed in section Section 11.1 of [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]. [RFC7433].  However, since this
   capability is designed to interwork with the ISDN, the general
   security considerations of SIP to ISUP (ISDN ISDN User Part) Part (ISUP) interworking
   defined in [RFC3398] apply.  Any SIP/PSTN gateway implementing the
   ISDN User-to-User service should not blindly trust ISUP from the
   PSTN.  In general, the overlying use case will define the security
   measures required.  The underlying User-to-User header field
   extension provides a number of tools that can meet certain security
   requirements.

   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, 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 be aware that the
   security level of the ISDN service may be lower than the security of
   the SIP service.  The ISDN security is itself not definable on an
   end-to-end basis, basis and exists on a hop-by-hop basis.  This can be high
   in some places (e.g. (e.g., it can require physical access to a secure
   building) and in other places it can be low (e.g. (e.g., the point where an
   ISDN access enters a building).  If this level of security is not
   sufficient, then either a different package, package or indeed, indeed a different
   method of data transfer, transfer needs to be selected by the application user.

16.

15.  References

16.1.

15.1.  Normative References

   [Q931]     ITU-T, "ISDN user-network interface layer 3 specification
              for basic call control", ITU-T Recommendation Q.931,
              <http://www.itu.int/rec/T-REC-Q.931-199805-I/en>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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. 2002, <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol
              for Telephones (SIP-T): Context and Architectures", BCP
              63, RFC 3372, September 2002. 2002,
              <http://www.rfc-editor.org/info/rfc3372>.

   [RFC3398]  Camarillo, G., Roach, A., Peterson, J., and L. Ong,
              "Integrated Services Digital Network (ISDN) User Part
              (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC
              3398, December 2002,
              <http://www.rfc-editor.org/info/rfc3398>.

   [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] 2004,
              <http://www.rfc-editor.org/info/rfc3840>.

   [RFC7433]  Johnston, A. and J. Rafferty, "A Mechanism for
              Transporting User to User User-to-User Call Control Information in
              SIP", draft-ietf-cuss-sip-uui-17 (work in progress),
              June RFC 7433, December 2014.

   [Q931]     "ITU-T Recommendation Q.931:

15.2.  Informative References

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

   [RFC3398]  Camarillo, G., Roach, A., Peterson, J., and L. Ong, (ISDN) -
              Explicit Call Transfer Supplementary Service", ANSI-
              T1.643A - SUP A, December 1996.

   [ETSI]     ETSI, "Integrated Services Digital Network (ISDN) User (ISDN);
              Diversion supplementary services; Digital Subscriber
              Signalling System No. one (DSS1) protocol; Part
              (ISUP) to Session Initiation 1:
              Protocol (SIP) Mapping",
              RFC 3398, specification", ETSI ETS 300 207-1, Ed. 1,
              December 2002.

16.2.  Informative References

   [Q957.1]   "ITU-T 1994.

   [Q763]     ITU-T, "Signalling System No. 7 - ISDN User Part formats
              and codes", ITU-T Recommendation Q.957.1: Digital Q.763,
              <http://www.itu.int/rec/T-REC-Q.763-199912-I/en>.

   [Q957.1]   ITU-T, "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)", ITU-T 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",
              ITU-T http://www.itu.int/rec/T-REC-Q.931-199805-I/en. Recommendation Q.957.1,
              <http://www.itu.int/rec/T-REC-Q.957.1-199607-I>.

   [RFC6567]  Johnston, A. and L. Liess, "Problem Statement and
              Requirements for Transporting User-to-User Call Control
              Information in SIP", RFC 6567, April 2012.

   [ANSII]    "ANSI T1.643-1995, Telecommunications-Integrated Services
              Digital Network  (ISDN)-Explicit Call Transfer
              Supplementary Service", ANSI T1.643-1995 .

   [ETSI]     ""ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
              Digital Network  (ISDN); Diversion supplementary
              services"", ETSI ETF 300 207-1 .

15. 2012,
              <http://www.rfc-editor.org/info/rfc6567>.

Appendix A.  Acknowledgments

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

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

   The death of Francois Audet occurred before this document was
   finalised,
   finalized, and the authors would like to identify the significant
   contribution of Francois to this and a number of important RFCs, RFCs and
   to express their condolences to his family.  It was always a pleasure
   to work with Francois.

Authors' Addresses

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

   Email:
   United Kingdom

   EMail: keith.drage@alcatel-lucent.com

   Alan Johnston
   Avaya
   St. Loius, Louis, MO
   US

   Email:
   United States

   EMail: alan.b.johnston@gmail.com