Internet Draft                                      Mary Barnes,Editor
Document: draft-ietf-sipping-req-history-04.txt            Mark Watson
                                                       Nortel Networks
                                                       Cullen Jennings
                                                         Cisco Systems
                                                          Jon Peterson
Category: Informational                                  NeuStar, Inc.
Expires  December 2003                                       June 2003

          SIP Generic Request History Capability Requirements

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Many services that SIP is anticipated to support require the ability
   to determine why and how the call arrived at a specific application.
   Examples of such services include (but are not limited to) sessions
   initiated to call centers via "click to talk" SIP URLs on a web page,
   "call history/logging" style services within intelligent "call
   management" software for SIP UAs and calls to voicemail servers and
   call centers.  While SIP implicitly provides the redirect/retarget
   capabilities that enable calls to be routed to chosen applications,
   there is currently no standard mechanism within SIP for communicating
   the history of such a request. This "request history" information
   allows the receiving application to determine hints about how and why
   the call arrived at the application/user.



Barnes                 Expires - December 2003               [Page 1]


SIP Generic Request History Capability Requirements        June 2003


   This draft discusses the motivations in support of a mechanism for
   recording the "request history", and proposes detailed requirements
   for such a generic "request history" capability.


Table of Contents

1.   Introduction:  Why define a Generic "Request History" capability?
     2
2.   Conventions used in this document...............................3
3.   "Request History" Requirements..................................3
4.   Security Considerations.........................................5
5.   Privacy Considerations..........................................6
6.   IANA Considerations.............................................6
7.   References......................................................6
8.   Contributors....................................................7
9.   Acknowledgments.................................................7
10.  Appendix A - Scenarios..........................................8
      10.1   Sequentially forking with Retargeting..................9
      10.2   Voicemail.............................................10


1.  Introduction:  Why define a Generic "Request History" capability?

   SIP implicitly provides redirect/retarget capabilities that enable
   calls to be routed to specific applications as defined in [1]. The
   term retarget will be used henceforth in this draft to refer to the
   process of a Proxy Server/UAC changing a URI in a request and thus
   changing the target of the request.  This term is chosen to avoid
   associating this request history only with the specific SIP Redirect
   Server capability that provides for a response to be sent back to a
   UAC requesting that the UAC should retarget the original request to
   an alternate URI.  The rules for determining request targets as
   described in section 16.5 of [1] are consistent with the use of the
   retarget term in this draft.

   The motivation for the request history is that in the process of
   retargeting old routing information can be forever lost. This lost
   information may be important history that allows elements to which
   the call is retargeted to process the call in a locally defined,
   application specific manner. The proposal in this draft is to provide
   a mechanism for transporting the request history.  It is not
   proposing any behavior for a Proxy or UA upon receipt of the
   information. Indeed, such behavior should be a local decision for the
   recipient application.

   Current network applications provide the ability for elements
   involved with the call to exchange additional information relating to



Barnes                 Expires û December 2003               [Page 2]


SIP Generic Request History Capability Requirements        June 2003


   how and why the call was routed to a particular destination.  The
   following are examples of such applications:

  1. Web "referral" applications, whereby an application residing
     within a web server determines that a visitor to a website has
     arrived at the site via an "associate" site which will receive
     some "referral" commission for generating this traffic,

  2. Email forwarding whereby the forwarded-to user obtains a "history"
     of who sent the email to whom and at what time

  3. Traditional telephony services such as Voicemail, call-center
     "automatic call distribution", and "follow-me" style services.


   Several of the aforementioned applications define application
   specific mechanisms through which it is possible to obtain the
   necessary history information.

   In addition, request history information could be used to enhance
   basic SIP functionality by providing:

  4. Some diagnostic information for debugging SIP requests.

  5. A stronger security solution for SIP. A side effect is that each
     proxy which captures the "request history" information in a secure
     manner provides an additional means (without requiring signed keys)
     for the original requestor to be assured that the request was
     properly retargeted.

   This draft summarizes the requirements for defining a generic
   mechanism for the transport of request history information.  Example
   scenarios are provided in the appendix illustrating how a SIP
   building block that provides request history information could be
   used by some applications. It is not the intent, nor is it within the
   scope, of this requirement's draft to prescribe a complete solution
   for any of these applications.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.


3.  "Request History" Requirements

   The following list constitutes a set of requirements for a "Request
   History" capability. It is anticipated that some of these


Barnes                 Expires û December 2003               [Page 3]


