Summary

  • RFC 5368 lets a REFER point to a URI list, after which the REFER-Recipient creates one SIP request for every effective target. Its response accepts or rejects the REFER operation; it does not report the result of those generated requests.
  • The specification recommends norefersub and Refer-Sub: false, deliberately suppressing the implicit refer-event subscription that ordinarily carries message/sipfrag status. A quiet result channel is therefore expected, not proof of success.
  • Evidence must preserve list reference, non-forking precondition, returned Refer-Sub value, normalized target set, every generated transaction and any separate service-specific observation. RFC 8262 later clarified whether the cid: reference names a body part or the whole message body.

The missing notifications were part of the design

SIP REFER has an attractive ordinary story. One user agent asks another to send a request to a third party. The REFER recipient accepts the instruction, initiates the new transaction and reports progress through an implicit subscription. NOTIFY bodies using message/sipfrag can carry a status line from that triggered exchange.

That story stops scaling cleanly when one REFER names many targets. There is no single downstream transaction whose status can represent the set. One target may accept, another may reject, a third may time out and a fourth may redirect. Ordering can change. Some transactions can still be active after others finish. Compressing them into one status line would erase which proposition belonged to which target.

RFC 5368 responds with restraint. It defines multiple-refer so the REFER recipient knows that the Refer-To header points to a resource list. It then recommends norefersub and, where appropriate, Refer-Sub: false. The recipient should honor the request, return Refer-Sub: false in its successful response and avoid creating the implicit subscription.

The protocol did not forget to report results. It declined to make a result channel promise that the defined subscription could not fulfil. The issuer must use a mechanism owned by the application. In a conference, that may mean subscribing to conference state. In another service, it may require a different event package or an operational ledger.

This distinction matters for dashboards. A field such as refer_complete=true is ambiguous unless its contract says whether “complete” means the REFER transaction was accepted, all target requests were emitted, every target transaction ended, the requested application state appeared, or a human outcome occurred. RFC 5368 supplies none of those equivalences.

A 202 arrived before the work it requested

The RFC's example makes the ordering visible. A conference moderator sends one REFER asking a conference server to send BYE requests to several participants. The server returns 202 Accepted. Only afterwards does it originate the individual BYE requests.

The 202 is therefore incapable of being their final receipt. It belongs to the relationship between issuer and REFER recipient. It says the recipient accepted responsibility for attempting the operation under its local rules. It does not say that each target was reachable, that the BYE matched a live dialog, that the remote endpoint accepted it or that the participant disappeared from the conference.

The same boundary holds when a deployment returns 200 under the suppression extension. A successful response can confirm that the recipient understood and accepted a multi-target REFER without establishing an implicit subscription. The returned Refer-Sub value is itself evidence: false confirms suppression; absence or true means the recipient did not grant the suggestion and the ordinary subscription rules apply.

An audit record should therefore store the request and response as a negotiation pair. Recording only what the issuer asked for loses whether the recipient agreed. Recording only the 2xx loses the required option tags, the list reference and the intended method. The receipt is the pair, scoped to the REFER transaction.

Silence after Refer-Sub false proved no target outcome

Silence often gets interpreted as completion because an operator has seen ordinary REFER traffic before. Under RFC 5368, that is unsafe. Refer-Sub: false means no implicit refer-event subscription and therefore no required stream of target-status NOTIFY messages through that path.

This creates three different kinds of absence. The first is expected silence because suppression succeeded. The second is a missing notification on a subscription that should exist. The third is absence of application state because no target operation achieved the desired effect. They require different evidence to distinguish.

The most dangerous implementation shortcut is to promote expected protocol silence into aggregate success. A queue worker receives 202, sees no NOTIFY error and closes every target as completed. The system has manufactured positive evidence from a deliberately removed channel.

A safer ledger opens a parent operation for the REFER and a child operation for every effective target. The parent records acceptance and subscription disposition. Each child records generation, method, dialog context, network response and any service observation. Unknown remains unknown until the relevant surface supplies a receipt.

Suppression depended on one recipient, not a fork

RFC 4488 places a condition on Refer-Sub: false: the issuer can use it only when it is certain that the REFER will not fork. The implicit subscription helped an issuer discover multiple dialogs created by a forked REFER. Suppressing that subscription while allowing forking would remove the mechanism that exposes the branches.

