SIPPING WG A. Johnston, Ed.
Internet-Draft J. McMillen
Intended status: Standards Track Avaya
Expires: January 11, 2009 July 10, 2008
Transporting User to User Call Control Information in SIP for ISDN
Interworking
draft-johnston-sipping-cc-uui-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 11, 2009.
Abstract
Several approaches to transporting the ITU-T Q.931 User to User
Information Element (UU IE) data in SIP have been implemented. 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 the information to/from ISDN for end-to-end
transparency. This document discusses the approaches and recommends
a new header field User-to-User be standardized. Example use cases
include an exchange between two User Agents, insertion of UUI by a
proxy, modification of UUI by a proxy. An example application is in
an Automatic Call Distributor (ACD) in a contact center.
Johnston & McMillen Expires January 11, 2009 [Page 1]
Internet-Draft SIP UUI for CC July 2008
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. User Agent to User Agent . . . . . . . . . . . . . . . . . 3
3.2. Proxy to User Agent . . . . . . . . . . . . . . . . . . . 4
3.3. User Agent to Proxy to User Agent . . . . . . . . . . . . 4
3.4. Redirection . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Referral . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Possible Mechanisms . . . . . . . . . . . . . . . . . . . . . 7
4.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 7
4.2. MIME body Approach . . . . . . . . . . . . . . . . . . . . 8
4.3. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Header Field Approach . . . . . . . . . . . . . . . . . . 9
5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Appendix - Syntax for UUI Header Field . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Registration of Header Field . . . . . . . . . . . . . . . 11
7.2. Registration of Header Field Parameter . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Johnston & McMillen Expires January 11, 2009 [Page 2]
Internet-Draft SIP UUI for CC July 2008
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] data in SIP.
Five different use case call flows are discussed.
It is important to note that standardization of the UUI content is
explicitly out of scope for this specification. For cases where the
content of user to user information is relevant to SIP, it is
expected a new SIP header field will be created to transport the
information. For example, location information is an example of user
to user information, and obviously it needs to be transported in a
specifically named SIP header rather than transported using this
generic mechanism.
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
[RFC2119].
3. Use Cases
This section discusses four uses cases for the transport of call
control related user to user information. What is not discussed here
is the transport of non-call control UUI. We define call control UUI
as information that is generated, transported, and consumed at the
time of call setup (i.e. during a pending INVITE transaction). The
information can be used for call routing, alerting, call
distribution, or simply rendering. The exact usage and semantics of
call control UUI is out of scope - SIP is simply providing the
transport function for this that ISDN Provides in the PSTN. Non-call
control UUI can be sent using the INFO method and not using the
extensions described in this specification.
3.1. User Agent to User Agent
In this scenario, the originator UA includes UUI in the INVITE sent
through a proxy to the terminating UA. The terminator can use the
UUI in any way. If it is an ISDN gateway, it could map the UUI into
the appropriate Q.931 element. Alternatively, it might render the
information to the user, or use it for alerting or as a lookup for a
screen pop. In this case, the proxy does not need to understand the
Johnston & McMillen Expires January 11, 2009 [Page 3]
Internet-Draft SIP UUI for CC July 2008
UUI mechanism, but normal proxy rules should result in the UUI being
forwarded without modification. This call flow is shown in Figure 1.
Originator Proxy Terminator
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 1. Call flow with UUI exchanged between Originator and
Terminator.
3.2. Proxy to User Agent
In this scenario, proxy inserts the UUI into the INVITE from the
originating UA which is then processed by the terminating UA. The
proxy can insert the UUI based on the identity of the originator, the
time of day, the dialed URI or any other service specific information
available when the INVITE is received. This call flow is shown in
Figure 2.
Originator Proxy Terminator
| | |
| INVITE F1 | |
|------------------->| INVITE (UUI) F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 2. Call flow with UUI inserted by Proxy for the Terminator.
3.3. User Agent to Proxy to User Agent
In this scenario, the originator UA includes UUI in the INVITE sent
through a proxy to the terminating UA. The proxy inspects the UUI in
the INVITE and either modifies it or inserts new UUI. This
information is then processed by the terminating UA. This call flow
is shown in Figure 3.
Johnston & McMillen Expires January 11, 2009 [Page 4]
Internet-Draft SIP UUI for CC July 2008
Originator Proxy Terminator
| | |
| INVITE (UUI) F1 | |
|------------------->| INVITE (UUI') F2 |
| 100 Trying F3 |------------------->|
|<-------------------| 200 OK F4 |
| 200 OK F5 |<-------------------|
|<-------------------| |
| ACK F6 | |
|------------------->| ACK F7 |
| |------------------->|
Figure 3. Call flow with UUI exchanged between Originator and
Terminator and modified by the Proxy.
3.4. Redirection
In this scenario, UUI is inserted by a redirect server which is then
included in the INVITE sent by the Originator to the Terminator. In
this case, the Originator does not need to support the UUI mechanism
but does need to support the SIP redirection mechanism used to
include the UUI information.
Originator Redirect Server Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 302 Moved (UUI) F2 | |
|<-------------------| |
| ACK F3 | |
|------------------->| |
| INVITE (UUI) F4 | |
|---------------------------------------->|
| 200 OK F5 |
|<----------------------------------------|
| ACK F6 |
|---------------------------------------->|
Figure 4. Call flow with UUI exchanged between Redirect Server and
Terminator
A common application of this call flow is an Automatic Call
Distributer (ACD) in a PSTN contact center. The originator would be
a PSTN gateway. The ACD would act as a Redirect Server, inserting
UUI based on called number, calling number, time of day, and other
information. The resulting UUI would be passed to the agent's
handset which acts as the Terminator. The UUI could be used to
lookup information rendered to the agent at the time of call
Johnston & McMillen Expires January 11, 2009 [Page 5]
Internet-Draft SIP UUI for CC July 2008
answering.
3.5. Referral
In this scenario, a Referrer UA causes an INVITE to be generated
between the Originator and Terminator with UUI information inserted
by the Referrer UA. Note that this REFER [RFC3515] could be part of
a transfer operation or it might be unrelated to an existing call,
such as out-of-dialog REFER call control. In some cases, this call
flow is used in place of the redirection call flow, but where
immediately upon answer, the REFER is sent. This scenario is shown
in Figure 5.
Originator Referrer Terminator
| | |
| REFER (UUI) F1 | |
|<-------------------| |
| 202 Accepted F2 | |
|------------------->| |
| NOTIFY (100 Trying) F3 |
|------------------->| |
| 200 OK F4 | |
|<-------------------| |
| INVITE (UUI) F5 | |
|---------------------------------------->|
| 200 OK F6 |
|<----------------------------------------|
| ACK F7 |
|---------------------------------------->|
| NOTIFY (200 OK) F8 | |
|------------------->| |
| 200 OK F9 | |
|<-------------------| |
Figure 5. Call flow with transfer after answer.
Some scenarios involving referral have been proposed to use a REFER
sent during an early dialog. . This NOT RECOMMENDED call flow is
shown in Figure 6. This flow is not recommended due to the number of
messages exchanged (due to the REFER, CANCEL, and 487 responses) and
the sending of the REFER in the early dialog.
Johnston & McMillen Expires January 11, 2009 [Page 6]
Internet-Draft SIP UUI for CC July 2008
Originator Referrer Terminator
| | |
| INVITE F1 | |
|------------------->| |
| 180 Ringing F2 | |
|<-------------------| |
| REFER (UUI) F3 | |
|<-------------------| |
| 202 Accepted F4 | |
|------------------->| |
| NOTIFY (100 Trying) F5 |
|------------------->| |
| 200 OK F6 | |
|<-------------------| |
| INVITE (UUI) F7 | |
|---------------------------------------->|
| 200 OK F8 |
|<----------------------------------------|
| ACK F9 |
|---------------------------------------->|
| NOTIFY (200 OK) F10| |
|------------------->| |
| 200 OK F11 | |
|<-------------------| |
| CANCEL F12 | |
|------------------->| |
| 200 OK F13 | |
|<-------------------| |
| 487 Request Terminated F14 |
|<-------------------| |
| ACK F15 | |
|------------------->| |
Figure 6. NOT RECOMMENDED call flow showing REFER prior to answer.
4. Possible Mechanisms
Three mechanisms for transporting UUI will be described: MIME body,
header field, and URI parameter transport.
4.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
Johnston & McMillen Expires January 11, 2009 [Page 7]
Internet-Draft SIP UUI for CC July 2008
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.
4.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. However,
in the SIP-T example, the body is added by the originator and used by
the terminator. Since the INVITE will normally have an SDP message
body, the INVITE with SDP and UUI will be multipart MIME. The
insertion of a UUI message body by a proxy is not permitted by RFC
3261. The insertion of a UUI message body by a redirect server or in
a REFER is difficult. The body would need to be encoded in the
Contact URI of the 3xx response or the Refer-To URI of a REFER. For
example:
Contact:
Note that the tag convention from SIP Torture Test
Messages [RFC4475] is used to show that there are no line breaks in
the actual message syntax.
4.3. URI Parameter
Another proposed approach is to encode the UUI as a URI parameter
into the Contact or Refer-To URI.
Contact:
The resulting INVITE would contain UUI in the Request-URI of the
INVITE. The URI parameter has a drawback in that a URI parameter
will not survive retargeting by a proxy. That is, if the URI is an
Address of Record instead of a Contact URI, the URI parameter will
not be copied over the Contact URI, resulting in the loss of the
information.
Johnston & McMillen Expires January 11, 2009 [Page 8]
Internet-Draft SIP UUI for CC July 2008
4.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 escaped
into the Contact or Refer-To URI. The header field approach will
work with the redirection, REFER, and proxy call flows. The Call-
Info header field is related to the UUI information. However, there
are a number of important differences:
Call-Info is 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.
Call-Info contains a URI pointer the information instead of the
actual information itself. UUI is always a small amount of data
and must be carried with the request.
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:
User-to-User: 56a390f3d2b7310023a;encoding=hex
For example, here is an escaped User-to-User header field from the
redirection response F2 of Figure 4:
Contact:
The resulting INVITE F5 would contain the User-to-User header field
of the previous example.
An escaped User-to-User header field from the REFER message response
F1 of Figure 5:
Refer-To:
This would result in the INVITE F4 containing the User-to-User header
field of the first example.
5. Recommendation
The recommendation is to define a new SIP header field User-to-User
Johnston & McMillen Expires January 11, 2009 [Page 9]
Internet-Draft SIP UUI for CC July 2008
to transport UUI information in ISDN interworking applications.
The format of the UUI information is a topic of future
standardization. Currently, UUI is proprietary, requiring
coordinated configuration between servers. Standardizing the format
or providing content tags would provide additional benefits.
6. Appendix - Syntax for UUI Header Field
Editor's Note: Eventually this text will move to a SIP Working Group
document to define the new header field.
The User-to-User header field can be present in INVITE requests and
responses only and in BYE requests and responses.
Current usage 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-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. 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 | generic-param
enc-param = "encoding=" ("hex" | token)
Only one User-to-User header field may be present in a request or
response.
The only defined parameter for the User-to-User header field is the
encoding parameter. "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.
Johnston & McMillen Expires January 11, 2009 [Page 10]
Internet-Draft SIP UUI for CC July 2008
Note that ISDN limits UUI to 128 octets in length. While this header
field has no such limitations, transporting UUI longer than 128
octets will result in interoperability failures when interworking
with ISDN.
7. IANA Considerations
7.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.
7.2. Registration of Header Field Parameter
This document defines a parameter for the header field defined in the
preceding section. The header field "User-to-User" can contain the
parameter "encoding".
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 | No | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.
8. Security Considerations
User to user information can be exchanged over SIP on a hop-by-hop or
Johnston & McMillen Expires January 11, 2009 [Page 11]
Internet-Draft SIP UUI for CC July 2008
end-to-end basis. In some cases, it may carry private information
that may need confidential transport and integrity protection.
Standard SIP security mechanisms can be used to secure this header
field. For example, TLS transport can provide single hop
confidentiality and integrity protection. For multiple hop or end-
to-end confidentiality and integrity protection, S/MIME can be
utilized.
Information contained in a User-to-User header field should only be
trusted 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,
appropriate policy should be applied based on the PSTN trust domain.
9. Acknowledgements
The authors wish to thank Francois Audet, Denis Alexeitsev, and Keith
Drage for their comments.
10. Informative 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 Q.931 User to User Information Element (UU IE)",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[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.,
Johnston & McMillen Expires January 11, 2009 [Page 12]
Internet-Draft SIP UUI for CC July 2008
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
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 11, 2009 [Page 13]
Internet-Draft SIP UUI for CC July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Johnston & McMillen Expires January 11, 2009 [Page 14]