Network Working Group K. Drage
Internet-Draft Alcatel-Lucent
Intended status: Standards Track A. Johnston
Expires: March 24, 2011 Avaya
J. McMillen
Unaffiliated
September 20, 2010
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
Drage, et al. Expires March 24, 2011 [Page 1]
Internet-Draft SIP UUI for CC September 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 5
4. Relation to SIP-T . . . . . . . . . . . . . . . . . . . . . . 6
5. Transition away from ISDN . . . . . . . . . . . . . . . . . . 6
6. ISDN Usage of the User-to-User Header Field . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Drage, et al. Expires March 24, 2011 [Page 2]
Internet-Draft SIP UUI for CC September 2010
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].
2. Overview
This document describes a usage of the User-to-User header field
defined in [johnston-cuss-sip-uui] to enable the transport of User to
User Information (UUI) in ISDN interworking scenarios using SIP
[RFC3261]. Specifically, this document discuss the interworking of
call control related ITU-T DSS1 User-user information element[Q931],
[Q957.1] and ITU-T Q.763 User-to-user information parameter [Q763]
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]. 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].
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
Drage, et al. Expires March 24, 2011 [Page 3]
Internet-Draft SIP UUI for CC September 2010
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]. 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].
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
Drage, et al. Expires March 24, 2011 [Page 4]
Internet-Draft SIP UUI for CC September 2010
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.
Drage, et al. Expires March 24, 2011 [Page 5]
Internet-Draft SIP UUI for CC September 2010
4. Relation to SIP-T
A method of transport of ISDN UUI 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, 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]. 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] and [ETSI].
OPEN ISSUE 1: Key to defining such an application is to understand
how the capabilities of the generic SIP User-to-User header field
Drage, et al. Expires March 24, 2011 [Page 6]
Internet-Draft SIP UUI for CC September 2010
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
Drage, et al. Expires March 24, 2011 [Page 7]
Internet-Draft SIP UUI for CC September 2010
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
Drage, et al. Expires March 24, 2011 [Page 8]
Internet-Draft SIP UUI for CC September 2010
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
[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.
[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",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[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)",
http://www.itu.int/rec/T-REC-Q.957.1-199607-I .
[Q763] "ITU-T Q.763 Signaling System No. 7 - ISDN user part
formats and codes",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[ANSII] "ANSI T1.643-1995, Telecommunications-Integrated Services
Digital Network (ISDN)-Explicit Call Transfer
Supplementary Service".
[ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
Digital Network (ISDN); Diversion supplementary
services".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
Drage, et al. Expires March 24, 2011 [Page 9]
Internet-Draft SIP UUI for CC September 2010
[johnston-cuss-sip-uui-reqs]
Johnston, A., McMillen, J., and L. Liess, "Problem
Statement and Requirements for Transporting User to User
Call Control Information in SIP",
draft-johnston-cuss-sip-uui-reqs-00 .
[johnston-cuss-sip-uui]
Johnston, A., McMillen, J., and J. Rafferty, "A Mechanism
for Transporting User to User Call Control Information in
SIP", draft-johnston-cuss-sip-uui-00 .
Authors' Addresses
Keith Drage
Alcatel-Lucent
Quadrant, Stonehill Green, Westlea
Swindon
UK
Email: keith.drage@alcatel-lucent.com
Alan Johnston
Avaya
St. Louis, MO 63124
Email: alan.b.johnston@gmail.com
Joanne McMillen
Unaffiliated
Email: c.joanne.mcmillen@gmail.com
Drage, et al. Expires March 24, 2011 [Page 10]