SIP Generic Request History Capability Requirements        June 2003


   requirements can be met using existing elements within SIP; whether
   and what SIP extensions would be needed to meet these requirements is
   out of scope of this draft.

   1) CAPABILITY-req:  The "Request History" capability will provide a
   capability to inform proxies and UAs involved in processing a request
   about the history/progress of that request. While this is inherently
   provided when the retarget is in response to a SIP redirect, it is
   deemed useful for non-redirect retargeting scenarios, as well.

   2) OPTIONALITY-req: The "Request History" information is optional.

   2.1) In many cases, it is anticipated that whether the history is
   added to the Request would be a local policy decision enforced by the
   specific application, thus no specific protocol element is needed.

   2.2) Due to the capability being "optional" from the SIP protocol
   perspective, the impact to an application of not having the "Request
   History" must be described. Applicability guidelines to be addressed
   by applications using this capability must be provided as part of the
   solution to these requirements.


   3) GENERATION-req: "Request History" information is generated when
   the request is retargeted.

   3.1) In some scenarios, it might be possible for more than one
   instance of retargeting to occur within the same Proxy.  A proxy
   should also generate Request History information for the 'internal
   retargeting'.

   3.2) An entity (UA or proxy) retargeting in response to a redirect or
   REFER should include any Request History information from the
   redirect/REFER in the new request.


   4) ISSUER-req: "Request History" information can be generated by a
   UA, proxy or redirect server. It can be passed in both requests and
   responses.


   5) CONTENT-req:  The "Request History" information for each
   occurrence of retargeting, shall include the following:

     5.1) The new URI or address to which the request is in the process
     of being retargeted,

     5.2) The URI or address from which the request was retargeted,



Barnes                 Expires û December 2003               [Page 4]


SIP Generic Request History Capability Requirements        June 2003


     5.3) The reason for the Request-URI modification,

     5.4) Chronological ordering of the Request History information.

   6) REQUEST-VALIDITY-req:  Request-History is applicable to requests
   not sent within an established dialog. (i.e. INVITE, REGISTER,
   MESSAGE, and OPTIONS).

   7) BACKWARDS-req: Request-History information may be passed from the
   generating entity backwards towards the UAC. This is needed to enable
   services that inform the calling party about the dialog establishment
   attempts.

   8) FORWARDS-req:  Request-History information may also be included by
   the generating entity in the request, if it is forwarded onwards.


4.  Security Considerations

   The Request History information is being inserted by a network
   element retargeting a Request, resulting in a slightly different
   problem than the basic SIP header problem, thus requiring specific
   consideration.  It is recognized that these security requirements can
   be generalized to a basic requirement of being able to secure
   information that is inserted by proxies.

   The potential security problems include the following:
   1) A rogue application could insert a bogus Request History entry
   either by adding an additional entry as a result of retargeting or
   entering invalid information.

   2) Loss of privacy associated with forwarding a specific Request URI
   in the Request History.

   3) A rogue application could re-arrange the Request History
   information to change the nature of the end application or to mislead
   the receiver of the information.

   Thus, a security solution for "Request History" must meet the
   following requirements:

   1) SEC-req-1: The entity receiving the Request History must be able
   to determine whether any of the previously added Request History
   content has been altered.

   2) SEC-req-2: The ordering of the Request History information must be
   preserved at each instance of retargeting.




Barnes                 Expires û December 2003               [Page 5]


SIP Generic Request History Capability Requirements        June 2003


   3) SEC-req-3: The entity receiving the information conveyed by the
   Request History must be able to authenticate the source of the
   information.

   4) SEC-req-4: To ensure the confidentiality of the Request History
   information, only entities which process the request should have
   visibility to the information.

   It should be noted that these security requirements apply to any
   entity making use of the Request History information, either by
   retargeting and capturing the information, or as an application
   making use of the information in a Request or Response.

5.  Privacy Considerations

   Since the Request URI that is captured could inadvertently reveal
   information about the originator, there are general privacy
   requirements that MUST be met:

   1) PRIV-req-1: The entity retargeting the Request must ensure that it
   maintains the network-provided privacy (as described in [2])
   associated with the Request as it is retargeted.

   2) PRIV-req-2: The entity receiving the Request History must maintain
   the privacy associated with the information.

   In addition, local policy at a proxy may identify privacy
   requirements associated with Request History information. Request
   History information subject to privacy requirements shall not be
   included in outgoing messages unless it is protected as described in
   [2].


6.  IANA Considerations

   This document does not have any implications for IANA.

