The Five Meanings of the REFER Method

Document Type Expired Internet-Draft (individual)
Author Dale Worley 
Last updated 2006-06-21
Stream (None)
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


The REFER method is defined in RFC 3515. That RFC defines the syntax of the REFER request and some of the machinery involved in its execution, but it defines the semantics of the method only so far as to specify that the recipient will initiate a request to the target specified in the Refer-To header. But since almost all requests that can be sent by the recipient are inherently part of an encompassing UA action that affects the state of the recipient in ways that are not directly reflected in SIP protocol actions, the standardized action of initiating a request implicitly has further consequences which are often not clearly specified. As a result, various SIP call-control proposals assume that a UA receiving a REFER will perform the UA operation that is needed at that moment without specifying clearly how the UA recognizes which UA operation is needed. As a result there are now five semantically distinct defined uses of REFER. All five uses bear a family resemblance, and each involves sending a SIP request, but the exact meaning of each use is logically independent of the others, and the rules by which a UA distinguishes the five cases are at best implicit.


Dale Worley (

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)