diff options
Diffstat (limited to 'doc/rfc/rfc7434.txt')
| -rw-r--r-- | doc/rfc/rfc7434.txt | 955 |
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] + |