draft-ietf-sipcore-rfc4244bis-09.txt   draft-ietf-sipcore-rfc4244bis-10.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Expires: March 5, 2013 S. Schubert Expires: March 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 Sept 2012
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-09.txt draft-ietf-sipcore-rfc4244bis-10.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 3, line 42 skipping to change at page 3, line 42
Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . . 22 11. Application Considerations . . . . . . . . . . . . . . . . . . 22
12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 24
12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24 12.1. PBX Voicemail . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 25 12.2. Consumer Voicemail . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
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 . . . . 26
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 . . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28 16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 28
16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30 16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . . 31 17.1. Normative References . . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . . 32 17.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Request History Requirements . . . . . . . . . . . . 32 Appendix A. Request History Requirements . . . . . . . . . . . . 32
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 33 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 33
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 34 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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. In addition, this specification defines a value for the
Privacy header field specific to the History-Info header. Privacy header field specific to the History-Info header.
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. Appendix A. Example scenarios using the History-Info header field
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The term "retarget" is used in this specification to refer to the The term "retarget" is used in this specification to refer to the
process of a SIP entity changing the request-URI [RFC3261, section process of a SIP entity changing the request-URI [RFC3261, section
7.1] in a request based on the rules for determining request targets 7.1] in a request based on the rules for determining request targets
as described in Section 16.5 of [RFC3261] and of the subsequent as described in Section 16.5 of [RFC3261] and of the subsequent
forwarding of that request as described in step 2 in section 16.6 of forwarding of that request as described in step 2 in section 16.6 of
[RFC3261]. This includes changing the Request-URI due to a location [RFC3261]. This includes changing the Request-URI due to a location
service lookup and redirect processing. This also includes internal service lookup and redirect processing. This also includes internal
(to a Proxy/SIP intermediary) changes of the URI prior to forwarding (to a Proxy/SIP intermediary) changes of the URI prior to forwarding
of the request. of the request.
The terms "location service", "forward", "redirect" and "AOR" are The terms "location service", "forward", "redirect" and "AOR" are
used consistent with the terminology in [RFC3261]. used consistently with the terminology in [RFC3261].
The terms "target user" is used in this specification as the human The terms "target user" is used in this specification as the human
user associated with particular AoR or AoRs (in case the human user user associated with particular AoR or AoRs (in case the human user
has multiple alias). has multiple alias).
The references to "domain for which the SIP entity/Proxy/Intermediary The references to "domain for which the SIP entity/Proxy/Intermediary
is responsible" are consistent with and intended to convey the same is responsible" are consistent with and intended to convey the same
context as the usage of that terminology in [RFC3261]. The context as the usage of that terminology in [RFC3261]. The
applicability of History-Info to architectures or models outside the applicability of History-Info to architectures or models outside the
context of [RFC3261] is outside the scope of this specification. context of [RFC3261] is outside the scope of this specification.
skipping to change at page 6, line 22 skipping to change at page 6, line 25
o Facilitating the use of limited use addresses (minted on demand) o Facilitating the use of limited use addresses (minted on demand)
and sub-addressing. and sub-addressing.
o Preserving service specific URIs that can be overwritten by a o Preserving service specific URIs that can be overwritten by a
downstream proxy, such as those defined in [RFC3087], and control downstream proxy, such as those defined in [RFC3087], and control
of network announcements and IVR with SIP URI [RFC4240]. of network announcements and IVR with SIP URI [RFC4240].
4. Overview 4. Overview
The fundamental functionality provided by the request history The fundamental functionality provided by the request history
information is the ability to inform proxies and UAs involved in information is the ability to inform proxies and user agents (UAs)
processing a request about the history or progress of that request. involved in processing a request about the history or progress of
The solution is to capture the Request-URIs as a request is that request. The solution is to capture the Request-URIs as a
retargeted, in a SIP header field: History-Info. This allows for the request is retargeted, in a SIP header field: History-Info. This
capturing of the history of a request that would be lost with the allows for the capturing of the history of a request that would be
normal SIP processing involved in the subsequent retargeting of the lost with the normal SIP processing involved in the subsequent
request. retargeting of the request.
The History-Info header field is added to a Request when a new The History-Info header field is added to a Request when a new
request is created by a UAC or forwarded by a Proxy, or when the request is created by a user agent client (UAC) or forwarded by a
target of a request is changed. It is possible for the target of a Proxy, or when the target of a request is changed. It is possible
request to be changed by the same proxy/SIP intermediary multiple for the target of a request to be changed by the same proxy/SIP
times (referred to as 'internal retargeting'). A SIP entity changing intermediary multiple times (referred to as 'internal retargeting').
the target of a request in response to a redirect also propagates any A SIP entity changing the target of a request in response to a
History-Info header field from the initial request in the new redirect also propagates any History-Info header field from the
request. The ABNF and detailed description of the History-Info initial request in the new request. The ABNF and detailed
header field parameters along with examples, is provided in description of the History-Info header field parameters along with
Section 5. Section 6, Section 7 and Section 8 provide the detailed examples, is provided in Section 5. Section 6, Section 7 and
handling of the History-Info header field by SIP User Agents, Proxies Section 8 provide the detailed handling of the History-Info header
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 10.4. parameters is provided in Section 5.
In addition, this specification defines a priv-value for the Privacy In addition, this specification defines a priv-value for the Privacy
header, "history", that requires anonymization of all the History- header, "history", that requires anonymization of all the History-
Info header field entries in a Request or to a specific History-Info Info header field entries in a Request or to a specific History-Info
header field hi-entry as described above. Further detail is provided header field hi-entry as described above. Further detail is provided
in Section 10.1. in Section 10.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
skipping to change at page 10, line 19 skipping to change at page 10, line 19
specific hi-entry MUST be anonymized. 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 that is part of HCOLON, COMMA and SEMI, and lines due to the SWS (sep whitespace) that is part of HCOLON, COMMA
there can be multiple History-Info header fields due to the rule of and SEMI, and there can be multiple History-Info header fields due to
section 7.3 [RFC3261]. Additional detailed examples are available in the rule of section 7.3 [RFC3261]. Additional detailed examples are
[I-D.barnes-sipcore-rfc4244bis-callflows]. available in [I-D.ietf-sipcore-rfc4244bis-callflows].
History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar History-Info: <sip:UserA@ims.example.com>;index=1;foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\ History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1.1,\ cause%3D302>;index=1.1,\
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\ <sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2;mp=1.1,\ cause%3D486>;index=1.2;mp=1.1,\
<sip:45432@192.168.0.3>;index=1.3;rc=1.2 <sip:45432@192.168.0.3>;index=1.3;rc=1.2
5.1. History-Info Header Field Example Scenario 5.1. History-Info Header Field Example Scenario
skipping to change at page 11, line 11 skipping to change at page 11, line 11
initial request-URI, including any parameters in the request URI. initial request-URI, including any parameters in the request URI.
Bob can recover that information by locating the last hi-entry with Bob can recover that information by locating the last hi-entry with
an "rc" header field parameter. This "rc" header field parameter an "rc" header field parameter. This "rc" header field parameter
contains the index of the hi-entry containing the lost target contains the index of the hi-entry containing the lost target
information - i.e., the sip:bob@biloxi.example.com hi-entry with information - i.e., the sip:bob@biloxi.example.com hi-entry with
index=1.1. Note that in the 200 response to Alice, an hi-entry is index=1.1. Note that in the 200 response to Alice, an hi-entry is
not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since
biloxi.example.com had not received a response from that fork at the biloxi.example.com had not received a response from that fork at the
time it sent the 200 OK that ultimately reached Alice. time it sent the 200 OK that ultimately reached Alice.
Additional detailed examples are available in
[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 | | |
| | | | | | | | | |
| | INVITE sip:bob@biloxi.example.com;p=x | | | INVITE sip:bob@biloxi.example.com;p=x |
| |--------------->| | | | |--------------->| | |
skipping to change at page 13, line 8 skipping to change at page 13, line 8
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | | | | | | |
| ACK | | | | | ACK | | | |
|--------------->| ACK | | | |--------------->| ACK | | |
| |--------------->| ACK | | | |--------------->| ACK | |
| | |--------------->| | | | |--------------->| |
Figure 1: Basic Call Figure 1: Basic Call
6. User Agent Handling of the History-Info Header Field 6. User Agent Handling of the History-Info Header Field
A B2BUA MAY follow the behavior of a SIP intermediary as an A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP
alternative to following the behavior of a UAS per Section 6.2 and a intermediary as an alternative to following the behavior of a user
UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries agent server (UAS) per Section 6.2 and a UAC per Section 6.1. In
forward hi-entries received in requests at the UAS to requests being behaving as an intermediary, a B2BUA carries forward hi-entries
forwarded by the UAC, as well as carrying forward hi-entries in received in requests at the UAS to requests being forwarded by the
responses received at the UAC to the responses forwarded by the UAS, UAC, as well as carrying forward hi-entries in responses received at
subject to privacy considerations per Section 10.1. the UAC to the responses forwarded by the UAS, subject to privacy
considerations per Section 10.1.
6.1. User Agent Client (UAC) Behavior 6.1. User Agent Client (UAC) Behavior
The UAC MUST include the "histinfo" option tag in the Supported The UAC MUST include the "histinfo" option tag in the Supported
header field in any out-of-dialog requests or initial requests for a header field in any out-of-dialog requests or initial requests for a
dialog for which the UAC would like the History-Info header field in dialog for which the UAC would like the History-Info header field in
the response. When issuing a request, the UAC MUST follow the the response. When issuing a request, the UAC MUST follow the
procedures in Section 9.2. In the case of an initial request, except procedures in Section 9.2. In the case of an initial request, except
where the UAC is part of a B2BUA, there is no cache of hi- entries where the UAC is part of a B2BUA, there is no cache of hi- entries
with which to populate the History-Info header field and the hi-index with which to populate the History-Info header field and the hi-index
skipping to change at page 14, line 31 skipping to change at page 14, line 31
In some cases, an intermediary may retarget a request more than once In some cases, an intermediary may retarget a request more than once
before forwarding - i.e., a request is retargeted to a SIP entity before forwarding - i.e., a request is retargeted to a SIP entity
that is "internal" to the intermediary before the same intermediary that is "internal" to the intermediary before the same intermediary
retargets the request to an external target . A typical example retargets the request to an external target . A typical example
would be a proxy that retargets a request first to a different user would be a proxy that retargets a request first to a different user
(i.e., it maps to a different AOR) and then forwards to a registered (i.e., it maps to a different AOR) and then forwards to a registered
contact bound to the same AOR. In this case, the intermediary MUST contact bound to the same AOR. In this case, the intermediary MUST
add a hi-entry for (each of) the internal target(s) per the add a hi-entry for (each of) the internal target(s) per the
procedures in Section 9.2. The intermediary MAY include a Reason procedures in Section 9.2. The intermediary MAY include a Reason
header field in the hi-entry with the hi-targeted-to-uri that has header field in the hi-entry with the hi-targeted-to-uri that has
been retargeted. been retargeted. Note, that this is shown in the INVITE (F6) in the
example entitled "Sequentially Forking (History-Info in Response)" in
[I-D.ietf-sipcore-rfc4244bis-callflows].
8. Redirect Server Handling of History-Info Header Fields 8. Redirect Server Handling of History-Info Header Fields
A redirect server MUST follow the procedures in Section 9.1 when it A redirect server MUST follow the procedures in Section 9.1 when it
receives a SIP Request. A redirect server MUST follow the procedures receives a SIP Request. A redirect server MUST follow the procedures
in Section 9.4 when it sends a SIP Response. When generating the in Section 9.4 when it sends a SIP Response. When generating the
Contact header field in a 3xx response, the redirect server MUST add Contact header field in a 3xx response, the redirect server MUST add
the appropriate "mp", "np" or "rc" header field parameter to each the appropriate "mp", "np" or "rc" header field parameter to each
Contact header field as described in Section 10.4, if applicable. Contact header field as described in Section 10.4, if applicable.
skipping to change at page 24, line 42 skipping to change at page 24, line 42
impact some applications (e.g., debug), however, it could require impact some applications (e.g., debug), however, it could require
some applications to make some default assumptions in this case. For some applications to make some default assumptions in this case. For
example, in an ACD scenario, the application could select the oldest example, in an ACD scenario, the application could select the oldest
hi-entry with the domain associated with the ACD system and display hi-entry with the domain associated with the ACD system and display
that as the original called party. Depending upon how and where the that as the original called party. Depending upon how and where the
request may have been retargeted, the complete list of agents to whom request may have been retargeted, the complete list of agents to whom
the call was targeted may not be available. the call was targeted may not be available.
12. Application Specific Usage 12. Application Specific Usage
Following are possible (non-normative) application-specific usages of The following are possible (non-normative) application-specific
History-Info. usages of History-Info.
12.1. PBX Voicemail 12.1. PBX Voicemail
A voicemail system typically requires the original called party A voicemail system typically requires the original called party
information to determine the appropriate mailbox so an appropriate information to determine the appropriate mailbox so an appropriate
greeting can be provided and the appropriate party notified of the greeting can be provided and the appropriate party notified of the
message. message.
The original target is determined by finding the first hi-entry The original target is determined by finding the first hi-entry
tagged with "rc" and using the hi-entry referenced by the index of tagged with "rc" and using the hi-entry referenced by the index of
"rc" header field parameter as the target for determining the "rc" header field parameter as the target 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 at the URI hi-entry and find the target of the mailbox by looking at the URI
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
entitled "PBX Voicemail Example" in
[I-D.ietf-sipcore-rfc4244bis-callflows].
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. "target" URI parameter in the hi-entry. Further detail for this
example can be found in the call flow entitled "Consumer Voicemail
Example" in [I-D.ietf-sipcore-rfc4244bis-callflows].
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
skipping to change at page 26, line 20 skipping to change at page 26, line 26
specification is REQUIRED in the entity's domain, so that the privacy specification is REQUIRED in the entity's domain, so that the privacy
can be applied, as described in Section 10.1.2, when a request or can be applied, as described in Section 10.1.2, when a request or
response leaves the domain. response leaves the domain.
14. IANA Considerations 14. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
This document obsoletes [RFC4244] but uses the same SIP header field This document obsoletes [RFC4244] but uses the same SIP header field
name and option tag. The IANA registry needs to update the name, Privacy header field and Option tag. The IANA registry needs
references to [RFC4244] with [RFC XXXX]. to update the references to [RFC4244] with [RFC XXXX], where XXXX is
the RFC number for this document.
14.1. Registration of New SIP History-Info Header Field 14.1. Registration of New SIP History-Info Header Field
This document defines a SIP header field name: History-Info and an This document defines a SIP header field name: History-Info and an
option tag: histinfo. The following changes have been made to option tag: histinfo. The following updates have been made to
http:///www.iana.org/assignments/sip-parameters The following row has http:///www.iana.org/assignments/sip-parameters.
been added to the header field section:.
The following row has been added to the header field section: The following row has been updated in the header field section:
Header Name Compact Form Reference Header Name Compact Form Reference
----------- ------------ --------- ----------- ------------ ---------
History-Info none [RFC XXXX] History-Info none [RFC XXXX]
The following has been added to the Options Tags section: The following has been updated in the Options Tags section:
Name Description Reference Name Description Reference
---- ----------- --------- ---- ----------- ---------
histinfo When used with the Supported header field, [RFC XXXX] histinfo When used with the Supported header field, [RFC XXXX]
this option tag indicates the UAC this option tag indicates the UAC
supports the History Information to be supports the History Information to be
captured for requests and returned in captured for requests and returned in
subsequent responses. This tag is not subsequent responses. This tag is not
used in a Proxy-Require or Require used in a Proxy-Require or Require
header field since support of header field since support of
History-Info is optional. History-Info is optional.
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.
14.2. Registration of "history" for SIP Privacy Header Field 14.2. Registration of "history" for SIP Privacy Header Field
This document defines a priv-value for the SIP Privacy header field: This document defines a priv-value for the SIP Privacy header field:
history The following changes have been made to history. The following updates have been made to
http://www.iana.org/assignments/sip-priv-values The following has http://www.iana.org/assignments/sip-priv-values. The following has
been added to the registration for the SIP Privacy header field: been updated in the registration for the SIP Privacy header field:
Name Description Registrant Reference Name Description Registrant Reference
---- ----------- ---------- --------- ---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC XXXX] history Privacy requested for Mary Barnes [RFC XXXX]
History-Info header mary.barnes@polycom.com History-Info header mary.barnes@polycom.com
fields(s) fields(s)
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.
skipping to change at page 31, line 16 skipping to change at page 31, line 21
4. Inclusion of hi-entries in response has changed from SHOULD to 4. Inclusion of hi-entries in response has changed from SHOULD to
MUST. MUST.
None of above behavior changes impact backwards compatibility since None of above behavior changes impact backwards compatibility since
they only strengthen normative behavior to improve interoperability. they only strengthen normative behavior to improve interoperability.
In cases where an entity that is compliant to this document, receives In cases where an entity that is compliant to this document, receives
a request that contains hi-entries compliant only to RFC4244 (i.e, a request that contains hi-entries compliant only to RFC4244 (i.e,
the hi-entries do not contain any of the new header field the hi-entries do not contain any of the new header field
parameters), the entity should not make any changes to the hi-entries parameters), the entity MUST NOT add any of the new header field
- i.e., the entries should be cached and forwarded as any other parameters to the hi-entries. The hi-entries MUST be cached and
entries are. As with RFC4244 compliant entities, applications must forwarded as any other entries are as specified in Section 9.1. As
be able to function in cases of missing information. The same with RFC4244 compliant entities, applications must be able to
applies to this document as specified in Section 11. function in cases of missing information, as specified in Section 11.
17. References 17. References
17.1. Normative References 17.1. Normative References
[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.
skipping to change at page 32, line 20 skipping to change at page 32, line 24
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC3087] Campbell, B. and R. Sparks, "Control of Service Context [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context
using SIP Request-URI", RFC 3087, April 2001. using SIP Request-URI", RFC 3087, April 2001.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458, Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006. April 2006.
[I-D.barnes-sipcore-rfc4244bis-callflows] [I-D.ietf-sipcore-rfc4244bis-callflows]
Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
Holmberg, "Session Initiation Protocol (SIP) History-Info Holmberg, "Session Initiation Protocol (SIP) History-Info
Header Call Flow Examples", Header Call Flow Examples",
draft-barnes-sipcore-rfc4244bis-callflows-03 (work in draft-ietf-sipcore-rfc4244bis-callflows-01 (work in
progress), March 2012. progress), September 2012.
Appendix A. Request History Requirements Appendix A. Request History Requirements
The following list constitutes a set of requirements for a "Request The following list constitutes a set of requirements for a "Request
History" capability. History" capability.
1. CAPABILITY-req: The "Request History" capability provides a 1. CAPABILITY-req: The "Request History" capability provides a
capability to inform proxies and UAs involved in processing a capability to inform proxies and UAs involved in processing a
request about the history/progress of that request. Although request about the history/progress of that request. Although
this is inherently provided when the retarget is in response to a this is inherently provided when the retarget is in response to a
 End of changes. 23 change blocks. 
61 lines changed or deleted 68 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/