Summary

  • RFC 5366 binds request-contained participant lists to the initial INVITE sent to a conference factory. The conference URI returned in Contact is a different resource and does not inherit that list-processing capability for re-INVITEs.
  • A 200 response proves three things: the conference was created, the requesting user agent joined, and the server understood the list. It does not prove that a listed person was invited successfully, admitted, connected to media or present.
  • Participant invitation, focus authorization, each SIP dialog, conference-state observation and usable media are separate receipts. A later list in re-INVITE has no defined semantics and is rejected with 420 when the required extension is asserted.

One request created two kinds of state

RFC 5366 solves a real latency problem. Without it, a user might ask a server to create an ad hoc conference, wait for the new conference address, and then add the initial participants through later operations. The RFC lets the user send the intended participant list with the first INVITE to the conference factory. One request starts the creator's session and asks the server to begin inviting the others.

The apparent simplicity hides two kinds of state. The first belongs to the creator's dialog with the conference server: request, response, Contact, offer, answer and media parameters. The second is a set of downstream operations: one attempted addition for each member of the list, followed by authentication, admission and separate session establishment.

Those states share an origin but not an outcome. A valid list can accompany an unacceptable session description. A successful creator dialog can coexist with failed invitations. One invitee can be admitted while another is unavailable and a third fails policy. The conference may exist for hours after the original list has ceased to describe it.

An evidence system therefore needs a creation record and a participant-operation record, joined by identifiers but never collapsed. The creation record should preserve the factory URI, initial transaction, list hash, conference URI returned in Contact and creator-dialog result. Each participant record needs the normalized target, invitation operation, focus policy version, authentication result, SIP disposition, dialog state and any later conference-state observation.

“Conference created with seven participants” is defensible only if the system can say which event made each of the seven a participant. The factory request supplies candidates. It does not supply the missing events.

The factory address was not the room address

The most consequential line in RFC 5366 is architectural rather than syntactic. The initial INVITE is sent to a conference factory URI. The server's response supplies the actual conference URI in Contact, marked as a focus. A later re-INVITE in the established dialog is sent to that conference URI.

These are not two spellings for the same authority. The factory is a creation resource. It can accept the recipient-list-invite extension and interpret a recipient-list body as the requested initial set. The resulting conference resource manages an existing dialog. At the time of the RFC, a recipient-list body in re-INVITE had no defined meaning.

That distinction defeats a common capability shortcut. A successful OPTIONS response against the factory can show that the addressed factory resource advertises the option tag. It does not prove that every URI on the same host, every future conference or every method phase accepts the same body. Conversely, a 420 response from a conference URI does not prove that the product lacks request-contained list support. It can prove that the client presented the right extension to the wrong resource.

Discovery evidence must retain the queried URI, method, time, response and option tags. A feature flag that says only recipient-list-invite=true is too broad. It loses whether the capability belonged to a factory, a particular tenant, a specific route or the conference that was eventually created.

The new conference URI also creates a binding problem. Operators should retain the initial Call-ID and transaction identifiers, the returned Contact value, focus marker, server identity and the internal conference identifier that connects subsequent state. If the platform cannot explain how a factory decision produced this conference resource, it cannot reconcile invitation attempts or state notifications later.

The 200 response contained exactly three propositions

RFC 5366 is unusually direct about response scope. A 200 response to the initial INVITE means the conference was created successfully, the UAC that generated the request is in the conference, and the server understood the URI list. It provides no information about whether the server brought the other listed users into the conference.

Each word matters. “Understood” is a parsing and service-semantics statement, not a promise that every entry survived normalization or policy. “Created” describes the conference resource, not its population. “The UAC is in” describes the requesting endpoint's relationship with the focus, not the state of people named in the list.

The separation is operationally useful. A server can return promptly after it creates the conference and begins downstream work. It need not hold the creator's transaction open while every invited user rings, redirects, authenticates, rejects or times out. The price is that the creator cannot treat the response as a group admission receipt.

An API or dashboard that maps this 200 to all_participants_joined fabricates evidence. A more honest state model records conference_created, creator_dialog_established and initial_list_understood, then opens one participant attempt per normalized entry. The aggregate view can count attempts, responses, admissions, established dialogs and observed presence separately.

This prevents a particularly damaging dispute. Suppose an organizer submits a list that includes a required decision-maker, receives 200 and starts a meeting. The decision-maker's invitation fails. A system that retained only the initial transaction can prove the room existed, but not that the person was invited correctly or had any opportunity to participate. The missing receipt cannot be reconstructed from the successful factory response.

Attempting to add someone is not admitting them

After creating the ad hoc conference, the server should attempt to add the listed participants as if their addition had been requested through one of the mechanisms described by RFC 4579. “Attempt” is the control-plane action. Admission is a later decision at the focus.