7.  References

   [1] J. Rosenberg et al, "SIP: Session initiation protocol," RFC 3261,
   June, 2002.

   [2] J. Peterson, "A Privacy Mechanism for the Session Initiation
   Protocol (SIP)", RFC 3323, November, 2002.







Barnes                 Expires û December 2003               [Page 6]


SIP Generic Request History Capability Requirements        June 2003


8.  Contributors

     Robert Sparks contributed excellent feedback and direction for the
     Security considerations section of this document.  In addition, he
     highlighted the importance of addressing the optionality aspects of
     the "Request History" capability.

9.  Acknowledgments

     The editor would like to thank Sanjoy Sen, Ben Campbell, Rohan
     Mahy, Jonathan Rosenberg and John Elwell for providing useful
     comments and suggestions related to this draft.


 Authors' Addresses

    Mary Barnes
    Nortel Networks
    2380 Performance Drive
    Richardson, Texas 75082
    USA

    Phone: +1 972-684-5432
    EMail:  mbarnes@nortelnetworks.com


    Mark Watson
    Nortel Networks
    Maidenhead Office Park (Bray House)
    Westacott Way
    Maidenhead, Berkshire
    England

    Phone: +44 (0)1628-434456
    EMail: mwatson@nortelnetworks.com


    Cullen Jennings
    Cisco Systems
    170 West Tasman Drive
    MS: SJC-21/3
    San Jose, CA  95134
    USA

    Phone: +1 408-527-9132
    EMail: fluffy@cisco.com

    Jon Peterson
    NeuStar, Inc.


