Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
RFC 4488
|
| Document |
Type |
|
RFC - Proposed Standard
(May 2006; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4488 (Proposed Standard)
|
|
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]
Show full document text