Network Working Group                                          M. Barnes
Internet-Draft                                                   Polycom
Intended status: Informational                                  F. Audet
Expires: September 14, 2011                                        Skype
                                                             S. Schubert
                                                                     NTT
                                                           J. van Elburg
                                              Detecon International Gmbh
                                                             C. Holmberg
                                                                Ericsson
                                                            Mar 13, 2011


Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
            draft-barnes-sipcore-rfc4244bis-callflows-01.txt

Abstract

   This document describes use cases and documents call flows which
   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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2011.

Copyright Notice

   Copyright (c) 2011 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



Barnes, et al.         Expires September 14, 2011               [Page 1]


Internet-Draft           History-Info Call Flows                Mar 2011


   (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 . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  3
   3.  Detailed call flows  . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Automatic Call Distribution  . . . . . . . . . . . . . . .  3
     3.2.  Determining the Alias used.  . . . . . . . . . . . . . . .  5
     3.3.  PBX Voicemail Example  . . . . . . . . . . . . . . . . . .  7
     3.4.  Consumer Voicemail Example . . . . . . . . . . . . . . . .  9
     3.5.  GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.6.  Limited Use Address  . . . . . . . . . . . . . . . . . . . 13
     3.7.  Service Invocation . . . . . . . . . . . . . . . . . . . . 16
     3.8.  Toll Free Number . . . . . . . . . . . . . . . . . . . . . 16
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
























Barnes, et al.         Expires September 14, 2011               [Page 2]


Internet-Draft           History-Info Call Flows                Mar 2011


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 [I-D.ietf-sipcore-rfc4244bis] for example applications and
   common scenarios.  The optional "rc" and "mp" header field parameters
   defined in [I-D.ietf-sipcore-rfc4244bis] are required for several of
   the use cases.  Descriptions of the example use cases, call flow
   diagrams and messaging details are provided.


2.  Conventions and Terminology

   The term "retarget" is used as defined in
   [I-D.ietf-sipcore-rfc4244bis].  The terms "location service",
   "redirect", "redirect" and "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.  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 an hi-target of "mp".  In the
   example this would be the hi-entry referenced by the value of the
   last "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 by the agent - i.e., "I'm so sorry for the
   delay, blah, blah, blah..."



Barnes, et al.         Expires September 14, 2011               [Page 3]


Internet-Draft           History-Info Call Flows                Mar 2011


   For scenarios whereby calls might overflow from the Silver to the
   Gold, clearly the alternate group identification, internal routing,
   or actual agent that handles the call should not be sent to UA1.
   Thus, for this scenario, one would expect that the Proxy would not
   support the sending of the History-Info in the response, even if
   requested by Alice.

   As with the other examples, this is not 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 is not addressing 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 sip:Gold@example.com |             |            |
|------------->|              |             |            |
| Supported: histinfo
|              |              |             |            |
|              |  INVITE sip:Gold@example.com            |
|              |------------->|             |            |
  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com>;index=1.1
|              |              |             |            |
|              |  302 Moved Temporarily     |            |
|              |<-------------|             |            |
  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com>;index=1.1
  Contact: <sip:Silver@example.com>
               |              |             |            |
|              |  INVITE sip:Silver@example.com          |
|              |--------------------------->|            |
  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
                index=1.1
  History-Info: <sip:Silver@example.com>;index=1.2;mp=1
  History-Info: <sip:Silver@silver.example.com>;index=1.2.1
|              |              |             |            |
|              |              | INVITE sip:Silver@192.0.2.7
|              |              |             |----------->|
  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
                index=1.1
  History-Info: <sip:Silver@example.com>;index=1.2;mp=1
  History-Info: <sip:Silver@silver.example.com>;index=1.2.1
  History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1



Barnes, et al.         Expires September 14, 2011               [Page 4]


Internet-Draft           History-Info Call Flows                Mar 2011


|              |              |             |            |
|              |              |             |  200 OK    |
|              |              |             |<-----------|
  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
                index=1.1
  History-Info: <sip:Silver@example.com>;index=1.2;mp=1
  History-Info: <sip:Silver@silver.example.com>;index=1.2.1
  History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1
|              |              |             |            |
|              |         200 OK             |            |
|              |<---------------------------|            |
  History-Info: <sip:Gold@example.com>;index=1
  History-Info: <sip:Gold@gold.example.com?Reason%3BSIP%3Dcause%3B302>;\
                index=1.1
  History-Info: <sip:Silver@example.com>;index=1.2;mp=1
  History-Info: <sip:Silver@silver.example.com>;index=1.2.1
  History-Info: <sip:Silver@192.0.2.7>;index=1.2.1.1;rc=1.2.1
|              |              |             |            |
   200 OK      |              |             |            |
|<-------------|              |             |            |
|              |              |             |            |
|    ACK       |              |             |            |
|------------->|                  ACK                    |
|              |---------------------------------------->|


   The last hi-entry with the "mp" header field parameter contains a
   "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.

3.2.  Determining the Alias used.

   SIP user agents are associated with an address-of-record (AOR).  It
   is possible for a single UA to actually have multiple 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 Internet Multimedia Subsystem (IMS), where
   it is called implicit registration and each alias is called a public
   identity.

   It is a common requirement for a UAS, on receipt of a call, to know



Barnes, et al.         Expires September 14, 2011               [Page 5]


Internet-Draft           History-Info Call Flows                Mar 2011


   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 a "rc" header field
   parameter in the Request received.

Alice             example.com             Agent1           Agent2
 |                     |                     |               |
 |                     |              REGISTER               |
 |                     |<------------------------------------|
 |                     |                200 OK               |
 |                     |------------------------------------>|
 | INVITE sip:john.smith@example.com         |               |
 |-------------------->|                     |               |
 |                     | INVITE              |               |
 |                     |-------------------->|               |
       History-Info: <sip:john.smith@example.com>;index=1;
       History-Info: <sip:john@192.0.2.1>;index=1.1;rc=1;

 |                     | 180 Ringing         |               |
 |                     |<--------------------|               |
       History-Info: <sip:john.smith@example.com>;index=1;
       History-Info: <sip:john@192.0.2.1>;index=1.1;rc=1;
 | 180 Ringing         |                     |               |
 |<--------------------|                     |               |
       History-Info: <sip:john.smith@example.com>;index=1;
       History-Info: <sip:john@192.0.2.1>;index=1.1;rc=1;
 |                     | (Time out)          |               |
 |                     |                 INVITE              |
 |                     |------------------------------------>|
       History-Info: <sip:john.smith@example.com>;index=1;
       History-Info: <sip:john@192.0.2.1?Reason%3BSIP%3Dcause%3B408>;index=1.1;rc=1;
       History-Info: <sip:john@192.0.2.5>;index=1.2;rc=1;
 |                     |                     |               |
         * Rest of flow not shown *


                          Figure 1: Alias Example

   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".



Barnes, et al.         Expires September 14, 2011               [Page 6]


Internet-Draft           History-Info Call Flows                Mar 2011


3.3.  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" and using the hi-entry referenced by the
   index of "rc" 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" (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 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.

   Furthermore it is the proxy forwarding the call to 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 RFC4244bis
   to find the target which is usually based on local policy installed
   by the user or an administrator.

   Alice      example.com       Bob          Carol        VM

   | INVITE sip:bob@example.com  |             |          |
   |------------->|              |             |          |
   |              | INVITE sip:bob@192.0.2.3   |          |
   |              |------------->|             |          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3>;index=1.1;rc=1
   |              |              |             |          |
   |  100 Trying  |              |             |          |
   |<-------------| 302 Moved Temporarily      |          |
   |              |<-------------|             |          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3>; index=1.1;rc=1
     Contact: <sip:carol@example.com>
   |              |              |             |          |



Barnes, et al.         Expires September 14, 2011               [Page 7]


Internet-Draft           History-Info Call Flows                Mar 2011


   |              | INVITE sip:Carol@192.0.2.4 |          |
   |              |--------------------------->|          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
   |              |              |             |          |
   |              |         180 Ringing        |          |
   |              |<---------------------------|          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
   |              |              |             |          |
   | 180 Ringing  |              |             |          |
   |<-------------|              |             |          |
   |              |              |             |          |
   |  . . .       |              |             |          |
   |              |       (timeout)            |          |
   |              |              |             |          |
   |              | INVITE sip:vm@192.0.2.5;\
   |              |        target=sip:bob@example.com>;\
   |              |        cause=408
   |              |-------------------------------------->|
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
                   index=1.2.1;rc=1.2
     History-Info: <sip:vm@example.com;\
                   target=sip:bob@example.com;cause=408>\
                   index=1.3;mp=1.2
     History-Info: <sip:vm@192.0.2.5;\
                   target=sip:bob@example.com;cause=408>\
                   index=1.3.1
   |              |              |             |          |
   |              |               200 OK                  |
   |              |<--------------------------------------|
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4?Reason%3BSIP%3Dcause%3B408>;\
                   index=1.2.1;rc=1.2
     History-Info: <sip:vm@example.com;\



Barnes, et al.         Expires September 14, 2011               [Page 8]


Internet-Draft           History-Info Call Flows                Mar 2011


                   target=sip:bob@example.com;cause=408>\
                   index=1.3;mp=1.2
     History-Info: <sip:vm@192.0.2.5;\
                   target=sip:bob@example.com;cause=408>\
                   index=1.3.1
   |   200 OK     |              |             |          |
   |<-------------|              |             |          |
   |              |              |             |          |
   |     ACK      |              |             |          |
   |------------->|                    ACK                |
   |              |-------------------------------------->|


   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.4.  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
   environment 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 the Bob but Bob has temporarily
   forwarded his phone to Carol because she is his wife.  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 appropriate target for the request.  The last
   target is determined by finding the hi-entry referenced by the index
   of last hi-entry tagged with "rc" 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 sip:bob@example.com  |             |          |
   |------------->|              |             |          |
   |              | INVITE sip:bob@192.0.2.3   |          |
   |              |------------->|             |          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3>;index=1.1;rc=1
   |              |              |             |          |
   |  100 Trying  |              |             |          |



Barnes, et al.         Expires September 14, 2011               [Page 9]


Internet-Draft           History-Info Call Flows                Mar 2011


   |<-------------| 302 Moved Temporarily      |          |
   |              |<-------------|             |          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3>; index=1.1;rc=1
     Contact: <sip:carol@example.com>
   |              |              |             |          |
   |              | INVITE sip:Carol@192.0.2.4 |          |
   |              |--------------------------->|          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
   |              |              |             |          |
   |              |         180 Ringing        |          |
   |              |<---------------------------|          |
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc=1
     History-Info: <sip:carol@example.com>;index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
   |              |              |             |          |
   | 180 Ringing  |              |             |          |
   |<-------------|              |             |          |
   |              |              |             |          |
   |  . . .       |              |             |          |
   |              |       (timeout)            |          |
   |              |              |             |          |
   |              | INVITE sip:vm@192.0.2.5;\
   |              |        target=sip:carol@example.com
   |              |-------------------------------------->|
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\
                   index=1.1;rc
     History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
                   index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
     History-Info: <sip:vm@example.com;
                    target=sip:carol@example.com>;\
                    index=1.3;mp=1.2
     History-Info: <sip:vm@192.0.2.5;\
                    target=sip:carol@example.com>;\
                    index=1.3.1
   |              |              |             |          |
   |              |               200 OK                  |
   |              |<--------------------------------------|
     History-Info: <sip:bob@example.com>;index=1
     History-Info: <sip:bob@192.0.2.3?Reason%3BSIP%3Dcause%3B302>;\



Barnes, et al.         Expires September 14, 2011              [Page 10]


Internet-Draft           History-Info Call Flows                Mar 2011


                   index=1.1;rc
     History-Info: <sip:carol@example.com?Reason%3BSIP%3Dcause%3B408>;\
                   index=1.2;mp=1
     History-Info: <sip:carol@192.0.2.4>;index=1.2.1;rc=1.2
     History-Info: <sip:vm@example.com;\
                    target=sip:carol@example.com>;\
                    index=1.3;mp=1.2
     History-Info: <sip:vm@192.0.2.5;\
                    target=sip:carol@example.com>;\
                    index=1.3.1
   |   200 OK     |              |             |          |
   |<-------------|              |             |          |
   |              |              |             |          |
   |     ACK      |              |             |          |
   |------------->|                    ACK                |
   |              |-------------------------------------->|


   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.

3.5.  GRUU

   A variation on the problem in Section 3.2 occurs with Globally
   Routable User Agent URI (GRUU) [RFC5627].  A GRUU is a URI assigned
   to a UA instance which has many of the same properties as the AOR,
   but causes requests to be routed only to that specific instance.  It
   is desirable for a UA to know whether it was reached because a
   correspondent sent a request to its GRUU or to its AOR.  This can be
   used to drive differing authorization policies on whether the request
   should be accepted or rejected, for example.  However, like the AOR
   itself, the GRUU is lost in translation at the home proxy.  Thus, the
   UAS cannot know whether it was contacted via the GRUU or its AOR.

   Following call-flow and example messages show how History-Info can be
   used to find out the GRUU used to reach the callee.

   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
   containting 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
   GRUU doesn not allow multiple instance to be mapped to a contact
   address.



Barnes, et al.         Expires September 14, 2011              [Page 11]


Internet-Draft           History-Info Call Flows                Mar 2011


          Alice             Example.com             John
          |                     | REGISTER F1         |
          |                     |<--------------------|
          |                     | 200 OK F2           |
          |                     |-------------------->|
          | INVITE F3           |                     |
          |-------------------->|                     |
          |                     | INVITE F4           |
          |                     |-------------------->|
                       * Rest of flow not shown *

   F1 REGISTER John -> Example.com

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
   Max-Forwards: 70
   From: John <sip:John@example.com>;tag=a73kszlfl
   Supported: gruu
   To: John <sip:john@example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
   CSeq: 1 REGISTER
   Contact: <sip:john@192.0.2.1>
    ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
   Content-Length: 0

   F2 200 OK Example.com -> John

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
   From: John <sip:john@example.com>;tag=a73kszlfl
   To: John <sip:john@example.com> ;tag=b88sn
   Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
   CSeq: 1 REGISTER
   Contact: <sip:john@192.0.2.1>
    ;pub-gruu="sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
    ;temp-gruu=
     "sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
    ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
    ;expires=3600
   Content-Length: 0

   Assuming Alice has a knowledge of a gruu either through
   prior communication or through other means such as presence
   places a call to John's gruu.

   F3 INVITE Alice -> Example.com




Barnes, et al.         Expires September 14, 2011              [Page 12]


Internet-Draft           History-Info Call Flows                Mar 2011


   INVITE sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0
   Via: SIP/2.0/TCP  192.0.2.3:5060;branch=232sxxeserg
   From: Alice <sip:alice@example.com>;tag=kkaz-
   To: <sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
   Supported: gruu, histinfo
   Call-Id: 12345600@example.com
   CSeq: 1 INVITE
   History-Info: <sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
   Contact: Alice <sip:alice@192.0.2.3>
   Content-Length: <appropriate value>

   F4 INVITE Example.com -> John

   INVITE sip:john@192.0.2.1 SIP/2.0
   Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
   From: Alice <sip:alice@example.com>;tag=kkaz-
   To: John <sip:john@example.com>
   Supported: gruu, histinfo
   Call-Id: 12345600@example.com
   CSeq: 1 INVITE
   Record-Route: <sip:proxy.example.com;lr>
   History-Info: <sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=1
   History-Info: <sip:john@192.0.2.1>;index=1.1
   Contact: Alice <sip:alice@192.0.2.3>
   Content-Type: application/sdp
   Content-Length: <appropriate value>


                          Figure 2: GRUU Example

   The last hi-entry has no "rc" header field parameter which indicates
   that source of retargeting is likely to be a GRUU.  UAS can look for
   a "gr" URI parameter in the hi-entry prior to the last hi-entry to
   ensure it is indeed a GRUU.

3.6.  Limited Use Address

   A limited use address is a SIP URI that is minted on-demand, and
   passed out to a small number (usually one) remote correspondent.
   Incoming calls targeted to that limited use address are accepted as
   long as the UA still desires communications from the remote target.
   Should they no longer wish to be bothered by that remote
   correspondent, the URI is invalidated so that future requests



Barnes, et al.         Expires September 14, 2011              [Page 13]


Internet-Draft           History-Info Call Flows                Mar 2011


   targeted to it are rejected.

   Limited use addresses are used in battling voice spam [RFC5039].  The
   easiest way to provide them would be for a UA to be able to take its
   AOR, and "mint" a limited use address by appending additional
   parameters to the URI.  It could then give out the URI to a
   particular correspondent, and remember that URI locally.  When an
   incoming call arrives, the UAS would examine the parameter in the URI
   and determine whether or not the call should be accepted.
   Alternatively, the UA could push authorization rules into the
   network, so that it need not even see incoming requests that are to
   be rejected.

   This approach, especially when executed on the UA, requires that
   parameters attached to the AOR, but not used by the home proxy in
   processing the request, will survive the translation at the home
   proxy and be presented to the UA.  This will not be the case with the
   logic in RFC 3261, since the Request-URI is replaced by the
   registered contact, and any such parameters are lost.

   Using the history-info John's UA can easily see if the call was
   addressed to its AoR, GRUU or a temp-gruu and treat the call
   accordingly by looking 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 *


   F1 REGISTER John -> Example.com

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
   Max-Forwards: 70
   From: John <sip:John@example.com>;tag=a73kszlfl
   Supported: gruu
   To: John <sip:john@example.com>
   Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
   CSeq: 1 REGISTER
   Contact: <sip:john@192.0.2.1>



Barnes, et al.         Expires September 14, 2011              [Page 14]


Internet-Draft           History-Info Call Flows                Mar 2011


    ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
   Content-Length: 0

   F2 200 OK Example.com -> John

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKnashds7
   From: John <sip:john@example.com>;tag=a73kszlfl
   To: John <sip:john@example.com> ;tag=b88sn
   Call-ID: 1j9FpLxk3uxtm8tn@192.0.2.1
   CSeq: 1 REGISTER
   Contact: <sip:john@192.0.2.1>
    ;pub-gruu="sip:john@example.com
    ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
    ;temp-gruu=
     "sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr"
    ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
    ;expires=3600
   Content-Length: 0

    Assuming Alice has a knowledge of a temp-gruu, she places a
    call to the temp-gruu.

   F3 INVITE Alice -> Example.com

   INVITE sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com
    ;gr SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
   From: Alice <sip:alice@example.com>;tag=kkaz-
   To: <sip:sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com
    ;gr>
   Supported: gruu, histinfo
   Call-Id: 12345600@example.com
   CSeq: 1 INVITE
   History-Info:
    <sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
    ;index=1
   Contact: Alice <sip:alice@192.0.2.3>
   Content-Length: <appropriate value>

   F4 INVITE Example.com -> John

   INVITE sip:john@192.0.2.1 SIP/2.0
   Via: SIP/2.0/TCP proxy.example.com:5060;branch=as2334se
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=232sxxeserg
   From: Alice <sip:alice@example.com>;tag=kkaz-
   To: John <sip:john@example.com>
   Supported: gruu, histinfo



Barnes, et al.         Expires September 14, 2011              [Page 15]


Internet-Draft           History-Info Call Flows                Mar 2011


   Call-Id: 12345600@example.com
   CSeq: 1 INVITE
   Record-Route: <sip:proxy.example.com;lr>
   History-Info:
    <sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr>
    ;index=1
   History-Info: <sip:john@192.0.2.1>;index=1.1
   Contact: Alice <sip:alice@192.0.2.3>
   Content-Type: application/sdp
   Content-Length: <appropriate value>


                   Figure 3: Limited Use Address Example

   The last hi-entry has no "rc" header field parameter which indicates
   that source of retargeting is likely to be a GRUU.  UAS can look for
   a "gr" URI parameter in the hi-entry prior to the last hi-entry to
   ensure it is indeed a GRUU.  UAS can further diagnose the URI to see
   that it's a temp GRUU.

3.7.  Service Invocation

   Several SIP specifications have been developed which make use of
   complex URIs to address services within the network rather than
   subscribers.  The URIs are complex because they contain numerous
   parameters that control the behavior of the service.  Examples of
   this include the specification which first introduced the concept,
   [RFC3087], control of network announcements and IVR with SIP URI
   [RFC4240], and control of voicemail access with SIP URI [RFC4458].

   A common problem with all of these mechanisms is that once a proxy
   has decided to rewrite the Request-URI to point to the service, it
   cannot be sure that the Request-URI will not be destroyed by a
   downstream proxy which decides to forward the request in some way,
   and does so by rewriting the Request-URI.

   Section on voicemail (Section 3.3) shows how History-Info can be used
   to invocate a service.

3.8.  Toll Free Number

   Toll free numbers, also known as 800 or 8xx numbers in the United
   States, are telephone numbers that are free for users to call.

   In the telephone network, toll free numbers are just aliases to
   actual numbers which are used for routing of the call.  In order to
   process the call in the PSTN, a switch will perform a query (using a
   protocol called TCAP), which will return either a phone number or the



Barnes, et al.         Expires September 14, 2011              [Page 16]


Internet-Draft           History-Info Call Flows                Mar 2011


   identity of a carrier which can handle the call.

   There has been recent work on allowing such PSTN translation services
   to be accessed by SIP proxy servers through IP querying mechanisms.
   ENUM, for example [RFC3761] has already been proposed as a mechanism
   for performing Local Number Portability (LNP) queries [RFC4769], and
   recently been proposed for performing calling name queries
   [I-D.ietf-enum-cnam].  Using it for 8xx number translations is a
   logical next-step.

   Once such a translation has been performed, the call needs to be
   routed towards the target of the request.  Normally, this would
   happen by selecting a PSTN gateway which is a good route towards the
   translated number.  However, one can imagine all-IP systems where the
   8xx numbers are SIP endpoints on an IP network, in which case the
   translation of the 8xx number would actually be a SIP URI and not a
   phone number.  Assuming for the moment it is a PSTN connected entity,
   the call would be routed towards a PSTN gateway.  Proper treatment of
   the call in the PSTN (and in particular, correct reconciliation of
   billing records) requires that the call be marked with both the
   original 8xx number AND the target number for the call.  However, in
   our example here, since the translation was performed by a SIP proxy
   upstream from the gateway, the original 8xx number would have been
   lost, and the call will not interwork properly with the PSTN.

   Furthermore, even if the translation of the 8xx number was a SIP URI,
   the enterprise or user who utilize the 8xx service would like to know
   whether the call came in via 8xx number in order to treat the call
   differently (for example to play a special announcement..) but if the
   original R-URI is lost through translation, there is no way to tell
   if the call came in via 8xx number.

   Similar problems arise with other "special" numbers and services used
   in the PSTN, such as operator services, pay/premium numbers (9xx
   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
   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.

         Alice      Toll Free Service   Atlanta.com          John
          |                |              |                   |
          |    INVITE F1   |              |                   |
          |--------------->|   INVITE F2  |                   |
          |                |------------->|                   |
          |                |              |  INVITE F3        |



Barnes, et al.         Expires September 14, 2011              [Page 17]


Internet-Draft           History-Info Call Flows                Mar 2011


          |                |              |------------------>|

                       * Rest of flow not shown *

   F1: INVITE 192.0.2.1 -> proxy.example.com

   INVITE sip:+18005551002@example.com;user=phone  SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
   To: sip:+18005551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Supported: histinfo
   History-Info: <sip:+18005551002@example.com;user=phone >;index=1
   Contact: <sip:alice@192.0.2.1>
   Content-Type: application/sdp
   Content-Length: <appropriate value>

   [SDP Not Shown]

   F2: INVITE proxy.example.com -> atlanta.com

   INVITE sip:+15555551002@atlanta.com SIP/2.0
   Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
   Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
   To: sip:+18005551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Supported: histinfo
   History-Info: <sip:+18005551002@example.com;user=phone >;index=1,
                 <sip:+15555551002@atlanta.com>;index=1.1;mp=1
   Contact: <sip:alice@192.0.2.1>
   Content-Type: application/sdp
   Content-Length: <appropriate value>

   [SDP Not Shown]

   F3: INVITE atlanta.com -> John

   INVITE sip:john@198.51.100.2 SIP/2.0
   Via: SIP/2.0/TCP 198.51.100.1:5060;branch=z9hG4bK-pxk7g-3
   Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
   Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
   To: sip:+18005551002@example.com;user=phone



Barnes, et al.         Expires September 14, 2011              [Page 18]


Internet-Draft           History-Info Call Flows                Mar 2011


   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Supported: histinfo
   History-Info: <sip:+18005551002@example.com;user=phone >;index=1,
                 <sip:+15555551002@atlanta.com>;index=1.1;mp=1,
                 <sip:john@atlanta.com>;index=1.1.1,
                 <sip:john@198.51.100.2>;index=1.1.2;rc=1.1
   Contact: <sip:alice@192.0.2.1>
   Content-Type: application/sdp
   Content-Length: <appropriate value>

   [SDP Not Shown]


                     Figure 4: Service Number Example


4.  Security Considerations

   The security considerations for the History-Info header field are
   specified in [I-D.ietf-sipcore-rfc4244bis].


5.  IANA Considerations

   This document has no IANA considerations.

5.1.  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.


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.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session



Barnes, et al.         Expires September 14, 2011              [Page 19]


Internet-Draft           History-Info Call Flows                Mar 2011


              Initiation Protocol (SIP)", RFC 3323, November 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC4244]  Barnes, M., "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 4244,
              November 2005.

   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent URIs (GRUUs) in the Session Initiation Protocol
              (SIP)", RFC 5627, October 2009.

   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Session
              Initiation Protocol (SIP)", RFC 5630, 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.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC4769]  Livingood, J. and R. Shockey, "IANA Registration for an
              Enumservice Containing Public Switched Telephone Network
              (PSTN) Signaling Information", RFC 4769, November 2006.

   [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Uniform Resource Identifier (URI) Parameter
              Registry for the Session Initiation Protocol (SIP)",
              BCP 99, RFC 3969, December 2004.

   [I-D.ietf-enum-cnam]
              Shockey, R., "IANA Registration for an Enumservice Calling



Barnes, et al.         Expires September 14, 2011              [Page 20]


Internet-Draft           History-Info Call Flows                Mar 2011


              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]
              Barnes, M., Audet, F., Schubert, S., Netherlands, T., and
              C. Holmberg, "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information",
              draft-ietf-sipcore-rfc4244bis-03 (work in progress),
              February 2011.


Authors' Addresses

   Mary Barnes
   Polycom
   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







Barnes, et al.         Expires September 14, 2011              [Page 21]


Internet-Draft           History-Info Call Flows                Mar 2011


   Christer Holmberg
   Ericsson
   Hirsalantie 11, Jorvas
   Finland

   Email: christer.holmberg@ericsson.com













































Barnes, et al.         Expires September 14, 2011              [Page 22]