draft-ietf-sipcore-rfc4244bis-00.txt   draft-ietf-sipcore-rfc4244bis-01.txt 
Network Working Group M. Barnes Network Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Polycom
Obsoletes: RFC4244 F. Audet Obsoletes: 4244 (if approved) F. Audet
(if approved) Skype Intended status: Standards Track Skype
Intended status: Standards Track S. Schubert Expires: December 26, 2010 S. Schubert
Expires: August 17, 2010 NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
February 13, 2010 June 24, 2010
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-00.txt draft-ietf-sipcore-rfc4244bis-01.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 call arrives at a specific the information as to how and why a call arrives at a specific
application or user. This document defines an optional SIP header, application or user. This document defines an optional SIP header,
History-Info, for capturing the history information in requests. A History-Info, for capturing the history information in requests. A
SIP/SIPS URI parameter is defined to tag information necessary to SIP/SIPS URI parameter is defined to tag information necessary to
populate the History-Info header. In addition, this document defines populate the History-Info header. In addition, this document defines
a value for the Privacy header specific to the History-Info header. a value for the Privacy header specific to the History-Info header.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 26, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 21 skipping to change at page 2, line 15
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 BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 5
4. General User Agent Behavior . . . . . . . . . . . . . . . . . 9 4. General User Agent Behavior . . . . . . . . . . . . . . . . . 9
4.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 9 4.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 9
4.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 10 4.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 10
4.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 10 4.2.1. Processing of Requests with History-Info . . . . . . . 10
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Generation of Responses with History-Info . . . . . . 10
5.1. Adding the History-Info Header to Requests . . . . . . . . 10 4.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 11
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Adding the History-Info Header to Requests . . . . . . . . 11
5.1.1. Initial Request . . . . . . . . . . . . . . . . . . . 11 5.1.1. Initial Request . . . . . . . . . . . . . . . . . . . 11
5.1.2. Re-sending based on failure response . . . . . . . . . 12 5.1.2. Re-sending based on failure response . . . . . . . . . 12
5.1.3. Re-sending based on redirection response . . . . . . . 13 5.1.3. Re-sending based on redirection response . . . . . . . 13
5.2. Sending History-Info in Responses . . . . . . . . . . . . 13 5.2. Sending History-Info in Responses . . . . . . . . . . . . 14
6. The History-Info header field . . . . . . . . . . . . . . . . 13 6. The History-Info header field . . . . . . . . . . . . . . . . 14
6.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3.1. SIP/SIPS URI target parameter for History-Info 6.3.1. SIP/SIPS URI target parameter for History-Info
Header . . . . . . . . . . . . . . . . . . . . . . . . 16 Header . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3.2. Privacy in the History-Info Header . . . . . . . . . . 17 6.3.2. Privacy in the History-Info Header . . . . . . . . . . 17
6.3.3. Reason in the History-Info Header . . . . . . . . . . 18 6.3.3. Reason in the History-Info Header . . . . . . . . . . 18
6.3.4. Indexing in the History-Info Header . . . . . . . . . 18 6.3.4. Indexing in the History-Info Header . . . . . . . . . 19
6.3.5. Request Target in the History-Info Header . . . . . . 20 6.3.5. Request Target in the History-Info Header . . . . . . 20
7. Application Considerations . . . . . . . . . . . . . . . . . . 20 7. Application Considerations . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. Registration of New SIP History-Info Header . . . . . . . 21 9.1. Registration of New SIP History-Info Header . . . . . . . 22
9.2. Registration of "history" for SIP Privacy Header . . . . . 22 9.2. Registration of "history" for SIP Privacy Header . . . . . 23
9.3. Registration of "hit" SIP/SIPS URI Parameter . . . . . . . 22 9.3. Registration of "hit" SIP/SIPS URI Parameter . . . . . . . 23
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 24
12. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 23 11.1. Backwards compatibility . . . . . . . . . . . . . . . . . 26
12.1. Backwards compatibility . . . . . . . . . . . . . . . . . 25 12. Changes since last Version . . . . . . . . . . . . . . . . . . 26
13. Changes since last Version . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 30
14.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Request History Requirements . . . . . . . . . . . . 30
Appendix A. Request History Requirements . . . . . . . . . . . . 29 A.1. Security Requirements . . . . . . . . . . . . . . . . . . 32
A.1. Security Requirements . . . . . . . . . . . . . . . . . . 31 A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 32
A.2. Privacy Requirements . . . . . . . . . . . . . . . . . . . 31 Appendix B. Example call flows . . . . . . . . . . . . . . . . . 33
Appendix B. Detailed call flows . . . . . . . . . . . . . . . . . 32 B.1. Sequentially Forking (History-Info in Response) . . . . . 33
B.1. Sequentially Forking (History-Info in Response) . . . . . 32 B.2. History-Info with Privacy Header . . . . . . . . . . . . . 40
B.2. Voicemail . . . . . . . . . . . . . . . . . . . . . . . . 39 B.3. Privacy Header for a Specific History-Info Entry . . . . . 41
B.3. Automatic Call Distribution . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
B.4. History-Info with Privacy Header . . . . . . . . . . . . . 43
B.5. Privacy Header for a Specific History-Info Entry . . . . . 44
B.6. Determining the Alias used. . . . . . . . . . . . . . . . 46
B.7. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.8. Limited Use Address . . . . . . . . . . . . . . . . . . . 50
B.9. Sub-Address . . . . . . . . . . . . . . . . . . . . . . . 52
B.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 56
B.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
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 the call arrived at a specific application. to determine why and how the call arrived at a specific application.
Examples of such services include (but are not limited to) sessions Examples of such services include (but are not limited to) sessions
initiated to call centers via "click to talk" SIP Uniform Resource initiated to call centers via "click to talk" SIP Uniform Resource
Locators (URLs) on a web page, "call history/logging" style services Locators (URLs) on a web page, "call history/logging" style services
within intelligent "call management" software for SIP User Agents within intelligent "call management" software for SIP User Agents
(UAs), and calls to voicemail servers. Although SIP implicitly (UAs), and calls to voicemail servers. Although SIP implicitly
skipping to change at page 10, line 46 skipping to change at page 9, line 46
Section 6.3.3. A new hi-entry MUST then be added for the URI from Section 6.3.3. A new hi-entry MUST then be added for the URI from
the Contact header (which becomes the new Request-URI). An index the Contact header (which becomes the new Request-URI). An index
MUST be added to the hi-entry. The value for the index is determined MUST be added to the hi-entry. The value for the index is determined
by reading and incrementing the value of the index from the previous by reading and incrementing the value of the index from the previous
hi-entry, thus following the same rules as those prescribed for a hi-entry, thus following the same rules as those prescribed for a
proxy in retargeting, described in Section 6.3.4. If the URI in the proxy in retargeting, described in Section 6.3.4. If the URI in the
Contact header contains a "hit" URI parameter, the UAC MUST add a Contact header contains a "hit" URI parameter, the UAC MUST add a
target parameter to the hi-entry and MUST remove the URI parameter as target parameter to the hi-entry and MUST remove the URI parameter as
described in Section 6.3.5. described in Section 6.3.5.
With the exception of the processing of a 3xx response described Prior to any application usage of the information by the UAC (e.g.,
above, the processing of the History-Info header received in the debug), the validity SHOULD be ascertained. The entries SHOULD be
Response is application specific and outside the scope of this evaluated to determine gaps in indices, which could indicate that an
document. entry has been maliciously removed. Either way, an application
SHOULD be aware of potentially missing information. The
interpretation of the information in the History-Info header by a UAC
in a request depends upon the specific applications supported by the
UAC. Application considerations and guidelines are provided in
section 7.
4.2. User Agent Server (UAS) Behavior 4.2. User Agent Server (UAS) Behavior
Once the request terminates at the UAS, the processing of the 4.2.1. Processing of Requests with History-Info
information in the History-Info header by a UAS in a request depends
upon local policy and specific applications at the UAS that might Once the request terminates at the UAS, the UAS evaluates the
make use of the information. Some examples are included in History-Info header. The last hi-entry reflects the most recent
Appendix B. target and SHOULD contain the Request-URI for the received request.
If the Request-URI of the incoming request does not match the last
hi-entry (e.g., the last proxy does not support History-Info), the
UAS MUST insert an hi-entry. The UAS MUST set the hi-targeted-to-uri
based to the value of Request-URI in the incoming request, unless
privacy is required. If privacy is required, the procedures of
Section 6.3.2 MUST be used. The UAS MUST include an hi-index
attribute as described in Section 6.3.4. The UAS MUST NOT include a
hi-target attribute, since the UAS has no way to know the mechanism
by which the Request-URI was determined. The addition of the missing
hi-entry ensures that the most complete information can be provided
in the response and provides consistency in the information presented
to applications. The information can also be useful for
implementations with B2BUAs that include the History-Info, received
in the incoming request, in the subsequent outgoing request.
Prior to any application usage of the information, the validity Prior to any application usage of the information, the validity
SHOULD be ascertained. For example, the entries MAY be evaluated to SHOULD be ascertained. The entries SHOULD be evaluated to determine
determine gaps in indices, which could indicate that an entry has gaps in indices, which could indicate that an entry has been
been maliciously removed or removed for privacy reasons. Either way, maliciously removed. Either way, an application SHOULD be aware of
an application MAY want to be aware of potentially missing potentially missing information. The interpretation of the
information. information in the History-Info header by a UAS in a request depends
upon the specific applications supported by the UAS. Application
considerations and guidelines are provided in section 7.
4.2.2. Generation of Responses with History-Info
If the "histinfo" option tag is received in a request, the UAS MUST If the "histinfo" option tag is received in a request, the UAS MUST
include any History-Info received in the request in the subsequent include any History-Info received in the request in the subsequent
response. If privacy is required, entries MUST be anonymized using response. If privacy is required, entries MUST be anonymized using
[RFC3323]. The UAS MUST follow the rules for a redirect server per [RFC3323]. The UAS MUST follow the rules for a redirect server per
Section 4.3 in generating a 3xx response. Section 4.3 in generating a 3xx response.
The processing of History-Info in responses follows the methodology The processing of History-Info in responses follows the methodology
described in Section 16.7 of [RFC3261], with the processing of described in Section 16.7 of [RFC3261], with the processing of
History-Info headers adding an additional step, just before Step 9, History-Info headers adding an additional step, just before Step 9,
skipping to change at page 21, line 19 skipping to change at page 20, line 49
The hi-target attribute MUST be added to the History-Info header if The hi-target attribute MUST be added to the History-Info header if
the target to which the request is being forwarded contains a "hit" the target to which the request is being forwarded contains a "hit"
URI parameter as defined in Section 6.3.1. URI parameter as defined in Section 6.3.1.
If the value of the "hit" parameter is "mp", then the index of the If the value of the "hit" parameter is "mp", then the index of the
entry corresponding to the original target (i.e., the "mapped-from" entry corresponding to the original target (i.e., the "mapped-from"
target) MUST be added as a parameter to "mp". target) MUST be added as a parameter to "mp".
7. Application Considerations 7. Application Considerations
As seen by the example scenarios in the Appendix B, History-Info History-Info provides a very flexible building block that can be used
provides a very flexible building block that can be used by by intermediaries and UAs for a variety of services. The following
intermediaries and UAs for a variety of services. As such, any summarizes the categories of information that applications may use:
services making use of History-Info must be designed with the
following considerations:
1. History-Info is optional; thus, a service MUST define default 1. Complete history information - e.g., for debug or other
behavior for requests and responses not containing History-Info operational and management aspects, optimization of determining
headers. targets to avoid retargeting to the same URI, etc. This
information is relevant to proxies, UACs and UASs.
2. History-Info may be impacted by privacy considerations. 2. Entry prior to last entry with hi-target of "rc" in the Request
Applications requiring History-Info need to be aware that if received by a UAS - i.e., the Request URI associated with the
Header-, Session-, or History-level privacy is requested by a UA destination of the request was determined based on a Registered
(or imposed by an intermediary) that History-Info may not be Contact.
available in a request or response. This would be addressed by
an application in the same manner as the previous consideration
by ensuring there is reasonable default behavior should the
information not be available.
3. History-Info may be impacted by local policy. Each application 3. Entry with the index that matches the value of the last entry
making use of the History-Info header SHOULD address the impacts with a "mp" hi-target parameter in the Request received by a UAS
of the local policies on the specific application (e.g., what - i.e., the last Request URI that was mapped to reach the
specification of local policy is optimally required for a destination.
specific application and any potential limitations imposed by
local policy decisions). Note that this is related to the 4. Entry prior to first entry with hi-target of "rc" in the Request
optionality and privacy considerations identified in 1 and 2 received by a UAS - i.e., the first Registered Contact to which
above, but goes beyond that. For example, due to the optionality the request was targeted.
and privacy considerations, an entity may receive only partial
History-Info entries; will this suffice? Note that this would be 5. Entry with the index that matches the value of the first entry
a limitation for debugging purposes, but might be perfectly with a "mp" hi-target parameter - i.e., the original target of
satisfactory for some models whereby only the information from a the request.
specific intermediary is required.
In many cases, applications are most interested in the information
within a particular domain(s), thus only a subset of the information
is required.
Some applications may use multiple types of information. For
example, an Automatic Call Distribution (ACD)/Call center application
that utilizes the entry prior to the first History-Info entry with an
hi-target value of "mp", may also display other agents, reflected by
other History-Info entries prior to entries with hi-target values of
"rc", to whom the call was targeted prior to its arrival at the
current agent. This could allow the agent the ability to decide how
they might forward or reroute the call if necessary (avoiding agents
that were not previously available for whatever reason, etc.).
Since support for History-Info header is optional, a service MUST
define default behavior for requests and responses not containing
History-Info headers. For example, an entity may receive only
partial History-Info entries or entries which are not tagged
appropriately with an hi-target parameter. This may not impact some
applications (e.g., debug), however, it could require some
applications to make some default assumptions in this case. For
example, in an ACD scenario, the application could select the oldest
hi-entry with the domain associated with the ACD system and display
that as the original called party. Depending upon how and where the
request may have been retargeted, the complete list of agents to whom
the call was targeted may not be available.
8. Security Considerations 8. Security Considerations
The security requirements for this document are specified in The security requirements for this document are specified in
Appendix A.1. Appendix A.1.
This document defines a header for SIP. The use of the Transport This document defines a header for SIP. The use of the Transport
Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the Layer Security (TLS) protocol [RFC5246] as a mechanism to ensure the
overall confidentiality of the History-Info headers (SEC-req-4) is overall confidentiality of the History-Info headers (SEC-req-4) is
strongly RECOMMENDED. This results in History-Info having at least strongly RECOMMENDED. This results in History-Info having at least
skipping to change at page 24, line 8 skipping to change at page 24, line 10
"SIP/SIPS URI Parameters" registry, http:/www.iana.org/assignments/ "SIP/SIPS URI Parameters" registry, http:/www.iana.org/assignments/
sip-parameters, as defined in [RFC3969]. sip-parameters, as defined in [RFC3969].
Parameter Name Predefined Values Reference Parameter Name Predefined Values Reference
____________________________________________ ____________________________________________
hit Yes ("rc"/"mp") [RFCxxxx] hit Yes ("rc"/"mp") [RFCxxxx]
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.
10. Contributors 10. Acknowledgements
Cullen Jennings, Mark Watson, and Jon Peterson contributed to the
development of the initial requirements for [RFC4244].
Jonathan Rosenberg et al produced the document that provided Jonathan Rosenberg et al produced the document that provided
additional use cases precipating the requirement for the new "target" additional use cases precipitating the requirement for the new
parameter in the History-Info header and the new SIP/SIPS URI "target" parameter in the History-Info header and the new SIP/SIPS
parameter. URI parameter. Ian Elz provided feedback on the privacy aspects.
11. Acknowledgements
The editor would like to acknowledge the constructive feedback Mark Watson, Cullen Jennings and Jon Peterson provided significant
provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, input into the initial work that resulted in the development of of
Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, [RFC4244]. The editor would like to acknowledge the constructive
Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin Dolly, feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John
Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien Elwell, Nir Chen, Palash Jain, Brian Stucker, Norma Ng, Anthony
Garcin in the development of [RFC4244]. Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Martin
Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and
Sebastien Garcin in the development of [RFC4244].
The editor would like to acknowledge the significant input from Rohan The editor would like to acknowledge the significant input from Rohan
Mahy on some of the normative aspects of the ABNF for [RFC4244], Mahy on some of the normative aspects of the ABNF for [RFC4244],
particularly around the need for and format of the index and around particularly around the need for and format of the index and around
the security aspects. the security aspects.
Thanks to Ian Elz for his feedback on privacy for this specification. 11. Changes from RFC 4244
12. Changes from RFC 4244
This RFC replaces [RFC4244]. This RFC replaces [RFC4244].
Deployment experience with [RFC4244] over the years has shown a Deployment experience with [RFC4244] over the years has shown a
number of issues, warranting an update: number of issues, warranting an update:
o In order to make [RFC4244] work in "real life", one needs to make o In order to make [RFC4244] work in "real life", one needs to make
"assumptions" on how History-Info is used. For example, many "assumptions" on how History-Info is used. For example, many
implementations filter out many entries, and only leave specific implementations filter out many entries, and only leave specific
entries corresponding, for example, to first and last redirection. entries corresponding, for example, to first and last redirection.
Since vendors uses different rules, it causes significant Since vendors uses different rules, it causes significant
interoperability isssues. interoperability isssues.
o [RFC4244] is overly permissive and evasive about recording o [RFC4244] is overly permissive and evasive about recording
entries, causing interoperability issues. entries, causing interoperability issues.
o The examples in the call flows had errors, and confusing because o The examples in the call flows had errors, and confusing because
they often assume "loose routing." they often assume "loose routing".
o [RFC4244] has lots of repetitive and unclear text o [RFC4244] has lots of repetitive and unclear text due to the
combination of requirements with solution.
o [RFC4244] gratuitly mandates the use of TLS on every hop. No o [RFC4244] gratuitly mandates the use of TLS on every hop. No
existing implementation enforces this rule, and instead, the use existing implementation enforces this rule, and instead, the use
of TLS or not is a general SIP issue, not an [RFC4244] issue per of TLS or not is a general SIP issue, not an [RFC4244] issue per
se. se.
o [RFC4244] does not include clear procedures on how to deliver o [RFC4244] does not include clear procedures on how to deliver
current target URI information to the UAS when the Request-URI is current target URI information to the UAS when the Request-URI is
replaced with a contact. replaced with a contact.
skipping to change at page 25, line 48 skipping to change at page 25, line 49
3. Updated the security section to be equivalent to the security 3. Updated the security section to be equivalent to the security
recommendations for other SIP headers inserted by intermediaries. recommendations for other SIP headers inserted by intermediaries.
The first 2 changes are intended to facilitate application usage of The first 2 changes are intended to facilitate application usage of
the History-Info header and eliminate the need to make assumptions the History-Info header and eliminate the need to make assumptions
based upon the order of the entries and ensure that the most complete based upon the order of the entries and ensure that the most complete
set of information is available to the applications. set of information is available to the applications.
In addition, editorial changes were done to both condense and clarify In addition, editorial changes were done to both condense and clarify
the text and examples were simplified and updated to reflect the the text, moving the requirements to an appendix. The examples were
protocol changes. simplified and updated to reflect the protocol changes. Several of
the call flows in the appendix were removed and put into a separate
document that includes additional use cases that require the new
parameters.
12.1. Backwards compatibility 11.1. Backwards compatibility
This specification is backwards compatible since [RFC4244] allows for This specification is backwards compatible since [RFC4244] allows for
the addition of new optional parameters. This specification adds an the addition of new optional parameters. This specification adds an
optional parameter "target" to the History-Info header. Entities optional parameter "target" to the History-Info header. Entities
that have not implemented this specification should ignore this that have not implemented this specification should ignore this
parameter, however, per [RFC4244] an entity MUST not remove this parameter, however, per [RFC4244] an entity MUST NOT remove this
parameter from an hi-entry. This specification defines a SIP/SIPS parameter from an hi-entry. This specification defines a SIP/SIPS
URI parameter, "hit". An entity that does not understand the "hit" URI parameter, "hit". An entity that does not understand the "hit"
URI parameter SHOULD ignore the parameter and MAY remove the URI parameter SHOULD ignore the parameter and MAY remove the
parameter from the URI as it is used as the target for a request. parameter from the URI as it is used as the target for a request.
13. Changes since last Version 12. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from 00 to 01:
1. Moved examples (except first) in appendix to a new
(informational) document.
2. Updated UAS and UAC sections to clarify and expand on the
handling of the History-Info header.
3. Updated the Application considerations section:
* Included more detail with regards to how applications can make
use of the information, in particular based on the new tags.
* Removed privacy consideration (2nd bullet) since privacy is
now accomplished by anonymizing rather than removal of
entries.
Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf- Changes from (individual) barnes-sipcore-4244bis-03 to (WG) ietf-
sipcore-4244bis-00: sipcore-4244bis-00:
1. Added a new SIP/SIPS URI parameter to tag the URIs as they are 1. Added a new SIP/SIPS URI parameter to tag the URIs as they are
added to the target list and those returned in the contact header added to the target list and those returned in the contact header
in a 3xx response. in a 3xx response.
2. Updated description of "target" parameter to use the new URI 2. Updated description of "target" parameter to use the new URI
parameter value in setting the value for the parameter. parameter value in setting the value for the parameter.
skipping to change at page 26, line 47 skipping to change at page 27, line 20
processing). processing).
5. Additional text to clarify that a service such as voicemail can 5. Additional text to clarify that a service such as voicemail can
be done in multiple ways. be done in multiple ways.
6. Editorial changes including removal of some vestiges of tagging 6. Editorial changes including removal of some vestiges of tagging
all entries (including the "aor" tag). all entries (including the "aor" tag).
Changes from barnes-sipcore-4244bis-02 to 03: Changes from barnes-sipcore-4244bis-02 to 03:
1. Fixed problem with indices in example in Appendix B.2. 1. Fixed problem with indices in example in voicemail example.
2. Removed oc and rt from the Hi-target parameter. 2. Removed oc and rt from the Hi-target parameter.
3. Removed aor tag 3. Removed aor tag
4. Added index parameter to "mp" 4. Added index parameter to "mp"
5. Added use-cases and call-flows from target-uri into appendix. 5. Added use-cases and call-flows from target-uri into appendix.
Changes from barnes-sipcore-4244bis-01 to 02: Changes from barnes-sipcore-4244bis-01 to 02:
skipping to change at page 29, line 24 skipping to change at page 29, line 43
4. Added hi-target parameter values to HI header to ABNF and 4. Added hi-target parameter values to HI header to ABNF and
protocol description, as well as defining proxy, UAC and UAS protocol description, as well as defining proxy, UAC and UAS
behavior for the parameter. behavior for the parameter.
5. Simplified example call flow in section 4.5. Moved previous call 5. Simplified example call flow in section 4.5. Moved previous call
flow to appendix. flow to appendix.
6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new 6. Fixed ABNF per RFC4244 errata "dot" -> "." and added new
parameter. parameter.
14. References 13. References
14.1. Normative References 13.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.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
skipping to change at page 30, line 5 skipping to change at page 30, line 22
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4244] Barnes, M., "An Extension to the Session Initiation [RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244, Protocol (SIP) for Request History Information", RFC 4244,
November 2005. November 2005.
14.2. Informative References 13.2. Informative References
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[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.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network
(PSTN) Signaling Information", RFC 4769, November 2006.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter (IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004. BCP 99, RFC 3969, December 2004.
[I-D.ietf-enum-cnam]
Shockey, R., "IANA Registration for an Enumservice Calling
Name Delivery (CNAM) Information and IANA Registration for
URI type 'pstndata'", draft-ietf-enum-cnam-08 (work in
progress), September 2008.
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
SIP redirect, it is deemed useful for non-redirect retargeting SIP redirect, it is deemed useful for non-redirect retargeting
skipping to change at page 33, line 19 skipping to change at page 33, line 19
2. PRIV-req-2: The entity receiving the Request History must 2. PRIV-req-2: The entity receiving the Request History must
maintain the privacy associated with the information. In maintain the privacy associated with the information. In
addition, local policy at a proxy may identify privacy addition, local policy at a proxy may identify privacy
requirements associated with the Request-URI being captured in requirements associated with the Request-URI being captured in
the Request History information. the Request History information.
3. PRIV-req-3: Request History information subject to privacy shall 3. PRIV-req-3: Request History information subject to privacy shall
not be included in ougoing messages unless it is protected as not be included in ougoing messages unless it is protected as
described in [RFC3323]. described in [RFC3323].
Appendix B. Detailed call flows Appendix B. Example call flows
The scenarios in this section provide sample use cases for the The scenarios in this section provide sample use cases for the
History-Info header for informational purposes only. They are not History-Info header for informational purposes only. They are not
intended to be normative. intended to be normative. A basic forking use case is included,
along with two use cases illustrating the use of the privacy.
B.1. Sequentially Forking (History-Info in Response) B.1. Sequentially Forking (History-Info in Response)
This scenario highlights an example where the History-Info in the This scenario highlights an example where the History-Info in the
response is useful to an application or user that originated the response is useful to an application or user that originated the
request. request.
Alice sends a call to Bob via sip:example.com. The proxy sip: Alice sends a call to Bob via sip:example.com. The proxy sip:
example.com sequentially tries Bob on a SIP UA that has bound a example.com sequentially tries Bob on a SIP UA that has bound a
contact with the sip:bob@example.com AOR, and then several alternate contact with the sip:bob@example.com AOR, and then several alternate
addresses (Office and Home) unsuccessfully before sending a response addresses (Office and Home) unsuccessfully before sending a response
to Alice. In this example, note that Office and Home are not the to Alice. The hi-entry containing the initial contact is the entry
same AOR as sip:bob@example.com, but rather different AORs that have just prior to the firt entry tagged with an hi-target value of "rc".
been configured as alternate addresses for Bob in the proxy. In In this example, the Office and Home are not the same AOR as
other words, Office and Bob are not bound through SIP Registration sip:bob@example.com, but rather different AORs that have been
with Bob's AOR. This type of arrangement is common for example when configured as alternate addresses for Bob in the proxy. In other
a "routing" rule to a PSTN number is manually configured in a Proxy. words, Office and Bob are not bound through SIP Registration with
Bob's AOR. This type of arrangement is common for example when a
"routing" rule to a PSTN number is manually configured in a Proxy.
These hi-entries are identified by the index contained in the hi-
target "mp" parameter in the hi-entries.
This scenario is provided to show that by providing the History-Info This scenario illustrates that by providing the History-Info to
to Alice, the end-user or an application at Alice could make a Alice, the end-user or an application at Alice could make a decision
decision on how best to attempt finding Bob. Without this mechanism, on how best to attempt finding Bob without sending multiple requests
Alice might well attempt Office (and thus Home) and then re-attempt to the same destination. Upon receipt of the response containing the
Home on a third manual attempt at reaching Bob. With this mechanism, History-Info entries, the Request URIs for the History-Info entries
either the end-user or application could know that Bob is not tagged with "mp" are extracted. Those Request-URIs can be compared
answering in the Office, and his busy on his home phone. If there to other URIs (if any) that might be attempted in order to establish
were an alternative address for Bob known to this end-user or the session with Bob. Thus, avoiding another INVITE to Bob's home
application, that hasn't been attempted, then either the application phone. Without this mechanism, Alice might well attempt to reach Bob
or the end- user could attempt that. The intent here is to highlight at his office phone, which would then retarget the request to Bob's
an example of the flexibility of this mechanism that enables home phone. When that attempt failed, then Alice might attempt to
applications well beyond SIP as it is certainly well beyond the scope reach Bob directly at his home phone, unknowingly for a third time.
of this document to prescribe detailed applications.
Alice example.com Bob Office Home Alice example.com Bob Office Home
| | | | | | | | | |
| INVITE F1 | | | | | INVITE F1 | | | |
|----------->| INVITE F2 | | | |----------->| INVITE F2 | | |
| |----------------->| | | | |----------------->| | |
| 100 Trying F3 | | | | 100 Trying F3 | | |
|<-----------| 302 Move Temporarily F4 | | |<-----------| 302 Move Temporarily F4 | |
| |<-----------------| | | | |<-----------------| | |
| | ACK F5 | | | | | ACK F5 | | |
skipping to change at page 40, line 25 skipping to change at page 40, line 25
ACK sip:bob@example.com SIP/2.0 ACK sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060 Via: SIP/2.0/TCP 192.0.2.3:5060
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-Id: 12345600@example.com Call-Id: 12345600@example.com
Route: <sip:proxy.example.com;lr> Route: <sip:proxy.example.com;lr>
CSeq: 1 ACK CSeq: 1 ACK
Content-Length: 0 Content-Length: 0
B.2. Voicemail B.2. History-Info with Privacy Header
This scenario highlights an example where the History-Info in the
request is primarily of use by an edge service (e.g., voicemail
server). It should be noted that this is not intended to be a
complete specification for this specific edge service as it is quite
likely that additional information is needed by the edge service.
History-Info is just one building block that this service can use.
Alice called Bob, which had been forwarded to Carol, which forwarded
to VM (voicemail server). Based upon the retargeted URIs and Reasons
(and other information) in the INVITE, the VM server makes a policy
decision about what mailbox to use, which greeting to play, etc. An
example policy would be forwarding the request to the mailbox for the
first hi-targeted-to-uri in the History-Info header within the domain
for which the processing entity is responsible (e.g., in a PBX
environment). Whereas another policy might be to forward the request
to the mailbox for the last hi-targeted-to-uri tagged with "mp" in
the History-Info header (e.g., in a customer service environment).
Alice example.com Bob Carol VM
| INVITE sip:bob@example.com | | |
|------------->| | | |
| | INVITE sip:bob@192.0.2.3 | |
| |------------->| | |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3>;index=1.1;rc
| | | | |
| 100 Trying | | | |
|<-------------| 302 Moved Temporarily | |
| |<-------------| | |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
| | | | |
| | INVITE sip:Carol@192.0.2.4 | |
| |--------------------------->| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
| | | | |
| | 180 Ringing | |
| |<---------------------------| |
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
| | | | |
| 180 Ringing | | | |
|<-------------| | | |
| | | | |
| . . . | | | |
| | (timeout) | |
| | | | |
| | INVITE sip:vm@192.0.2.5 |
| |-------------------------------------->|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
History-Info: <sip:vm@example.com>;index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5>;index=1.3.1
| | | | |
| | 200 OK |
| |<--------------------------------------|
History-Info: <sip:bob@example.com>;index=1
History-Info: <sip:bob@192.0.2.3?Reason=SIP;cause=302>;\
index=1.1;rc
History-Info: <sip:carol@example.com>;index=1.2;mp=1
History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc
History-Info: <sip:vm@example.com>;index=1.3;mp=1.2
History-Info: <sip:vm@192.0.2.5>;index=1.3.1
| 200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |-------------------------------------->|
B.3. Automatic Call Distribution
This scenario highlights an example of an Automatic Call Distribution
service, where the agents are divided into groups based upon the type
of customers they handle. In this example, the Gold customers are
given higher priority than Silver customers, so a Gold call would get
serviced even if all the agents servicing the Gold group were busy,
by retargeting the request to the Silver Group for delivery to an
agent. Upon receipt of the call at the agent assigned to handle the
incoming call, based upon the History-Info header in the message, the
application at the agent can provide an indication that this is a
Gold call, from how many groups it might have overflowed before
reaching the agent, etc. and thus can be handled appropriately by the
agent.
For scenarios whereby calls might overflow from the Silver to the
Gold, clearly the alternate group identification, internal routing,
or actual agent that handles the call should not be sent to UA1.
Thus, for this scenario, one would expect that the Proxy would not
support the sending of the History-Info in the response, even if
requested by Alice.
As with the other examples, this is not prescriptive of how one would
do this type of service but an example of a subset of processing that
might be associated with such a service. In addition, this example
is not addressing any aspects of Agent availability, which might also
be done via a SIP interface.
Alice example.com Gold Silver Agent
| | | | |
| INVITE sip:Gold@example.com | | |
|------------->| | | |
| Supported: histinfo
| | | | |
| | INVITE sip:Gold@example.com |
| |------------->| | |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com>;index=1.1
| | | | |
| | 302 Moved Temporarily | |
| |<-------------| | |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
Contact: <sip:Silver@example.com>
| | | |
| | INVITE sip:Silver@example.com |
| |--------------------------->| |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
| | | | |
| | | INVITE sip:Silver@192.0.2.7
| | | |----------->|
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
History-Info: <sip:Silver@192.0.2.7>;index=2.1.1;rc
| | | | |
| | | | 200 OK |
| | | |<-----------|
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
History-Info: <sip:Silver@192.0.2.7>;index=2.1.1;rc
| | | | |
| | 200 OK | |
| |<---------------------------| |
History-Info: <sip:Gold@example.com>;index=1
History-Info: <sip:Gold@gold.example.com?Reason=SIP;cause=302>;\
index=1.1
History-Info: <sip:Silver@example.com>;index=2;mp=1
History-Info: <sip:Silver@silver.example.com>;index=2.1
History-Info: <sip:Silver@192.0.2.7>;index=2.1.1;rc
| | | | |
200 OK | | | |
|<-------------| | | |
| | | | |
| ACK | | | |
|------------->| ACK |
| |---------------------------------------->|
B.4. History-Info with Privacy Header
This example provides a basic call scenario such as the one in This example provides a basic call scenario without forking, with
Figure 1 but without forking, with sip:biloxi.example.com adding the sip:biloxi.example.com adding the Privacy header indicating that the
Privacy header indicating that the History-Info header information is History-Info header information is anonymized outside the
anonymized outside the biloxi.example.com domain. This scenario biloxi.example.com domain.
highlights the potential functionality lost with the use of "history"
privacy in the Privacy header for the entire request and the need for
careful consideration on the use of privacy for History-Info.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob
| | | | | | | |
| 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
| |--------------->| | | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
skipping to change at page 45, line 47 skipping to change at page 41, line 47
| History-Info: <sip:anonymous@anonymous.invalid>;index=1.1 | History-Info: <sip:anonymous@anonymous.invalid>;index=1.1
| History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc | History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc
| | | | | | | |
| ACK | | | | ACK | | |
|--------------->| ACK | | |--------------->| ACK | |
| |--------------->| ACK | | |--------------->| ACK |
| | |--------------->| | | |--------------->|
Figure 2: Example with Privacy Header Figure 2: Example with Privacy Header
B.5. Privacy Header for a Specific History-Info Entry B.3. Privacy Header for a Specific History-Info Entry
This example also provides a basic call scenario such as the one in This example provides a basic call scenario similar to Appendix B.2,
Figure 1 but without forking, however, due to local policy at sip: however, due to local policy at sip:biloxi.example.com, only the
biloxi.example.com, only the final hi-entry in the History-Info, final hi-entry in the History-Info, which is Bob's local URI,
which is Bob's local URI, contains a priv-value of "history", thus contains a priv-value of "history", thus providing Alice with some
providing Alice with some information about the history of the information about the history of the request, but anonymizing Bob's
request, but anonymizing Bob's local URI. local URI.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob
| | | | | | | |
| 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
| |--------------->| | | |--------------->| |
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
skipping to change at page 47, line 5 skipping to change at page 43, line 5
| History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 | History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
| History-Info: <sip:anonymous@anynymous.invalid>;index=1.1.1;rc | History-Info: <sip:anonymous@anynymous.invalid>;index=1.1.1;rc
| | | | | | | |
| ACK | | | | ACK | | |
|--------------->| ACK | | |--------------->| ACK | |
| |--------------->| ACK | | |--------------->| ACK |
| | |--------------->| | | |--------------->|
Figure 3: Example with Privacy Header for Specific URI Figure 3: Example with Privacy Header for Specific URI
B.6. Determining the Alias used.
SIP user agents are associated with an address-of-record (AOR). It
is possible for a single UA to actually have multiple AOR associated
with it. One common usage for this is aliases. For example, a user
might have an AOR of sip:john@example.com but also have the AORs
sip:john.smith@example.com and sip:jsmith@example.com. Rather than
registering against each of these AORs individually, the user would
register against just one of them, and the home proxy would
automatically accept incoming calls for any of the aliases, treating
them identically and ultimately forwarding them towards the UA. This
is common practice in the Internet Multimedia Subsystem (IMS), where
it is called implicit registrations and each alias is called a public
identity.
It is a common requirement for a UAS, on receipt of a call, to know
which of its aliases was used to reach it. This knowledge can be
used to choose ringtones to play, determine call treatment, and so
on. For example, a user might give out one alias to friends and
family only, resulting in a special ring that alerts the user to the
importance of the call.
Following call-flow and example messages show how History-Info can be
used to find out the alias used to reach the callee.
UAS can see which alias was used in the call by looking at the hi-
entry prior to the last hi-entry with the "rc" tag.
Alice Example.com John
| | REGISTER F1 |
| |<--------------------|
| | 200 OK F2 |
| |-------------------->|
| INVITE F3 | |
|-------------------->| |
| | INVITE F4 |
| |-------------------->|
* Rest of flow not shown *
F1 REGISTER John -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
Content-Length: 0
F2 200 OK Example.com -> John
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>;expires=3600
Content-Length: 0
F3 INVITE Alice -> Example.com
INVITE sip:john.smith@example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: John <sip:john.smith@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:john.smith@example.com>;index=1;
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F4 INVITE Example.com -> Bob
INVITE sip:john@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: John <sip:john.smith@example.com>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:john.smith@example.com>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
Figure 4: Alias Example
B.7. GRUU
A variation on the problem in Appendix B.6 occurs with Globally
Routable User Agent URI (GRUU) [RFC5627]. A GRUU is a URI assigned
to a UA instance which has many of the same properties as the AOR,
but causes requests to be routed only to that specific instance. It
is desirable for a UA to know whether it was reached because a
correspondent sent a request to its GRUU or to its AOR. This can be
used to drive differing authorization policies on whether the request
should be accepted or rejected, for example. However, like the AOR
itself, the GRUU is lost in translation at the home proxy. Thus, the
UAS cannot know whether it was contacted via the GRUU or its AOR.
Following call-flow and example messages show how History-Info can be
used to find out the GRUU used to reach the callee.
GRUU is merely an AoR with a URI parameter that distinguishes the
target instance, and as any URI parameters are preserved in history-
info as Request-URI is trasnlated, UA can see if the request was
addressed to a specific instance (gruu) by evaluating the presence of
"gr" parameter in the hi-entry prior to the last hi-entry with the
"rc" tag.
Alice Example.com John
| | REGISTER F1 |
| |<--------------------|
| | 200 OK F2 |
| |-------------------->|
| INVITE F3 | |
|-------------------->| |
| | INVITE F4 |
| |-------------------->|
* Rest of flow not shown *
F1 REGISTER John -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:John@example.com>;tag=a73kszlfl
Supported: gruu
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
F2 200 OK Example.com -> John
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;pub-gruu="sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu=
"sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
Content-Length: 0
Assuming Alice has a knowledge of a gruu either through
prior communication or through other means such as presence
places a call to John's gruu.
F3 INVITE Alice -> Example.com
INVITE sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: <sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Length: <appropriate value>
F4 INVITE Example.com -> John
INVITE sip:john@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: John <sip:john@example.com>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
Figure 5: GRUU Example
B.8. Limited Use Address
A limited use address is a SIP URI that is minted on-demand, and
passed out to a small number (usually one) remote correspondent.
Incoming calls targeted to that limited use address are accepted as
long as the UA still desires communications from the remote target.
Should they no longer wish to be bothered by that remote
correspondent, the URI is invalidated so that future requests
targeted to it are rejected.
Limited use addresses are used in battling voice spam [RFC5039]. The
easiest way to provide them would be for a UA to be able to take its
AOR, and "mint" a limited use address by appending additional
parameters to the URI. It could then give out the URI to a
particular correspondent, and remember that URI locally. When an
incoming call arrives, the UAS would examine the parameter in the URI
and determine whether or not the call should be accepted.
Alternatively, the UA could push authorization rules into the
network, so that it need not even see incoming requests that are to
be rejected.
This approach, especially when executed on the UA, requires that
parameters attached to the AOR, but not used by the home proxy in
processing the request, will survive the translation at the home
proxy and be presented to the UA. This will not be the case with the
logic in RFC 3261, since the Request-URI is replaced by the
registered contact, and any such parameters are lost.
Using the history-info John's UA can easily see if the call was
addressed to its AoR, GRUU or a temp-gruu and treat the call
accordingly by looking at the hi-entry prior to the last hi-entry
with the "rc" tag.
Alice Example.com John
| | REGISTER F1 |
| |<--------------------|
| | 200 OK F2 |
| |-------------------->|
| INVITE F3 | |
|-------------------->| |
| | INVITE F4 |
| |-------------------->|
* Rest of flow not shown *
F1 REGISTER John -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:John@example.com>;tag=a73kszlfl
Supported: gruu
To: John <sip:john@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Content-Length: 0
F2 200 OK Example.com -> John
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:john@example.com>;tag=a73kszlfl
To: John <sip:john@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:john@192.0.2.1>
;pub-gruu="sip:john@example.com
;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
;temp-gruu=
"sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
;expires=3600
Content-Length: 0
Assuming Alice has a knowledge of a temp-gruu, she places a
call to the temp-gruu.
F3 INVITE Alice -> Example.com
INVITE sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com
;gr SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: <sip:sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com
;gr>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info:
<sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
;index=1
Contact: Alice <sip:alice@192.0.2.3>
Content-Length: <appropriate value>
F4 INVITE Example.com -> John
INVITE sip:john@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>;tag=kkaz-
To: John <sip:john@example.com>
Supported: gruu, histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info:
<sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
;index=1
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
Figure 6: Limited Use Address Example
B.9. Sub-Address
Sub-Addressing is very similar to limited use addresses. Sub-
addresses are addresses within a subdomain that are multiplexed into
a single address within a parent domain. The concept is best
illustrated by example. Consider a VoIP service provided to
consumers. A consumer obtains a single address from its provider,
say sip:family@example.com. However, Joe is the patriarch of a
family with four members, and would like to be able to have a
separate identifier for each member of his family. One way to do
that, without requiring Joe to purchase new addresses for each member
from the provider, is for Joe to mint additional URI by adding a
parameter to the AOR. For example, his wife Judy with have the URI
sip:family@example.com;member=judy, and Joe himself would have the
URI sip:family@example.com;member=joe. The SIP server provider would
receive requests to these URI, and ignoring the unknown parameters
(as required by [RFC3261]) route the request to the registered
contact, which corresponds to a SIP server in Joes home. That
server, in turn, can examine the URI parameters and determine which
phone in the home to route the call to.
This feature is not specific to VoIP, and has existing in Integrated
Services Digital Networking (ISDN) for some time. It is particularly
useful for small enterprises, in addition to families. It is also
similar in spirit (though not mechanism) to the ubiquitous home
routers used by consumers, which allow multiple computers in the home
to "hide" behind the single IP address provided by the service
provider, by using the TCP and UDP port as a sub-address.
The sub-addressing feature is not currently feasible in SIP because
of the fact that any SIP URI parameter used to convey the sub-address
would be lost at the home proxy, due to the fact that the Request-URI
is rewritten there.
Call-flow and example messages below show the how History-Info can be
used to deliver the sub-address. UAS or Proxy can determine the sub-
address by looking at the hi-entry prior to the last hi-entry with
the "rc" tag.
Alice Example.com John's Home Judy John
| | REGISTER F1 | | |
| |<-------------| | |
| | 200 OK F2 | | |
| |------------->| | |
| | | REGISTER F3 | |
| | |<-------------| |
| | | 200 OK F4 | |
| | |------------->| |
| | | | REGISTER F5 |
| | |<----------------------------|
| | | | 200 OK F6 |
| | |---------------------------->|
| INVITE F7 | | | |
|----------->| | | |
| | INVITE F8 | | |
| |------------->| | |
| | | INVITE F9 | |
| | |------------->| |
* Rest of flow not shown *
F1 REGISTER John's Home Server -> Example.com
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
Max-Forwards: 70
From: John <sip:johnhome@example.com>;tag=a73kszlfl
To: John <sip:johnhome@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:johnhome@192.0.2.1>
Content-Length: 0
F2 200 OK Example.com -> John's Home Server
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
From: John <sip:johnhome@example.com>;tag=a73kszlfl
To: John <sip:johnhome@example.com> ;tag=b88sn
Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
CSeq: 1 REGISTER
Contact: <sip:johnhome@192.0.2.1>;expires=3600
Content-Length: 0
We assume that John's server acts as a proxy allowing
each of the device in the house to register.
F3 REGISTER Judy's phone -> John's Home Server
REGISTER sip:192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bKnasdds
Max-Forwards: 70
From: Judy <sip:judy@192.168.1.1>;tag=a73kszlfl
To: Judy <sip:judy@192.168.1.1>
Call-ID: 12345pLxk3uxtm8tn@192.168.1.2
CSeq: 1 REGISTER
Contact: <sip:judy@192.168.1.2>
Content-Length: 0
F4 200 OK John's Home Server -> Judy's phone
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bKnashds7
From: Judy <sip:judy@192.168.1.1>;tag=a73kszlfl
To: Judy <sip:judy@192.168.1.1>tag=b88sn
Call-ID: 12345pLxk3uxtm8tn@192.168.1.2
CSeq: 1 REGISTER
Contact: <sip:judy@192.168.1.2>;expires=3600
Content-Length: 0
F5 REGISTER John's phone -> John's Home Server
REGISTER sip:192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bKnasdds
Max-Forwards: 70
From: Judy <sip:john@192.168.1.1>;tag=a73kszlfl
To: Judy <sip:john@192.168.1.1>
Call-ID: 12346pLxk3uxtm8tn@192.168.1.3
CSeq: 1 REGISTER
Contact: <sip:john@192.168.1.3>
Content-Length: 0
F6 200 OK John's Home Server -> John's phone
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.3;branch=z9hG4bKnashds7
From: John <sip:john@192.168.1.1>;tag=a73kszlfl
To: John <sip:john@192.168.1.1> ;tag=b88sn
Call-ID: 12346pLxk3uxtm8tn@192.168.1.3
CSeq: 1 REGISTER
Contact: <sip:john@192.168.1.3>;expires=3600
Content-Length: 0
F7 INVITE Alice -> Example.com
INVITE sip:johnhome@example.com;member=judy SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: Judy <sip:johnhome@example.com;member=judy>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
History-Info: <sip:johnhome@example.com;member=judy>;index=1;
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F8 INVITE Example.com -> John's Home
INVITE sip:johnhome@192.0.2.1 SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: Judy <sip:johnhome@example.com;member=judy>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:johnhome@example.com;member=judy>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
John's Home server can see that the call was addressed to
Judy by evaluating the entry prior to the last entry with the
"rc" tag and forwards the call accordingly.
F9 INVITE John's Home -> Judy
INVITE sip:judy@192.168.1.2 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.1:5060;branch=abc2334se
Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
From: Alice <sip:alice@example.com>
To: Judy <sip:johnhome@example.com;member=judy>
Supported: histinfo
Call-Id: 12345600@example.com
CSeq: 1 INVITE
Record-Route: <sip:proxy.example.com;lr>
History-Info: <sip:johnhome@example.com;member=judy>;index=1;
History-Info: <sip:john@192.0.2.1>;index=1.1;rc
History-Info: <sip:judy@192.168.1.1>;index=1.1.1;mp=1.1
History-Info: <sip:judy@192.168.1.2>;index=1.1.1.1;rc
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
Figure 7: Sub-Address Example
B.10. Service Invocation
Several SIP specifications have been developed which make use of
complex URIs to address services within the network rather than
subscribers. The URIs are complex because they contain numerous
parameters that control the behavior of the service. Examples of
this include the specification which first introduced the concept,
[RFC3087], control of network announcements and IVR with SIP URI
[RFC4240], and control of voicemail access with SIP URI [RFC4458].
A common problem with all of these mechanisms is that once a proxy
has decided to rewrite the Request-URI to point to the service, it
cannot be sure that the Request-URI will not be destroyed by a
downstream proxy which decides to forward the request in some way,
and does so by rewriting the Request-URI.
Section on voicemail (Appendix B.2) shows how History-Info can be
used to invocate a service.
B.11. Toll Free Number
Toll free numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call.
In the telephone network, toll free numbers are just aliases to
actual numbers which are used for routing of the call. In order to
process the call in the PSTN, a switch will perform a query (using a
protocol called TCAP), which will return either a phone number or the
identity of a carrier which can handle the call.
There has been recent work on allowing such PSTN translation services
to be accessed by SIP proxy servers through IP querying mechanisms.
ENUM, for example [RFC3761] has already been proposed as a mechanism
for performing Local Number Portability (LNP) queries [RFC4769], and
recently been proposed for performing calling name queries
[I-D.ietf-enum-cnam]. Using it for 8xx number translations is a
logical next-step.
Once such a translation has been performed, the call needs to be
routed towards the target of the request. Normally, this would
happen by selecting a PSTN gateway which is a good route towards the
translated number. However, one can imagine all-IP systems where the
8xx numbers are SIP endpoints on an IP network, in which case the
translation of the 8xx number would actually be a SIP URI and not a
phone number. Assuming for the moment it is a PSTN connected entity,
the call would be routed towards a PSTN gateway. Proper treatment of
the call in the PSTN (and in particular, correct reconciliation of
billing records) requires that the call be marked with both the
original 8xx number AND the target number for the call. However, in
our example here, since the translation was performed by a SIP proxy
upstream from the gateway, the original 8xx number would have been
lost, and the call will not interwork properly with the PSTN.
Furthermore, even if the translation of the 8xx number was a SIP URI,
the enterprise or user who utilize the 8xx service would like to know
whether the call came in via 8xx number in order to treat the call
differently (for example to play a special announcement..) but if the
original R-URI is lost through translation, there is no way to tell
if the call came in via 8xx number.
Similar problems arise with other "special" numbers and services used
in the PSTN, such as operator services, pay numbers (9xx numbers in
the U.S), and short service codes such as 311.
To find the service number, the UAS can look at the hi-entry prior to
the first hi-entry with "mp" tag. Technically call can be forwarded
to these "special" numbers from non "special" numbers, but with the
way these services authorize trasnlation, it is not common.
Alice Toll Free Service Atlanta.com John
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | | INVITE F3 |
| | |------------------>|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+18005551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+18005551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone >;index=1
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F2: INVITE proxy.example.com -> atlanta.com
INVITE sip:+15555551002@atlanta.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+18005551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone >;index=1,
<sip:+15555551002@atlanta.com>;index=1.1;mp=1
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
F3: INVITE atlanta.com -> Joe
INVITE sip:joe@192.168.1.2 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.1:5060;branch=z9hG4bK-pxk7g-3
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+18005551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Supported: histinfo
History-Info: <sip:+18005551002@example.com;user=phone >;index=1,
<sip:+15555551002@atlanta.com>;index=1.1;mp=1,
<sip:joe@atlanta.com>;index=1.1.1;mp=1.1,
<sip:joe@192.168.1.2>;index=1.1.2;rc
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: <appropriate value>
[SDP Not Shown]
Figure 8: Service Number Example
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Polycom
Richardson, TX TX
US
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
Francois Audet Francois Audet
Skype Skype
Email: francois.audet@skype.net Email: francois.audet@skype.net
Shida Schubert Shida Schubert
NTT NTT
Email: shida@agnada.com Email: shida@agnada.com
 End of changes. 48 change blocks. 
1015 lines changed or deleted 216 lines changed or added

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