Conferences have rules about who may join, which media they may use and what roles they may hold. The focus must authenticate prospective participants strongly enough to apply those rules. Inclusion in the creator's XML list does not grant the listed identity a conference credential, and it does not require the focus to ignore a ban, media restriction or tenant boundary.

This produces at least four identities that should not be conflated: the authenticated creator, the address written in the list, the endpoint that answers the outbound INVITE and the principal admitted by the focus. Redirects, forwarding, shared addresses and authentication challenges can make them differ. A participant audit should preserve the transitions rather than overwrite the requested address with the final authenticated identity.

The same applies to media. The initial request can carry SDP because the creator and server need an offer-answer exchange. Outgoing invitations create other dialogs with other session descriptions. The creator's successful audio and video negotiation does not prove an invitee's codec agreement, transport path, encryption, rendering or usable media.

A participant row should therefore avoid a single joined Boolean. Better states include requested, normalized, invitation generated, provisional response, final response, authenticated, admitted, dialog established, media negotiated, conference state observed, departed and removed. Not every implementation will observe every step, but unknown is better than inheriting success from a neighbouring transaction.

Re-INVITE was not a second invitation batch

Once the creator's dialog exists, re-INVITE can change characteristics of the media exchanged with the server. It cannot, under RFC 5366, reuse the original recipient-list operation to add another group. No semantics were assigned to recipient lists in re-INVITE, and clients should not send them.

If a client nevertheless sends a re-INVITE with the list and declares the required recipient-list-invite option, the conference resource rejects the unsupported extension with 420 and names the option tag in Unsupported. That response is not a generic conference failure. It is a precise statement about the extension at that resource and phase.

Retry automation must respect the statement. Removing Require and resending the same body would not establish a silent fallback meaning. The body would still lack the conference-list semantics that the client wanted. Redirecting the re-INVITE to the factory would also change the resource and could create another conference rather than modify the existing one.

The recovery path must choose an operation that the conference model actually defines: use an established participant-addition method, or create a new conference intentionally. Record the operator's choice. Automatic syntactic downgrade can turn a clean 420 into an ambiguous action whose effect is impossible to defend.

This is an instance of a broader rule. A protocol extension is not merely a parser feature. Its meaning is scoped by method, target resource and state. Preserving the option tag while changing one of those dimensions does not preserve the operation.

A conference-state feed is an observation, not the factory's delayed answer

RFC 5366 points a client that wants participant status toward general conference mechanisms such as the conference event package. That package gives the focus a way to report conference state. It is a better source than the initial response for learning who the focus currently represents as present, but it is not a timeless attendance ledger.

Conference notifications are versioned observations. They can be full or partial, can arrive late, can be missed during subscription failure and can describe state that changes immediately after emission. A recipient appearing in a notification is stronger evidence than appearing in the original list, yet it still does not prove human attention, audible media or meaningful contribution.

Reconciliation needs the subscription identity, notification version, full-versus-partial status, receive time and the conference identifier bound to the factory result. A partial update without its baseline cannot be treated as a complete roster. A subscription gap should remain visible instead of being filled from invitation intent.

Three ledgers are useful: requested participants from the factory list, invitation/admission operations from the focus, and observed membership from conference state. Differences between them are the investigation surface. They can show a requested user never attempted, an invitation rejected by policy, a joined user who later left, or an attendee added through another mechanism.

The flat list may lose information without losing validity

RFC 5366 uses the RFC 4826 resource-list format but needs only a flat set of URIs. Hierarchical lists and XCAP-relative entry references are not needed. A factory that receives more structure may discard the extra information.

That permission creates another evidence boundary. “The server understood the URI list” does not mean it preserved every annotation or resolved every structure exactly as the sender imagined. The sender should use the defined flat form, and the server should record the normalized list it acted on, along with any unsupported material it discarded.

Copy-control and anonymization affect what outgoing invitees may see about one another. They do not settle whether the server invited or admitted anyone. The prior RFC 5364 analysis owns those disclosure rules. Here they matter only because the history delivered with an invitation can differ from both the source list and actual conference membership.

The clean audit comparison is therefore three-way: submitted flat list, per-recipient disclosed history and later conference state. Treating any one as the other turns intentional projection, parser normalization or temporal change into apparent corruption—or hides a real omission behind the word “list.”

Evidence boundary

The frozen sources establish standards text, registered option-tag vocabulary, protocol roles and normative requirements. They do not show that any named product currently implements RFC 5366, that any real conference was created, that a deployment returns a particular failure, or that a security incident occurred. The RFC's message flows are examples, not captured traffic.

The durable conclusion is narrower. A factory can be authoritative for creating a conference and understanding an initial list. It is not authoritative for every later participant outcome, and the conference resource does not inherit the factory's list operation merely because both belong to one service.