Interworking ISDN Call Control User Information with SIP
draft-drage-cuss-sip-uui-isdn-00

Abstract

The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage of the User-to-User header field to enable interworking with this ISDN service.

This document is covers the interworking with both public ISDN and private ISDN capabilities, so the interworking with QSIG will also be addressed.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on March 24, 2011.

Copyright Notice

Copyright (c) 2010 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.  Terminology
2.  Overview
3.  Summary of the ISDN User-to-User Service
    3.1.  The service
    3.2.  Impacts of the ISDN service on SIP operation
4.  Relation to SIP-T
5.  Transition away from ISDN
6.  ISDN Usage of the User-to-User Header Field
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  Normative References
§  Authors' Addresses

1.  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 BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Overview

This document describes a usage of the User-to-User header field defined in [johnston‑cuss‑sip‑uui] (Johnston, A., McMillen, J., and J. Rafferty, “A Mechanism for Transporting User to User Call Control Information in SIP,” .) to enable the transport of User to User Information (UUI) in ISDN interworking scenarios using SIP [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). Specifically, this document discuss the interworking of call control related ITU-T DSS1 User-user information element[Q931] (, “ITU-T Recommendation Q.931: Digital subscriber Signalling System No. 1 - Network layer; ISDN user-network interface layer 3 specification for basic call control,” .), [Q957.1] (, “ITU-T Recommendation Q.957.1: 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),” .) and ITU-T Q.763 User-to-user information parameter [Q763] (, “ITU-T Q.763 Signaling System No. 7 - ISDN user part formats and codes,” .) data in SIP. UUI is widely used in the PSTN today in contact centers and call centers which are transitioning away from ISDN to SIP.

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, which 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 section 3.3 and section 7 [Q931] (, “ITU-T Recommendation Q.931: Digital subscriber Signalling System No. 1 - Network layer; ISDN user-network interface layer 3 specification for basic call control,” .). It also defines a user-to-user signalling supplementary service, which uses the information elements / parameters in the signalling channel to carry additional data, but which 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] (, “ITU-T Recommendation Q.957.1: 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),” .).

ISDN defines three variants of the user-to-user signalling supplementary service as follows:

UUS1:

User-to-user information exchanged during the setup and clearing phases of a call, by transporting User-to-user information element within call control messages. This in itself has two subvariants, UUS1 implicit and UUS1 explicit. UUS1 explicit uses additional supplementary service control information to control the request and granting of the service, as in USS2 and UUS3. In UUS1 implicit, it is the presence of the user signalling data itself that constitutes the request for the service. UUS1 explicit as a result 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:

User-to-user information 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:

User-to-user information 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 application 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 indeed the one that matches the requirements specified in draft-johnston-cuss-sip-uui-reqs.

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 in 128 octets. It is noted that some early ISDN implementations had a limitation of 32 octets, but it is understood that these are not currently deployed.

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] (, “ITU-T Recommendation Q.931: Digital subscriber Signalling System No. 1 - Network layer; ISDN user-network interface layer 3 specification for basic call control,” .). That protocol descriminator 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 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] (, “ITU-T Recommendation Q.931: Digital subscriber Signalling System No. 1 - Network layer; ISDN user-network interface layer 3 specification for basic call control,” .).

Only a single user information package 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 CRC 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 payload itself, although the limit on the size of the payload (128 octets) will restrict this.

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 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, this means that when an individual party clears, those clearing messages can still contain user-to-user data. As a conferee this is sent to the conference controller. As the conference controller, as this effectively clears the conference, it can be broadcast to all conferees, or sent to individual conferees [OPEN ISSUE - CHECK THIS IN THE PROTOCOL - DOES IT REQUIRE EXPLICIT].

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.

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.

Contributors note: The above list needs to be studied further in regard to private ISDN service definitions, e.g. for the interworking of SIP and QSIG.

4.  Relation to SIP-T

A method of transport of ISDN UUI is to use SIP-T [RFC3372] (Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” September 2002.) 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, this approach is not reasonable. Instead, the better approach is to interwork the ISDN UUI using the native SIP UUI transport mechanism, the User-to-User header field. The rest of this document describes this approach.

5.  Transition away from ISDN

