RFC 7434

Interworking ISDN Call Control User Information with SIP

📅 published January 2015, from ietf

Interworking ISDN Call Control User Information with SIP ✨🎀

RFC: 7434 Category: Standards Track (an Internet Standards Track document) 🦋 ISSN: 2070-1721 Date: January 2015 📅 Authors: K. Drage, Ed. (Alcatel-Lucent) and A. Johnston (Avaya) 💅 Stream: IETF Obsoletes / Updates: the header doesn't list any RFCs here, so nothing is obsoleted or updated 🙈

Abstract

Okay bestie, so the why and the use cases for moving User-to-User Information (UUI) from the ITU-T DSS1 User-user information element into SIP are already covered in RFC 6567 💖. As networks move to SIP 🌸, the apps that need this data should keep working in SIP networks, and they should be able to interwork with this ISDN service so the data stays transparent end-to-end ✨. This doc defines a usage (a brand-new package called the ISDN UUI package) of the User-to-User header field to make that happen 🎀. It covers both public ISDN and private ISDN, so interworking with QSIG gets addressed too 🌈.

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 got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💜. More info on Internet Standards is in Section 2 of RFC 5741 📚.

For the current status, any errata, and how to give feedback, check out http://www.rfc-editor.org/info/rfc7434 🦋.

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) as they stand on the date this document was published 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙏. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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

1. Overview 🌟

This doc describes a usage of the User-to-User header field, which is defined in [RFC7433] 💖. It lets UUI travel in ISDN interworking scenarios using SIP [RFC3261] 🦋. Specifically, it covers the interworking of these call control items: the ITU-T Recommendation Q.931 DSS1 User-user information element [Q931], the ITU-T Recommendation Q.957.1 DSS1 User-to-User Signalling (UUS) supplementary service [Q957.1], and the ITU-T Recommendation Q.763 User-to-User information parameter [Q763] data in SIP 🎀. Right now, UUI is hugely used in the Public Switched Telephone Network (PSTN) in contact centers and call centers that are moving from ISDN to SIP 📞✨.

This usage isn't limited to places where interworking will happen 🌈. It describes a usage where interworking is possible if interworking is met 🙈. That doesn't rule out using it 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 💫

Okay so ISDN defines a bunch of related services 🧠. First up, there's a user signalling bearer service. It uses the information elements / parameters in the signalling channel to carry the data, and it does not set up a related circuit-switched connection 📡. For DSS1, this is specified in ITU-T Recommendation Q.931, Sections 3.3 and 7 of [Q931] 📜. Second, there's the User-to-User Signalling (UUS) supplementary service. It uses the information elements / parameters in the signalling channel to carry additional data, but it's used together with setting up a related circuit-switched connection 🦋. It reuses the same information elements / parameters as the user signalling bearer service, plus some other signalling info, and for DSS1 it's specified in ITU-T Recommendation Q.957.1 [Q957.1] 💖.

ISDN defines three variants of the UUS supplementary service, and they go like this 👑:

  • 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 one has two subvariants, UUS1 implicit and UUS1 explicit 🌸. In UUS1 implicit, the presence of the user signalling data itself is the request for the service ✨. UUS1 explicit uses extra supplementary service control information to control the request and granting of the service, same as UUS2 and UUS3 🎀. Because of that, UUS1 explicit also lets the requester say whether the parallel circuit-switched connection should go ahead if the UUS1 service can't 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 🦋.
  • UUS3: DSS1 User-user information elements exchanged while a call is in the Active state, within DSS1 USER INFORMATION messages 💜.

The calling user is always the one who requests the service 📞.

This document only brings the ISDN UUS1 implicit supplementary service into interworking scenarios 🔥. It's the most widely deployed and used of the various ISDN User-to-User services, and it's the one that matches the requirements in [RFC6567] 💅.

The above comes from the ISDN specs for public networks 🌍. There's a parallel set of ISDN specs for private networks (QSIG) 🏢. Those specs don't define a UUS1 implicit supplementary service 🙈. But a UUS1 implicit service for private networks can easily be built in a proprietary way based on the public network specs, and evidence suggests some vendors have done exactly that 🫶. So there's no reason this package can't also support interworking with that private network service, on the assumption that the constraints are exactly the same as the public network's ✨.