Barnes                 Expires û December 2003               [Page 7]


 SIP Generic Request History Capability Requirements        June 2003


    1800 Sutter Street, Suite 570
    Concord, CA  94520
    USA

    Phone: +1 925-363-8720
    EMail: Jon.Peterson@NeuStar.biz



 Full Copyright Statement

    Copyright (C) The Internet Society (2003).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain
    it or assist in its implementation may be prepared, copied,
    published and distributed, in whole or in part, without restriction
    of any kind, provided that the above copyright notice and this
    paragraph are included on all such copies and derivative works.
    However, this document itself may not be modified in any way, such
    as by removing the copyright notice or references to the Internet
    Society or other Internet organizations, except as needed for the
    purpose of developing Internet standards in which case the
    procedures for copyrights defined in the Internet Standards process
    must be followed, or as required to translate it into languages
    other than English.  The limited permissions granted above are
    perpetual and will not be revoked by the Internet Society or its
    successors or assigns.  This document and the information contained
    herein is provided on an "AS IS" basis and THE INTERNET SOCIETY
    AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
    WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
    FOR A PARTICULAR PURPOSE."


 10.       Appendix A - Scenarios

    This section highlights some scenarios under which the Request
    History Capability could be applicable.

    Certainly, various other solutions can be applied in some fashion
    to each of these scenarios.  However, the objective of this draft
    has been to abstract the requirements from these scenarios towards
    providing a more robust solution for each and at the same time
    providing fundamental building block(s) applicable to future
    applications.




 Barnes                 Expires û December 2003              [Page 8]


 SIP Generic Request History Capability Requirements        June 2003


      10.1 Sequentially forking with Retargeting

    This scenario is as follows:

      UA 1 sends a call to proxy 1. Proxy 1 sequentially tries several
      places (UA2, UA3 and UA4) before retargeting the call to Proxy 2.
      Proxy 2 unfortunately tries several of the same places (UA3 and
      UA4), before completing at UA5.


    UA1        Proxy1  Proxy2     UA2      UA3      UA4      UA5

    |            |         |        |        |        |        |
    |--INVITE -->|         |        |        |        |        |
    |            |         |        |        |        |        |
    |            |--INVITE -------->|        |        |        |
    |<--100 -----|         |        |        |        |        |
    |            |<-302 ------------|        |        |        |
    |            |         |        |        |        |        |
    |            |-------INVITE ------------>|        |        |
    |            |         |        |        |        |        |
    |            |<-------180 ---------------|        |        |
    |<---180 ----|         |        |        |        |        |
    |  . .       |-------INVITE------------->|        |        |
    |            |       timeout    |        |        |        |
    |            |         |        |        |        |        |
    |            |------INVITE ---------------------->|        |
    |<--100 -----|         |        |        |        |        |
    |            |<-302 ------------------------------|        |
    |            |         |        |        |        |        |
    |            |-INVITE->|        |        |        |        |
    |            |         |        |        |        |        |
    |            |         |---INVITE ------>|        |        |
    |            |         |        |        |        |        |
    |            |         |<---180----------|        |        |
    |<---180 --------------|        |        |        |        |
    |            |         |        |        |        |        |
    |  . .       |         |----INVITE------>|        |        |
    |            |         |      timeout    |        |        |
    |            |         |        |        |        |        |
    |            |         |------INVITE ------------>|        |
    |<--100 ---------------|        |        |        |        |
    |            |         |<-302 --------------------|        |
    |            |         |        |        |        |        |
    |            |         |------INVITE --------------------->|
    |            |         |        |        |        |        |
    |            |         |<-----200 OK---------------------->|
    |<--200 OK-------------|        |        |        |        |


 Barnes                 Expires û December 2003              [Page 9]


 SIP Generic Request History Capability Requirements        June 2003


    |            |         |        |        |        |        |
    |--ACK --------------------------------------------------->|
    |            |         |        |        |        |        |


    This scenario is provided to show the duplication of messaging when
    there isn't sufficient knowledge to optimize a sequential attempt
    at reaching an end user.  With the "Request History" capability,
    this flow could be optimized as follows:

    UA1        Proxy1  Proxy2     UA2      UA3      UA4      UA5

    |            |         |        |        |        |        |
    |--INVITE -->|         |        |        |        |        |
    |            |         |        |        |        |        |
    |            |--INVITE -------->|        |        |        |
    |<--100 -----|         |        |        |        |        |
    |            |<-302 ------------|        |        |        |
    |            |         |        |        |        |        |
    |            |-------INVITE ------------>|        |        |
    |            |         |        |        |        |        |
    |            |<-------180 ---------------|        |        |
    |<---180 ----|         |        |        |        |        |
    |  . .       |-------INVITE------------->|        |        |
    |            |       timeout    |        |        |        |
    |            |         |        |        |        |        |
    |            |------INVITE ---------------------->|        |
    |<--100 -----|         |        |        |        |        |
    |            |<-302 ------------------------------|        |
    |            |         |        |        |        |        |
    |            |-INVITE->|        |        |        |        |
    |            |         |        |        |        |        |
    |            |         |        |        |        |        |
    |            |         |------INVITE --------------------->|
    |            |         |        |        |        |        |
    |            |         |<-----200 OK---------------------->|
    |<--200 OK-------------|        |        |        |        |
    |            |         |        |        |        |        |
    |--ACK --------------------------------------------------->|
    |            |         |        |        |        |        |



      10.2 Voicemail
    This scenario highlights an example where the request history
    information is primarily of use by an edge service (e.g. Voicemail
    Server). It should be noted that this isn't intended to be a
    complete specification for this specific edge service as it is


 Barnes                 Expires û December 2003             [Page 10]


 SIP Generic Request History Capability Requirements        June 2003


    quite likely that additional information is needed by the edge
    service.

     This scenario is as follows:

      UA 1 called UA A which had been forwarded to UA B which forwarded
      to a UA VM (voicemail server) which needs information (e.g.
      reason the call was retargeted, original Request URI) to make a
      policy decision about what mailbox to use, which greeting to play
      etc. This scenario shows that something like the "Request
      History" capability must be used for this service to function.



 UA1          Proxy           UA-A         UA-B        UA-VM

 |              |              |             |          |
 |--INVITE ---->|              |             |          |
 |              |              |             |          |
 |              |--INVITE ---->|             |          |
 |<--100 -------|              |             |          |
 |              |<-302 --------|             |          |
 |              |              |             |          |
 |              |--------INVITE ------------>|          |
 |              |              |             |          |
 |              |<--------180 ---------------|          |
 |<---180 ------|              |             |          |
 |  . . .       |--------INVITE------------->|          |
 |              |        timeout             |          |
 |              |              |             |          |
 |              |-------INVITE ------------------------>|
 |              |              |             |          |
 |              |<-200 ---------------------------------|
 |              |              |             |          |
 |<-200---------|              |             |          |
 |              |              |             |          |
 |--ACK ----------------------------------------------->|
 |              |              |             |          |
 |              |              |             |          |

 This scenario is specifically highlighting a case whereby the desired
 functionality (e.g. via local policy) is for a call which is not
 answered (or undeliverable for other reasons) to revert to the
 voicemail server of UA A.  Additional scenarios are certainly valid
 whereby the call is routed to the voicemail server of UA B, thus NOT
 necessarily requiring history information to process the request. This
 latter situation further highlights that the use of the request
 history information is not prescriptive for any particular service.



 Barnes                 Expires û December 2003             [Page 11]