This interworking usage of the SIP UUI mechanism will likely begin with one User Agent being an ISDN gateway while the other User Agent is a native SIP endpoint. As networks transition away from ISDN, it is possible that both User Agents 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 [johnston‑cuss‑sip‑uui] (Johnston, A., McMillen, J., and J. Rafferty, “A Mechanism for Transporting User to User Call Control Information in SIP,” .). This will be possible when both endpoints are aware of the actual application using the UUI.

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 usage application for the UUI has been standardized, the endpoint can carry the UUI both as ISDN and application encoding. This will permit the other endpoint to utlize the UUI if it is an ISDN gateway or a native SIP endpoint. When all the endpoints have moved away from ISDN, the ISDN encoding usage can be discontinued.

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

This document defines the purpose usage of the ISDN interworking application of UUI which is to interoperate with ISDN User to User Signaling (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] (, “ANSI T1.643-1995, Telecommunications-Integrated Services Digital Network (ISDN)-Explicit Call Transfer Supplementary Service,” .) and [ETSI] (, “ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services Digital Network (ISDN); Diversion supplementary services,” .).

OPEN ISSUE 1: Key to defining such an application is to understand how the capabilities of the generic SIP User-to-User header field extension relate to those provide by the ISDN user-to-user signalling supplementary service. If they are the same as the ISDN User-to-user signalling supplementary service then interworking is solely a matter of mapping the construct in one protocol into the equivalent construct in the other protocol. As the ISDN user-to-user signalling supplementary service is a somewhat restricted service, it is unlikely that the capabilities will be more than the generic SIP User-to-User header field extension. So we need to deal with the question of what occurs when (and if) the generic SIP User-to-User header field extension has wider capabilities than those of the ISDN user-to-user signalling supplementary service. The capabilities of the ISDN user-to-user signalling supplementary service have been outlined in section 3. The following open issues target what could occur if each of these capabilities are exceeded.

OPEN ISSUE 2: The maximum number of octets defined for the generic SIP User-to-User header field extension exceeds the 128 octets supported by the ISDN user-to-user signalling supplementary service. Obviously if the SIP sender sends more than that allowed, then mapping of the entire contents is impossible. Truncation should not occur (as the truncation cannot be signalled in the ISDN and the contents will probably end up meaningless) and therefore the only option is to discard the information and proceed without it. Mapping in the opposite direction will never be a problem. Is extra signalling needed to allow for this discard; it is believed that the answer is no. 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 128 octet packets, in 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-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.

OPEN ISSUE 3: The generic SIP User-to-User header field extension supports the description of more "protocol discriminators" that that supported by the ISDN user-to-user signalling supplementary service. Part of this depends on how these additional application identifiers (if any) are carried, and as a result whether the existing ISDN protocol discriminator is carried "as is". At the moment this is assumed, and therefore if a valid protocol discriminator value exists, then it is mapped. If one does not exist then it is not mapped, and discard of the entire user data occurs as in open issue 2. It is believed that many of the considerations of Issue 2 apply, and therefore the sole reason for any additional signalling support is to identify a protocol discriminator that can be mapped (i.e. one that forms part of the set that exists in ISDN), from those that cannot. Note that failure to include the user-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.

OPEN ISSUE 4: It could be that more than one payload is allowed to be included in the generic SIP User-to-User header field extension whereas only one payload is supported by the ISDN user-to-user signalling supplementary service. It is believed the considerations are identical to open issue 2.

OPEN ISSUE 5: If integrity protection or encryption is supported in the generic SIP User-to-User header field extension then it is unlikely this can be supported in the ISDN. It is assumed that the gateway will support nothing but the transparent mapping of payload, and indeed fulfils no useful function by performing any capability in regard to integrity protection or encryption. Similar considerations apply as for open issue 2, i.e. that the UUI application at the SIP endpoint has complete control over what occurs.

OPEN ISSUE 6: Interworking depends on there being equivalent functionality existing in both protocols. The mapping for ISDN basic call to SIP is well established and deployed. It is believed that there is no issue in mapping the generic SIP User-to-User header field extension as supported in RFC 3261 to the ISDN user-to-user signalling supplementary service in this respect. Issues may occur when more complex SIP transactions are used such as the 3xx response and the REFER method. This is of course dependent on there being a mapping at the ISDN gateway of the the 3xx response or the REFER method in the first place. Many SIP deployments rely on some server converting REFER transactions to INVITE transactions within the SIP environment, therefore the interworking requirements are merely those of the INVITE dialog itself. Are there other more complex scenarios that need to be studied for interworking?

7.  IANA Considerations

8.  Security Considerations

9.  Acknowledgements

Thanks to Spencer Dawkins, Vijay Gurbani, and Laura Liess for their review of earlier versions of this document. The authors wish to thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and Mahalingam Mani for their comments.

10. Normative References

Authors' Addresses