The ISDN UUS1 service also has these extra characteristics about the data it can carry 🌈:

  • The maximum number of octets of user information that can be transported is 128 octets plus a protocol discriminator 📏. Some early ISDN implementations had a 32-octet limit, but those aren't currently deployed, as far as we know 🙈. This package doesn't prohibit longer data fields, but 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 discriminator may describe the protocol used within the user data, the structure of the user data, or leave it totally open 🌸. Not every value of the protocol discriminator makes sense for the ISDN User-to-User service, though 🤔. The content lines up with the protocol discriminator that shows up 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 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 operators of those elements, not to modify the data and to deliver all of it to the remote user 🫣. On a link-by-link basis, message contents are protected at Layer 2 by standard cyclic redundancy check mechanisms, which lets link-level loss get detected but doesn't guard against fraudulent attacks on the link itself 🛡️. Additional encryption or integrity protection within the UUI data is still possible, though the limit on UUI data size (protocol discriminator plus 128 octets) will restrict it 🔐💖.

3.2. Impacts of the ISDN Service on SIP Operation

okay so there are a few ISDN things you NEED to understand before you touch the SIP side 🧠💅 let's go bestie:

  • Call transfer: ISDN call transfer cancels ALL the ISDN User-to-User supplementary services 💀. If you still need User-to-User data after a transfer, UUS3 has to be renegotiated, and this SIP extension doesn't give you a way to do that 🙈. So for SIP, it means UUI header fields can't be exchanged in the transactions that clear down the SIP dialog after a call transfer has happened.
  • Conference: ISDN conferencing lets the user keep exchanging User-to-User data after the conference is created 🎀. But as far as UUS1 is concerned, that's not allowed. The ISDN three-party supplementary service is kind of similar to conferencing, just signalled with a different mechanism 🧚. So when clearing happens, the controller using UUS1 implicit does get to choose whether to send data to one remote user, both, or neither (wait, not neither, just either or both 😭). Since SIP conferencing can't fully copy the ISDN three-party service at the served user, UUS1 implicit is not possible.
  • Diversion: when ISDN diversion happens, any UUS1 User-to-User data gets sent to the forwarded-to-user 🦋 (as long as the call meets the requirements for the service, which only the explicit service affects). If the type of diversion also delivers the call to the forwarding user, they get any UUS1 User-to-User data too 👑.

4. Relation to SIP-T ✨

One way to carry 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 you're using SIP-T to encapsulate ISDN instead of doing interworking, this is a reasonable mechanism, and it doesn't need any extensions to existing SIP-T 🙌. But if you're doing true ISDN interworking, and SIP-T wouldn't otherwise be in the picture, this approach isn't reasonable 😩. Why? Because then you'd have to implement the many elements of the ISUP syntax just to understand one piece of data. The better move is to interwork the ISDN User-to-User data using the native SIP UUI transport mechanism, which is the User-to-User header field 💖. The rest of this document describes that approach.

5. Transition Away from ISDN 🦋

This interworking usage of the SIP UUI mechanism will probably start with one UA acting as an ISDN gateway while the other UA is a native SIP endpoint 🌸. As networks move away from ISDN, both UAs could end up being native SIP endpoints. When that happens, there's a chance to move away from this ISDN usage and toward a more general usage of [RFC7433] ✨.

The SIP UUI mechanism gives you a way to make that transition 🫶. As an endpoint goes from being an ISDN gateway to a native SIP endpoint, and once 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. It can do this in parallel, either in the same messages or in different messages, depending on what the application needs 💅. That way the other endpoint can use the UUI according to the ISDN UUI package if it's an ISDN gateway, or according to the future package if it's a native SIP endpoint 🌈.

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

This document defines the package for ISDN interworking of UUI that works with ISDN UUS 💜. UUS is a supplementary service where a user can send and receive a limited amount of information to and from another ISDN user over the signalling channel, in association with a call to that other ISDN user 📞.

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

One big goal in designing this package was to keep the functionality at the interworking point as simple as possible 🍓. Because of that, only one encoding value is specified. ✨

