Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
RFC 4488
Document | Type | RFC - Proposed Standard (May 2006; No errata) | |
---|---|---|---|
Author | Orit Levin | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4488 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | rohan@ekabal.com |
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 theShow full document text