doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7434.txt b/doc/rfc/rfc7434.txt
new file mode 100644
index 0000000..77dbc37
--- /dev/null
+++ b/doc/rfc/rfc7434.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     K. Drage, Ed.
+Request for Comments: 7434                                Alcatel-Lucent
+Category: Standards Track                                    A. Johnston
+ISSN: 2070-1721                                                    Avaya
+                                                            January 2015
+
+
+        Interworking ISDN Call Control User Information with SIP
+
+Abstract
+
+   The motivation and use cases for interworking and transporting User-
+   to-User Information (UUI) from the ITU-T Digital Subscriber
+   Signalling System No. 1 (DSS1) User-user information element within
+   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 interworking with both public ISDN and private
+   ISDN capabilities, so the potential interworking with QSIG will also
+   be addressed.
+
+   The package is identified by the new value "isdn-uui" of the
+   "purpose" header field parameter.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for 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 this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7434.
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 1]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Summary of the ISDN User-to-User Service  . . . . . . . . . .   3
+     3.1.  The Service . . . . . . . . . . . . . . . . . . . . . . .   3
+     3.2.  Impacts of the ISDN Service on SIP Operation  . . . . . .   6
+   4.  Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . .   6
+   5.  Transition Away from ISDN . . . . . . . . . . . . . . . . . .   7
+   6.  ISDN Usage of the User-to-User Header Field . . . . . . . . .   7
+   7.  UAC Requirements  . . . . . . . . . . . . . . . . . . . . . .   8
+   8.  UAS Requirements  . . . . . . . . . . . . . . . . . . . . . .  10
+   9.  UUI Contents  . . . . . . . . . . . . . . . . . . . . . . . .  11
+   10. Considerations for ISDN Interworking Gateways . . . . . . . .  12
+   11. Coding Requirements . . . . . . . . . . . . . . . . . . . . .  12
+   12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . .  13
+   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+   14. Security Considerations . . . . . . . . . . . . . . . . . . .  14
+   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     15.1.  Normative References . . . . . . . . . . . . . . . . . .  15
+     15.2.  Informative References . . . . . . . . . . . . . . . . .  16
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 2]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+1.  Overview
+
+   This document describes a usage of the User-to-User header field
+   defined in [RFC7433] to enable the transport of UUI in ISDN
+   interworking scenarios using SIP [RFC3261].  Specifically, this
+   document discusses the interworking of the following items, which are
+   call control related: ITU-T Recommendation Q.931 DSS1 User-user
+   information element [Q931], ITU-T Recommendation Q.957.1 DSS1 User-
+   to-User Signalling (UUS) supplementary service [Q957.1], and ITU-T
+   Recommendation Q.763 User-to-User information parameter [Q763] data
+   in SIP.  Today, UUI is widely used in the Public Switched Telephone
+   Network (PSTN) in contact centers and call centers 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.
+
+2.  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].
+
+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 that 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, Sections 3.3 and 7 of
+   [Q931].  Secondly, it defines a User-to-User Signalling (UUS)
+   supplementary service that uses the information elements / parameters
+   in the signalling channel to carry additional data but 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].
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 3]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+   ISDN defines three variants of the UUS supplementary service as
+   follows:
+
+   UUS1:  User-to-User Information exchanged during the setup and
+      clearing phases of a 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 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].
+
+   The above comes from the ISDN specifications defined for public
+   networks.  There is 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.
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 4]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+   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 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 4-26 of ITU-T
+      Recommendation Q.931) [Q931].  That protocol 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 4-1 of ITU-T Recommendation Q.931)
+      [Q931].  The protocol discriminator value has no impact on the
+      interworking capability.
+
+      Only a single piece of UUI data 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 cyclic
+      redundancy check 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 5]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+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 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 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 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 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.
+
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 6]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+5.  Transition Away from ISDN
+
+   This interworking usage of the SIP UUI mechanism will likely begin
+   with one UA as an ISDN gateway while the other UA is a native SIP
+   endpoint.  As networks transition away from ISDN, it is possible that
+   both 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 [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 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
+   that interoperates with ISDN 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.  As a
+   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 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 with the limitations of ISDN.
+
+   The general principals of the UUI mechanism package are, therefore,
+   as follows:
+
+      The sending application is expected to limit their sending
+      requirements to the subset provided by the ISDN User-to-User
+      service.
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 7]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+      The SIP UA will not allow the reception of more than one
+      User-to-User header field relating to the "isdn-uui" package in
+      the same SIP request or 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.
+
+      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 packets of 128 octets plus the protocol
+      discriminator, 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
+
+   The User Agent Client (UAC) MUST meet the requirements of [RFC7433]
+   in addition to the requirements defined in this document.
+
+   The UAC MUST only use this 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,
+   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 and is, therefore, included even when there is no data except
+   the protocol discriminator octet to send at that point in time.
+
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 8]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+   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" 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 ones are the intended UUI 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 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;
+   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
+   [RFC7433].
+
+   A "uui" option tag for use with the UUI mechanism extension is
+   defined in [RFC7433].  Because the service is UUS1 implicit for the
+   ISDN User-to-User service, 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".
+   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 usage is allowed but will produce
+   results that are inconsistent with the mechanisms defined in the ISDN
+   UUS supplementary service.
+
+
+
+
+Drage & Johnston             Standards Track                    [Page 9]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+8.  UAS Requirements
+
+   The UAS MUST meet the requirements of [RFC7433] in addition to the
+   requirements defined in this document.
+
+   The UAS MUST only use this 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,
+   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" 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 header field with the "purpose" header field parameter
+   set to "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 documents that led to the publication of the present
+   document.  Although these documents had no other status than "Work in
+   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.
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 10]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+   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 ones are the intended UUI data, so
+   all are discarded.
+
+9.  UUI Contents
+
+   These requirements apply when the "purpose" header field parameter is
+   set to "isdn-uui" or 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 than "hex".
+
+   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 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; otherwise,
+   the usage is entirely up to the application and is outside the scope
+   of this document.  Valid values are identified and documented by
+   ITU-T, and there is no IANA registry for these values.
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 11]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+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
+   [RFC7433] 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 to send to the ISDN side.
+
+   When mapping data content from the ISDN to 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; the application usage sorts out any discrepancy.  The
+   same applies to the ISDN protocol discriminator as the first octet of
+   the UUI data, as defined in Table 4-26 of ITU-T Recommendation Q.931
+   [Q931]; the interworking gateway will not perform any additional
+   checking of this value.
+
+   A "uui" option tag for use with the UUI mechanism 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
+
+   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 [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 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.
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 12]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+   The following ABNF adds to the production in [RFC7433].
+
+          cont-param-value =/ "isdn-uui"
+
+12.  Media Feature Tag
+
+   This document defines 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 [RFC3840].  This
+   document makes no additional provisions for the use of this feature
+   tag.
+
+13.  IANA Considerations
+
+   Per this document, the following row has been added to the "UUI
+   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: RFC 7434
+
+   Per this document, the following row has been added to the "UUI
+   Content" subregistry of the SIP parameter registry:
+
+      Value: isdn-uui
+
+      Description: The associated contents 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), this is the
+      default meaning and therefore need not be included in this case.
+
+      Reference: RFC 7434
+
+   This document defines the following media feature tag, which 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
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 13]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+      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
+      Single Radio Voice call Continuity (SRVCC) for calls in the
+      alerting phase.
+
+      Related standards or documents: RFC 7434
+
+      Security Considerations: Security considerations for this media
+      feature tag are discussed in Section 11.1 of [RFC3840]
+
+14.  Security Considerations
+
+   This document contains no specific requirements in regard to security
+   over and above those specified in [RFC7433].  However, since this
+   capability is designed to interwork with the ISDN, the general
+   security considerations of SIP to ISDN User 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 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 and exists on a hop-by-hop basis.  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 package or indeed a different
+   method of data transfer needs to be selected by the application user.
+
+
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 14]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+15.  References
+
+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,
+              <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, <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,
+              <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,
+              <http://www.rfc-editor.org/info/rfc3840>.
+
+   [RFC7433]  Johnston, A. and J. Rafferty, "A Mechanism for
+              Transporting User-to-User Call Control Information in
+              SIP", RFC 7433, December 2014,
+              <http://www.rfc-editor.org/info/rfc7433>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 15]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+15.2.  Informative References
+
+   [ANSII]    ANSI, "Integrated Services Digital Network (ISDN) -
+              Explicit Call Transfer Supplementary Service", ANSI-
+              T1.643A - SUP A, December 1996.
+
+   [ETSI]     ETSI, "Integrated Services Digital Network (ISDN);
+              Diversion supplementary services; Digital Subscriber
+              Signalling System No. one (DSS1) protocol; Part 1:
+              Protocol specification", ETSI ETS 300 207-1, Ed. 1,
+              December 1994.
+
+   [Q763]     ITU-T, "Signalling System No. 7 - ISDN User Part formats
+              and codes", ITU-T Recommendation 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 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,
+              <http://www.rfc-editor.org/info/rfc6567>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 16]
+
+RFC 7434                  ISDN Call Control UUI             January 2015
+
+
+Acknowledgments
+
+   Joanne McMillen was a major contributor and 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, and Celine Serrut-Valette for their comments.
+
+   The death of Francois Audet occurred before this document was
+   finalized, and the authors would like to identify the significant
+   contribution of Francois to this and a number of important 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
+   United Kingdom
+
+   EMail: keith.drage@alcatel-lucent.com
+
+
+   Alan Johnston
+   Avaya
+   St. Louis, MO
+   United States
+
+   EMail: alan.b.johnston@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drage & Johnston             Standards Track                   [Page 17]
+