Summary

  • In RFC 3515, a successful response to REFER meant the recipient accepted responsibility for processing the instruction and reporting status; it did not mean the referred request had succeeded.
  • The implicit subscription, message/sipfrag NOTIFY stream and referred action had separate lifetimes. Ending observation did not cancel execution, and forked subscriptions could not be merged.

The familiar call-transfer story makes SIP REFER look almost instantaneous. Alice tells Bob to contact Carol; Bob accepts; Carol is reached. RFC 3515 used that example, but its protocol did not compress those events into one response. It constructed a chain of transactions precisely because the instruction, the attempt, the report and the human outcome could diverge.

Published in April 2003 on the Standards Track, RFC 3515 defined three pieces together: the REFER method, the Refer-To request header and the refer event package. The method asks the recipient identified by the Request-URI to contact the resource named in Refer-To. A well-formed request contains exactly one such header value. The resource is then contacted through the ordinary mechanism for that URI type.

That last clause made REFER broader than call transfer. A SIP URI could lead to a new INVITE; another URI scheme could trigger a different protocol. RFC 3515 even allowed a REFER body while assigning it no meaning of its own. A recipient could interpret the body through its Content-Type, but the REFER contract itself did not turn arbitrary payload into standardized instructions.

The recipient first had to decide whether to accept. It could reject malformed syntax, unsupported URI handling, failed authentication or policy. For a well-formed request, it should obtain user approval or satisfy approval through configured policy. If no earlier final response applied, the original specification required a 202 Accepted before the REFER transaction expired.

The word “Accepted” is where operational histories often run too fast. It closed the question of whether the recipient had accepted the REFER transaction. It did not say that the new INVITE had received a final 200, that a non-SIP resource had answered, that media flowed, that Carol spoke, or that a transfer achieved its business purpose. Indeed, the referred request might not yet have been sent.

Under RFC 3515's original contract, a 2xx response also required the recipient to create an implicit subscription to the refer event and send notifications. The notification channel was not ornamental. It carried the status that the REFER response could not truthfully supply.

The first NOTIFY followed subscription rules and could arrive before the REFER transaction itself completed. A sender therefore had to handle apparent temporal inversion: the observation stream might begin while the instruction exchange was still closing. A pending notification could contain only SIP/2.0 100 Trying. That line reported a current state; it was not evidence that the target had been reached.

Each NOTIFY carried Event: refer and a message/sipfrag body beginning with a SIP response status line. The response class represented the status of the referred action. RFC 3515 described each body as a complete statement at that reporting point, not a state delta that depended on reconstructing every earlier message.

A minimal implementation could report 100 for pending, 200 for success, 503 for failure or 603 when approval was denied after the REFER had already been accepted. The sequence explains why the initial 202 was deliberately weaker than action success. Acceptance could precede user approval; the delegated operation could later fail; a final report could reverse the optimistic story attached to the first response.

There were two distinct 200-class messages to keep apart. A user agent receiving NOTIFY answered that NOTIFY transaction with its own 200 OK. That acknowledgment meant the status report was received. It did not adopt the response code embedded inside the message/sipfrag body, and it did not prove the referred action. Protocol traces that label both lines merely “200” can erase this distinction.

For a SIP referral, an implementation could include more of the referenced SIP response inside the fragment, perhaps to aid debugging. RFC 3515 warned that doing so could have grave security repercussions. A report can disclose headers, topology or details that the referrer was not entitled to learn. More telemetry is not automatically more authority or safer observability.

For a non-SIP resource, the notifier still had to express status as a SIP response status line. That mapping was useful for one event package, but it was necessarily an adapter's account. A SIP 200 in the notification could summarize another protocol's result without preserving its native receipts, exact target, side effects or physical outcome.

The subscription had its own lifetime. REFER carried no subscription duration in its request or response. The accepting agent chose a duration and announced it in the first NOTIFY, ordinarily long enough for the referred request to complete. The referrer could refresh the subscription or terminate it early.

Crucially, ending observation did not end the action. RFC 3515 says that explicitly unsubscribing or rejecting NOTIFY is not an indication that the referenced request should be withdrawn or abandoned. The recipient should not send CANCEL merely because the referrer stopped following the refer event. A monitoring relationship and an executing operation were separate control surfaces.

This is more than a SIP curiosity. Systems often mistake “stop sending me updates” for “stop doing the work,” or treat the disappearance of a dashboard row as proof that a job ended. RFC 3515 made the opposite choice: subscription control governed reporting; the referred request retained its own transaction semantics.

Forking added another separation. A REFER inside an existing dialog would not fork under the document's rules. An out-of-dialog REFER could reach multiple accepting agents and create multiple subscriptions. The issuer had to manage each subscription independently and not merge their state. One agent's 200 and another's 503 were not a single averaged outcome; they described different attempted actions by different recipients.

Dialog identifiers connected each NOTIFY to its REFER-created subscription, but correlation was not the whole security model. The recipient still needed to authorize who could cause it to contact which resource. A careless policy could turn REFER into a way to reach protected SIP, HTTP or other targets from a trusted position. Refer-To construction therefore had to restrict protected resources appropriately.

Later RFCs changed the shape of the observation channel. RFC 4488 allowed an issuer to request that the implicit subscription be suppressed. RFC 7614 defined explicit subscriptions. RFC 7647 clarified REFER behavior under the event framework updated by RFC 6665, and RFC 8217 refined relevant SIP syntax. These updates matter, but none makes acceptance and outcome identical. If anything, optional and explicit observation make it more important to record which contract governed a trace.

Heng Lu's distinction between symbolic and operational reality is useful here. A 202 is a symbolic receipt for a particular responsibility. A NOTIFY is a report from a named notifier within a subscription. The referred request runs under its own protocol. Media, speech, human consent and business completion occupy still later observation layers. A correct message at one layer cannot manufacture the receipts of the next.

The evidence ladder therefore begins with a valid REFER and authorized issuer. It proceeds to the REFER response, the subscription identity or negotiated absence of one, the exact referred request, correlated progress reports, a final protocol response, and finally an application or human outcome. Skipping a rung changes a bounded protocol fact into a claim the trace cannot support.

RFC 3515's design lesson is not that delegation is unreliable. It is that delegation needs separate records for instruction, observation and execution. The REFER was accepted. That was real and useful. The action still had to happen somewhere else, and success needed its own proof.

Sources