The Session Initiation Protocol (SIP) Refer Method
updated by
Extracted elements (24)
Early versions of REFER required the agent to wait until the referenced action completed before sending a final response. This was infeasible due to non-INVITE transaction timeout rules in RFC 3261, which require a final response within the transaction lifetime. The current design uses an immediate 202 Accepted plus asynchronous NOTIFYs instead.
The REFER method evolved from the TRANSFER method and then from BYE/Also (draft-ietf-sip-cc-01). The change to REFER improved on BYE/Also by disassociating transfers from BYE processing, facilitating recovery from failed transfers and clarifying state management.
A REFER sent within an existing dialog will not fork. A REFER sent outside the context of a dialog MAY fork and, if accepted by multiple agents, MAY create multiple subscriptions. The agent sending the REFER manages each subscription separately and does NOT merge state from separate subscriptions.
SIP proxies do not require modification to support the REFER method; a proxy should process a REFER request the same way it processes an OPTIONS request. A registrar unaware of REFER returns 501; a registrar aware of REFER SHOULD return 405.
A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog.
A REFER request MUST contain exactly one Refer-To header field value. An agent responding to REFER MUST return a 400 (Bad Request) if the request contained zero or more than one Refer-To header field values.
A UA accepting a well-formed REFER request SHOULD request approval from the user to proceed. If approval is granted, the UA MUST contact the resource identified by the URI in the Refer-To header field value.
A UA not capable of accessing non-SIP URIs SHOULD NOT accept REFER requests to them.
An agent acting on a REFER request SHOULD NOT issue a CANCEL to any referenced SIP requests because the agent sending the REFER terminated its subscription to the refer event before the referenced request completes.
Each NOTIFY MUST contain an Event header field with a value of 'refer' and possibly an id parameter. Each NOTIFY MUST contain a body of type 'message/sipfrag'.
For the second and subsequent REFER requests a UA receives in a given dialog, it MUST include an id parameter in the Event header field of each NOTIFY containing the CSeq sequence number of the associated REFER. A SUBSCRIBE sent to refresh or terminate this subscription MUST also contain this id parameter.
If no final response has been generated, the UA MUST return a 202 Accepted response before the REFER transaction expires. If a REFER request is accepted (2xx response), the recipient MUST create a subscription and send notifications of the status of the refer.
NOTIFYs to event refer SHOULD NOT be sent more frequently than once per second.
REFER is the only mechanism that can create a subscription to event refer. If a SUBSCRIBE request for event refer is received for a subscription that does not already exist, it MUST be rejected with a 403.
The final NOTIFY sent in response to a REFER MUST indicate the subscription has been 'terminated' with a reason of 'noresource', because the resource being subscribed to is the state of the referenced request.
The NOTIFY mechanism MUST be used to inform the agent sending the REFER of the status of the reference. The dialog identifiers (To, From, and Call-ID) of each NOTIFY must match those of the REFER as they would if the REFER had been a SUBSCRIBE request.
The body of each NOTIFY for event refer MUST be of type 'message/sipfrag' and MUST begin with a SIP Response Status-Line. The response class indicates the status of the referred action. The refer event package does not support state deltas.
The REFER method is a SIP extension that requests the recipient to contact a third party using contact information provided in the request. It implicitly establishes a subscription to the 'refer' event and follows the same protocol as BYE for emitting and responding.
The Refer-To header field is a request-header that appears only in REFER requests. Its syntax is: Refer-To = ('Refer-To' / 'r') HCOLON ( name-addr / addr-spec ) *(SEMI generic-param). It provides a URL to reference and may be encrypted as part of end-to-end encryption.
The subscription duration for an implicit subscription created by REFER is initially determined by the agent accepting the REFER and communicated in the Subscription-State header field's expire parameter in the first NOTIFY. The duration SHOULD be chosen to be longer than the time the referenced request will be given to complete.
This document registers a new SIP method name (REFER) in the SIP method sub-registry, a new SIP header field (Refer-To) with compact form 'r' in the SIP header sub-registry, and an event package named 'refer' under the SIP event package registry.
Authorization for REFER requests requires care: a UA should prompt the user with the full URI before acting on it, since display names in Refer-To may be misleading (e.g., 'president' may map to an unrelated telemarketing URI). Pre-configured policy may authorize certain classes of REFER (e.g., call transfer within an existing dialog to sip:/sips:/tel: URIs) without interactive prompting.
Automated action on arbitrary URIs in Refer-To (especially non-SIP schemes) risks being used to indirectly attack hosts vulnerable to scheme-specific flaws. Agents behind a firewall are at heightened risk since automated URI access can bypass the firewall's protective boundary and increase denial-of-service exposure through resource exhaustion.
Returning full SIP responses in NOTIFY message/sipfrag bodies can circumvent privacy and confidentiality: an attacker can send a REFER to probe whether a target is reachable (leaking presence and UA identity) or to extract server version strings from internal resources. Implementers should return minimal sipfrag bodies (e.g., '200 OK' or '503 Unavailable') to limit information exposure.