Summary

  • RFC 5359's service flows are reviewed companion examples, while the SIP specifications and referenced extensions remain definitive. The document explicitly permits other architectures and simplifies message fields for readability. A diagram can seed a test, but it cannot be replayed as literal wire evidence.
  • Content-Length: ..., non-real Digest responses, reused Call-IDs, reset CSeq values and normalized headers identify an editorial layer. Before execution, an implementation must create unique identifiers, exact bytes, real authentication material and state that every parser and transaction machine can validate.
  • Signaling receipt, peer identity, group membership, feature authorization, dialog transition, SDP negotiation, media delivery and user-visible outcome are separate receipts. A BCP example and a matching sequence of arrows do not prove that a call was secure, audible, transferred or correctly cleaned up.

The ellipsis is an honest boundary

A parser cannot receive three dots in place of a calculated body length and pretend the example has become a packet. RFC 5359 uses that notation deliberately to keep long call flows readable. The same editorial choice appears in Digest values that are not actual MD5 encodings, Call-IDs that may be reused across examples, CSeq values that often begin at one and headers presented in a regular order.

These choices do not weaken the document. They tell the reader what sort of artifact it is. The flow preserves relationships among methods, responses, dialogs and media transitions while abstracting away bytes that an implementation must generate afresh.

Trouble begins when a test harness copies the visible message and reports conformance because the intended arrows appeared. A real request needs an exact length, unique branch and dialog identifiers, a valid authentication response, correct route state, implementation-specific headers and a body whose bytes match its declaration.

The transformation from example to fixture needs its own receipt. Record the source section and revision, each substituted value, the generator version, the final byte hash and the reason every omission was filled. Without that ledger, a green test can mean only that a permissive harness recognized its own reconstruction.

Working-group review strengthens the example, not its monopoly

RFC 5359 describes the scenarios as carefully checked and working-group reviewed. That matters. It distinguishes the flows from an arbitrary blog diagram and makes them useful common reference points for designers and researchers.

The same section says the SIP specification and referenced documents are definitive for protocol issues. It also says these flows are not the only way to implement the services. Third-party call control, B2BUAs and other approaches remain possible.

Those statements are not tension to be resolved by choosing one. Review supports the coherence of the illustrated path; the referenced specifications define protocol obligations; deployed architecture selects a path; execution produces evidence about one run.

BCP status likewise does not turn every arrow into a mandatory topology. It identifies practice guidance for the Internet community. It does not prove that a named product implements a feature, chooses the peer-to-peer pattern, interoperates with another product or delivers the intended user experience.

An audit should therefore name whether it is checking fidelity to one RFC 5359 scenario, conformance to the underlying specifications, compatibility with a deployment architecture or success of a service. Those are related but different questions.

A message sequence needs a state sequence

The diagrams make a complex conversation visible. Mandatory control messages use one line style, optional messages another, and media paths a separate double line. Labels such as F1 and F2 connect each arrow to detailed example content.

An arrow confirms neither acceptance nor durable state. A request can reach a parser and fail transaction matching. A response can arrive after the relevant state has changed. A proxy can forward correctly while an endpoint rejects an option. A dialog can be created and then leave an orphan after the feature appears complete.

Executable verification must join message bytes to transaction, dialog, subscription and media state at each participant. It should preserve event time, role, direction, unique identifiers, route set, tags, CSeq, branch, authentication decision and resulting state transition.

Otherwise a trace can look visually similar to the example while breaking the property the example was meant to explain. Sequence similarity is not state-machine equivalence.

Architecture is part of the result

Many RFC 5359 flows place feature behavior in user agents with help from proxies. Yet the document does not preclude a B2BUA or 3pcc controller. Those choices move custody and decision points.

A proxy-oriented trace may preserve end-to-end dialog relationships that a B2BUA terminates and recreates. A 3pcc controller may generate offers, answers and call-control actions that the endpoints did not originate. The user-visible service can look similar while the evidence path differs.

For that reason, an implementation report must name every role and termination boundary. It should say which component generated each identifier, authenticated each peer, made each authorization decision, transformed SDP and observed media.

Calling all architectures “the RFC 5359 flow” erases the very information needed to debug or assign responsibility. The document supplies examples across a design space; it does not collapse that space into one authority model.

Signaling and media are different receipts

RFC 5359 emphasizes SIP signaling. Its SDP exchanges are intentionally simple, usually showing audio, and it directs readers elsewhere for more advanced offer/answer examples. The diagram gives media its own line style because media is not merely another SIP response.

A successful INVITE transaction and 200 response can establish signaling state while media fails because of address selection, codec mismatch, policy, firewall behavior, ICE or transport conditions outside the simplified scenario. A hold re-INVITE can be accepted while one endpoint renders, suppresses or misdirects audio differently from expectation.

Call hold is directional. The party placing the peer on hold commonly stops sending too, but that common behavior is not the definition of every direction. RFC 5359 also identifies the older 0.0.0.0 connection-address technique as deprecated in favor of a=inactive when no media is sent or a=sendonly when it is.

