draft-ietf-sipcore-rfc4244bis-10.txt   draft-ietf-sipcore-rfc4244bis-11.txt 
Network Working Group M. Barnes Network Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Obsoletes: 4244 (if approved) F. Audet Obsoletes: 4244 (if approved) F. Audet
Intended status: Standards Track Skype Intended status: Standards Track Skype
Expires: March 5, 2013 S. Schubert Expires: July 5, 2013 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
Sept 2012 Jan 2013
An Extension to the Session Initiation Protocol (SIP) for Request An Extension to the Session Initiation Protocol (SIP) for Request
History Information History Information
draft-ietf-sipcore-rfc4244bis-10.txt draft-ietf-sipcore-rfc4244bis-11.txt
Abstract Abstract
This document defines a standard mechanism for capturing the history This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing request. This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific the information as to how and why a SIP request arrives at a specific
application or user. This document defines an optional SIP header application or user. This document defines an optional SIP header
field, History-Info, for capturing the history information in field, History-Info, for capturing the history information in
requests. The document also defines SIP header field parameters for requests. The document also defines SIP header field parameters for
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 March 5, 2013. This Internet-Draft will expire on July 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 16 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 9.4. Sending History-Info in Responses . . . . . . . . . . . . 16
10. Processing the History-Info Header Field . . . . . . . . . . . 17 10. Processing the History-Info Header Field . . . . . . . . . . . 17
10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18
10.2. Reason in the History-Info Header Field . . . . . . . . . 19 10.2. Reason in the History-Info Header Field . . . . . . . . . 19
10.3. Indexing in the History-Info Header Field . . . . . . . . 20 10.3. Indexing in the History-Info Header Field . . . . . . . . 20
10.4. Mechanism for Target Determination in the History-Info 10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . . 22 11. Application Considerations . . . . . . . . . . . . . . . . . . 23
12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 25
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 25
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 25 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14.1. Registration of New SIP History-Info Header Field . . . . 26 14.1. Registration of New SIP History-Info Header Field . . . . 27
14.2. Registration of "history" for SIP Privacy Header Field . . 27 14.2. Registration of "history" for SIP Privacy Header Field . . 27
14.3. Registration of Header Field Parameters . . . . . . . . . 27 14.3. Registration of Header Field Parameters . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 29
16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
17.1. Normative References . . . . . . . . . . . . . . . . . . . 31 17.1. Normative References . . . . . . . . . . . . . . . . . . . 32
17.2. Informative References . . . . . . . . . . . . . . . . . . 32 17.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Request History Requirements . . . . . . . . . . . . 32 Appendix A. Request History Requirements . . . . . . . . . . . . 33
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 33 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 34
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 34 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Many services that SIP is anticipated to support require the ability Many services that SIP is anticipated to support require the ability
to determine why and how a SIP request arrived at a specific to determine why and how a SIP request arrived at a specific
application. Examples of such services include (but are not limited application. Examples of such services include (but are not limited
to) sessions initiated to call centers via "click to talk" SIP to) sessions initiated to call centers via "click to talk" SIP
Uniform Resource Locators (URLs) on a web page, "call history/ Uniform Resource Locators (URLs) on a web page, "call history/
logging" style services within intelligent "call management" software logging" style services within intelligent "call management" software
skipping to change at page 4, line 26 skipping to change at page 4, line 26
standard mechanism within SIP for communicating the retargeting standard mechanism within SIP for communicating the retargeting
history of the requests. This "request history" information allows history of the requests. This "request history" information allows
the receiving application to obtain information about how and why the the receiving application to obtain information about how and why the
SIP request arrived at the application/user. SIP request arrived at the application/user.
This document defines a SIP header field, History-Info, to provide a This document defines a SIP header field, History-Info, to provide a
standard mechanism for capturing the request history information to standard mechanism for capturing the request history information to
enable a wide variety of services for networks and end-users. SIP enable a wide variety of services for networks and end-users. SIP
header field parameters are defined for the History-Info and Contact header field parameters are defined for the History-Info and Contact
header fields to tag the method by which the target of a request is header fields to tag the method by which the target of a request is
determined. In addition, this specification defines a value for the determined. This specification also defines a value, "history", for
Privacy header field specific to the History-Info header. the Privacy header field. In addition a SIP option tag, "histinfo",
is defined.
The History-Info header field provides a building block for The History-Info header field provides a building block for
development of SIP based applications and services. The requirements development of SIP based applications and services. The requirements
for the solution described in this specification are included in for the solution described in this specification are included in
Appendix A. Example scenarios using the History-Info header field Appendix A. Example scenarios using the History-Info header field
are available in [I-D.ietf-sipcore-rfc4244bis-callflows]. are available in [I-D.ietf-sipcore-rfc4244bis-callflows].
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 5 skipping to change at page 7, line 5
examples, is provided in Section 5. Section 6, Section 7 and examples, is provided in Section 5. Section 6, Section 7 and
Section 8 provide the detailed handling of the History-Info header Section 8 provide the detailed handling of the History-Info header
field by SIP User Agents, Proxies and Redirect Servers respectively. field by SIP User Agents, Proxies and Redirect Servers respectively.
This specification also defines three new SIP header field This specification also defines three new SIP header field
parameters, "rc", "mp" and "np", for the History-Info and Contact parameters, "rc", "mp" and "np", for the History-Info and Contact
header fields, to tag the method by which the target of a request is header fields, to tag the method by which the target of a request is
determined. Further detail on the use of these header field determined. Further detail on the use of these header field
parameters is provided in Section 5. parameters is provided in Section 5.
In addition, this specification defines a priv-value for the Privacy This specification also defines a priv-value for the Privacy header,
header, "history", that requires anonymization of all the History- "history", that requires anonymization of all the History-Info header
Info header field entries in a Request or to a specific History-Info field entries in a Request or to a specific History-Info header field
header field hi-entry as described above. Further detail is provided hi-entry as described above. Further detail is provided in
in Section 10.1. Section 10.1.
In addition a SIP option tag, "histinfo", is defined. The use of
this option tag is described in Section 6.1.
5. History-Info Header Field Protocol Structure 5. History-Info Header Field Protocol Structure
The History-Info header field defined in this specification defines The History-Info header field defined in this specification defines
the usage in out-of-dialog requests or initial requests for a dialog the usage in out-of-dialog requests or initial requests for a dialog
(e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and
SUBSCRIBE, etc.) and any non-100 provisional or final responses to SUBSCRIBE, etc.) and any non-100 provisional or final responses to
these requests. these requests.
The following provides details for the information that is captured The following provides details for the information that is captured
in the History-Info header field entries for each target used for in the History-Info header field entries for each target used for
forwarding a request: forwarding a request:
o hi-targeted-to-uri: A mandatory parameter for capturing the o hi-targeted-to-uri: A mandatory parameter for capturing the
Request-URI for the specific request as it is forwarded. Request-URI for the specific request as it is forwarded.
o hi-index: A mandatory parameter for History-Info reflecting the o hi-index: A mandatory parameter for History-Info reflecting the
chronological order of the information, indexed to reflect the chronological order of the information, indexed to reflect the
forking and retargeting of requests. The format for this forking and retargeting of requests. The format for this
parameter is a sequance of nonnegative integers, separated by dots parameter is a sequence of non-negative integers, separated by
to indicate the number of forward hops and retargets. This dots to indicate the number of forward hops and retargets. This
results in a tree representation of the history of the request, results in a tree representation of the history of the request,
with the lowest-level index reflecting a leaf. By adding the new with the lowest-level index reflecting a leaf. By adding the new
entries in order (i.e., following existing entries per the details entries in chronological order (i.e., following existing entries
in Section 10.3), including the index and sending the messages per the details in Section 10.3), including the index and sending
using a secure transport, the ordering of the History-Info header the messages using a secure transport, the ordering of the
fields in the request is assured. In addition, applications may History-Info header fields in the request is assured. In
extract a variety of metrics (total number of retargets, total addition, applications may extract a variety of metrics (total
number of retargets from a specific branch, etc.) based upon the number of retargets, total number of retargets from a specific
index values. branch, etc.) based upon the index values.
o hi-target-param: An optional parameter reflecting the mechanism by o hi-target-param: An optional parameter reflecting the mechanism by
which the Request URI captured in the hi-targeted-to-uri in the which the Request URI captured in the hi-targeted-to-uri in the
History-Info header field value (hi-entry) was determined. This History-Info header field value (hi-entry) was determined. This
parameter is either an "rc", "mp" or "np" header field parameter, parameter is either an "rc", "mp" or "np" header field parameter,
which is interpreted as follows: which is interpreted as follows:
"rc": The hi-targeted-to-URI represents a change in Request-URI "rc": The hi-targeted-to-URI represents a change in Request-URI
while the target user remains the same. This occurs for while the target user remains the same. This occurs for
example when user has multiple AoRs as an alias. The "rc" example when user has multiple AoRs as an alias. The "rc"
skipping to change at page 9, line 50 skipping to change at page 9, line 50
o Reason: An optional parameter for History-Info, reflected in the o Reason: An optional parameter for History-Info, reflected in the
History-Info header field by including the Reason header field History-Info header field by including the Reason header field
[RFC3326] included in the hi-targeted-to-uri. A reason is [RFC3326] included in the hi-targeted-to-uri. A reason is
included in the hi-targeted-to-uri of an hi-entry to reflect included in the hi-targeted-to-uri of an hi-entry to reflect
information received in a response to the request sent to that information received in a response to the request sent to that
URI. URI.
o Privacy: An optional parameter for History-Info, reflected in the o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header History-Info header field values by including the Privacy Header
[RFC3323] included in the hi- targeted-to-uri or by adding the [RFC3323] with a priv-value of "history", as defined in this
Privacy header field to the request. The latter case indicates document, included in the hi- targeted-to-uri or by adding the
that the History-Info entries for all History-Info entries whose Privacy header field with a priv-value of "history" to the
hi-targeted-to-uri has the same domain as the domain for which the request. The latter case indicates that the History-Info entries
SIP entity processing the message is responsible MUST be for all History-Info entries whose hi-targeted-to-uri has the same
anonymized prior to forwarding, whereas the use of the Privacy domain as the domain for which the SIP entity processing the
header field included in the hi-targeted-to-uri means that a message is responsible MUST be anonymized prior to forwarding,
specific hi-entry MUST be anonymized. whereas the use of the Privacy header field included in the hi-
targeted-to-uri means that a specific hi-entry MUST be anonymized.
Note that since both the Reason and Privacy parameters are included Note that since both the Reason and Privacy parameters are included
in the hi-targeted-to-uri, these fields will not be available in the in the hi-targeted-to-uri, these fields will not be available in the
case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. case that the hi-targeted-to-uri is a Tel-URI [RFC3966].
The following provides examples of the format for the History-Info The following provides examples of the format for the History-Info
header field. Note that the backslash, CRLF and whitespace between header field. Note that the backslash, CRLF and whitespace between
the lines in the examples below are inserted for readability purposes the lines in the examples below are inserted for readability purposes
only. Note, however, that History-Info can be broken into multiple only. Note, however, that History-Info can be broken into multiple
lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA
skipping to change at page 12, line 10 skipping to change at page 12, line 10
Additional detailed examples are available in Additional detailed examples are available in
[I-D.ietf-sipcore-rfc4244bis-callflows]. [I-D.ietf-sipcore-rfc4244bis-callflows].
Note: This example uses loose routing procedures. Note: This example uses loose routing procedures.
Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone
| | | | | | | | | |
| INVITE sip:bob@biloxi.example.com;p=x | | | INVITE sip:bob@biloxi.example.com;p=x | |
|--------------->| | | | |--------------->| | | |
| Supported: histinfo | | | | Supported: histinfo | | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| | | | | | | | | |
| | INVITE sip:bob@biloxi.example.com;p=x | | | INVITE sip:bob@biloxi.example.com;p=x |
| |--------------->| | | | |--------------->| | |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 |
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
| | | | | | | | | |
| | | INVITE sip:bob@192.0.2.3| | | | INVITE sip:bob@192.0.2.3|
| | |--------------->| | | | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
| History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;np=1;index=1.1
skipping to change at page 16, line 46 skipping to change at page 16, line 46
in the response that are not already in the cache. This situation in the response that are not already in the cache. This situation
can occur when the entity that generated the non-100 response can occur when the entity that generated the non-100 response
retargeted the request before generating the response. As per retargeted the request before generating the response. As per
Step 1, the hi-entries MUST be added to the cache in ascending Step 1, the hi-entries MUST be added to the cache in ascending
order as indicated by the values in the hi-index parameters of the order as indicated by the values in the hi-index parameters of the
hi-entries hi-entries
It is important to note that the cache (and the request or response) It is important to note that the cache (and the request or response)
does not contain hi-entries for requests that have not yet received a does not contain hi-entries for requests that have not yet received a
non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4 non-100 response, so there can be gaps in indices (e.g., 1.2 and 1.4
could but present but not 1.3). could be present but not 1.3).
9.4. Sending History-Info in Responses 9.4. Sending History-Info in Responses
When sending a response other than a 100, a SIP entity MUST include When sending a response other than a 100, a SIP entity MUST include
all the cached hi-entries in the response, subject to the privacy all the cached hi-entries in the response, subject to the privacy
consideration in Section 10.1.2, and with the following exception: If consideration in Section 10.1.2, and with the following exception: If
the received request contained no hi-entries and there is no the received request contained no hi-entries and there is no
"histinfo" option tag in the Supported header field, the SIP entity "histinfo" option tag in the Supported header field, the SIP entity
MUST NOT include History-Info in the response. MUST NOT include History-Info in the response.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
hop (i.e., the number of branches) at the time that the request hop (i.e., the number of branches) at the time that the request
represented by this hi-entry was generated. Thus, the indexing represented by this hi-entry was generated. Thus, the indexing
results in a logical tree representation for the history of the results in a logical tree representation for the history of the
request and the hi-entries are given in the preorder of the tree. request and the hi-entries are given in the preorder of the tree.
The first index in a series of History-Info entries MUST be set to 1. The first index in a series of History-Info entries MUST be set to 1.
In the case that a SIP entity (intermediary or UAS) adds a first hi- In the case that a SIP entity (intermediary or UAS) adds a first hi-
entry on behalf of the previous hop, the hi-index MUST be set to 1. entry on behalf of the previous hop, the hi-index MUST be set to 1.
For each forward hop (i.e., each new level of indexing), the last For each forward hop (i.e., each new level of indexing), the last
integers of the hi-indexes of the new requests MUST be generated integers of the hi-indexes of the new requests MUST be generated
starting at 1 and incrementing by 1 for each additional request" starting at 1 and incrementing by 1 for each additional request.
The basic rules for adding the hi-index are summarized as follows: The basic rules for adding the hi-index are summarized as follows:
1. Forwarding a request without changing the target: In the case of 1. Forwarding a request without changing the target: In the case of
a request that is being forwarded without changing the target, a request that is being forwarded without changing the target,
the hi-index reflects the increasing length of the branch. In the hi-index reflects the increasing length of the branch. In
this case, the SIP entity MUST read the value from the History- this case, the SIP entity MUST read the value from the History-
Info header field in the received request and MUST add another Info header field in the received request and MUST add another
level of indexing by appending the dot delimiter followed by an level of indexing by appending the dot delimiter followed by an
initial value of 1 for the new level. For example, if the hi- initial value of 1 for the new level. For example, if the hi-
skipping to change at page 21, line 27 skipping to change at page 21, line 27
above, with each new request having a unique index. Each index above, with each new request having a unique index. Each index
MUST be sequentially assigned. For example, if the index in the MUST be sequentially assigned. For example, if the index in the
last History-Info header field in the received request is 1.1, last History-Info header field in the received request is 1.1,
this processing entity would initialize its index to 1.1.1 for this processing entity would initialize its index to 1.1.1 for
the first fork, 1.1.2 for the second, and so forth (see Figure 1 the first fork, 1.1.2 for the second, and so forth (see Figure 1
for an example). Note, that in the case of parallel forking, for an example). Note, that in the case of parallel forking,
only the hi-entry corresponding to the fork is included in the only the hi-entry corresponding to the fork is included in the
request because no response can yet have been received for any of request because no response can yet have been received for any of
the parallel forked requests. the parallel forked requests.
6. Missing entity: If the request clearly has a gap in the hi-entry 6. Missing entry: If the request clearly has a gap in the hi-entry
(i.e., the last hi-entry and Request-URI differ), the entity (i.e., the last hi-entry and Request-URI differ), the entity
adding an hi-entry MUST add a single index with a value of "0" adding an hi-entry MUST add a single index with a value of "0"
(i.e., the non-negative integer zero) prior to adding the (i.e., the non-negative integer zero) prior to adding the
appropriate index for the action to be taken. For example, if appropriate index for the action to be taken. For example, if
the index of the last hi-entry in the request received was 1.1.2 the index of the last hi-entry in the request received was 1.1.2
and there was a missing hi-entry and the request was being and there was a missing hi-entry and the request was being
forwarded to the next hop, the resulting index will be 1.1.2.0.1. forwarded to the next hop, the resulting index will be 1.1.2.0.1.
In the case of requests which are forked by a proxy that does not
support History-Info, it is possible for hi-entries generated by
different entities to have the same index - i.e., each entity
supporting History-Info would receive a forked request with the
same hi-index to which they would add the value of ".0" prior to
adding the appropriate index. Thus, in the previous example,
each of the next hop entities would generate an hi-index of
1.1.2.0.1.
10.4. Mechanism for Target Determination in the History-Info Header 10.4. Mechanism for Target Determination in the History-Info Header
Field Field
This specification defines three header field parameters, "rc", "mp" This specification defines three header field parameters, "rc", "mp"
and "np". The header field parameters "rc" and "mp" indicate the and "np". The header field parameters "rc" and "mp" indicate the
mechanism by which a new target for a request is determined. The mechanism by which a new target for a request is determined. The
header field "np" reflects that the target has not changed. All header field "np" reflects that the target has not changed. All
parameters contain an index whose value is the hi-index of the hi- parameters contain an index whose value is the hi-index of the hi-
entry with an hi-targeted-to-uri that represents the Request-URI that entry with an hi-targeted-to-uri that represents the Request-URI that
skipping to change at page 23, line 7 skipping to change at page 23, line 19
application usage of the History-Info header field parameters, the application usage of the History-Info header field parameters, the
SIP entity that processes the hi-entries MUST evaluate the hi- SIP entity that processes the hi-entries MUST evaluate the hi-
entries. The SIP entity MUST be prepared to process effectively entries. The SIP entity MUST be prepared to process effectively
messages whose hi-entries show evidence of "gaps", that is, messages whose hi-entries show evidence of "gaps", that is,
situations that reveal that not all of the forks of the request have situations that reveal that not all of the forks of the request have
been recorded in the hi-entries. Gaps are possible if the request is been recorded in the hi-entries. Gaps are possible if the request is
forwarded through intermediaries that do not support the History-Info forwarded through intermediaries that do not support the History-Info
header field and are reflected by the existence of hi-entries with a header field and are reflected by the existence of hi-entries with a
nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in nonnegative integer of "0" e.g. "1.1.0.1". Gaps are also possible in
the case of parallel forking if there is an outstanding request at the case of parallel forking if there is an outstanding request at
the time the SIP entity sends a message. Thus, if gaps are detected, the time the SIP entity sends a message. In addition, gaps may
the SIP entity MUST NOT treat this as an error, but SHOULD indicate introduce the possibility of duplicate values for the hi-index in the
to any applications that there are gaps. The interpretation of the case that a proxy that does not support History-Info forks a request.
information in the History-Info header field depends upon the If gaps are detected, the SIP entity MUST NOT treat this as an error,
specific application; an application might need to provide special but SHOULD indicate to any applications that there are gaps. The
handling in some cases where there are gaps. interpretation of the information in the History-Info header field
depends upon the specific application; an application might need to
provide special handling in some cases where there are gaps.
The following describes some categories of information that The following describes some categories of information that
applications can use: applications can use:
1. Complete history information - e.g., for debug or other 1. Complete history information - e.g., for debug or other
operational and management aspects, optimization of determining operational and management aspects, optimization of determining
targets to avoid retargeting to the same URI, etc. This targets to avoid retargeting to the same URI, etc. This
information is relevant to proxies, UACs and UASs. information is relevant to proxies, UACs and UASs.
2. Hi-entry with the index that matches the value of the "rc" header 2. Hi-entry with the index that matches the value of the "rc" header
skipping to change at page 25, line 21 skipping to change at page 25, line 33
entry in the "target" URI parameter in the hi-entry. entry in the "target" URI parameter in the hi-entry.
This example usage does not work properly in the presence of This example usage does not work properly in the presence of
forwarding that takes place before the call reaches the company in forwarding that takes place before the call reaches the company in
that case not the first hi-entry with an rc value, but the first hi- that case not the first hi-entry with an rc value, but the first hi-
entry with an rc value following an mp entry needs to be picked. entry with an rc value following an mp entry needs to be picked.
Further detail for this example can be found in the call flow Further detail for this example can be found in the call flow
entitled "PBX Voicemail Example" in entitled "PBX Voicemail Example" in
[I-D.ietf-sipcore-rfc4244bis-callflows]. [I-D.ietf-sipcore-rfc4244bis-callflows].
Note that in the case where there is no entry tagged with "rc", a VMS
can follow the procedures, as defined in [RFC4458], for the
"Interaction with Request History Information".
12.2. Consumer Voicemail 12.2. Consumer Voicemail
The voicemail system in these environment typically requires the last The voicemail system in these environment typically requires the last
called party information to determine the appropriate mailbox so an called party information to determine the appropriate mailbox so an
appropriate greeting can be provided and the appropriate party appropriate greeting can be provided and the appropriate party
notified of the message. notified of the message.
The last target is determined by finding the hi-entry referenced by The last target is determined by finding the hi-entry referenced by
the index of last hi-entry tagged with "rc" for determining the the index of last hi-entry tagged with "rc" for determining the
appropriate mailbox. This hi-entry is used to populate the "target" appropriate mailbox. This hi-entry is used to populate the "target"
URI parameter as defined in [RFC4458]. The VMS can look at the last URI parameter as defined in [RFC4458]. The VMS can look at the last
hi-entry and find the target of the mailbox by looking for the hi-entry and find the target of the mailbox by looking for the
"target" URI parameter in the hi-entry. Further detail for this "target" URI parameter in the hi-entry. Further detail for this
example can be found in the call flow entitled "Consumer Voicemail example can be found in the call flow entitled "Consumer Voicemail
Example" in [I-D.ietf-sipcore-rfc4244bis-callflows]. Example" in [I-D.ietf-sipcore-rfc4244bis-callflows].
In the case where there is no entry tagged with "rc", a VMS can
follow the procedures, as defined in [RFC4458], for the "Interaction
with Request History Information".
13. Security Considerations 13. Security Considerations
The security requirements for this specification are specified in The security requirements for this specification are specified in
Appendix A.1. Appendix A.1.
This document defines a header field for SIP. The use of the This document defines a header field for SIP. The use of the
Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to
ensure the overall confidentiality of the History-Info header fields ensure the overall confidentiality of the History-Info header fields
(SEC-req-4) is strongly RECOMMENDED. This results in History-Info (SEC-req-4) is strongly RECOMMENDED. This results in History-Info
having at least the same level of security as other headers in SIP having at least the same level of security as other headers in SIP
skipping to change at page 28, line 14 skipping to change at page 28, line 31
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
15. Acknowledgements 15. Acknowledgements
Jonathan Rosenberg et al produced the document that provided Jonathan Rosenberg et al produced the document that provided
additional use cases precipitating the requirement for the new header additional use cases precipitating the requirement for the new header
parameters to capture the method by which a Request URI is parameters to capture the method by which a Request URI is
determined. The authors would like to acknowledge the constructive determined. The authors would like to acknowledge the constructive
feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel feedback provided by Ian Elz, Paul Kyzivat, John Elwell, Hadriel
Kaplan and Dale Worley. John Elwell provided excellent suggestions Kaplan, Marianne Mohali, Brett Tate, and Dale Worley. John Elwell
in terms of document structure. also provided excellent suggestions in terms of document structure.
Dan Romascanu performed the Gen-ART review.
Mark Watson, Cullen Jennings and Jon Peterson provided significant Mark Watson, Cullen Jennings and Jon Peterson provided significant
input into the initial work that resulted in the development of of input into the initial work that resulted in the development of of
[RFC4244]. The editor would like to acknowledge the constructive [RFC4244]. The editor would like to acknowledge the constructive
feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John
Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony
Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin
Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and
Sebastien Garcin in the development of [RFC4244]. Sebastien Garcin in the development of [RFC4244].
 End of changes. 26 change blocks. 
52 lines changed or deleted 77 lines changed or added

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