Network Working Group A. Johnston
Internet-Draft Avaya
Intended status: Standards Track J. Rafferty
Expires: April 25, 2012 Dialogic
October 23, 2011
A Mechanism for Transporting User to User Call Control Information in
SIP
draft-ietf-cuss-sip-uui-03
Abstract
There is a need for applications using SIP to exchange User to User
Information (UUI) data during session establishment. This
information, known as call control UUI data, is a small piece of data
inserted by an application initiating the session, and utilized by an
application accepting the session. Applications define a UUI package
for the transport of their UUI data. This data is opaque to SIP and
its function is unrelated to any basic SIP function. This document
defines a new SIP header field, User-to-User, to transport UUI data,
along with an extension mechanism.
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 April 25, 2012.
Copyright Notice
Copyright (c) 2011 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
Johnston & Rafferty Expires April 25, 2012 [Page 1]
Internet-Draft SIP UUI for CC October 2011
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3
4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5
4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5
4.2. Source Identity of UUI data . . . . . . . . . . . . . . . 6
5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Registration of User-to-User Header Field . . . . . . . . 9
6.2. Registration of User-to-User Header Field Parameters . . . 9
6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 9
6.4. Registration of UUI Content Parameters . . . . . . . . . . 10
6.5. Registration of UUI Encoding Parameters . . . . . . . . . 10
6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 11
8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 11
8.2. Why Other Protocol Encapsulation UUI Mechanisms are
Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 12
8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Informative References . . . . . . . . . . . . . . . . . . 14
10.2. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Johnston & Rafferty Expires April 25, 2012 [Page 2]
Internet-Draft SIP UUI for CC October 2011
1. Overview
This document describes the transport of User to User Information
(UUI) data using SIP [RFC3261]. Specifically, we discuss a mechanism
for the transport of general application UUI data and also for 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 data 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. Note that in most cases, there is
an a priori understanding between the endpoints in regard to what to
do with received UUI data.
This mechanism was designed to meet the use cases, requirements, and
call flows for SIP call control UUI detailed in
[I-D.ietf-cuss-sip-uui-reqs]. All references to requirement numbers
(REQ-N) and figure numbers refer to this document.
The mechanism chosen is a new SIP header field, along with a new SIP
option tag. The header field carries the UUI data, along with
parameters indicating the encoding of the UUI data, the UUI package,
and optionally the content of the UUI data. The package definition
contains details about how a particular application can utilize the
UUI mechanism. The header field can be escaped into URIs supporting
referral and redirection scenarios. In these scenarios, History-Info
is used to indicate the inserter of the UUI data. The SIP option tag
can be used to indicate support for the header field. Support for
the header field indicates that a UA is able to extract the
information in the UUI data and pass it up the protocol stack.
Individual packages using the UUI mechanism can utlize SIP media
feature tags to indicate that a UA supports a particular UUI package.
Guidelines for defining UUI packages are provided.
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. Requirements Discussion
This section describes how the User-to-User header field meets the
requirements in [I-D.ietf-cuss-sip-uui-reqs]. The header field can
Johnston & Rafferty Expires April 25, 2012 [Page 3]
Internet-Draft SIP UUI for CC October 2011
be included in INVITE requests and responses and BYE requests and
responses, meeting REQ-1 and REQ-2.
For redirection and referral use cases and REQ-3, the header field
would be escaped into the Contact or Refer-To URI. Currently, UAs
that support attended transfer support the ability to escape a
Replaces header field into a Refer-To URI, and when acting upon this
URI add the Replaces header field to the triggered INVITE. This
logic and behavior is identical for the UUI header field. The UA
processing the REFER or the 3xx to the INVITE will need to support
the UUI mechanism, as UAs in general do not process unknown escaped
header fields.
Since SIP proxy forwarding and retargeting does not affect header
fields, the header field meets REQ-4.
The UUI header field will carry the UUI data and not a pointer to the
data, so REQ-5 is met.
Since the basic design of the UUI header field is similar to the ISDN
UUI service, interworking with PSTN protocols will be straightforward
and will be documented in a separate specification, meeting REQ-6.
Requirements REQ-7, REQ-8, and REQ-10 relate to discovery of the
mechanism and supported packages, and hence applications. REQ-7
relates to support of the UUI header field, while REQ-8 relates to
routing based on support of the UUI header field. REQ-7 is met by
defining a new SIP option tag 'uui'. The use of a Require:uui in a
request, or Supported:uui in an OPTIONS response could be used to
require or discover support of the mechanism. The presence of a
Supported:uui or Require:uui header field can be used by proxies to
route to an appropriate UA, meeting REQ-8. However, note that the
only endpoints are expected to understand the UUI data - proxies and
other intermediaries do not. REQ-10 is met by utlizing SIP feature
tags [RFC3840]. For example, the feature tag 'sip.uui-isdn' could be
used to indicate support of the ISDN UUI package, or 'sip.uui-pk1'
could be used to indicate support for a particular package, pk1.
Proxies commonly apply policy to the presence of certain SIP header
fields in requests by either passing them or removing them from
requests. REQ-9 is met by allowing proxies and other intermediaries
to remove UUI header fields in a request or response based on policy.
Carrying UUI data elements of at least 129 octets is trivial in the
UUI header field, meeting REQ-11. Note that very large UUI data
elements should be avoided, as SIP header fields have traditionally
not been large.
Johnston & Rafferty Expires April 25, 2012 [Page 4]
Internet-Draft SIP UUI for CC October 2011
To meet REQ-12 in redirection and referral use cases, History-Info
[I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting
cases, the changed Request-URI will be recorded in the History-Info
header field along with the identity of the element that performed
the retargeting.
The requirement for integrity protection in REQ-13 could be met by
the use of an S/MIME signature over a subset of header fields, as
defined in Section 23.4 of RFC 3261 "SIP Header Privacy and Integrity
using S/MIME: Tunneling SIP". The requirement of REQ-14 for end-to-
end privacy could be met using S/MIME or using encryption at the
application layer. Note that the use of S/MIME to secure the UUI
data will result in an additional body being added to the request.
Hopwise TLS allows the header field to meet REQ-15 for hop-by-hop
security.
4. Normative Definition
This document defines a new SIP header field "User-to-User" to
transport call control UUI data to meet the requirements in
[I-D.ietf-cuss-sip-uui-reqs].
To help tag and identify the UUI data used with this header field,
"package", "content", and "encoding" parameters are defined. The
"package" parameter identifies the package which defines the
generation and usage of the UUI data for a particular application.
For the case of interworking with the ISDN UUI Service, the ISDN UUI
Service interworking package is used. If the "package" parameter is
not present, interworking with the ISDN UUI Service MUST be assumed.
The "content" parameter identifies the actual content of the UUI
data. If not present, the content MUST be assumed to be unknown as
it is in the ISDN UUI Service. Newly defined UUI packages MUST
define a new "content" value. The "encoding" parameter indicates the
method of encoding the information in the UUI data. This
specification only defines "encoding=hex". If the "encoding"
parameter is not present, "hex" MUST be assumed.
UUI data is considered an opaque series of octets. This mechanism
SHOULD NOT be used to convey a URL or URI: the Call-Info header field
[RFC3261] is used for this purpose.
4.1. 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. Note that only
end-to-end responses can be used, e.g. 1xx (excluding 100), 2xx, and
3xx responses.
Johnston & Rafferty Expires April 25, 2012 [Page 5]
Internet-Draft SIP UUI for CC October 2011
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 5234 and extends RFC 3261.
UUI = "User-to-User" HCOLON uui-data *(SEMI uui-param)
uui-data = token / quoted-string
uui-param = pkg-param / cont-param / enc-param / generic-param
pkg-param = "package" EQUAL token
cont-param = "content" EQUAL token
enc-param = "encoding" EQUAL ("hex" / token)
A single User-to-User header field may be present in a request or a
response. Any size limitations on the UUI data for a particular
purpose must be defined by a UUI package.
4.2. Source Identity of UUI data
It is important for the recipient of UUI data to know the identity of
the UA that inserted the UUI data. In a request without a History-
Info [I-D.ietf-sipcore-rfc4244bis] header field, the inserter of the
UUI data will be assumed to be the identity of the source of the SIP
message. For a SIP request, typically this is the UA identified by
the URI in the From header field or a P-Asserted-Identity [RFC3325]
header field. In a request with a History-Info header field, the
recipient needs to parse the Targeted-to-URIs present (hi-targeted-
to-uri) to see if any escaped User-to-User header fields are present.
If an escaped User-to-User header field is present and matches the
UUI data in the request, it indicates that redirection has taken
place which has resulted in the UUI data inclusion in the request.
The inserter of the UUI data will be the UA identified by the
Targeted-to-URI of the History-Info element prior to the element with
the escaped UUI data. In a response, the inserter of the UUI data
will be the identity of the UA that generated the response.
Typically, this is the UA identified in the To header field of the
response. Note that any updates to this identity by use of the SIP
Connected Identity extension [RFC4916] or others will update this
information.
For an example of History-Info and redirection, consider Figure 2
from [I-D.ietf-cuss-sip-uui-reqs] where the Originating UA is Carol,
the Redirector Bob, and the Terminating UA Alice. The INVITE F4
containing UUI data could be:
Johnston & Rafferty Expires April 25, 2012 [Page 6]
Internet-Draft SIP UUI for CC October 2011
INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061
;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com>
From: Carol <sips:carol@example.com>;tag=323sf33k2
Call-ID: dfaosidfoiwe83ifkdf
Max-Forwards: 70
Contact: <sips:carol@lab.example.com>
Supported: histinfo
User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1
<allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine>
Without the redirection captured in the History-Info, Alice would
conclude the UUI data was inserted by Carol. However, the History-
Info containing UUI data (index=1.1) indicates that the inserter was
Bob (index=1).
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.
To enable the inserter identity of UUI data, UAs supporting this
mechanism SHOULD support History-Info [I-D.ietf-sipcore-rfc4244bis]
and include Supported: histinfo in all requests and responses.
5. Guidelines for UUI Packages
UUI packages defined using this SIP UUI mechanism must publish a
standards track RFC which describes the usage. Note that this
mechanism is not suitable for the transport of arbitrary data between
endpoints. The following guidelines are provided to help determine
if this mechanism is appropriate or some other SIP mechanism should
be used. The SIP UUI mechanism is applicable in the following
situations:
1. The information is generated and consumed by an application
during session setup using SIP, but the application is not
necessarily SIP aware.
2. The behavior of SIP entities that support it is not
significantly changed (as discussed in Section 4 of [RFC5727]).
Johnston & Rafferty Expires April 25, 2012 [Page 7]
Internet-Draft SIP UUI for CC October 2011
3. User Agent Clients (UAC) and User Agent Servers (UAS) are the
generators and consumers of the UUI data. Proxies may route based
on the presence of a User-to-User header field or a particular
package tag but not otherwise be involved.
4. Intermediary elements or proxies can remove or insert UUI data
This mechanism is not applicable in the following situations:
1. The behavior of SIP entities that support it is significantly
changed (as discussed in Section 4 of [RFC5727]).
2. The information is generated and consumed at the SIP layer by
SIP elements.
3. SIP elements besides the UAC and UAS might be interested in
consuming (beyond adding or removing) the information.
4. There are specific privacy issues involved with the
information being transported (e.g., geolocation or emergency-
related information).
5. The UUI data is a user-to-user Remote Procedure Call (RPC)
mechanism.
This specification defines only the value of "hex" for the "encoding"
parameter. 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 data and
give some example use cases. The default "encoding" and other
allowed encoding methods must be defined for this new content.
New "package" values must describe the new application which is
utilizing the UUI data and give some example use cases. The default
"content" value and other allowed contents must be defined for the
package. Any restrictions on the size of the UUI data must be
described. In addition, a package may define a Media Feature tag per
RFC 3840 [RFC3840] to indicate support for this UUI package. For
example, the media feature tag sip.uui-pk1 could be defined to
indicate support for a UUI package named pk1. The definition of a
new SIP option tag solely to identify support for a UUI package is
NOT RECOMMENDED unless there are additional SIP behaviors needed to
implement this feature.
Johnston & Rafferty Expires April 25, 2012 [Page 8]
Internet-Draft SIP UUI for CC October 2011
For an example UUI package definition, see
[I-D.drage-cuss-sip-uui-isdn].
6. IANA Considerations
6.1. Registration of User-to-User 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 User-to-User 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 "package".
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 | | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
| User-to-User | package | | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of
this document.
6.3. Registration of UUI Packages
This specification establishes the uui-packages sub-registry under
http://www.iana.org/assignments/sip-parameters. New uui-packages are
Johnston & Rafferty Expires April 25, 2012 [Page 9]
Internet-Draft SIP UUI for CC October 2011
registered by standards track RFC publication.
The descriptive text for the table of uui-content is:
UUI Packages provides information about the usage of the UUI data in
a User-to-User header field [RFCXXXX].
+------------+-------------------------------------------+-----------+
| Package | Description | Reference |
+------------+-------------------------------------------+-----------+
6.4. Registration of UUI Content Parameters
This specification establishes the uui-content sub-registry under
http://www.iana.org/assignments/sip-parameters. New uui-content
values are registered by standards track RFC publication.
The descriptive text for the table of uui-content is:
UUI Content provides information about the content of the UUI data in
a User-to-User header field [RFCXXXX].
+------------+-------------------------------------------+-----------+
| Content | Description | Reference |
+------------+-------------------------------------------+-----------+
6.5. Registration of UUI Encoding Parameters
This specification establishes the uui-encoding sub-registry under
http://www.iana.org/assignments/sip-parameters and initiates its
population with the table below. Additional uui-encoding values are
registered by a standards track RFC publication.
The descriptive text for the table of uui-encoding is:
UUI Encoding provides information about the encoding of the UUI data
in a User-to-User header field [RFCXXXX].
+------------+-------------------------------------------+-----------+
| Encoding | Description | Reference |
+------------+-------------------------------------------+-----------+
| hex | The UUI data is encoded using hexadecimal | |
+------------+-------------------------------------------+-----------+
Johnston & Rafferty Expires April 25, 2012 [Page 10]
Internet-Draft SIP UUI for CC October 2011
6.6. 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".
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 potentially carry sensitive information
that might require privacy or integrity protection. Standard
deployed SIP security mechanisms such as TLS transport, offer these
properties on a hop-by-hop basis. To preserve multi-hop or end-to-
end confidentiality and integrity of UUI data, approaches using
S/MIME can be used, as discussed in the draft. However, the lack of
deployment of these mechanisms means that applications can not in
general rely on them. As such, applications are encouraged to
utilize their own security mechanisms.
8. Appendix - Other Possible Mechanisms
Two other possible mechanisms for transporting UUI data will be
described: MIME body and URI parameter transport.
8.1. Why INFO is Not Used
Since the INFO method [RFC6086], 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 [I-D.ietf-cuss-sip-uui-reqs] show, the information is
Johnston & Rafferty Expires April 25, 2012 [Page 11]
Internet-Draft SIP UUI for CC October 2011
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.
8.2. Why Other Protocol Encapsulation UUI Mechanisms are Not Used
Other protocols have the ability to transport UUI data. For example,
consider the ITU-T Q.931 User to User Information Element (UU IE)
[Q931] and the ITU-T Q.763 User to User Information Parameter [Q763].
In addition, NSS (Narrowband Signaling System) [Q1980] is also able
to transport UUI data. Should one of these protocols be in use, and
present in both User Agents, then utilizing these other protocols to
transport UUI data might be a logical solution. Essentially, this is
just adding an additional layer in the protocol stack. In these
cases, SIP is not transporting the UUI data; it is encapsulating
another protocol, and that protocol is transporting the UUI data.
Once a mechanism to transport that other protocol using SIP exists,
the UUI data transport function is essentially obtained without any
additional effort or work.
However, the authors believe that SIP needs to have its own native
UUI data transport mechanism. It is not reasonable for a SIP UA to
have to implement another entire protocol (either ISDN or NSS, for
example) just to get the very simple UUI data transport service. Of
course, this work does not preclude anyone from using other protocols
with SIP to transport UUI data.
8.3. MIME body Approach
One method of transport is to use 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 data 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, the authors are not aware of any UAs that support this
capability today for any body type. As such, the complete set of
semantics for this operation would need to be determined and defined.
Some issues will need to be resolved, such as, do all the Content-*
header fields have to be escaped as well? And, what if the escaped
Content-Length does not agree with the escaped body?
Since proxies cannot remove a body from a request or response, it is
Johnston & Rafferty Expires April 25, 2012 [Page 12]
Internet-Draft SIP UUI for CC October 2011
not at all clear how this mechanism could meet REQ-9.
The requirement for integrity protection could be met by the use of
an S/MIME signature over the body, as defined in Section 23.3 of RFC
3261 "Securing MIME bodies". Alternatively, this could be achieved
using RFC 4474 [RFC4474]. The requirement for end-to-end privacy
could be met using S/MIME encryption or using encryption at the
application layer. However, note that neither S/MIME or RFC 4474
enjoys deployment in SIP today.
An example:
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com?Content-Type=
application/uui&body=ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
As such, the MIME body approach meets REQ-1, REQ-2, REQ-4, REQ-5,
REQ-7, REQ-11, REQ-13, and REQ-14. Meeting REQ-12 seems possible,
although the authors do not have a specific mechanism to propose.
Meeting REQ-3 is problematic, but not impossible for this mechanism.
However, this mechanism does not seem to be able to meet REQ-9.
8.4. URI Parameter
Another proposed approach is to encode the UUI data as a URI
parameter. This UUI parameter could be included in a Request-URI or
in the Contact URI or Refer-To URI. It is not clear how it could be
transported in a responses which does not have a Request-URI, or in
BYE requests or responses.
<allOneLine>
Contact: <sip:+12125551212@gateway.example.com;uui=ZeGl9i2icVqaNVailT6
F5iJ90m6mvuTS4OK05M0vDk0Q4Xs>
</allOneLine>
An INVITE sent to this Contact URI would contain UUI data 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 [I-D.ietf-cuss-sip-uui-reqs].
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. Note that if this same URI was present in a Refer-To
header field, the same loss of information would occur.
The URI parameter approach would meet REQ-3, REQ-5, REQ-7, REQ-9, and
REQ-11. It is possible the approach could meet REQ-12 and REQ-13.
Johnston & Rafferty Expires April 25, 2012 [Page 13]
Internet-Draft SIP UUI for CC October 2011
The mechanism does not appear to meet REQ-1, REQ-2, REQ-4, and
REQ-14.
9. Acknowledgements
Joanne McMillen was a major contributor and co-author of earlier
versions of this document. 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.
10. References
10.1. Informative References
[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 .
[Q931] "ITU-T Q.931 User to User Information Element (UU IE)",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
[ETSI] "ETSI ETS 300 207-1 Ed.1 (1994), Integrated Services
Digital Network (ISDN); Diversion supplementary
services".
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67,
RFC 5727, March 2010.
[I-D.drage-cuss-sip-uui-isdn]
Drage, K. and A. Johnston, "Interworking ISDN Call Control
User Information with SIP",
Johnston & Rafferty Expires April 25, 2012 [Page 14]
Internet-Draft SIP UUI for CC October 2011
draft-drage-cuss-sip-uui-isdn-01 (work in progress),
September 2011.
[Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
sg11aap/history/q1980.1/q1980.1.html .
10.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[I-D.ietf-cuss-sip-uui-reqs]
Johnston, A. and L. Liess, "Problem Statement and
Requirements for Transporting User to User Call Control
Information in SIP", draft-ietf-cuss-sip-uui-reqs-06 (work
in progress), September 2011.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[I-D.ietf-sipcore-rfc4244bis]
Barnes, M., Audet, F., Schubert, S., Gmbh, D., and C.
Holmberg, "An Extension to the Session Initiation Protocol
(SIP) for Request History Information",
draft-ietf-sipcore-rfc4244bis-05 (work in progress),
April 2011.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
Johnston & Rafferty Expires April 25, 2012 [Page 15]
Internet-Draft SIP UUI for CC October 2011
Authors' Addresses
Alan Johnston
Avaya
St. Louis, MO 63124
Email: alan.b.johnston@gmail.com
James Rafferty
Dialogic
Email: james.rafferty@dialogic.com
Johnston & Rafferty Expires April 25, 2012 [Page 16]