RFC 5368's flow uses a globally routable UA URI to make the non-forking assumption explicit. That address choice is not decorative. It is part of the proof that one response and one returned Refer-Sub value belong to the recipient that will perform the list operation.

This is a useful warning for service meshes and routing layers. A stable service name can still fan out internally. From the SIP issuer's perspective, “no fork” is a protocol property, not an assertion that a load balancer will eventually choose one worker. If the request can reach several independent user agents, suppression can hide divergent dialogs rather than merely reduce redundant traffic.

Evidence should include the Request-URI, route set, GRUU or equivalent non-forking basis, response branch and recipient identity. A feature flag saying only norefersub=true omits the condition that made its use safe.

A cid URL connected authority to exact bytes

The REFER does not place the target list directly inside the Refer-To value. Refer-To carries a Content-ID URL, and the request body contains the resource list. This indirection lets a control header identify the bytes that define the operation.

That binding must be exact. The record needs the Content-ID URL, the corresponding identifier, MIME framing, body hash, content type and content disposition. If a gateway rewrites multipart boundaries, moves a part or changes an identifier, it must preserve or regenerate the reference coherently. Otherwise the header may point nowhere or to different content.

RFC 8262 exposes why examples are not enough. Earlier specifications including RFC 5368 showed a complete message body being labelled and referenced even though the existing rules had specified references to body parts. Implementers treated the example as permission. RFC 8262 later supplied normative language allowing the Refer-To pointer to identify either a body part or the complete message body and permitting a MIME or SIP Content-ID field.

The later update does not make every historical packet retrospectively unambiguous. A verifier must know which rule set the implementation followed, whether the identifier was attached to a part or the full body, and what exact bytes were resolved. “The cid matched” is too weak if the object boundary is unknown.

One target list did not create one method semantics

The list format can carry copyControl and anonymization attributes inherited from RFC 5364. Those attributes make sense only where the triggered method gives them meaning. A role such as to, cc or bcc can shape an INVITE's disclosed recipient history. It has no useful role in a mid-dialog BYE.

This is another reason the REFER recipient must understand the application and method. RFC 5368 says it must not accept methods it does not understand and should operate only within an application context it knows. The recipient is not a generic request amplifier. It makes a local decision about whether the requested method, targets, dialog state and permissions form a valid operation.

List parsing success is therefore not execution authorization. Support for multiple-refer proves a capability vocabulary. Authentication identifies the issuer. Authorization decides whether that issuer may request this method in this application. Target opt-in and dialog ownership constrain the child transactions. Those receipts are related but not interchangeable.

Duplicate normalization must remain visible too. The issuer should avoid repeating a URI, and the list service must avoid duplicated requests using the framework's comparison rules. The submitted list, normalized set and emitted transaction set can differ without corruption. A count should name which set it counts.

Conference state was a different camera

RFC 5368 suggests conference state as one way for a moderator to learn what happened after multi-target INVITE or BYE operations. That feed can show the focus's current representation of participants. It is better evidence of conference membership than the original REFER response.

It is still a different camera. Conference notifications can be full or partial, versioned and separated by subscription gaps. A participant disappearing after a BYE request supports an application-level inference, but does not preserve every network step. The endpoint may have left independently, another controller may have removed it, or the observer may have missed the transition.

Reconciliation should join, not collapse, the ledgers: requested target, generated transaction, target response and observed application state. Differences are useful. They show a request that was accepted but never emitted, a transaction that completed without the expected state change, or a state change with no matching operation.

Evidence boundary

The defensible statement after a successful multi-target REFER is narrow: a particular recipient accepted a request whose Refer-To resolved to a particular normalized list, under particular option-tag and subscription terms. Nothing in that statement claims that every child request was sent or succeeded.

For each operation, preserve:

  1. issuer identity, authorization decision and application context;
  2. Request-URI and proof that suppression was safe from forking;
  3. exact REFER bytes, option tags and returned Refer-Sub value;
  4. Content-ID reference, framing and list hash;
  5. submitted and normalized target sets, including duplicate resolution;
  6. one child record per generated request, with method and dialog binding;
  7. each downstream response or timeout;
  8. service-specific observation with version and receive time;
  9. any business or human outcome as a separate claim.

The result is not more bureaucracy. It is the minimum structure required to prevent a request receipt from impersonating the work it initiated.