Interworking ISDN Call Control User Information with SIP
Extracted elements (23)
Responsibility for respecting ISDN data limits (128 octets plus protocol discriminator) is placed on the end UA rather than on the interworking point. If an interworking point receives UUI data that exceeds ISDN limits, it discards the UUI data silently but proceeds with the SIP-to-ISDN interworking of the call itself.
SIP-T encapsulation of ISUP/QSIG as a MIME body is rejected for true ISDN interworking because it would require implementing the full ISUP syntax to extract a single data element. The native SIP User-to-User header field is preferred as it avoids that dependency.
The package design allows parallel carriage of both 'isdn-uui' and a future package in the same or different messages during the ISDN-to-SIP transition, enabling the remote endpoint to consume whichever format it supports depending on whether it is an ISDN gateway or a native SIP endpoint.
ISDN call transfer cancels all ISDN User-to-User supplementary services; therefore UUI header fields cannot be exchanged in transactions clearing down the SIP dialog after call transfer has occurred. ISDN conferencing also precludes UUS1 implicit.
The 'uui' option tag in the Supported header field conveys no additional information over the presence of the User-to-User header field in the INVITE. Using the 'uui' option tag in a Require header field will cause the request to fail at UAS or ISDN gateways not supporting the extension, producing results inconsistent with ISDN UUS mechanisms.
The value 'isdn-interwork' for the 'purpose' parameter was used in predecessor documents and is implemented by some vendors. Implementations may find it useful to parse and interpret 'isdn-interwork' the same way as 'isdn-uui' when receiving messages, for interoperability with those implementations.
If the UAC wishes to use or permit sending of UUI data at any point in the dialog, it MUST include a User-to-User header field in the INVITE request for that dialog, even when there is no data other than the protocol discriminator octet to send at that time. The UAC SHOULD set the 'purpose' parameter to 'isdn-uui'.
ISDN interworking gateways encode octet-structured ISDN data using 'hex' encoding for the SIP User-to-User header field, and decode in the reverse direction. All content is treated as octet-structured binary regardless of the protocol discriminator value; no additional checking of the discriminator is performed.
ISDN interworking gateways MUST support UAC and UAS requirements, MUST support only the 'isdn-uui' package on interworked dialogs, and MUST NOT treat omission of the 'uui' option tag in a received INVITE as an indication that UUI interworking is not to be performed.
The UAC MUST NOT include more than one User-to-User header field for the isdn-uui package in any single SIP request or response. When multiple such headers are received, the UAC MUST discard all of them, as there is no mechanism for determining which is the intended UUI data.
The UAC MUST NOT include the User-to-User header field with purpose 'isdn-uui' (or no purpose parameter) in any message of an INVITE dialog if the original INVITE did not itself include such a header field. This prevents UUI from appearing mid-dialog without prior signalling.
The UAC MUST only use this UUI package in association with the initial INVITE method and the BYE method relating to an INVITE dialog. Usage on re-INVITE transactions, other methods within the INVITE dialog, or methods not associated with a dialog is precluded.
The UAS MUST only use this package in association with the initial INVITE and BYE methods. The UAS MUST NOT include the User-to-User header field in a dialog if the original INVITE did not include it, and MUST NOT include it in header URI parameters of 3xx redirect responses.
When sending UUI, the sending SIP entity MUST include a protocol discriminator octet conforming to Table 4-26 of ITU-T Q.931 as the first octet of the UUI data. A receiving entity MUST ignore a User-to-User header field if the 'content' parameter is present with a value other than 'isdn-uui'.
When the UAS receives a User-to-User header field that is not from the originating user (with purpose 'isdn-uui' or no purpose), the UAS MUST discard the header field. When multiple such headers are received from the originating user in the same request, the UAS MUST discard all of them.
Only the UUS1 implicit variant of the ISDN User-to-User supplementary service is covered. In UUS1 implicit, the presence of the user signalling data itself constitutes the request for the service, without additional supplementary service control information.
RFC 7434 defines the 'isdn-uui' package for the User-to-User header field (RFC 7433) to enable SIP interworking with the ISDN User-to-User Signalling (UUS) supplementary service. The package is identified by the value 'isdn-uui' of the 'purpose' header field parameter.
The ISDN UUS1 service limits UUI data to a maximum of 128 octets of user information plus a single-octet protocol discriminator. Only a single piece of UUI data can be transported in each message.
A new entry 'isdn-uui' was added to the 'UUI Content' subregistry of the SIP parameter registry. It indicates that the contents conform to the ISDN User-to-User service format (protocol discriminator octet followed by up to 128 octets). This is the default for the isdn-uui purpose and need not be explicitly included.
A new media feature tag 'sip.uui-isdn' was registered in the features.sip-tree of the Media feature tags registry. When present in a Contact header field, it indicates that the entity supports the 'uui-isdn' package, with a defined use case of indicating SRVCC support for calls in the alerting phase.
If ISDN forms part of the call route, the security level of the ISDN service may be lower than that of SIP. ISDN security exists only on a hop-by-hop basis and is not definable end-to-end; it can range from high (requiring physical access to secure premises) to low (at building entry points). Applications requiring higher security should use a different package or data transfer method.
SIP/PSTN gateways implementing the ISDN User-to-User service should not blindly trust ISUP received from the PSTN, following the general SIP-to-ISUP interworking security principles of RFC 3398. Information revealing private data or requiring authenticity guarantees may not be suitable for this package given the lower ISDN security baseline.
The UUI data for this package uses 'hex' encoding (the only defined encoding). The first octet MUST be a protocol discriminator conforming to Table 4-26 of ITU-T Q.931, followed by up to 128 octets of user information data. The 128-octet limit applies before hex encoding or after hex decoding.