Responsibility for respecting the limits has been handed over to the end UA 👑. If an interworking point is reached and the limitations of the ISDN (see Section 3.1) aren't met, then the UUI data won't be transferred, but the SIP request will still be interworked 🙈. The alternative would be for the interworking point to try to fix the non-compliance with the ISDN limitations, and that's not what happens here 💀.

So the general principals of the UUI mechanism package are as follows 🌸:

  • The sending application is expected to limit its sending requirements to the subset provided by the ISDN User-to-User service 💅.
  • 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 that tries to interwork UUI data that's too long will discard the UUI data but still proceed with the interworking 🫠. There's no notification of that discard back to the sending user 🙈. If the SIP user knows it's 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, knowing that discard will happen if it doesn't 💖. The UUI application at the SIP endpoint has complete control over what happens 👑. This was exactly the envisaged operation when early ISDN implementations that only supported 32 octets interworked with those supporting 128 octets 🧠. It also matches interworking with ISDNs that don't support the supplementary service at all, because discard will happen in those cases too 🌈. Note that if the User-to-User data isn't included in the ISDN SETUP message (when discard occurs), the service will be unavailable for the rest 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 with the initial INVITE method and with the BYE method relating to an INVITE dialog 🦋. Using it on transactions tied to any other type of dialog, or on methods not tied to a dialog, is precluded 🙅. Using it on other methods within the INVITE dialog, and on re-INVITE transactions within the INVITE dialog, is also precluded 🚫.

If the UAC wants to use or permit sending UUI data at any point in the dialog, the UAC MUST include a User-to-User header field in the INVITE request for that dialog 📩. The UAC SHOULD set the purpose header field parameter to "isdn-uui" ✨. Leaving out the purpose header field parameter is permitted, but this is mainly so earlier implementations can still support this package 🧚. This initial header field is the implicit request to use the UUI service, so it's included even when there's no data to send at that point except the protocol discriminator octet 💜.

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 didn't 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, if 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 of these header fields 🗑️. There's no mechanism for working out which ones are the intended UUI data, so all of them get discarded 😭.

The application designer needs to take the ISDN service restrictions into account 🧠. Failing to do that can result in information being discarded at any interworking point with the ISDN 💀. This document doesn't add any further normative requirements based on those constraints, because the constraints may vary from one ISDN to another 🌸. It's reasonable to expect that a limitation of 128 octets (plus a protocol discriminator) can be imposed by the ISDN 🌈. So UUI data longer than that will never reach the destination if that kind of interworking happens 🫠. 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, including the "uui" option tag in a Supported header field doesn't add any information beyond what's already there: the presence of the User-to-User header field with the purpose header field parameter set to "isdn-uui" in the INVITE request 🎀. There's no harm in including the "uui" option tag, and strictly speaking it should be included if the extension is supported, but it doesn't do anything 🙃. Putting the "uui" option tag in the Require header field of an INVITE request will make the request fail if it reaches a UAS or ISDN interworking gateway that doesn't support this extension 💀. That usage is allowed, but it'll give results that are inconsistent with the mechanisms defined in the ISDN UUS supplementary service 😭.

8. UAS Requirements 🎀

Okay bestie, the UAS MUST meet the requirements of [RFC7433] on top of everything in this document 💅

The UAS MUST only use this UUI mechanism extension package with the initial INVITE method and the BYE method for an INVITE dialog. Using it on transactions tied to any other kind of dialog, or on methods that aren't tied to a dialog at all, is a hard no 🙅‍♀️ Using it on other methods inside the INVITE dialog, or on re-INVITE transactions within that dialog, is also ruled out 🚫

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 didn't include the User-to-User header field with either a purpose set to isdn-uui or no purpose parameter at all. Not the vibe 😤

The UAS MAY include the User-to-User header field in responses to the initial INVITE request, or in the BYE requests or responses for the dialog, but only when the original INVITE request had a User-to-User header field with purpose set to isdn-uui or had no purpose parameter included. When sending UUI for the ISDN UUI package, the UAS SHOULD set the User-to-User purpose header field parameter to isdn-uui ✨ Leaving out the purpose parameter is allowed, but that's mainly so older implementations can still 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. One per message, periodt 💖

The isdn-interwork value for the purpose header field parameter came from the documents that led to this one. Those were only "Work in Progress" drafts, but some vendors implemented the value anyway 🌸 This document doesn't define it, but implementations could find it useful for interoperability to parse and interpret 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. No sneaking UUI into redirects 🙈