The evidence set should separately record the offer, answer, negotiated direction, selected media addresses and codecs, packet counters in each direction, rendering state and user observation. “The signaling matched” is not an audible call receipt.

sips is an assumption in the example, not a captured handshake

The flows use Secure SIP URIs throughout, implying TLS on each hop with assumed certificate validation. RFC 5359 also notes that other security approaches can be used and shows Digest authentication in some examples.

The word “assumed” marks another evidence boundary. The document does not contain the certificate chain, hostname decision, trust store, negotiated TLS properties, peer mapping or application authorization of a current exchange.

A deployment may render the same sips URI while failing certificate verification, terminating TLS at a different boundary or mapping the authenticated hop to an unexpected application identity. Conversely, a different protected architecture may satisfy relevant requirements without looking exactly like the example.

Security evidence must be collected from the running path: handshake transcript or bounded equivalent, certificate and validation result, authenticated identity, protected hop boundaries, Digest challenge and response state where used, and the authorization that followed. Typography in a call flow cannot supply those receipts.

Group membership is a privilege decision

Several services rely on a user agent being part of a group: a department, home extension set or call center. Members may receive privileges unavailable to outsiders, including detailed dialog information needed for call pickup.

RFC 5359 requires group members to be authenticated through normal SIP means such as certificates or shared secrets. Authentication alone still does not define the group or grant the feature. A directory, policy system or endpoint must map the identity to membership and the membership to a permitted action.

A call-pickup arrow can therefore be protocol-correct and operationally unauthorized. A dialog notification can be authentic and still disclose more state than the recipient should see. The flow shows how a feature can proceed once prerequisites hold; it does not provide the current membership ledger.

Retain identity proof, membership source, policy version, requested privilege, authorization decision and disclosed dialog fields. When access is denied, retain that result too rather than rewriting the scenario as a transport failure.

REFER acceptance is not a completed transfer

REFER asks a recipient to access a referred resource and, when accepted, creates event state for reporting progress. A 2xx response proves acceptance of the request at that stage. It does not prove that the new target answered, media moved, the original dialog ended or the user intended the final topology.

NOTIFY messages carry later status, but even a successful notification describes protocol progress rather than everything a user heard or saw. A transfer can establish a new dialog and fail cleanup of the old one. It can reach the correct address yet violate a policy about who may redirect whom.

The transfer ledger needs the authenticated referrer, Refer-To value, authorization decision, subscription, each NOTIFY, replacement-dialog identifiers, old-dialog termination, media observation and user-visible result.

This separation prevents the first positive response from borrowing evidence from steps that have not happened. It also makes partial success visible instead of forcing the entire feature into one Boolean.

Replaces and Join name relationships, not permission

The Replaces header identifies an existing dialog to be logically replaced by a new one. Join identifies an existing dialog to be joined with a new one. These primitives enable attended transfer, pickup, conferencing and related behavior.

Correct tags and Call-ID can identify a target dialog. They do not establish that the requester is allowed to replace or join it. Extension-specific security rules, authenticated identity, group privilege and local policy remain active.

This matters because detailed dialog identifiers themselves can be sensitive. RFC 5359's group examples assume a reason to share dialog information; a deployment must prove that the subscriber and actor belong in that trust boundary.

Record lookup, identity, policy, dialog match, extension decision, resulting state and media consequence separately. A header that points to the right object is an addressing receipt, not an authority receipt.

Later event work changes the normative environment

RFC 5359 references the SIP Events framework then defined in RFC 3265. RFC 6665 later obsoleted that document after implementation experience while providing a backward-compatible improvement and updating related behavior.

That history does not invalidate the examples or automatically upgrade them. It means a current implementation review must identify which normative documents and extension versions govern the tested path.

The same restraint applies to every later update. A publication relationship proves documentary evolution; it does not prove that a product implemented the change or that an old trace can be reinterpreted without evidence.

The captured RFC Editor errata page for RFC 5359 displays one Rejected report and no displayed Verified, Held for Document Update or Reported group. That dated snapshot belongs beside the source record. It is not proof that the examples are error-free and not permission to incorporate an unaccepted report silently.

A diagram can become a test only through a recorded compiler

The safest use of RFC 5359 in automation is to treat it as high-quality source material for generated scenarios. A scenario compiler can turn roles, methods, responses and checkpoints into concrete messages tailored to an implementation.

That compiler is part of the evidence chain. It chooses identifiers, fills lengths, produces authentication material, handles optional branches, maps roles to components, decides timers and defines what counts as success.

Its output should be versioned and hashed. Assertions should distinguish parser acceptance, transaction progression, dialog state, authorization, media and cleanup. Negative cases should test forbidden group access, malformed bodies, stale dialog identifiers, failed certificates and incomplete transfer rather than only the happy path.

When a test fails, preserve the generated bytes and state observations. Regenerating until green without retaining the failure would convert the example into an oracle whose interpretation changes invisibly.