Source record · tier 1 standards and regulators
RFC 3515 — The Session Initiation Protocol (SIP) Refer Method
- Publisher
- IETF / RFC Editor
- URL
- https://www.rfc-editor.org/rfc/rfc3515.html
- Published
- 2003-04
- Updated
- unknown
- Accessed
- 2026-09-16
- HTTP status
- 200
- License
- IETF Trust / BCP 78; permitted with the RFC's own copyright and license notices intact
Source notes citing this source
- The Refer-To header field carries the URL being referenced and appears only in a REFER request, and RFC 3515 states that the Contact header field is part of the Route and Record-Route mechanism and is not available to indicate the target of the reference. in context
- If no final response has been generated, the user agent receiving a REFER must return a 202 Accepted before the REFER transaction expires, and if the REFER is accepted with any 2xx the recipient must create a subscription and send notifications of the status of the refer. in context
- A user agent accepting a well-formed REFER should request approval from the user to proceed, which may be satisfied interactively or from configured policy, and may decline the request if that approval is immediately denied; RFC 3515 also says a user agent not capable of accessing non-SIP URIs should not accept REFER requests to them. in context
- A REFER request implicitly establishes a subscription to the refer event, creates a dialog and so must contain a single Contact header field value, may be placed outside the scope of a dialog created with an INVITE, and when sent inside an existing dialog must follow that dialog's Route and Record-Route logic. in context
- A REFER request must contain exactly one Refer-To header field value, and an agent responding to a REFER must return 400 Bad Request if the request contained zero or more than one. in context
- Creating a subscription always results in an immediate NOTIFY, and the agent that issued the REFER must be prepared to receive a NOTIFY before the REFER transaction completes. in context
- REFER is the only mechanism that can create a subscription to the refer event, and a SUBSCRIBE request for event refer received for a subscription that does not already exist must be rejected with a 403. in context
- RFC 3515 gives a minimal but complete set of 4 NOTIFY bodies: SIP/2.0 100 Trying while the subscription is pending, SIP/2.0 200 OK if the reference succeeded, SIP/2.0 503 Service Unavailable if it failed, and SIP/2.0 603 Declined where the REFER was accepted before approval could be obtained and approval was then denied. in context
- Every NOTIFY reporting a refer must carry an Event header field with the value refer and a message/sipfrag body that begins with a SIP Response Status-Line whose response class indicates the status of the referred action, and the refer event package does not support state deltas so each body is a complete statement of status. in context
- A REFER transaction carries no subscription duration in either the request or the response; the lifetime of the subscribed state follows the progress of the referenced request, and the duration is chosen by the agent accepting the REFER and communicated in the initial NOTIFY's Subscription-State expires parameter, which an agent unwilling to hold state may use to terminate the subscription immediately. in context
- Terminating a refer subscription, either by unsubscribing or by rejecting a NOTIFY, is not an indication that the referenced request should be withdrawn, and RFC 3515 states that an agent acting on a REFER should not issue a CANCEL to the referenced request because the referring agent ended its subscription before that request completed. in context
Cite this source record
APA
WarmTransfer. (n.d.). RFC 3515 — The Session Initiation Protocol (SIP) Refer Method. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-3515-refer
BibTeX
@misc{warmtransfer-rfc-3515-refer,
title = {RFC 3515 — The Session Initiation Protocol (SIP) Refer Method},
author = {{WarmTransfer}},
year = {2003},
url = {https://warmtransfer.net/knowledge/sources/rfc-3515-refer},
note = {IETF / RFC Editor, accessed 2026-09-16}
}