When receiving UUI, if a User-to-User header field arrives in a request that isn't from the originating user, and it has purpose set to isdn-uui or no purpose parameter at all, the UAS MUST discard that header field. Bye bye 👋

When receiving UUI, if multiple User-to-User header fields arrive from the originating user in the same request, with purpose set to isdn-uui or with no purpose parameter, or some mix of those, the UAS MUST discard all of them. Why? There's no way to tell which one holds the intended UUI data, so they all get tossed 💀

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 any other purpose value is outside the scope of this document, so the package document for that value is the one that 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 has any value other 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 has any value other 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's up to the receiving application what it does with that value. This document places no other normative requirement on the protocol discriminator. It's required at interworking gateways so it can be mapped into the right fields in the ISDN protocols. Otherwise, how it's used is totally up to the application and out of scope here 🔥 Valid values are identified and documented by ITU-T, and there's no IANA registry for them 💅

10. Considerations for ISDN Interworking Gateways 🌸

ISDN interworking gateways MUST support the requirements defined for UAS and UAC operation. Gateways have to keep up with both sides ✨

ISDN interworking gateways MUST support only the isdn-uui package on dialogs that are interworked. Just that one package, no others 👑

ISDN interworking gateways will take octet-structured data from the ISDN side and encode it with the hex encoding scheme defined in [RFC7433] so it can go into the User-to-User header field as UUI data. In the other direction, they'll take valid UUI data in the hex encoding, decode it into octet-structured data, and send that 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 all content is octet-structured binary, no matter what the protocol discriminator value is. The ISDN has no requirements to make sure the content matches the protocol discriminator, so the application usage sorts out any mismatch 🤷‍♀️ The same goes for the ISDN protocol discriminator as the first octet of the UUI data, defined in Table 4-26 of ITU-T Recommendation Q.931 [Q931]. The interworking gateway won't do any extra checking on that value 🙃

A uui option tag for use with the UUI mechanism extension is defined in [RFC7433]. The option tag isn't interworked at an ISDN interworking gateway. ISDN interworking gateways MUST NOT take the omission of the uui option tag in a received INVITE request to mean that interworking of a received header field isn't supposed to happen. Missing tag does not mean no interworking, babe 💁‍♀️

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 means the contents have a first octet that's a protocol discriminator (see Table 4-26 of ITU-T Recommendation Q.931 [Q931]), followed by UUI data that can have a length limitation (before encoding or after decoding), which is generally 128 octets 🧚

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 shows that the sender supports this ISDN UUI package, and its usage is totally in line with [RFC3840]. This document doesn't add any other rules for using 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
   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 for security over and above those 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 defines 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 not be suitable for this package at all. Keep that in mind with the next paragraph too 👀

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. ISDN security can't be defined end-to-end. It exists on a hop-by-hop basis. It can be high in some places (for example, it can require physical access to a secure building), and low in others (for example, the point where an ISDN access enters a building). If that level of security isn't sufficient, then the application user needs to pick either a different package or a different method of data transfer 😭🔥

15. References 📚

15.1. Normative References ✨

okay bestie, these are the references the spec needs you to have read, no skipping 💅

15.2. Informative References 🌈

these ones are the extra reading. helpful, not required, but I'd still totally read them 🧠

  • [ANSII] ANSI, "Integrated Services Digital Network (ISDN) - Explicit Call Transfer Supplementary Service", ANSI-T1.643A - SUP A, December 1996. 🔁 call transfer, but make it ANSI
  • [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. ↪️ diversion services, the European side of the story
  • [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>. 📡 the ISUP formats and codes, very detail-core 🤓
  • [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>. 💬 the UUS stage 3 deep dive, the origin of the vibe
  • [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>. 🎀 the "why do we even need this" RFC, so iconic for context 🫶

Acknowledgments 🙏

Joanne McMillen was a major contributor and coauthor of earlier versions of this document. 👑 we love a legend who laid the groundwork

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 squad that reviewed and commented, so grateful

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. 🥹💜 a real one, we're sending love to his family

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 🌟 the authors, the ones who made this all happen

📦 where this page comes from