From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7131.txt | 2915 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2915 insertions(+) create mode 100644 doc/rfc/rfc7131.txt (limited to 'doc/rfc/rfc7131.txt') diff --git a/doc/rfc/rfc7131.txt b/doc/rfc/rfc7131.txt new file mode 100644 index 0000000..51cd77b --- /dev/null +++ b/doc/rfc/rfc7131.txt @@ -0,0 +1,2915 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Barnes +Request for Comments: 7131 +Category: Informational F. Audet +ISSN: 2070-1721 Skype + S. Schubert + NTT + H. van Elburg + Detecon International Gmbh + C. Holmberg + Ericsson + March 2014 + + +Session Initiation Protocol (SIP) History-Info Header Call Flow Examples + +Abstract + + This document describes use cases and documents call flows that + require the History-Info header field to capture the Request-URIs as + a Session Initiation Protocol (SIP) Request is retargeted. The use + cases are described along with the corresponding call flow diagrams + and messaging details. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7131. + + + + + + + + + + + + + +Barnes, et al. Informational [Page 1] + +RFC 7131 History-Info Call Flows March 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Overview ........................................................2 + 2. Conventions and Terminology .....................................3 + 3. Detailed Call Flows .............................................3 + 3.1. Sequentially Forking (History-Info in Response) ............3 + 3.2. History-Info with Privacy Header Field ....................11 + 3.3. Privacy for a Specific History-Info Entry .................16 + 3.4. Automatic Call Distribution ...............................20 + 3.5. Determining the Alias Used ................................27 + 3.6. PBX Voicemail Example .....................................29 + 3.7. Consumer Voicemail Example ................................35 + 3.8. GRUU ......................................................41 + 3.9. Limited-Use Address .......................................44 + 3.10. Service Invocation .......................................47 + 3.11. Toll-Free Number .........................................48 + 4. Security Considerations ........................................51 + 5. Acknowledgements ...............................................51 + 6. Informative References .........................................51 + +1. Overview + + Many services that use SIP require the ability to determine why and + how the call arrived at a specific application. The use cases + provided in this document illustrate the use of the History-Info + header [RFC7044], for example, applications and common scenarios. + The optional "rc" and "mp" header field parameters defined in + [RFC7044] are required for several of the use cases. Descriptions of + the example use cases, call flow diagrams, and messaging details are + provided. + + + + + + +Barnes, et al. Informational [Page 2] + +RFC 7131 History-Info Call Flows March 2014 + + +2. Conventions and Terminology + + The term "retarget" is used as defined in [RFC7044]. The terms + "location service", "redirect", and "address-of-record (AOR)" are + used consistent with the terminology in [RFC3261]. + +3. Detailed Call Flows + + The scenarios in this section provide sample use cases for the + History-Info header for informational purposes only. They are not + intended to be normative. In many cases, only the relevant messaging + details are included in the body of the call flow. + +3.1. Sequentially Forking (History-Info in Response) + + This scenario highlights an example where the History-Info in the + response is useful to an application or user that originated the + request. + + Alice sends a call to Bob via sip:example.com. The proxy + sip:example.com sequentially tries Bob on a SIP User Agent (UA) that + has bound a contact with the sip:bob@example.com AOR, and then + several alternate addresses (Office and Home) unsuccessfully before + sending a response 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 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 been configured as alternate addresses for Bob in the + proxy. In other words, Office and Home are not bound through SIP + Registration with Bob's AOR. This type of arrangement is common, for + example, when a "routing" rule to a Public Switched Telephone Network + (PSTN) number is manually configured in a proxy. These hi-entries + are identified by the index contained in the hi-target-param "mp" + header field parameter in the hi-entries. + + This scenario illustrates that by providing the History-Info to + Alice, the end-user, or an application at Alice could make a decision + on how best to attempt finding Bob without sending multiple requests + to the same destination. Upon receipt of the response containing the + History-Info entries, the Request-URIs for the History-Info entries + tagged with an "mp" header field parameter are extracted. Those + Request-URIs can be compared to other URIs (if any) that might be + attempted in order to establish the session with Bob. This results + in avoiding the sending of another INVITE to Bob's home phone. + Without this mechanism, Alice might well attempt to reach Bob at his + office phone, which would then retarget the request to Bob's home + phone. When that attempt failed, then Alice might attempt to reach + Bob directly at his home phone, unknowingly for a third time. + + + +Barnes, et al. Informational [Page 3] + +RFC 7131 History-Info Call Flows March 2014 + + + Alice example.com Bob Office Home + + | | | | | + | INVITE F1 | | | | + |----------->| INVITE F2 | | | + | |----------------->| | | + | 100 Trying F3 | | | + |<-----------| 302 Move Temporarily F4 | | + | |<-----------------| | | + | | ACK F5 | | | + | |----------------->| | | + | | INVITE F6 | | + | |-------------------------->| | + | | 180 Ringing F7 | | + | |<--------------------------| | + | 180 Ringing F8 | | + |<-----------| retransmit INVITE | | + | |-------------------------->| | + | | ( timeout ) | | + | | INVITE F9 | + | |----------------------------------->| + | | 100 Trying F10 | + | |<-----------------------------------| + | | 486 Busy Here F11 | + | |<-----------------------------------| + | 486 Busy Here F12 | + |<-----------| ACK F13 | + | |----------------------------------->| + | ACK F14 | | + |----------->| | + + Figure 1: Example with Sequential Forking + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 4] + +RFC 7131 History-Info Call Flows March 2014 + + + Message Details + + F1 INVITE Alice -> example.com + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 70 + From: Alice ;tag=sr3dds + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F2 INVITE example.com -> Bob + + INVITE sip:bob@192.0.2.4 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 69 + From: Alice ;tag=sr3dds + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + Record-Route: + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + +Barnes, et al. Informational [Page 5] + +RFC 7131 History-Info Call Flows March 2014 + + + F3 100 Trying example.com -> Alice + + SIP/2.0 100 Trying + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + Content-Length: 0 + + + F4 302 Moved Temporarily Bob -> example.com + + SIP/2.0 302 Moved Temporarily + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob ;tag=es43sd + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: ;mp=1 + Content-Length: 0 + + + F5 ACK example.com -> Bob + + ACK sip:bob@example.com SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx3st + Max-Forwards: 70 + From: Alice ;tag=sr3dds + To: Bob ;tag=es43sd + Call-ID: 12345600@example.com + CSeq: 1 ACK + Content-Length: 0 + + + + + + + + + + + + + +Barnes, et al. Informational [Page 6] + +RFC 7131 History-Info Call Flows March 2014 + + + F6 INVITE example.com -> office + + INVITE sip:office@192.0.2.5 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx4st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 69 + From: Alice ;tag=sr3dds + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + Record-Route: + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + CSeq: 1 INVITE + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F7 180 Ringing office -> example.com + + SIP/2.0 180 Ringing + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx4st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob ;tag=53rdds + Supported: histinfo + Call-ID: 12345600@example.com + Record-Route: + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + CSeq: 1 INVITE + Contact: Office + Content-Length: 0 + + + + + + + + + +Barnes, et al. Informational [Page 7] + +RFC 7131 History-Info Call Flows March 2014 + + + F8 180 Ringing example.com -> Alice + + SIP/2.0 180 Ringing + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob ;tag=53rdds + Supported: histinfo + Call-ID: 12345600@example.com + Record-Route: + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + CSeq: 1 INVITE + Contact: Office + Content-Length: 0 + + + F9 INVITE example.com -> home + + INVITE sip:home@192.0.2.6 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx5st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 69 + From: Alice ;tag=sr3dds + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + Record-Route: + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;\ + index=1.2;mp=1 + History-Info: ;\ + index=1.2.1;rc=1.2 + History-Info: ;index=1.3;mp=1 + History-Info: ;index=1.3.1;rc=1.3 + CSeq: 1 INVITE + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + +Barnes, et al. Informational [Page 8] + +RFC 7131 History-Info Call Flows March 2014 + + + F10 100 Trying home -> example.com + + SIP/2.0 100 Trying + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx5st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob + Call-ID: 12345600@example.com + CSeq: 1 INVITE + Content-Length: 0 + + + F11 486 Busy Here home -> example.com + + SIP/2.0 486 Busy Here + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx5st + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob ;tag=55rdds + Call-ID: 12345600@example.com + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;\ + index=1.2;mp=1 + History-Info: ;\ + index=1.2.1;rc=1.2 + History-Info: ;index=1.3;mp=1 + History-Info: ;index=1.3.1;rc=1.3 + CSeq: 1 INVITE + Content-Length: 0 + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 9] + +RFC 7131 History-Info Call Flows March 2014 + + + F12 486 Busy Here example.com -> Alice + + SIP/2.0 486 Busy Here + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=sr3dds + To: Bob ;tag=55rdds + Call-ID: 12345600@example.com + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;\ + index=1.2;mp=1 + History-Info: ;\ + index=1.2.1;rc=1.2 + History-Info: ;index=1.3;mp=1 + History-Info: ;index=1.3.1;rc=1.3 + CSeq: 1 INVITE + Content-Length: 0 + + + F13 ACK example.com -> home + + ACK sip:home@192.0.2.6 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKx5st + Max-Forwards: 70 + From: Alice ;tag=sr3dds + To: Bob ;tag=55rdds + Call-ID: 12345600@example.com + CSeq: 1 ACK + Content-Length: 0 + + + F14 ACK Alice -> example.com + + ACK sip:bob@example.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 70 + From: Alice ;tag=sr3dds + To: Bob ;tag=55rdds + Call-ID: 12345600@example.com + Route: + CSeq: 1 ACK + Content-Length: 0 + + + + + + + + +Barnes, et al. Informational [Page 10] + +RFC 7131 History-Info Call Flows March 2014 + + +3.2. History-Info with Privacy Header Field + + This is an example of the use of the Privacy header field with a + value of "history" added by an intermediary. The intermediary + responsible for the biloxi.example.com domain adds a Privacy header + field with a value of "history" indicating that all the History-Info + header field information is anonymized outside the biloxi.example.com + domain. + + Alice atlanta.example.com biloxi.example.com Bob Work Bob Home + + | | | | | + | INVITE F1 | | | | + |------------>| | | | + | | | | | + | | INVITE F2 | | | + | |--------------->| | | + | | | | | + | | | INVITE F3 | | + | | |---------------->| | + | | |302 Move Temporarily F4 | + | | |<----------------| | + | | | ACK F5 | | + | | |---------------->| | + | | | | | + | | | INVITE F6 | | + | | |--------------------------->| + | | | 200 F7 | | + | | |<---------------------------| + | | | | | + | | 200 F8 | | | + | |<---------------| | | + | | | | | + | 200 F9 | | | | + |<------------| | | | + | | | | | + | | ACK | | | + |---------------------------------------------------------->| + | | | | | + + Figure 2: Example with Privacy Header Fields + + + + + + + + + + +Barnes, et al. Informational [Page 11] + +RFC 7131 History-Info Call Flows March 2014 + + + Message Details + + F1 INVITE Alice -> atlanta.example.com + + INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 70 + From: Alice ;tag=22 + To: Bob + Supported: histinfo + Privacy: history + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F2 INVITE atlanta.example.com -> biloxi.example.com + + 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 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 69 + From: Alice ;tag=22 + To: Bob + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + +Barnes, et al. Informational [Page 12] + +RFC 7131 History-Info Call Flows March 2014 + + + F3 INVITE biloxi.example.com -> Bob Work + + INVITE sip:bob@192.0.1.11 SIP/2.0 + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs33 + 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-Forwards: 68 + From: Alice ;tag=22 + To: Bob + Privacy: history + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [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 + From: Alice ;tag=22 + To: Bob ;tag=11 + Privacy: history + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: Bob Home + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + +Barnes, et al. Informational [Page 13] + +RFC 7131 History-Info Call Flows March 2014 + + + F5 ACK biloxi.example.com -> Bob Work + + ACK sip:bob@192.0.1.11 SIP/2.0 + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs33 + 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-Forwards: 68 + From: Alice ;tag=22 + To: Bob ;tag=11 + Call-ID: 12345600@atlanta.example.com + CSeq: 1 ACK + Content-Length: + + [SDP Not Shown] + + + F6 INVITE biloxi.example.com -> Bob Home + + 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-Forwards: 68 + From: Alice ;tag=22 + To: Bob + Privacy: history + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;\ + index=1.1.1;rc=1 + History-Info: ;index=1.1.2 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + +Barnes, et al. Informational [Page 14] + +RFC 7131 History-Info Call Flows March 2014 + + + F7 200 OK Bob -> biloxi.example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKgs32;\ + received=192.0.2.101 + 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 + From: Alice ;tag=22 + To: Bob ;tag=33 + Privacy: history + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;\ + index=1.1.1;rc=1 + History-Info: ;index=1.1.2;rc=1.1 + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F8 200 OK biloxi.example.com -> atlanta.example.com + + SIP/2.0 200 OK + 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 + From: Alice ;tag=22 + To: Bob ;tag=33 + Privacy: history + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1 + History-Info: ;index=1.1.2;rc=1.1 + Contact: Bob + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + +Barnes, et al. Informational [Page 15] + +RFC 7131 History-Info Call Flows March 2014 + + + F9 200 OK atlanta.example.com -> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=22 + To: Bob ;tag=33 + Privacy: history + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1 + History-Info: ;index=1.1.1;rc=1 + History-Info: ;index=1.1.2;rc=1.1 + Contact: Bob + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + +3.3. Privacy for a Specific History-Info Entry + + This example provides a basic call scenario similar to Section 3.2; + 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, + contains a privacy header field with a priv-value of "history", thus + providing Alice with some information about the history of the + request, but anonymizing Bob's local URI. + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 16] + +RFC 7131 History-Info Call Flows March 2014 + + + Alice atlanta.example.com biloxi.example.com Bob + | | | | + | INVITE F1 | | | + |--------------->| | | + | | | | + | | INVITE F2 | | + | |--------------->| | + | | | | + | | | INVITE F3 | + | | |--------------->| + | | | | + | | | 200 F4 | + | | |<---------------| + | | | | + | | 200 F5 | | + | |<---------------| | + | | | | + | 200 F6 | | | + |<---------------| | | + | | | | + | | ACK | | + |------------------------------------------------->| + | | | | + + Figure 3: Example with Privacy Header Field for Specific URI + + + Message Details + + F1 INVITE Alice -> atlanta.example.com + + INVITE sip:bob@biloxi.example.com;p=x SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 70 + From: Alice ;tag=22 + To: Bob + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + +Barnes, et al. Informational [Page 17] + +RFC 7131 History-Info Call Flows March 2014 + + + F2 INVITE atlanta.example.com -> biloxi.example.com + + 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 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 69 + From: Alice ;tag=22 + To: Bob + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;np=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F3 INVITE biloxi.example.com -> Bob + + INVITE sip:bob@192.0.1.11 SIP/2.0 + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset + Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + Max-Forwards: 68 + From: Alice ;tag=22 + To: Bob + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;np=1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + +Barnes, et al. Informational [Page 18] + +RFC 7131 History-Info Call Flows March 2014 + + + F4 200 OK Bob -> biloxi.example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKeset;\ + received=192.0.2.5 + Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=22 + To: Bob ;tag=33 + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;np=1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: Bob + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F5 200 OK biloxi.example.com -> atlanta.example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=22 + To: Bob ;tag=33 + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;np=1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: Bob + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + +Barnes, et al. Informational [Page 19] + +RFC 7131 History-Info Call Flows March 2014 + + + F6 200 OK atlanta.example.com -> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 + From: Alice ;tag=22 + To: Bob ;tag=33 + Supported: histinfo + Call-ID: 12345600@atlanta.example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;np=1 + History-Info: ;index=1.1.1;rc=1.1 + Contact: Bob + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + +3.4. 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 by extracting the hi-entry associated with the incoming + request, which is determined by locating the hi-entry whose index is + reflected in the first hi-entry with a hi-target of "mp". In the + example, this would be the hi-entry referenced by the value of the + first "mp" header field parameter, i.e., the hi-entry containing an + index of "1". An application can also determine how many groups from + which the call may have overflowed before reaching the agent, etc., + and present the information to the agent so that the call can be + handled appropriately, i.e., "I'm so sorry for the delay, blah, blah, + blah..." + + 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 or the proxy could anonymize the Silver related + hi-entries by adding privacy in the Silver hi-entries. + + + + +Barnes, et al. Informational [Page 20] + +RFC 7131 History-Info Call Flows March 2014 + + + As with the other examples, this is not a complete prescription 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 does not address any aspects of agent + availability resulting in the call being sent to an agent in another + group, which might also be done via a SIP interface. + + Alice example.com Gold Silver Agent + + | | | | | + | INVITE F1 | | | | + |------------->| | | | + | | | | | + | | INVITE F2 | | | + | |------------->| | | + | | | | | + | | 302 Moved Temporarily F3 | | + | |<-------------| | | + | | | | | + | | ACK | | | + | |------------->| | | + | | | | | + | | INVITE F4 | | | + | |--------------------------->| | + | | | | | + | | | | INVITE F5 | + | | | |----------->| + | | | | | + | | | | 200 OK F6 | + | | | |<-----------| + | | | | | + | | 200 OK F7 | | + | |<---------------------------| | + | | | | | + | 200 OK F8 | | | | + |<-------------| | | | + | | | | | + | ACK F9 | + |------------------------------------------------------->| + + Figure 4: Example for Automatic Call Distribution + + + + + + + + + + +Barnes, et al. Informational [Page 21] + +RFC 7131 History-Info Call Flows March 2014 + + + Message Details + + F1 INVITE Alice -> example.com + + INVITE sip:Gold@example.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 70 + From: Alice ;tag=1235 + To: Gold Member Assistance + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F2 INVITE example.com -> Gold.example.com + + INVITE sip:Gold@gold.example.com SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=1235 + To: Gold Member Assistance + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;rc=1;index=1.1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + +Barnes, et al. Informational [Page 22] + +RFC 7131 History-Info Call Flows March 2014 + + + F3 302 Moved Temporarily Gold.example.com -> example.com + + SIP/2.0 302 Moved Temporarily + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=1235 + To: Gold Member Assistance ;tag=kkaz- + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;rc=1;index=1.1 + Contact: ;mp=1 + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F4 INVITE example.com -> Silver.example.com + + INVITE sip:Silver@example.com SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK45q2 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=1235 + To: Gold Member Assistance + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + rc=1;index=1.1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + +Barnes, et al. Informational [Page 23] + +RFC 7131 History-Info Call Flows March 2014 + + + F5 INVITE Silver.example.com -> Agent + + INVITE sip:Silver@192.0.2.7 SIP/2.0 + Via: SIP/2.0/TCP silver.example.com:5060;branch=z9hG4bKerxs + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK45q2;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 68 + From: Alice ;tag=1235 + To: Gold Member Assistance + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + rc=1;index=1.1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2.1.1;rc=1.2.1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 24] + +RFC 7131 History-Info Call Flows March 2014 + + + F6 200 OK Agent -> Silver.example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP silver.example.com:5060;branch=z9hG4bKerxs;\ + received=192.0.2.5 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK45q2;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=1235 + To: Gold Member Assistance ;tag=2325 + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + rc=1;index=1.1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2.1.1;rc=1.2.1 + Contact: Agent + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F7 200 OK Silver.example.com -> example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK45q2;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=1235 + To: Gold Member Assistance ;tag=2325 + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + rc=1;index=1.1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2.1.1;rc=1.2.1 + Contact: Agent + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + +Barnes, et al. Informational [Page 25] + +RFC 7131 History-Info Call Flows March 2014 + + + F8 200 OK example.com -> Alice + + SIP/2.0 200 OK + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=1235 + To: Gold Member Assistance ;tag=2325 + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + rc=1;index=1.1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;index=1.2.1.1;rc=1.2.1 + Contact: Agent + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F9 ACK Alice -> Agent + + ACK sip:Silver@192.0.2.7 SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t3 + Max-Forwards: 70 + From: Alice ;tag=1235 + To: Gold Member Assistance ;tag=2325 + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 ACK + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + The first hi-entry with the "mp" header field parameter contains an + "mp" header field parameter value of 1, which points to the original- + target, which allows the operator to identify that the call was from + the Gold customer. + + + + + + + + + +Barnes, et al. Informational [Page 26] + +RFC 7131 History-Info Call Flows March 2014 + + +3.5. Determining the Alias Used + + SIP UAs are associated with an AOR. It is possible for a single UA + to actually have multiple AORs 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 IP Multimedia Subsystem (IMS), where it is + called "implicit registration" and each alias is called a "public + user identity (PUID)". + + It is a common requirement for a User Agent Server (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. + + The following call flow and example messages show how History-Info + can be used to find out the alias used to reach the callee. The + alias for the call is determined by hi-entry with the index that + matches the value of the last hi-entry with an "rc" header field + parameter in the Request received. + + Alice example.com John + | | REGISTER F1 | + | |<--------------------| + | | 200 OK F2 | + | |-------------------->| + | INVITE F3 | | + |-------------------->| | + | | INVITE F4 | + | |-------------------->| + * Rest of flow not shown * + + Figure 5: Alias Example + + + + + + + + + + + +Barnes, et al. Informational [Page 27] + +RFC 7131 History-Info Call Flows March 2014 + + + Message Details + + F1 REGISTER John -> example.com + + REGISTER sip:example.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bKnashds7 + Max-Forwards: 70 + From: John ;tag=a73kszlfl + To: John + Supported: histinfo + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: + Content-Length: 0 + + + F2 200 OK example.com -> John + + SIP/2.0 200 OK + Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bKnashds7 + From: John ;tag=a73kszlfl + To: John ;tag=d2dstee2 + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: ;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=z9hG4bK42t2 + Max-Forwards: 70 + From: Alice ;tag=a73kszlfl + To: John + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + +Barnes, et al. Informational [Page 28] + +RFC 7131 History-Info Call Flows March 2014 + + + 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=z9hG4bK12s4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=a73kszlfl + To: John + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + Record-Route: + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + The last hi-entry with the "rc" header field parameter references the + source of retargeting pointing at the alias AOR, which in the example + is "john.smith@example.com". + +3.6. PBX Voicemail Example + + A typical use case for voicemail is one whereby the original called + party is not reachable and the call arrives at a voicemail system. + In some cases, multiple alternate destinations may be tried without + success. The voicemail system typically requires the original called + party information to determine the appropriate mailbox so an + appropriate greeting can be provided and the appropriate party + notified of the message. + + In this example, Alice calls Bob, whose SIP client is forwarded to + Carol. Carol does not answer the call; thus, it is forwarded to a VM + (voicemail) server (VMS). In order to determine the appropriate + mailbox to use for this call, the VMS needs the original target for + the request. The original target is determined by finding the first + 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 + determining the appropriate mailbox. This hi-entry is used to + populate the "target" URI parameter as defined in [RFC4458]. The + reason associated with the first hi-entry tagged with "rc" or "mp" + (i.e., 302) could be used to provide a customized voicemail greeting + and is used to populate the "cause" URI parameter as defined in + [RFC4458]. Note that some VMSs may also (or instead) use the + + + + +Barnes, et al. Informational [Page 29] + +RFC 7131 History-Info Call Flows March 2014 + + + information available in the History-Info headers for custom handling + of the VM based on how and why the call arrived at the VMS. + + Furthermore, it is the proxy forwarding the call to the VMS that + determines the target of the voicemail; it is the proxy that sets the + target of voicemail, which is also the entity that utilizes [RFC7044] + to find the target that is usually based on local policy installed by + the user or an administrator. + + Alice example.com Bob Carol VM + + | INVITE F1 | | | | + |------------->| | | | + | | INVITE F2 | | | + | |------------->| | | + | | | | | + | 100 Trying | | | | + |<-------------| 302 Moved Temporarily F3 | | + | |<-------------| | | + | | | | | + | | ACK | | | + | |------------->| | | + | | | | | + | | INVITE F4 | | | + | |--------------------------->| | + | | | | | + | | 180 Ringing F5 | | + | |<---------------------------| | + | | | | | + | 180 Ringing | | | | + |<-------------| | | | + | | | | | + | | (timeout) | | + | | | | | + | | INVITE F6 | | | + | |-------------------------------------->| + | | | | | + | | 200 OK F7 | + | |<--------------------------------------| + | 200 OK | | | | + |<-------------| | | | + | | | | | + | ACK | + |----------------------------------------------------->| + + Figure 6: Enterprise Voicemail Example + + + + + +Barnes, et al. Informational [Page 30] + +RFC 7131 History-Info Call Flows March 2014 + + + Message Details + + F1 INVITE Alice -> example.com + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 70 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Length: + + [SDP Not Shown] + + + F2 INVITE example.com -> Bob + + INVITE sip:bob@192.0.2.5 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 31] + +RFC 7131 History-Info Call Flows March 2014 + + + F3 302 Moved Temporarily Bob -> example.com + + SIP/2.0 302 Moved Temporarily + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=kkaz- + To: Bob ;tag=2g22d-lnf + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: ;mp=1 + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F4 INVITE example.com -> Carol + + INVITE sip:carol@192.0.2.4 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4522 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + +Barnes, et al. Informational [Page 32] + +RFC 7131 History-Info Call Flows March 2014 + + + F5 180 Ringing Carol -> example.com + + SIP/2.0 180 Ringing + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4522;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=kkaz- + To: Bob ;tag=setss3x + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 33] + +RFC 7131 History-Info Call Flows March 2014 + + + F6 INVITE example.com -> VM + + INVITE sip:vm@192.0.2.6;target=sip:bob%40example.com;cause=480\ + SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4523 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;\ + index=1.3;mp=1 + History-Info: ;\ + index=1.3.1;rc=1.3 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 34] + +RFC 7131 History-Info Call Flows March 2014 + + + F7 200 OK VM -> example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK4523;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=kkaz- + To: Bob ;tag=3dweggs + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + History-Info: ;\ + index=1.3;mp=1 + History-Info: ;\ + index=1.3.1;rc=1.3 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + The VMS can look at the last hi-entry and find the target of the + mailbox by looking at the URI entry in the "target" URI parameter in + the hi-entry. + +3.7. Consumer Voicemail Example + + In the case of a consumer, when the call is retargeted, it is usually + to another administrative domain. The voicemail system in these + environments typically requires the last-called-party information to + determine the appropriate mailbox so an appropriate greeting can be + provided and the appropriate party notified of the message. + + In this example, Alice calls Bob, but Bob has temporarily forwarded + his phone to Carol (she is his wife). Carol does not answer the + call; thus, it is forwarded to a VMS. In order to determine the + appropriate mailbox to use for this call, the VMS needs the + appropriate target for the request. The last target is determined by + finding the hi-entry referenced by the index of last hi-entry tagged + + + +Barnes, et al. Informational [Page 35] + +RFC 7131 History-Info Call Flows March 2014 + + + with "mp" for determining the appropriate mailbox. This hi-entry is + used to populate the "target" URI parameter as defined in [RFC4458]. + Note that some VMSs may also (or instead) use the information + available in the History-Info headers for custom handling of the VM + in terms of how and why the called arrived at the VMS. + + Alice example.com Bob Carol VM + + | INVITE F1 | | | | + |------------->| | | | + | | INVITE F2 | | | + | |------------->| | | + | | | | | + | 100 Trying | | | | + |<-------------| 302 Moved Temporarily F3 | | + | |<-------------| | | + | | | | | + | | ACK | | | + | |------------->| | | + | | | | | + | | INVITE F4 | | | + | |--------------------------->| | + | | | | | + | | 180 Ringing F5 | | + | |<---------------------------| | + | | | | | + | 180 Ringing | | | | + |<-------------| | | | + | | | | | + | | (timeout) | | + | | | | | + | | INVITE F6 | | | + | |-------------------------------------->| + | | | | | + | | 200 OK F7 | + | |<--------------------------------------| + | 200 OK | | | | + |<-------------| | | | + | | | | | + | ACK | + |----------------------------------------------------->| + + Figure 7: Consumer Voicemail Example + + + + + + + + +Barnes, et al. Informational [Page 36] + +RFC 7131 History-Info Call Flows March 2014 + + + Message Details + + F1 INVITE Alice -> example.com + + INVITE sip:bob@example.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 70 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Length: + + [SDP Not Shown] + + + F2 INVITE example.com -> Bob + + INVITE sip:bob@192.0.2.5 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 37] + +RFC 7131 History-Info Call Flows March 2014 + + + F3 302 Moved Temporarily Bob -> example.com + + SIP/2.0 302 Moved Temporarily + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK12s4;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=kkaz- + To: Bob ;tag=224ls3s-t + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: ;mp=1 + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F4 INVITE example.com -> Carol + + INVITE sip:carol@192.0.2.4 SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK24s5 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: \ + ;index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + +Barnes, et al. Informational [Page 38] + +RFC 7131 History-Info Call Flows March 2014 + + + F5 180 Ringing Carol -> example.com + + SIP/2.0 180 Ringing + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK24s5;\ + received=192.0.2.101 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=kkaz- + To: Bob ;tag=setss3x + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;index=1.2;mp=1 + History-Info: ;index=1.2.1;rc=1.2 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 39] + +RFC 7131 History-Info Call Flows March 2014 + + + F6 INVITE example.com -> VM + + INVITE sip:vm@192.0.2.6;target=sip:carol%40example.com SIP/2.0 + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: Bob + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;\ + index=1.2;mp=1 + History-Info: ;\ + index=1.2.1;rc=1.2 + History-Info: ;index=1.2.2;mp=1.2 + History-Info: ;index=1.2.2.1;rc=1.2.2 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 40] + +RFC 7131 History-Info Call Flows March 2014 + + + F7 200 OK VM -> example.com + + SIP/2.0 200 OK + Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + From: Alice ;tag=kkaz- + To: Bob ;tag=3dweggs + Supported: histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + History-Info: ;\ + index=1.1;rc=1 + History-Info: ;\ + index=1.2;mp=1 + History-Info: ;\ + index=1.2.1;rc=1.2 + History-Info: ;index=1.2.2;mp=1.2 + History-Info: ;index=1.2.2.1;rc=1.2.2 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + The VMS can look at the last hi-entry and find the target of the + mailbox by looking for the "target" URI parameter in the hi-entry and + the reason by the "cause" URI parameter in the same hi-entry. + +3.8. GRUU + + A variation on the problem in Section 3.5 occurs with Globally + Routable User Agent URI (GRUU) [RFC5627]. A GRUU is a URI assigned + to a UA instance that 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. + + + + + + + +Barnes, et al. Informational [Page 41] + +RFC 7131 History-Info Call Flows March 2014 + + + The following call flow and example messages show how History-Info + can be used to find out the GRUU used to reach the callee. + + While a GRUU is comprised of an AOR with a URI parameter, as defined + in [RFC5627], the GRUU construct itself is not an AOR. Thus, the + retargeting of a request based on a GRUU does not result in the + addition of an "rc" header field parameter to the hi-entry containing + the GRUU. The lack of an "rc" header field parameter in the hi- + entries can be a hint that the source of retargeting is a GRUU. + However, to ensure this is the case, the UAS needs to search for a + "gr" parameter in the hi-entry prior to the last hi-entry. If there + is a GRUU, the URI will always be prior to the last hi-entry as the + GRUU does not allow multiple instance to be mapped to a contact + address. + + Alice example.com John + | | REGISTER F1 | + | |<--------------------| + | | 200 OK F2 | + | |-------------------->| + | INVITE F3 | | + |-------------------->| | + | | INVITE F4 | + | |-------------------->| + * Rest of flow not shown * + + Figure 8: GRUU Example + + + Message Details + + 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 ;tag=a73kszlfl + Supported: gruu + To: John + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: ;+sip.instance=\ + + Content-Length: 0 + + [SDP Not Shown] + + + + + +Barnes, et al. Informational [Page 42] + +RFC 7131 History-Info Call Flows March 2014 + + + F2 200 OK example.com -> John + + SIP/2.0 200 OK + Via: SIP/2.0/TCP 192.0.2.1;branch=z9hG4bKnashds7 + From: John ;tag=a73kszlfl + To: John ;tag=b88sn + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: ;\ + 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=\ + "";\ + expires=3600 + Content-Length: 0 + + [SDP Not Shown] + + Assuming Alice has 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=z9hG4bK42t2 + Max-Forwards: 70 + From: Alice ;tag=kkaz- + To: + Supported: gruu, histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: ;index=1 + Contact: Alice + Content-Length: + + [SDP Not Shown] + + + + + + + + + +Barnes, et al. Informational [Page 43] + +RFC 7131 History-Info Call Flows March 2014 + + + 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=z9hG4bK12s4 + Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: + Supported: gruu, histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + Record-Route: + History-Info: ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + By analyzing the entry referenced by the entry with the last "rc", + one can realize that the URI used to reach the device was GRUU by + finding the "gr" parameter. + +3.9. 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) of remote correspondents. + 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. + + + + + +Barnes, et al. Informational [Page 44] + +RFC 7131 History-Info Call Flows March 2014 + + + 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, 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 for a "gr" tag in the hi-entry prior to the + last hi-entry. + + Alice example.com John + | | REGISTER F1 | + | |<--------------------| + | | 200 OK F2 | + | |-------------------->| + | INVITE F3 | | + |-------------------->| | + | | INVITE F4 | + | |-------------------->| + * Rest of flow not shown * + + Figure 9: Limited-Use Address Example + + + Message Details + + 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 ;tag=a73kszlfl + Supported: gruu + To: John + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: ;\ + +sip.instance="" + Content-Length: 0 + + + + + + + + + + +Barnes, et al. Informational [Page 45] + +RFC 7131 History-Info Call Flows March 2014 + + + F2 200 OK example.com -> John + + SIP/2.0 200 OK + Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7 + From: John ;tag=a73kszlfl + To: John ;tag=b88sn + Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1 + CSeq: 1 REGISTER + Contact: ;\ + 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="";\ + expires=3600 + Content-Length: 0 + + Assuming Alice has 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/UDP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 70 + From: Alice ;tag=kkaz- + To: + Supported: gruu, histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + History-Info: \ + \ + ;index=1 + Contact: Alice + Content-Length: + + + + + + + + + + + + + +Barnes, et al. Informational [Page 46] + +RFC 7131 History-Info Call Flows March 2014 + + + F4 INVITE example.com -> John + + INVITE sip:john@192.0.2.1 SIP/2.0 + Via: SIP/2.0/UDP proxy.example.com:5060;branch=z9hG4bK12s4 + Via: SIP/2.0/UDP 192.0.2.3:5060;branch=z9hG4bK42t2 + Max-Forwards: 69 + From: Alice ;tag=kkaz- + To: + Supported: gruu, histinfo + Call-ID: 12345600@example.com + CSeq: 1 INVITE + Record-Route: + History-Info: \ + \ + ;index=1 + History-Info: ;index=1.1;rc=1 + Contact: Alice + Content-Type: application/sdp + Content-Length: + + By analyzing the entry referenced by the entry with the last "rc", + one can realize that the URI used to reach the device was GRUU by + finding the "gr" parameter. + +3.10. Service Invocation + + Several SIP specifications have been developed that 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 that first introduced the concept, + [RFC3087], control of network announcements and Interactive Voice + Response (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 that decides to forward the request in some way, and + does so by rewriting the Request-URI. + + Section 3.6 shows how History-Info can be used to invoke a service. + + + + + + + + +Barnes, et al. Informational [Page 47] + +RFC 7131 History-Info Call Flows March 2014 + + +3.11. Toll-Free Number + + Toll-free numbers, also known in the United States as 800 or 8xx + numbers, are telephone numbers that are free for users to call. + + In the telephone network, toll-free numbers are just aliases to + actual numbers that 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 Transaction Capabilities Application Part (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. + For example, ENUM [RFC6117] has already been proposed as a mechanism + for performing Number Portability (NP) queries [RFC4769]. Using it + for 8xx number translations is a logical next step. + + The new target from translating the 8xx number may be in the PSTN or + in the SIP network. If the new target is an entity in the PSTN, the + proper treatment in the PSTN (and in particular, correct + reconciliation of billing records) requires that the call be marked + with both the originating number (8xx number) and the new target + number, History-info would come in play here to assure original 8xx + number is not lost. + + Although not required to have both the originating number (8xx + number) and the new target in the SIP network, an enterprise or user + who utilize the 8xx service can benefit by knowing whether the call + came in via an 8xx number in order to treat the call differently (for + example, to play a special announcement), but if the original + Request-URI is lost through translation, there is no way to tell if + the call came in via 8xx number. History-Info again would come in + play here. + + Similar problems arise with other "special" numbers and services used + in the PSTN, such as operator services, pay/premium numbers (9xx + numbers in the United States), and short service codes such as 311. + + 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. + Technically, the call can be forwarded to these "special" numbers + from non-special numbers; however, that is uncommon based on the way + these services authorize translations. + + This example call flow shows a UAC that does not support History- + Info. + + + + +Barnes, et al. Informational [Page 48] + +RFC 7131 History-Info Call Flows March 2014 + + + Alice Toll-Free Service Atlanta.com John + | | | | + | INVITE F1 | | | + |--------------->| INVITE F2 | | + | |------------->| | + | | | INVITE F3 | + | | |------------------>| + + * Rest of flow not shown * + + Figure 10: Service Number Example + + + Message Details + + F1 INVITE 192.0.2.1 -> Toll-Free Service + + INVITE sip:+18005551002@example.com;user=phone SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf + From: Alice ;tag=9fxced76sl + To: + Call-ID: c3x842276298220188511 + CSeq: 1 INVITE + Max-Forwards: 70 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + + + + + + + + + + + + + +Barnes, et al. Informational [Page 49] + +RFC 7131 History-Info Call Flows March 2014 + + + F2 INVITE Toll-Free Service -> Atlanta.com + + INVITE sip:+15555551002@atlanta.com SIP/2.0 + Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik8 + Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf + From: Alice ;tag=9fxced76sl + To: + Call-ID: c3x842276298220188511 + CSeq: 1 INVITE + Max-Forwards: 69 + Supported: histinfo + History-Info: ;index=1 + History-Info: ;index=1.1;mp=1 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + F3 INVITE Atlanta.com -> John + + INVITE sip:john@198.51.100.2 SIP/2.0 + Via: SIP/2.0/TCP 198.51.100.1:5060;branch=z9hG4bKpxk7g + Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik8 + Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK74bf + From: Alice ;tag=9fxced76sl + To: + Call-ID: c3x842276298220188511 + CSeq: 1 INVITE + Max-Forwards: 68 + Supported: histinfo + History-Info: ;index=1 + History-Info: ;index=1.1;mp=1 + History-Info: ;index=1.1.1;rc=1.1 + History-Info: ;index=1.1.1.1;rc=1.1.1 + Contact: + Content-Type: application/sdp + Content-Length: + + [SDP Not Shown] + + + + + + + + + + +Barnes, et al. Informational [Page 50] + +RFC 7131 History-Info Call Flows March 2014 + + +4. Security Considerations + + The security considerations for the History-Info header field are + specified in [RFC7044]. + +5. Acknowledgements + + Jonathan Rosenberg, et al produced the document that provided + additional use cases precipitating the requirement for the new + "target" parameter in the History-Info header field and the new SIP/ + SIPS URI parameter. Hadriel Kaplan provided some comments. + + Brett Tate, Roland Jesske, Laura Liess, Scott Godin, Dale Worley, and + Marianne Mohali provided extensive review and comments on call flows, + message examples, and text. + +6. Informative References + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User + Agent URIs (GRUUs) in the Session Initiation Protocol + (SIP)", RFC 5627, October 2009. + + [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context + using SIP Request-URI", RFC 3087, April 2001. + + [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network + 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. + + [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA + Registration of Enumservices: Guide, Template, and IANA + Considerations", RFC 6117, March 2011. + + + + + + + +Barnes, et al. Informational [Page 51] + +RFC 7131 History-Info Call Flows March 2014 + + + [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an + Enumservice Containing Public Switched Telephone Network + (PSTN) Signaling Information", RFC 4769, November 2006. + + [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and + C. Holmberg, "An Extension to the Session Initiation + Protocol (SIP) for Request History Information", RFC 7044, + February 2014. + +Authors' Addresses + + Mary Barnes + TX + US + + EMail: mary.ietf.barnes@gmail.com + + + Francois Audet + Skype + + EMail: francois.audet@skype.net + + + Shida Schubert + NTT + Tokyo + Japan + + EMail: shida@ntt-at.com + + + Hans Erik van Elburg + Detecon International Gmbh + Oberkasseler str. 2 + Bonn + Germany + + EMail: ietf.hanserik@gmail.com + + + Christer Holmberg + Ericsson + Hirsalantie 11, Jorvas + Finland + + EMail: christer.holmberg@ericsson.com + + + + +Barnes, et al. Informational [Page 52] + -- cgit v1.2.3