draft-ietf-sipcore-rfc4244bis-callflows-06.txt   draft-ietf-sipcore-rfc4244bis-callflows-07.txt 
SIPCORE M. Barnes SIPCORE M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Intended status: Informational F. Audet Intended status: Informational F. Audet
Expires: January 2, 2014 Skype Expires: April 23, 2014 Skype
S. Schubert S. Schubert
NTT NTT
H. van Elburg H. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
Jul 2013 Oct 20, 2013
Session Initiation Protocol (SIP) History-Info Header Call Flow Examples Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
draft-ietf-sipcore-rfc4244bis-callflows-06.txt draft-ietf-sipcore-rfc4244bis-callflows-07.txt
Abstract Abstract
This document describes use cases and documents call flows which This document describes use cases and documents call flows which
require the History-Info header field to capture the Request-URIs as require the History-Info header field to capture the Request-URIs as
a Session Initiation Protocol (SIP) Request is retargeted. The use a Session Initiation Protocol (SIP) Request is retargeted. The use
cases are described along with the corresponding call flow diagrams cases are described along with the corresponding call flow diagrams
and messaging details. and messaging details.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2014. This Internet-Draft will expire on April 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Detailed call flows . . . . . . . . . . . . . . . . . . . . . 3 3. Detailed call flows . . . . . . . . . . . . . . . . . . . . . 3
3.1. Sequentially Forking (History-Info in Response) . . . . . 3 3.1. Sequentially Forking (History-Info in Response) . . . . . 3
3.2. History-Info with Privacy Header Field . . . . . . . . . . 11 3.2. History-Info with Privacy Header Field . . . . . . . . . . 11
3.3. Privacy for a Specific History-Info Entry . . . . . . . . 14 3.3. Privacy for a Specific History-Info Entry . . . . . . . . 16
3.4. Automatic Call Distribution . . . . . . . . . . . . . . . 18 3.4. Automatic Call Distribution . . . . . . . . . . . . . . . 20
3.5. Determining the Alias used. . . . . . . . . . . . . . . . 23 3.5. Determining the Alias used. . . . . . . . . . . . . . . . 25
3.6. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 26 3.6. PBX Voicemail Example . . . . . . . . . . . . . . . . . . 28
3.7. Consumer Voicemail Example . . . . . . . . . . . . . . . . 31 3.7. Consumer Voicemail Example . . . . . . . . . . . . . . . . 33
3.8. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.8. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9. Limited Use Address . . . . . . . . . . . . . . . . . . . 38 3.9. Limited Use Address . . . . . . . . . . . . . . . . . . . 40
3.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 41 3.10. Service Invocation . . . . . . . . . . . . . . . . . . . . 43
3.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 41 3.11. Toll Free Number . . . . . . . . . . . . . . . . . . . . . 43
4. Security Considerations . . . . . . . . . . . . . . . . . . . 44 4. Security Considerations . . . . . . . . . . . . . . . . . . . 45
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 44 5.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 46
6. Informative References . . . . . . . . . . . . . . . . . . . . 44 6. Informative References . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Overview 1. Overview
Many services that use SIP require the ability to determine why and Many services that use SIP require the ability to determine why and
how the call arrived at a specific application. The use cases how the call arrived at a specific application. The use cases
provided in this document illustrate the use of the History-Info provided in this document illustrate the use of the History-Info
header [I-D.ietf-sipcore-rfc4244bis] for example applications and header [I-D.ietf-sipcore-rfc4244bis] for example applications and
common scenarios. The optional "rc" and "mp" header field parameters common scenarios. The optional "rc" and "mp" header field parameters
defined in [I-D.ietf-sipcore-rfc4244bis] are required for several of defined in [I-D.ietf-sipcore-rfc4244bis] are required for several of
the use cases. Descriptions of the example use cases, call flow the use cases. Descriptions of the example use cases, call flow
diagrams and messaging details are provided. diagrams and messaging details are provided.
2. Conventions and Terminology 2. Conventions and Terminology
The term "retarget" is used as defined in The term "retarget" is used as defined in
[I-D.ietf-sipcore-rfc4244bis]. The terms "location service", [I-D.ietf-sipcore-rfc4244bis]. The terms "location service",
"redirect" and "AOR" are used consistent with the terminology in "redirect" and "address-of-record (AOR)" are used consistent with the
[RFC3261]. terminology in [RFC3261].
3. Detailed call flows 3. Detailed 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. In many cases, only the relevant messaging intended to be normative. In many cases, only the relevant messaging
details are included in the body of the call flow. details are included in the body of the call flow.
3.1. Sequentially Forking (History-Info in Response) 3.1. Sequentially Forking (History-Info in Response)
skipping to change at page 3, line 45 skipping to change at page 3, line 45
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. The hi-entry containing the initial contact is the hi- to Alice. The hi-entry containing the initial contact is the hi-
entry just prior to the first hi-entry tagged with an "rc" header entry just prior to the first hi-entry tagged with an "rc" header
field parameter. In this example, the Office and Home are not the field parameter. In this example, the Office and Home are not the
same AOR as sip:bob@example.com, but rather different AORs that have same AOR as sip:bob@example.com, but rather different AORs that have
been configured as alternate addresses for Bob in the proxy. In been configured as alternate addresses for Bob in the proxy. In
other words, Office and *Home* are not bound through SIP Registration other words, Office and Home are not bound through SIP Registration
with Bob's AOR. This type of arrangement is common for example when 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. 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- These hi-entries are identified by the index contained in the hi-
target-param "mp" header field parameter in the hi-entries. target-param "mp" header field parameter in the hi-entries.
This scenario illustrates that by providing the History-Info to This scenario illustrates that by providing the History-Info to
Alice, the end-user or an application at Alice could make a decision Alice, the end-user or an application at Alice could make a decision
on how best to attempt finding Bob without sending multiple requests on how best to attempt finding Bob without sending multiple requests
to the same destination. Upon receipt of the response containing the to the same destination. Upon receipt of the response containing the
History-Info entries, the Request URIs for the History-Info entries History-Info entries, the Request URIs for the History-Info entries
skipping to change at page 11, line 7 skipping to change at page 11, line 7
Max-Forward: 70 Max-Forward: 70
From: Alice <sip:alice@example.com>;tag=sr3dds From: Alice <sip:alice@example.com>;tag=sr3dds
To: Bob <sip:bob@example.com>;tag=55rdds To: Bob <sip:bob@example.com>;tag=55rdds
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
3.2. History-Info with Privacy Header Field 3.2. History-Info with Privacy Header Field
This example provides a basic call scenario without forking. Alice This is an example of the use of the Privacy header field with a
has indicated that she wants Privacy associated with the History-Info value of "history" added by an intermediary. The intermediary
header field entries. In addition, sip:biloxi.example.com adds responsible for the biloxi.example.com domain adds a Privacy header
Privacy header fields indicating that the History-Info header field field with a value of "history" indicating that all the History-Info
information is anonymized outside the biloxi.example.com domain. header field information is anonymized outside the biloxi.example.com
Note, that if the atlanta.example.com proxy had added privacy header domain. Thus, none of the URIs to which the request is retargeted in
fields to all its hi-entries, then all the hi-entries in the response the biloxi.example.com domain are sent in the final response nor are
would be anonymous. they sent in the request as it is forwared to Bob's Home domain.
Alice atlanta.example.com biloxi.example.com Bob Alice atlanta.example.com biloxi.example.com Bob Work Bob Home
| | | | | | | | |
| INVITE F1 | | | | INVITE F1 | | | |
|--------------->| | | |------------>| | | |
| | | | | | | | |
| | INVITE F2 | | | | INVITE F2 | | |
| |--------------->| | | |--------------->| | |
| | | | | | | | |
| | | INVITE F3 | | | | INVITE F3 | |
| | |--------------->| | | |---------------->| |
| | | | | | |302 Move Temporarily F4 |
| | | 200 F4 | | | |<----------------| |
| | |<---------------| | | | | |
| | | | | | | INVITE F5 | |
| | 200 F5 | | | | |--------------------------->|
| |<---------------| | | | | 200 F6 | |
| | | | | | |<---------------------------|
| 200 F6 | | | | | | | |
|<---------------| | | | | 200 F7 | | |
| | | | | |<---------------| | |
| | ACK | | | | | | |
|------------------------------------------------->| | 200 F8 | | | |
| | | | |<------------| | | |
| | | | |
| | ACK | | |
|---------------------------------------------------------->|
| | | | |
Figure 2: Example with Privacy Header Fields Figure 2: Example with Privacy Header Fields
Message Details Message Details
F1 INVITE alice -> atlanta.example.com F1 INVITE alice -> atlanta.example.com
INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
Max-Forward: 70 Max-Forward: 70
skipping to change at page 12, line 35 skipping to change at page 12, line 35
INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 INVITE sip:bob@biloxi.example.com;p=x SIP/2.0
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
Max-Forward: 69 Max-Forward: 69
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid>;index=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
Contact: Alice <sip:alice@192.0.2.3> Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F3 INVITE biloxi.example.com -> Bob F3 INVITE biloxi.example.com -> Bob Work
INVITE sip:bob@192.0.1.11 SIP/2.0 INVITE sip:bob@192.0.1.11 SIP/2.0
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs33
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\
received=192.0.2.3 received=192.0.2.3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
Max-Forward: 68 Max-Forward: 68
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
Privacy: history
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid>;index=1 History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
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:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1 History-Info: <sip:bob@192.0.1.11>;index=1.1.1;rc=1.1
Contact: Alice <sip:alice@192.0.2.3> Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F4 302 Moved Temporarily Bob Work -> biloxi.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs33;\
received=192.0.2.102
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\
received=192.0.2.3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
Max-Forward: 68
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Privacy: history
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1
History-Info: <sip:bob@192.0.1.11>;index=1.1.1;rc=1.1
Contact: <sip:home@example.com>;mp=1.1
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F5 INVITE biloxi.example.com -> Bob Home
<!-- Leaving biloxi.example.com thus entries are
anonymized and Privacy: history header removed -->
INVITE sip:bob@192.0.1.15 SIP/2.0
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\
received=192.0.2.3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
Max-Forward: 68
From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>
Supported: histinfo
Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid;p=x>;index=1
History-Info: <sip:anonymous@anonymous.invalid;p=x>;index=1.1
History-Info: <sip:anonymous@anonymous.invalid?\
Reason=SIP%3Bcause%3D302>;index=1.1.1;rc=1.1
History-Info: <sip:home@example.com>;index=1.2;mp=1.1
Contact: Alice <sip:alice@192.0.2.3>
Content-Type: application/sdp
Content-Length: <appropriate value>
<!-- SDP Not Shown -->
F4 200 OK Bob -> biloxi.example.com F4 200 OK Bob -> biloxi.example.com
<!-- additional hi-entry in the response reflects internal
retargeting at home@example.com -->
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32;\ Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32;\
received=192.0.2.101 received=192.0.2.101
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\
received=192.0.2.3 received=192.0.2.3
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid>;index=1 History-Info: <sip:anonymous@anonymous.invalid;p=x>;index=1
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 History-Info: <sip:anonymous@anonymous.invalid;p=x>;index=1.1
History-Info: <sip:bob@192.0.1.11?Privacy=history>;index=1.1.1;rc=1.1 History-Info: <sip:anonymous@anonymous.invalid?\
Contact: Bob <sip:bob@192.0.1.11> Reason=SIP%3Bcause%3D302>;index=1.1.1;rc=1.1
History-Info: <sip:home@example.com>;index=1.2;mp=1.1
History-Info: <sip:bob@192.0.1.15>;index=1.2.1;rc=1.2
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F5 200 OK biloxi.example.com -> atlanta.example.com F5 200 OK biloxi.example.com -> atlanta.example.com
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\
received=192.0.2.101 received=192.0.2.101
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Privacy: history
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid>;index=1 History-Info: <sip:anonymous@anonymous.invalid>;index=1
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 History-Info: <sip:anonymous@anonymous.invalid>;index=1.1
History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1 History-Info: <sip:anonymous@anonymous.invalid?\
Contact: Bob <sip:bob@192.0.1.11> Reason=SIP%3Bcause%3D302>;index=1.1.1;rc=1.1
History-Info: <sip:home@example.com>;index=1.2;mp=1.1
History-Info: <sip:bob@192.0.1.15>;index=1.2.1;rc=1.2
Contact: Bob <sip:bob@192.0.1.15>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
F6 200 OK atlanta.example.com -> Alice F6 200 OK atlanta.example.com -> Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321
From: Alice <sip:alice@atlanta.example.com>;tag=22 From: Alice <sip:alice@atlanta.example.com>;tag=22
To: Bob <sip:bob@biloxi.example.com>;tag=33 To: Bob <sip:bob@biloxi.example.com>;tag=33
Supported: histinfo Supported: histinfo
Call-Id: 12345600@atlanta.example.com Call-Id: 12345600@atlanta.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
History-Info: <sip:anonymous@anonymous.invalid>;index=1 History-Info: <sip:anonymous@anonymous.invalid>;index=1
History-Info: <sip:bob@biloxi.example.com;p=x>;index=1.1 History-Info: <sip:anonymous@anonymous.invalid>;index=1.1
History-Info: <sip:anonymous@anonymous.invalid>;index=1.1.1;rc=1.1 History-Info: <sip:anonymous@anonymous.invalid?\
Contact: Bob <sip:bob@192.0.1.11> Reason=SIP%3Bcause%3D302>;index=1.1.1;rc=1.1
History-Info: <sip:home@example.com>;index=1.2;mp=1.1
History-Info: <sip:bob@192.0.1.15>;index=1.2.1;rc=1.2
Contact: Bob <sip:bob@192.0.1.15>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: <appropriate value> Content-Length: <appropriate value>
<!-- SDP Not Shown --> <!-- SDP Not Shown -->
3.3. Privacy for a Specific History-Info Entry 3.3. Privacy for a Specific History-Info Entry
This example provides a basic call scenario similar to Section 3.2, This example provides a basic call scenario similar to Section 3.2,
however, due to local policy at sip:biloxi.example.com, only the however, due to local policy at sip:biloxi.example.com, only the
final hi-entry in the History-Info, which is Bob's local URI, final hi-entry in the History-Info, which is Bob's local URI,
contains a privacy header field with a priv-value of "history", thus contains a privacy header field with a priv-value of "history", thus
skipping to change at page 26, line 34 skipping to change at page 28, line 34
the request. The original target is determined by finding the first the request. The original target is determined by finding the first
hi-entry tagged with "rc" or "mp" and using the hi-entry referenced hi-entry tagged with "rc" or "mp" and using the hi-entry referenced
by the index of "rc" or "mp" header field parameter as the target for by the index of "rc" or "mp" header field parameter as the target for
determining the appropriate mailbox. This hi-entry is used to determining the appropriate mailbox. This hi-entry is used to
populate the "target" URI parameter as defined in [RFC4458]. The populate the "target" URI parameter as defined in [RFC4458]. The
reason associated with the first hi-entry tagged with "rc" or "mp" reason associated with the first hi-entry tagged with "rc" or "mp"
(i.e., 302) could be used to provide a customized voicemail greeting (i.e., 302) could be used to provide a customized voicemail greeting
and is used to populate the "cause" URI parameter as defined in and is used to populate the "cause" URI parameter as defined in
[RFC4458]. Note that some VMSs may also (or instead) use the [RFC4458]. Note that some VMSs may also (or instead) use the
information available in the History-Info headers for custom handling information available in the History-Info headers for custom handling
of the VM in terms of how and why the call arrived at the VMS. of the VM based on how and why the call arrived at the VMS.
Furthermore it is the proxy forwarding the call to VMS that Furthermore it is the proxy forwarding the call to VMS that
determines the target of the voicemail, it is the proxy that sets the determines the target of the voicemail, it is the proxy that sets the
target of voicemail which is also the entity that utilizes RFC4244bis target of voicemail which is also the entity that utilizes
to find the target which is usually based on local policy installed [I-D.ietf-sipcore-rfc4244bis] to find the target which is usually
by the user or an administrator. based on local policy installed by the user or an administrator.
Alice example.com Bob Carol VM Alice example.com Bob Carol VM
| INVITE F1 | | | | | INVITE F1 | | | |
|------------->| | | | |------------->| | | |
| | INVITE F2 | | | | | INVITE F2 | | |
| |------------->| | | | |------------->| | |
| | | | | | | | | |
| 100 Trying | | | | | 100 Trying | | | |
|<-------------| 302 Moved Temporarily F3 | | |<-------------| 302 Moved Temporarily F3 | |
skipping to change at page 41, line 22 skipping to change at page 43, line 22
[RFC3087], control of network announcements and IVR with SIP URI [RFC3087], control of network announcements and IVR with SIP URI
[RFC4240], and control of voicemail access with SIP URI [RFC4458]. [RFC4240], and control of voicemail access with SIP URI [RFC4458].
A common problem with all of these mechanisms is that once a proxy 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 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 cannot be sure that the Request-URI will not be destroyed by a
downstream proxy which decides to forward the request in some way, downstream proxy which decides to forward the request in some way,
and does so by rewriting the Request-URI. and does so by rewriting the Request-URI.
Section on voicemail (Section 3.6) shows how History-Info can be used Section on voicemail (Section 3.6) shows how History-Info can be used
to invocate a service. to invoke a service.
3.11. Toll Free Number 3.11. Toll Free Number
Toll free numbers, also known as 800 or 8xx numbers in the United Toll free numbers, also known as 800 or 8xx numbers in the United
States, are telephone numbers that are free for users to call. States, are telephone numbers that are free for users to call.
In the telephone network, toll free numbers are just aliases to In the telephone network, toll free numbers are just aliases to
actual numbers which are used for routing of the call. In order 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 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 protocol called TCAP), which will return either a phone number or the
identity of a carrier which can handle the call. identity of a carrier which can handle the call.
There has been recent work on allowing such PSTN translation services There has been recent work on allowing such PSTN translation services
to be accessed by SIP proxy servers through IP querying mechanisms. to be accessed by SIP proxy servers through IP querying mechanisms.
ENUM, for example [RFC6117] has already been proposed as a mechanism ENUM, for example [RFC6117] has already been proposed as a mechanism
for performing Local Number Portability (LNP) queries [RFC4769], and for performing Local Number Portability (LNP) queries [RFC4769].
recently been proposed for performing calling name queries Using it for 8xx number translations is a logical next-step.
[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 The new target from translating the 8xx number may be in PSTN or in
routed towards the target of the request. Normally, this would SIP network. If the new target is an entity in the PSTN network, the
happen by selecting a PSTN gateway which is a good route towards the proper treatment in the PSTN (and in particular, correct
translated number. However, one can imagine all-IP systems where the reconciliation of billing records) requires that the call be marked
8xx numbers are SIP endpoints on an IP network, in which case the with both the originating number (8xx number) and the new target
translation of the 8xx number would actually be a SIP URI and not a number, History-info could be used here to ensure original 8xx number
phone number. Assuming for the moment it is a PSTN connected entity, is not lost.
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.
History-info would come in play here to assure original 8xx number is
not lost.
Furthermore, even if the translation of the 8xx number was a SIP URI, Although not required to have both the originating number (8xx
the enterprise or user who utilize the 8xx service would like to know number) and the new target in the SIP network, an enterprise or a
whether the call came in via 8xx number in order to treat the call user that utilizes the 8xx service can benefit by knowing whether the
differently (for example to play a special announcement..) but if the call came in via an 8xx number in order to treat the call differently
original R-URI is lost through translation, there is no way to tell (e.g., to play a special announcement). However, if the original
if the call came in via 8xx number. R-URI is lost through translation, there is no way to tell if the
call came in via 8xx number. History-info again could be used here.
Similar problems arise with other "special" numbers and services used Similar problems arise with other "special" numbers and services used
in the PSTN, such as operator services, pay/premium numbers (9xx in the PSTN, such as operator services, pay/premium numbers (9xx
numbers in the U.S), and short service codes such as 311. numbers in the U.S), and short service codes such as 311.
To find the service number, the UAS can extract the hi-entry whose To find the service number, the UAS can extract the hi-entry whose
index matches the value of the first hi-entry with an "mp" tag. index matches the value of the first hi-entry with an "mp" tag.
Technically the call can be forwarded to these "special" numbers from Technically the call can be forwarded to these "special" numbers from
non "special" numbers, however that is uncommon based on the way non "special" numbers, however that is uncommon based on the way
these services authorize translations. these services authorize translations.
skipping to change at page 45, line 11 skipping to change at page 46, line 49
April 2006. April 2006.
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA Registration of Enumservices: Guide, Template, and IANA
Considerations", RFC 6117, March 2011. Considerations", RFC 6117, March 2011.
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network Enumservice Containing Public Switched Telephone Network
(PSTN) Signaling Information", RFC 4769, November 2006. (PSTN) Signaling Information", RFC 4769, November 2006.
[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.
[I-D.ietf-sipcore-rfc4244bis] [I-D.ietf-sipcore-rfc4244bis]
Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
Holmberg, "An Extension to the Session Initiation Protocol Holmberg, "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", (SIP) for Request History Information",
draft-ietf-sipcore-rfc4244bis-11 (work in progress), draft-ietf-sipcore-rfc4244bis-11 (work in progress),
January 2013. January 2013.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
 End of changes. 30 change blocks. 
104 lines changed or deleted 152 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/