SIPPING WG A. Johnston, Ed.
Internet-Draft J. McMillen
Intended status: Standards Track Avaya
Expires: January 3, 2010 July 2, 2009
Transporting User to User Call Control Information in SIP for ISDN
Interworking
draft-johnston-sipping-cc-uui-08
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Several approaches to transporting the ITU-T Q.931 User to User
Information Element (UU IE) data in SIP have been proposed. As
Johnston & McMillen Expires January 3, 2010 [Page 1]
Internet-Draft SIP UUI for CC July 2009
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 discusses three mechanisms to meet the requirements
defined in the Requirements for SIP Call Control UUI document. A new
SIP header field which bests meets these requirements is proposed.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 4
3.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 4
3.2. MIME body Approach . . . . . . . . . . . . . . . . . . . . 4
3.3. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Header Field Approach . . . . . . . . . . . . . . . . . . 5
4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Syntax for UUI Header Field . . . . . . . . . . . . . . . . . 7
5.1. Definition of New Parameter Values . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Registration of Header Field . . . . . . . . . . . . . . . 9
6.2. Registration of Header Field Parameters . . . . . . . . . 9
6.3. Registration of SIP Option Tag . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Johnston & McMillen Expires January 3, 2010 [Page 2]
Internet-Draft SIP UUI for CC July 2009
1. Overview
This document describes the transport of User to User Information
(UUI) in ISDN interworking scenarios using SIP [RFC3261].
Specifically, we discuss the transport of call control related ITU-T
Q.931 User to User Information Element (UU IE) [Q931] 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. This extension will also be
used for native SIP endpoints implementing similar services and
interworking with ISDN services.
Part of the definition of this ISDN service is that the UUI
information is not known and understood by the ISDN network that
transports it. This is for two reasons. Firstly, this supports a
strict layering of protocols and data. Providing information and
understanding of the data to the transport layer would not provide
any benefits and instead could create cross layer coupling and
increase the complexity of the system. Secondly, either the
originator or terminator of the service might be a simple PSTN
gateway designed for scalability and lowest cost. As a result, it is
neither feasible nor desirable for this device to understand the
information but instead the goal is to pass the information as
efficiently as possible to another application which does understand
the data. Both of these arguments still apply to SIP, especially
when one or both endpoints are gateways.
In the future, where both endpoints are intelligent SIP user agents,
it may be possible for them to understand and interpret the UUI data.
There may be some cases where the UUI information is relevant to SIP.
In this case, it might be worthwhile attempting to map UUI data to an
appropriate SIP header field or to standardize a new header field.
However, the requirements and use cases for this are different enough
from those described in this document that these two situations
should be examined separately. This document looks only at the
requirements and mechanisms for replicating the existing, widely used
and deployed ISDN UUI service.
The requirements, scenarios, and call flows for SIP call control UUI
is discussed in [johnston-dispatch-sip-cc-uui]. All references to
requirement numbers (REQ-N) and figure numbers refer to this draft.
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 BCP 14, RFC 2119
Johnston & McMillen Expires January 3, 2010 [Page 3]
Internet-Draft SIP UUI for CC July 2009
[RFC2119].
3. Possible Mechanisms
Three possible mechanisms for transporting UUI will be described:
MIME body, URI parameter, and header field transport.
3.1. Why INFO is Not Used
Since the INFO method [RFC2976], was developed for ISUP interworking
of user-to-user information, it might seem to be the logical choice
here. For non-call control user-to-user information, INFO can be
utilized for end to end transport. However, for transport of call
control user-to-user information, INFO can not be used. As the call
flows in the previous section show, the information is related to an
attempt to establish a session and must be passed with the session
setup request (INVITE), responses to that INVITE, or session
termination requests. As a result, it is not possible to use INFO in
these cases.
3.2. MIME body Approach
One method of transport is to transport the UUI information as a MIME
body. This is in keeping with the SIP-T architecture [RFC3372] in
which MIME bodies are used to transport ISUP information. Since the
INVITE will normally have an SDP message body, the resulting INVITE
with SDP and UUI will be multipart MIME. This is not ideal as many
SIP UAs do not support multipart MIME INVITEs.
A bigger problem is the insertion of a UUI message body by a redirect
server or in a REFER. The body would need to be encoded in the
Contact URI of the 3xx response or the Refer-To URI of a REFER.
Currently, no UAs support this capability today, and even defining
this is problematic. For example, do all the Content-* header fields
have to be escaped as well? What if the escaped Content-Length does
not agree with the escaped body?
An example:
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
Note that the <allOneLine> tag convention from SIP Torture Test
Messages [RFC4475] is used to show that there are no line breaks in
the actual message syntax.
Johnston & McMillen Expires January 3, 2010 [Page 4]
Internet-Draft SIP UUI for CC July 2009
The MIME body approach meets REQs 1-5. However, it does not meet
REQ-6 as support for Multipart MIME and escaped bodies in URIs is
uncommon in SIP UAs.
3.3. URI Parameter
Another proposed approach is to encode the UUI as a URI parameter
into the Contact or Refer-To URI.
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6
F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
An INVITE sent to this Contact URI would contain UUI in the Request-
URI of the INVITE. The URI parameter has a drawback in that a URI
parameter carried in a Request-URI will not survive retargeting by a
proxy as shown in Figure 2 of [johnston-dispatch-sip-cc-uui]. That
is, if the URI is included with an Address of Record instead of a
Contact URI, the URI parameter in the Reqeuest-URI will not be copied
over to the Contact URI, resulting in the loss of the information.
As a result, this approach does not meet REQ-4. Note that if this
same URI was present in a Refer-To header field, the same loss of
information would occur.
3.4. Header Field Approach
Another approach that has been proposed is to use a header field to
transport the UUI information. The header field would be included in
INVITE requests and responses and BYE requests and responses, and
would pass transparently through proxies. For redirection, the
header field would be escaped into the Contact or Refer-To URI. This
is commonly supported in UAs due to call transfer use cases. As a
result, the header field approach supports REQs 1-6. In order to
meet REQ- 7, a SIP feature tag is needed which can be included in
Supported and Require header fields.
The Call-Info header field is related to the UUI information.
However, there are a number of important differences:
o Call-Info is typically used for rendering to the user. While some
of the UUI information may ultimately be rendered to the user,
most of the UUI information will be consumed by the end device or
by an application server.
o Call-Info usually contains a URI pointer to the information
instead of the actual information itself which does not meet
REQ-5. It could be possible to use a data URI to carry the UUI
directly in this header field.
Johnston & McMillen Expires January 3, 2010 [Page 5]
Internet-Draft SIP UUI for CC July 2009
o The use of Call-Info for interworking to and from ISDN networks
seems problematic.
Overall, the overloading of the Call-Info header field for carrying
interworked UUI does not seem like a good idea. A separate header
field allows for clear policy and authorization rules to be used.
For these reasons, a separate header field needs to be defined,
described here as User-to-User. For example, here is an example
User-to-User header field from message F1 in Figure 1 of
[johnston-dispatch-sip-cc-uui]:
User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
;content=isdn-uui
For example, here is an escaped User-to-User header field from the
redirection response F2 of Figure 3:
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a%3Bencoding%3Dhex%3Bpurpose%3Disdn-interwork%3B
content%3Disdn-uui>
</allOneLine>
The resulting INVITE F5 would contain:
User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
;content=isdn-uui
An escaped User-to-User header field from the REFER message response
F1 of Figure 4:
<allOneLine>
Refer-To: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a%3Bencoding%3Dhex%3Bpurpose%3Disdn-interwork%3B
content%3Disdn-uui>
</allOneLine>
This would result in the INVITE F4 containing:
User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=isdn-interwork
;content=isdn-uui
4. Recommendation
The recommendation is to define a new SIP header field "User-to-User"
to transport UUI information in ISDN interworking applications since
this mechanism best supports the requirements in
Johnston & McMillen Expires January 3, 2010 [Page 6]
Internet-Draft SIP UUI for CC July 2009
[johnston-dispatch-sip-cc-uui] as demonstrated by existing
implementations and running code. A SIP feature tag "uui" also needs
to be defined so that it can be used in Supported and Require header
fields to meet REQ-7.
To help tag and identify the UUI used with this header field,
"purpose", "content", and "encoding" parameters are defined. This
specification only defines "purpose=isdn-intework", "content=isdn-
uui", and "encoding=hex". Other specifications can define other
purposes and contents for this header field per the requirements of
this document.
5. Syntax for UUI Header Field
The User-to-User header field can be present in INVITE requests and
responses only and in BYE requests and responses.
This document defines the purpose usage of "isdn-interwork" which is
to interoperate with ISDN User to User Signaling (UUS), a
supplementary service in which manufacturer specific information is
transported via the codeset 0 User- to-user Information IE. Three
services are defined: service 1, service 2, and service 3. This
draft only addresses the SIP equivalent of service 1 although it
could easily be expanded later to address services 2 and 3. UUS
Service 1 involves user to user signaling exchanged during call setup
and clearing within the following Q.931 call control messages: SETUP,
ALERT, CONNECT, DISCONNECT, RELEASE, and RELEASE COMPLETE. For SS7,
user-to-user information may be exchanged within the following Q.763
messages: INITIAL ADRESS MESSAGE, ADDRESS COMPLETE MESSAGE, CALL
PROGRESS, CONNECT, ANSWER, and RELEASE. UUS Service 2 involves user
to user signaling exchanged during call establishment (between ALERT
and CONNECT) via the USER INFORMATION message. This service usually
has a maximum of 2 USER INFORMATION messages in each direction. UUS
Service 3 involves user to user signaling exchanged on an active call
via the USER INFORMATION message.
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 2234 and extends RFC 3261.
UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
uui-data = token
uui-param = enc-param | cont-param | purp-param | generic-param
enc-param = "encoding=" ("hex" | token)
cont-param = "content=" ("isdn-uui" | token)
purp-param = "purpose=" ("isdn-interwork" | token)
If the encoding, content, or purpose parameters are not present,
Johnston & McMillen Expires January 3, 2010 [Page 7]
Internet-Draft SIP UUI for CC July 2009
their default values of "hex", "isdn-uui", and "isdn-interwork" MUST
be assumed. Only one User-to-User header field with purpose=isdn-
interwork may be present in a request or response. The
"encoding=hex" is used to indicate that the UUI information is
encoded as hex digits per the ISDN specification. The first octet is
the protocol discriminator. Other encoding methods of encoding MAY
also be standardized.
UUI data with purpose=isdn-interwork MUST be less than 129 octets in
length. This is because ISDN limits UUI to 128 octets in length plus
the single octet protocol discriminator. Transporting UUI longer
than 128 octets will result in interoperability failures when
interworking with ISDN. UUI used for other purposes may have other
length constraints, defined by the specification for that purpose.
A UA that supports this feature and the "uui" option tag MUST support
the call flows in [johnston-dispatch-sip-cc-uui]. In redirection
scenarios, if the Redirect Server is not in the same administrative
domain as the Terminator, the Redirect Server MUST NOT remove or
replace any UUI in the initial INVITE. In Figure 3 of
[johnston-dispatch-sip-cc-uui], this means that if F1 included UUI,
the Redirect Server could not modify or replace the UUI in F2.
However, if the Redirect Server and the Terminator are part of the
same administrative domain, they may have a policy allowing the
Redirect Server to modify or rewrite UUI information. In fact, many
UUI uses within an Enterprise rely on this feature to work today in
ISDN.
5.1. Definition of New Parameter Values
This specification defines only the values of "hex", "isdn-uui", and
"isdn- interwork" for the "encoding", "content", and "purpose"
parameters respectively. New values can be defined and added to the
IANA registry with a standards track RFC, which needs to discuss the
issues in this section.
New "encoding" values must reference a common encoding scheme or
define the exact new encoding scheme.
New "content" values must describe the content of the UUI and give
some example use cases. The default "encoding" and other allowed
encoding methods must be defined for this new content.
New "purpose" values must describe the new purpose and give some
example use cases. The default "content" value and other allowed
contents must be defined for this new purpose. Any restrictions on
the size of the UUI data must be described for the new purpose.
Johnston & McMillen Expires January 3, 2010 [Page 8]
Internet-Draft SIP UUI for CC July 2009
6. IANA Considerations
6.1. Registration of Header Field
This document defines a new SIP header field named "User-to-User".
The following row shall be added to the "Header Fields" section of
the SIP parameter registry:
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| User-to-User | | [RFCXXXX] |
+------------------+--------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.
6.2. Registration of Header Field Parameters
This document defines the parameters for the header field defined in
the preceding section. The header field "User-to-User" can contain
the parameters "encoding", "content", and "purpose".
The following rows shall be added to the "Header Field Parameters and
Parameter Values" section of the SIP parameter registry:
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| User-to-User | encoding | hex | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
| User-to-User | content | isdn-interwork | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
| User-to-User | purpose | isdn-uui | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.
6.3. Registration of SIP Option Tag
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of [RFC3261].
This document defines the SIP option tag "uui".
Johnston & McMillen Expires January 3, 2010 [Page 9]
Internet-Draft SIP UUI for CC July 2009
The following row has been added to the "Option Tags" section of the
SIP Parameter Registry:
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| uui | This option tag is used to indicate that | [RFCXXXX] |
| | a UA supports and understands the | |
| | User-to-User header field. | |
+------------+------------------------------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.
7. Security Considerations
User to user information can be exchanged over SIP on a hop-by-hop or
end-to-end basis. In some cases, UUI may carry privacy information
that would require confidentiality and message integrity. Standard
SIP security mechanisms, viz., based on TLS, offer these properties
per-hop. To preserve multi-hop or end-end confidentiality and
integrity, S/MIME profile MUST be utilized. Since the security
requirements and key management of the UUI information are likely to
be quite different from the SIP signaling transport, another approach
would be for the UUI information to be encrypted before being passed
to SIP for transport.
Received User-to-User information should only be trusted if it is
authenticated or if it is received within a trust domain. For
example, Spec-T, defined in [RFC3324] could be used to define a trust
domain. When utilized by a gateway to map information to or from
ISDN Q.931 and ISUP Q.763, appropriate policy should be applied based
on the PSTN trust domain.
8. Acknowledgements
Thanks to Spencer Dawkins, Keith Drage, Vijay Gurbani, and Laura
Liess for their review of the document. The authors wish to thank
Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen Jennings, and
Mahalingam Mani for their comments.
9. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Johnston & McMillen Expires January 3, 2010 [Page 10]
Internet-Draft SIP UUI for CC July 2009
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[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.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
[johnston-dispatch-sip-cc-uui]
Johnston, A. and J. McMillen, "Requirements for
Transporting User to User Call Control Information in SIP
for ISDN Interworking",
draft-johnston-dispatch-sip-cc-uui-00 .
Johnston & McMillen Expires January 3, 2010 [Page 11]
Internet-Draft SIP UUI for CC July 2009
Authors' Addresses
Alan Johnston (editor)
Avaya
St. Louis, MO 63124
Email: alan@sipstation.com
Joanne McMillen
Avaya
Email: joanne@avaya.com
Johnston & McMillen Expires January 3, 2010 [Page 12]