The Session Initiation Protocol (SIP) Referred-By Mechanism
RFC 3892

 
Document
Type RFC - Proposed Standard (September 2004; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 3892 (Proposed Standard)
Telechat date
Responsible AD Allison Mankin
Send notices to rjsparks@nostrum.com,rohan@cisco.com, dean.willis@softarmor.com, mankin@psg.com

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                          R. Sparks
Request for Comments: 3892                                          Xten
Category: Standards Track                                 September 2004

      The Session Initiation Protocol (SIP) Referred-By Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   The Session Initiation Protocol (SIP) REFER method provides a
   mechanism where one party (the referrer) gives a second party (the
   referee) an arbitrary URI to reference.  If that URI is a SIP URI,
   the referee will send a SIP request, often an INVITE, to that URI
   (the refer target).  This document extends the REFER method, allowing
   the referrer to provide information about the REFER request to the
   refer target using the referee as an intermediary.  This information
   includes the identity of the referrer and the URI to which the
   referrer referred.  The mechanism utilizes S/MIME to help protect
   this information from a malicious intermediary.  This protection is
   optional, but a recipient may refuse to accept a request unless it is
   present.

Sparks                      Standards Track                     [Page 1]
RFC 3892             The SIP Referred-By Mechanism        September 2004

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Requirements Notation  . . . . . . . . . . . . . . . . .  3
   2.  The Referred-By Mechanism  . . . . . . . . . . . . . . . . . .  3
       2.1.  Referrer Behavior  . . . . . . . . . . . . . . . . . . .  4
       2.2.  Referee Behavior . . . . . . . . . . . . . . . . . . . .  4
       2.3.  Refer Target Behavior  . . . . . . . . . . . . . . . . .  5
   3.  The Referred-By Header Field . . . . . . . . . . . . . . . . .  6
   4.  The Referred-By Token  . . . . . . . . . . . . . . . . . . . .  7
       4.1.  Refer Target Inspection of a Referred-By Token . . . . .  8
   5.  The 429 Provide Referrer Identity Error Response . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
       6.1.  Identifying the Referee in the Referred-by Token . . . . 10
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       7.1.  Basic REFER  . . . . . . . . . . . . . . . . . . . . . . 11
       7.2.  Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
       7.3.  Requiring Referrer Identity  . . . . . . . . . . . . . . 14
       7.4.  Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       10.1. Normative References . . . . . . . . . . . . . . . . . . 23
       10.2. Informative References . . . . . . . . . . . . . . . . . 24
   11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25

1.  Overview

   The SIP REFER method [2] provides a mechanism where one party (the
   referrer) provides a second party (the referee) with an arbitrary URI
   to reference.  If that URI is a SIP URI, the referee will send a SIP
   request, often an INVITE, to that URI (the refer target).  Nothing
   provided in [2] distinguishes this referenced request from any other
   request the referee might have sent to the refer target.

      Referrer           Referee            Refer Target
         |                  |                    |
         | REFER            |                    |
         | Refer-To: target |                    |
         |----------------->| INVITE target      |
         |                  |------------------->|

Sparks                      Standards Track                     [Page 2]
RFC 3892             The SIP Referred-By Mechanism        September 2004

   There are applications of REFER, such as call transfer [8], where it
   is desirable to provide the refer target with particular information
   about the referrer and the REFER request itself.  This information
   may include, but is not limited to, the referrer's identity, the
   referred to URI, and the time of the referral.  The refer target can
   use this information when deciding whether to admit the referenced
Show full document text