Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
RFC 4488

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                           O. Levin
Request for Comments: 4488                         Microsoft Corporation
Category: Standards Track                                       May 2006

           Suppression of Session Initiation Protocol (SIP)
                   REFER Method Implicit Subscription

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 (2006).

Abstract

   The Session Initiation Protocol (SIP) REFER extension as defined in
   RFC 3515 automatically establishes a typically short-lived event
   subscription used to notify the party sending a REFER request about
   the receiver's status in executing the transaction requested by the
   REFER.  These notifications are not needed in all cases.  This
   specification provides a way to prevent the automatic establishment
   of an event subscription and subsequent notifications using a new SIP
   extension header field that may be included in a REFER request.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Preventing Forking of REFER Requests  . . . . . . . . . . . . . 4
   6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
       10.1.  Normative References . . . . . . . . . . . . . . . . . . 7
       10.2.  Informative References . . . . . . . . . . . . . . . . . 7

Levin                       Standards Track                     [Page 1]
RFC 4488             SIP REFER without Subscription             May 2006

1.  Introduction

   The REFER specification [3] specifies that every REFER creates an
   implicit subscription between the REFER-Issuer and the REFER-
   Recipient.

   This document defines a new SIP header field: "Refer-Sub" meaningful
   within a REFER transaction only.  This header field, when set to
   "false", specifies that a REFER-Issuer requests that the REFER-
   Recipient doesn't establish an implicit subscription and the
   resultant dialog.

   This document defines a new option tag: "norefersub".  This tag, when
   included in the Supported header field, indicates that a User Agent
   (UA) is capable of accepting a REFER request without creating an
   implicit subscription when acting as a REFER-Recipient.

2.  Terminology

   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 [1].

   To simplify discussions of the REFER method and its extensions, the
   three terms below are being used throughout the document:

   o  REFER-Issuer: the UA issuing the REFER request

   o  REFER-Recipient: the UA receiving the REFER request

   o  REFER-Target: the UA designated in the Refer-To Uniform Resource
      Identifier (URI)

3.  Motivation

   The REFER specification mandates that every REFER creates an implicit
   subscription between the REFER-Issuer and the REFER-Recipient.  This
   subscription results in at least one NOTIFY being sent from the
   REFER-Recipient to the REFER-Issuer.  The REFER-Recipient may choose
   to cancel the implicit subscription with this NOTIFY.  The REFER-
   Issuer may choose to cancel this implicit subscription with an
   explicit SUBSCRIBE (Expires: 0) after receipt of the initial NOTIFY.

   One purpose of requiring the implicit subscription and initial NOTIFY
   is to allow for the situation where the REFER request gets forked and
   the REFER-Issuer needs a way to see the multiple dialogs that may be
   established as a result of the forked REFER.  This is the same
   approach used to handle forking of SUBSCRIBE [4] requests.  Where the

Levin                       Standards Track                     [Page 2]
RFC 4488             SIP REFER without Subscription             May 2006

   REFER-Issuer explicitly specifies that forking not occur, the
   requirement that an implicit subscription be established is
   unnecessary.

   Another purpose of the NOTIFY is to inform the REFER-Issuer of the
   progress of the SIP transaction that results from the REFER at the