Summary

  • RFC 3524 added SRF to SDP so named media lines could request one shared resource-reservation flow instead of separate flows.
  • The grouping line carried mapping intent. Admission, policy approval, classifier and scheduler state, refresh survival, packet treatment and rendered media remained separate events.

The attractive part of a=group:SRF 1 2 was its compactness. Two media descriptions—perhaps audio and video—could be named with mid values and placed inside one Single Reservation Flow group. A remote user agent no longer had to infer whether it should ask for one reservation or two. The signalling document carried the sender's requested grouping.

That did not make the SDP a resource allocator. RFC 3524 opened by distinguishing media streams from resource-reservation flows. A multimedia session could put every stream into one reservation flow, give every stream a separate flow, or mix the two arrangements. SRF selected one relationship among those possibilities. It did not supply bandwidth, select a route or configure a scheduler.

The normative verbs preserved the distinction. Media lines in an SRF group SHOULD be mapped into the same reservation flow. Lines outside that group SHOULD NOT be mapped into it. A group could even contain one media line. These were instructions to a compliant endpoint about constructing a reservation request, not a report that the network had accepted one.

The grouping framework supplied the addressing machinery. Each media description had a unique mid; the group line referred to those identifiers under a named semantics. An unresolved identifier did not acquire force merely because it appeared in a group line. Later RFC 5888 retained this structure, and modern SDP continued the extension rule that an unsupported attribute is ignored. Syntax could therefore arrive without operational effect.

RFC 3524 was most useful when the remote party had to participate in reservation. If the session-description generator could allocate both directions itself, it could choose a mapping without SRF. If the remote party received the same audio and video lines without the group line, it was free to create two different RSVP sessions. The token localized a choice; it did not centralize the rest of the resource process.

SIP and RSVP appeared in the worked example, but the document explicitly allowed other signalling and reservation mechanisms. This matters historically. SRF belonged to the descriptive layer. The implementation selected the machinery that would attempt to realize it.

RSVP shows how much still remained. A receiver sent a Resv carrying a flowspec for desired QoS and a filter spec selecting the packets. At every participating node, admission control asked whether sufficient resources were available. Policy control separately asked whether the request was permitted. If either check failed, the requested state was not installed there. Only after success could the packet classifier and scheduler be programmed.

Even success was temporal. RSVP maintained soft state through Path and Resv refreshes. A route change could build state along a new path while unused state on the old path expired. A grouping line had no knowledge of those transitions. It could remain byte-for-byte valid while the resource path disappeared beneath it.

RFC 2205 made the evidentiary limit sharper: receipt of a ResvConf gives no guarantees. A confirmation could be produced at one point and followed by a reservation error when later competition or merging changed the result. If even the reservation protocol's confirmation was bounded, an earlier SDP grouping declaration could not reasonably be treated as service proof.

RFC 3312 introduced a separate vocabulary of current and desired QoS preconditions. That design would be unnecessary if describing the wanted state made it current. The SRF group answered “which media should share a reservation?” It did not answer “has the required reservation been established in each direction?”

The security section reveals the control surface. An attacker who inserted SRF lines could force an endpoint to create more or fewer reservation flows than required. Too many could consume endpoint resources; too few could degrade session quality. Integrity protection was therefore strongly recommended, with S/MIME named for SIP-carried SDP.

Integrity solved an authorship problem. It could show that the grouping instruction had not been altered. It could not create free capacity, compel policy approval, repair an unsupported endpoint, keep RSVP soft state refreshed, make packets conform to the filter or prove that a decoder rendered useful audio and video.

The IANA registration of SRF performed another narrow job. It gave implementations one shared token and reference. The registry did not observe a live offer, one accepted mapping or one installed reservation. Publication coordinated meaning; adoption and execution remained with participants running code.

That is the durable history in RFC 3524. A thin shared expression let independent endpoints coordinate a resource-accounting choice without pretending that the expression owned the network. Operators should preserve the receipts in order: valid SDP, resolved membership, authenticated intent, chosen reservation mapping, request transmission, per-hop admission, installed state, surviving refresh, classified packets and observed media. Collapsing them into “SRF present” turns a useful design hint into fictional capacity.

Sources