GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7434

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7434.txt · Last modified: 2015/01/23 04:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki