< draft-ietf-cuss-sip-uui-12.txt   draft-ietf-cuss-sip-uui-13.txt >
Network Working Group A. Johnston Network Working Group A. Johnston
Internet-Draft Avaya Internet-Draft Avaya
Intended status: Standards Track J. Rafferty Intended status: Standards Track J. Rafferty
Expires: July 29, 2014 Human Communications Expires: September 4, 2014 Human Communications
January 25, 2014 March 3, 2014
A Mechanism for Transporting User to User Call Control Information in A Mechanism for Transporting User to User Call Control Information in
SIP SIP
draft-ietf-cuss-sip-uui-12 draft-ietf-cuss-sip-uui-13
Abstract Abstract
There is a class of applications which benefit from using SIP to There is a class of applications which benefit from using SIP to
exchange User to User Information (UUI) data during session exchange User to User Information (UUI) data during session
establishment. This information, known as call control UUI data, is establishment. This information, known as call control UUI data, is
a small piece of data inserted by an application initiating the a small piece of data inserted by an application initiating the
session, and utilized by an application accepting the session. The session, and utilized by an application accepting the session. The
rules which apply for a specific application are defined by a UUI rules which apply for a specific application are defined by a UUI
package. This UUI data is opaque to SIP and its function is package. This UUI data is opaque to SIP and its function is
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 3 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 4
4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5 4. Normative Definition . . . . . . . . . . . . . . . . . . . . . 5
4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 5 4.1. Syntax for UUI Header Field . . . . . . . . . . . . . . . 6
4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7 4.2. Hex Encoding Definition . . . . . . . . . . . . . . . . . 7
4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7 4.3. Source Identity of UUI data . . . . . . . . . . . . . . . 7
5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9 5. Guidelines for UUI Packages . . . . . . . . . . . . . . . . . 9
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registration of User-to-User Header Field . . . . . . . . 11 6.1. Registration of User-to-User Header Field . . . . . . . . 11
6.2. Registration of User-to-User Header Field Parameters . . . 11 6.2. Registration of User-to-User Header Field Parameters . . . 11
6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 11 6.3. Registration of UUI Packages . . . . . . . . . . . . . . . 12
6.4. Registration of UUI Content Parameters . . . . . . . . . . 12 6.4. Registration of UUI Content Parameters . . . . . . . . . . 12
6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12 6.5. Registration of UUI Encoding Parameters . . . . . . . . . 12
6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 13 6.6. Registration of SIP Option Tag . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14 8. Appendix - Other Possible Mechanisms . . . . . . . . . . . . . 14
8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14 8.1. Why INFO is Not Used . . . . . . . . . . . . . . . . . . . 14
8.2. Why Other Protocol Encapsulation UUI Mechanisms are 8.2. Why Other Protocol Encapsulation UUI Mechanisms are
Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14 Not Used . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15 8.3. MIME body Approach . . . . . . . . . . . . . . . . . . . . 15
8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16 8.4. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 32 skipping to change at page 3, line 32
references to requirement numbers (REQ-N) and figure numbers refer to references to requirement numbers (REQ-N) and figure numbers refer to
this document. this document.
The mechanism is a new SIP header field, along with a new SIP option The mechanism is a new SIP header field, along with a new SIP option
tag. The header field carries the UUI data, along with parameters tag. The header field carries the UUI data, along with parameters
indicating the encoding of the UUI data, the UUI package, and indicating the encoding of the UUI data, the UUI package, and
optionally the content of the UUI data. The package definition optionally the content of the UUI data. The package definition
contains details about how a particular application can utilize the contains details about how a particular application can utilize the
UUI mechanism. The header field can be included (sometimes called UUI mechanism. The header field can be included (sometimes called
"escaped") into URIs supporting referral and redirection scenarios. "escaped") into URIs supporting referral and redirection scenarios.
In these scenarios, History-Info is used to indicate the inserter of In these scenarios, the History-Info header field is used to indicate
the UUI data. The SIP option tag can be used to indicate support for the inserter of the UUI data. The SIP option tag can be used to
the header field. Support for the UUI header field indicates that a indicate support for the header field. Support for the UUI header
UA is able to extract the information in the UUI data and pass it up field indicates that a UA is able to extract the information in the
the protocol stack. Individual packages using the UUI mechanism can UUI data and pass it up the protocol stack. Individual packages
utilize SIP media feature tags to indicate that a UA supports a using the UUI mechanism can utilize SIP media feature tags to
particular UUI package. Guidelines for defining UUI packages are indicate that a UA supports a particular UUI package. Guidelines for
provided. defining UUI packages are provided.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [RFC2119]. 14, RFC 2119 [RFC2119].
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.
3. Requirements Discussion 3. Requirements Discussion
This section describes how the User-to-User header field meets the This section describes how the User-to-User header field meets the
requirements in [RFC6567]. The header field can be included in requirements in [RFC6567]. The header field can be included in
INVITE requests and responses and BYE requests and responses, meeting INVITE requests and responses and BYE requests and responses, meeting
REQ-1 and REQ-2. REQ-1 and REQ-2.
For redirection and referral use cases and REQ-3, the header field is For redirection and referral use cases and REQ-3, the header field is
included (escaped) within the Contact or Refer-To URI. The details included (escaped) within the Contact or Refer-To URI. The details
of this mechanism as it applies for redirection and referral use of this mechanism as it applies for redirection and referral use
skipping to change at page 4, line 49 skipping to change at page 5, line 5
Proxies commonly apply policy to the presence of certain SIP header Proxies commonly apply policy to the presence of certain SIP header
fields in requests by either passing them or removing them from fields in requests by either passing them or removing them from
requests. REQ-9 is met by allowing proxies and other intermediaries requests. REQ-9 is met by allowing proxies and other intermediaries
to remove UUI header fields in a request or response based on policy. 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 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 UUI header field, meeting REQ-11. Note that very large UUI data
elements should be avoided, as SIP header fields have traditionally elements should be avoided, as SIP header fields have traditionally
not been large. not been large.
To meet REQ-12 for the redirection and referral use cases, History- To meet REQ-12 for the redirection and referral use cases, the
Info [I-D.ietf-sipcore-rfc4244bis] can be used. In these retargeting History-Info header field [RFC7044] can be used. In these
cases, the changed Request-URI will be recorded in the History-Info retargeting cases, the changed Request-URI will be recorded in the
header field along with the identity of the element that performed History-Info header field along with the identity of the element that
the retargeting. performed the retargeting.
The requirement for integrity protection in REQ-13 could be met by 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 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 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- 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 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 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. data will result in an additional body being added to the request.
Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header Hop-wise Transport Layer Security (TLS) [RFC5246] allows the header
field to meet REQ-15 for hop-by-hop security. field to meet REQ-15 for hop-by-hop security.
skipping to change at page 6, line 33 skipping to change at page 6, line 40
response. Consistent with the rules of SIP syntax, the syntax response. Consistent with the rules of SIP syntax, the syntax
defined in this document allows any combination of individual User- defined in this document allows any combination of individual User-
to-User header fields or User-to-User header fields with multiple to-User header fields or User-to-User header fields with multiple
comma separated UUI data elements. Any size limitations on the UUI comma separated UUI data elements. Any size limitations on the UUI
data for a particular purpose must be defined by the related UUI data for a particular purpose must be defined by the related UUI
package. package.
UAs SHOULD ignore UUI data from packages or encoding that they do not UAs SHOULD ignore UUI data from packages or encoding that they do not
understand. understand.
For redirection and referral use cases, the header field is included For redirection use cases, the header field is included (escaped)
(escaped) within the Contact or Refer-To URI. For example, if a UA within the Contact URI. For referral use cases, the header field is
included (escaped) within the Refer-To URI. For example, if a UA
supports this specification, it SHOULD include any UUI data included supports this specification, it SHOULD include any UUI data included
in a redirection URI (if the UUI data and encoding is understood). in a redirection URI (if the UUI data and encoding is understood).
Note that redirection can occur multiple times to a request. Note that redirection can occur multiple times to a request.
Currently, UAs that support attended transfer support the ability to Currently, UAs that support attended transfer support the ability to
include a Replaces header field [RFC3891] into a Refer-To URI, and include a Replaces header field [RFC3891] into a Refer-To URI, and
when acting upon this URI, add the Replaces header field to the when acting upon this URI, add the Replaces header field to the
triggered INVITE. This sort of logic and behavior shall also be triggered INVITE. This sort of logic and behavior shall also be
utilized for the UUI header field (that is, the UUI header field is utilized for the UUI header field (that is, the UUI header field is
included in the triggered INVITE). The UA processing the REFER or included in the triggered INVITE). The UA processing the REFER
the 3xx to the INVITE SHOULD support the UUI mechanism. If the REFER
or redirect target does not support UUI, the UUI header will be [RFC3515] or the 3xx to the INVITE SHOULD support the UUI mechanism.
discarded as per [RFC3261]. However, this may limit the utility of If the REFER or redirect target does not support UUI, the UUI header
use cases which depend upon the UUI being supported by all elements. will be discarded as per [RFC3261]. However, this may limit the
utility of use cases which depend upon the UUI being supported by all
elements.
Here is an example of an included User-to-User header field from the Here is an example of an included User-to-User header field from the
redirection response F2 of Figure 2: redirection response F2 of Figure 2:
<allOneLine> <allOneLine>
Contact: <sip:+12125551212@gateway.example.com?User-to-User= Contact: <sip:+12125551212@gateway.example.com?User-to-User=
56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B 56a390f3d2b7310023a2%3Bencoding%3Dhex%3Bpurpose%3Dfoo%3B
content%3Dbar> content%3Dbar>
</allOneLine> </allOneLine>
skipping to change at page 7, line 30 skipping to change at page 7, line 39
length that terminates at an octet boundary. Each octet of binary length that terminates at an octet boundary. Each octet of binary
data to be represented in the hex encoding MUST be mapped to two data to be represented in the hex encoding MUST be mapped to two
hexadecimal digits (represented by ASCII characters 0-9, A-F and hexadecimal digits (represented by ASCII characters 0-9, A-F and
a-f), each representing four bits within the octet. The four bits a-f), each representing four bits within the octet. The four bits
appearing first in the binary UUI data MUST be mapped to the first appearing first in the binary UUI data MUST be mapped to the first
hexadecimal digit and the four subsequent bits in the binary UUI data hexadecimal digit and the four subsequent bits in the binary UUI data
MUST be mapped to the second hexadecimal digit. When mapping 4 bits MUST be mapped to the second hexadecimal digit. When mapping 4 bits
to a hexadecimal digit, the bit appearing first in the binary UUI to a hexadecimal digit, the bit appearing first in the binary UUI
data shall be most significant. Thus, Hex encoded UUI data must have data shall be most significant. Thus, Hex encoded UUI data must have
an even number of hexadecimal digits, and MUST be considered invalid an even number of hexadecimal digits, and MUST be considered invalid
if it has an odd number. Hex encoding is normally done as a token, if it has an odd number. The hex-encoded value is normally
although quoted-string is permitted, in which case the quotes MUST be represented using the 'token' construction from RFC 3261, although
ignored. the 'quoted-string' construction is permitted, in which case the
quotes MUST be ignored.
4.3. Source Identity of UUI data 4.3. Source Identity of UUI data
It is important for the recipient of UUI data to know the identity of 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- the UA that inserted the UUI data. In a request without a History-
Info [I-D.ietf-sipcore-rfc4244bis] header field, the identity of the Info header field, the identity of the entity which inserted the UUI
entity which inserted the UUI data will be assumed to be the source data will be assumed to be the source of the SIP message. For a SIP
of the SIP message. For a SIP request, typically this is the UA request, typically this is the UA identified by the URI in the From
identified by the URI in the From header field or a P-Asserted- header field or a P-Asserted-Identity [RFC3325] header field. In a
Identity [RFC3325] header field. In a request with a History-Info request with a History-Info header field, the recipient needs to
header field, the recipient needs to parse the Targeted-to-URIs parse the Targeted-to-URIs present (hi-targeted-to-uri defined in
present (hi-targeted-to-uri) to see if any included User-to-User [RFC7044]) to see if any included User-to-User header fields are
header fields are present. If an included User-to-User header field present. If an included User-to-User header field is present and
is present and matches the UUI data in the request, this indicates matches the UUI data in the request, this indicates that redirection
that redirection has taken place, resulting in the inclusion of UUI has taken place, resulting in the inclusion of UUI data in the
data in the request. The inserter of the UUI data will be the UA request. The inserter of the UUI data will be the UA identified by
identified by the Targeted-to-URI of the History-Info element prior the Targeted-to-URI of the History-Info element prior to the element
to the element with the included UUI data. In a response, the with the included UUI data. In a response, the inserter of the UUI
inserter of the UUI data will be the identity of the UA that data will be the identity of the UA that generated the response.
generated the response. Typically, this is the UA identified in the Typically, this is the UA identified in the To header field of the
To header field of the response. Note that any updates to this response. Note that any updates to this identity by use of the SIP
identity by use of the SIP Connected Identity extension [RFC4916] or Connected Identity extension [RFC4916] or others will update this
others will update this information. information.
For an example of History-Info and redirection, consider Figure 2 For an example of History-Info and redirection, consider Figure 2
from [RFC6567] where the Originating UA is Carol, the Redirector Bob, from [RFC6567] where the Originating UA is Carol, the Redirector Bob,
and the Terminating UA Alice. The INVITE F4 containing UUI data and the Terminating UA Alice. The INVITE F4 containing UUI data
could be: could be:
INVITE sips:alice@example.com SIP/2.0 INVITE sips:alice@example.com SIP/2.0
Via: SIP/2.0/TLS lab.example.com:5061 Via: SIP/2.0/TLS lab.example.com:5061
;branch=z9hG4bKnashds9 ;branch=z9hG4bKnashds9
To: Bob <sips:bob@example.com> To: Bob <sips:bob@example.com>
skipping to change at page 8, line 29 skipping to change at page 8, line 39
Max-Forwards: 70 Max-Forwards: 70
Contact: <sips:carol@lab.example.com> Contact: <sips:carol@lab.example.com>
Supported: histinfo Supported: histinfo
User-to-User: 342342ef34;encoding=hex User-to-User: 342342ef34;encoding=hex
History-Info: <sips:bob@example.com>;index=1 History-Info: <sips:bob@example.com>;index=1
<allOneLine> <allOneLine>
History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302 History-Info: <sips:alice@example.com?Reason=SIP%3Bcause%3D302
&User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1 &User-to-User=342342ef34%3Bencoding%3Dhex>;index=1.1;rc=1
</allOneLine> </allOneLine>
Without the redirection captured in the History-Info, Alice would Without the redirection captured in the History-Info header field,
conclude the UUI data was inserted by Carol. However, the History- Alice would conclude the UUI data was inserted by Carol. However,
Info containing UUI data (index=1.1) indicates that the inserter was the History-Info containing UUI data (index=1.1) indicates that the
Bob (index=1). 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 maintaining a record of the inserter identity of UUI data, To enable maintaining a record of the inserter identity of UUI data,
UAs supporting this mechanism SHOULD support History-Info UAs supporting this mechanism SHOULD support History-Info [RFC7044]
[I-D.ietf-sipcore-rfc4244bis] and include Supported: histinfo in all and include Supported: histinfo in all requests and responses.
requests and responses.
Border elements such as proxies or Back-to-Back User Agents (B2BUAs) Border elements such as proxies or Back-to-Back User Agents (B2BUAs)
which anonymize a SIP URI in a History-Info header field SHOULD leave which anonymize a SIP URI in a History-Info header field SHOULD leave
the corresponding User-to-User parameter, if present, and the the corresponding User-to-User parameter, if present, and the
corresponding User-to-User header field unchanged. Border elements corresponding User-to-User header field unchanged. Border elements
removing a History-Info header containing a User-to-User parameter removing a History-Info header containing a User-to-User parameter
SHOULD NOT drop the corresponding User-to-User header. Otherwise, SHOULD NOT drop the corresponding User-to-User header. Otherwise,
the UA consuming the UUI data may not be able at SIP level to the UA consuming the UUI data may not be able at SIP level to
identify the source of the UUI data. identify the source of the UUI data.
5. Guidelines for UUI Packages 5. Guidelines for UUI Packages
UUI packages defined using this SIP UUI mechanism MUST follow the UUI packages defined using this SIP UUI mechanism MUST follow the
"RFC Required" guideline as defined in [RFC5226] and publish a "Standards Action" guideline as defined in [RFC5226] and publish a
standards track RFC which describes the usage. Note that this standards track RFC which describes the usage. Note that this
mechanism is not suitable for the transport of arbitrary data between mechanism is not suitable for the transport of arbitrary data between
UAs. The following guidelines are provided to help determine if this UAs. The following guidelines are provided to help determine if this
mechanism is appropriate or some other SIP mechanism should be used. mechanism is appropriate or some other SIP mechanism should be used.
The SIP UUI mechanism is applicable when all of the following The SIP UUI mechanism is applicable when all of the following
conditions be met: conditions be met:
1. The information is generated and consumed by an application 1. The information is generated and consumed by an application
during session setup using SIP, but the application is not during session setup using SIP, but the application is not
necessarily SIP aware. necessarily SIP aware.
skipping to change at page 11, line 50 skipping to change at page 12, line 9
| User-to-User | purpose | | [RFCXXXX] | | User-to-User | purpose | | [RFCXXXX] |
+------------------+----------------+-------------------+-----------+ +------------------+----------------+-------------------+-----------+
Editor's Note: [RFCXXXX] should be replaced with the designation of Editor's Note: [RFCXXXX] should be replaced with the designation of
this document. this document.
6.3. Registration of UUI Packages 6.3. Registration of UUI Packages
This specification establishes the uui-packages sub-registry under This specification establishes the uui-packages sub-registry under
http://www.iana.org/assignments/sip-parameters. New uui-packages http://www.iana.org/assignments/sip-parameters. New uui-packages
MUST follow the "Specification Required" guideline as defined in MUST follow the "Standards Action" guideline as defined in [RFC5226].
[RFC5226].
The descriptive text for the table of uui-content is: The descriptive text for the table of uui-content is:
UUI Packages provides information about the usage of the UUI data in UUI Packages provides information about the usage of the UUI data in
a User-to-User header field [RFCXXXX]. a User-to-User header field [RFCXXXX].
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Package | Description | Reference | | Package | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
skipping to change at page 14, line 12 skipping to change at page 14, line 18
security at the SIP layer. This is the security model of the PSTN security at the SIP layer. This is the security model of the PSTN
and ISDN where UUI is commonly used today. This approach uses hop- and ISDN where UUI is commonly used today. This approach uses hop-
by-hop security mechanisms and relies on border elements for by-hop security mechanisms and relies on border elements for
filtering and application of policy. Standard deployed SIP security filtering and application of policy. Standard deployed SIP security
mechanisms such as TLS transport, offer privacy and integrity mechanisms such as TLS transport, offer privacy and integrity
protection properties on a hop-by-hop basis at the SIP layer. protection properties on a hop-by-hop basis at the SIP layer.
If the UUI data was included by the UA originator of the SIP request If the UUI data was included by the UA originator of the SIP request
or response, normal SIP mechanisms can be used to determine the or response, normal SIP mechanisms can be used to determine the
identity of the inserter of the UUI data. If the UUI data was identity of the inserter of the UUI data. If the UUI data was
included by a UA that was not the originator of the request, History- included by a UA that was not the originator of the request, a
Info can be used to determine the identity of the inserter of the UUI History-Info header field can be used to determine the identity of
data. UAs can apply policy based on the origin of the UUI data using the inserter of the UUI data. UAs can apply policy based on the
this information. In short, the UUI data included in an INVITE can origin of the UUI data using this information. In short, the UUI
be trusted as much as the INVITE itself can be trusted. data included in an INVITE can be trusted as much as the INVITE
itself can be trusted.
8. Appendix - Other Possible Mechanisms 8. Appendix - Other Possible Mechanisms
Two other possible mechanisms for transporting UUI data will be Two other possible mechanisms for transporting UUI data will be
described: MIME body and URI parameter transport. described: MIME body and URI parameter transport.
8.1. Why INFO is Not Used 8.1. Why INFO is Not Used
Since the INFO method [RFC6086], was developed for ISUP interworking Since the INFO method [RFC6086], was developed for ISUP interworking
of user-to-user information, it might seem to be the logical choice of user-to-user information, it might seem to be the logical choice
skipping to change at page 17, line 33 skipping to change at page 17, line 38
Torture Test Messages", RFC 4475, May 2006. Torture Test Messages", RFC 4475, May 2006.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real- for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67, time Applications and Infrastructure Area", BCP 67,
RFC 5727, March 2010. RFC 5727, March 2010.
[I-D.ietf-cuss-sip-uui-isdn] [I-D.ietf-cuss-sip-uui-isdn]
Drage, K. and A. Johnston, "Interworking ISDN Call Control Drage, K. and A. Johnston, "Interworking ISDN Call Control
User Information with SIP", User Information with SIP",
draft-ietf-cuss-sip-uui-isdn-06 (work in progress), draft-ietf-cuss-sip-uui-isdn-07 (work in progress),
December 2013. February 2014.
[Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) - [Q1980] "ITU-T Q.1980.1 The Narrowband Signalling Syntax (NSS) -
Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/ Syntax Definition", http://www.itu.int/itudoc/itu-t/aap/
sg11aap/history/q1980.1/q1980.1.html . sg11aap/history/q1980.1/q1980.1.html .
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
skipping to change at page 18, line 19 skipping to change at page 18, line 21
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[I-D.ietf-sipcore-rfc4244bis] [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. C. Holmberg, "An Extension to the Session Initiation
Holmberg, "An Extension to the Session Initiation Protocol Protocol (SIP) for Request History Information", RFC 7044,
(SIP) for Request History Information", February 2014.
draft-ietf-sipcore-rfc4244bis-12 (work in progress),
October 2013.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004. September 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
 End of changes. 21 change blocks. 
76 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/