Summary

  • In RFC 5188, mode-set-recv and recvmode communicate receiver preferences. A conformant remote sender may ignore them, so their presence in an SDP answer is not an encoder-execution receipt.
  • sendmode announces current sender state, but RTP media can arrive before the first or updated SDP declaration. Proving what happened therefore requires a joined timeline of offer, answer, encoder transition, packet and decoder evidence.

The answer was clean. The payload number resolved to EVRCWB0. The receiver's line requested mode 0. A policy engine marked the negotiation compliant and the service record later called the stream “wideband as requested.”

The sender was running mode 4.

That is not necessarily a protocol violation. It is the exact gap RFC 5188 leaves on purpose. The receive-side parameter communicates a preference, not a command that transfers control of the remote encoder. The sender may ignore the request, and the receiver is expected to continue decoding. A system that turns preference into a binary enforcement result has invented authority the protocol did not grant.

Three statements, three owners

RFC 5188 gives EVRC-WB a receive-only mode-set-recv parameter. It gives EVRC-B a receive-only recvmode parameter. Each tells the remote sender what the local decoder would prefer to receive. The EVRC-WB form can contain a set because more than one mode may be acceptable.

The same specification defines the send-only sendmode parameter. This is the sender's announcement of its current encoder mode. It is a different statement made by a different owner in the opposite direction.

The third state is running code: the mode that the encoder applied to a particular frame. Neither a request nor an announcement should speak for that execution event without a time-correlated receipt. If the service stores only the final SDP blob, it retains two symbolic statements and discards the fact that could reconcile them.

Direction matters. A receive-mode preference has no useful role on a sendonly stream, because that endpoint is not receiving the media whose mode it purports to prefer. Conversely, sendmode is not useful on a recvonly stream. Copying every known parameter into every direction produces syntactically plausible metadata with no coherent authority.

Preference is not noncompliance

The standard says the remote sender may ignore mode-set-recv and recvmode. It also says the receiver can continue decoding when the sender chooses a mode outside the preferred set. That is why an example can show willingness to receive EVRC-B mode 0 while the answerer chooses to send mode 4.

The operational lesson is not that preferences are useless. They can steer bandwidth, narrowband compatibility or local resource policy. The lesson is that their outcome vocabulary must be honest:

  • requested and honoured;
  • requested and knowingly declined;
  • requested but peer capability is legacy or unknown;
  • request was directionally inapplicable;
  • sender state was announced but not yet observed;
  • sender state was observed in media without a current declaration.

Collapsing those states into “negotiated” hides the party that retained the decision. It also turns a permissible choice into a false alarm, while letting a genuinely stale or misleading announcement pass as compliance.

SDP and RTP do not share one clock

RFC 5188 explicitly warns that RTP media may arrive well before SDP carrying a first-time or updated sendmode. That sentence prevents a comfortable but false ordering assumption. The control document can lag the media it is meant to describe.

Suppose the encoder moves from mode 0 to mode 4 at time T. Packets encoded under mode 4 may cross the network before an SDP update reaches the observer. During that interval, the stored session description is not the current execution state. Later, when the update arrives, it does not retroactively timestamp each packet.

An audit therefore needs at least four clocks: offer/answer version time, encoder transition time, RTP send/arrival time and decoder-ingestion time. The evidence should map a statement to the interval for which it was actually supported. “Latest SDP says mode 4” is not enough to classify an earlier frame, and “packet arrived before update” is not itself proof that the packet was wrongly encoded.

Payload selection is not mode selection

The media subtype identifies a packet format family. audio/EVRCWB, audio/EVRCWB0 and audio/EVRCWB1 select interleaved/bundled, header-free and compact bundled forms. That selection does not collapse the operating mode into the payload number.

EVRC-WB modes 4 and 7 are designed to interoperate with EVRC-B. An offerer is advised to announce EVRC-B support as well as preferred EVRC-WB so that a legacy answerer can select the narrower family. A selected EVRC-WB payload proves that the endpoints agreed to interpret that payload type under the EVRC-WB registration. It does not prove which allowed mode the encoder chose for each interval.

The clock rate creates another tempting shortcut. RFC 5188 requires a 16 kHz RTP clock for EVRC-WB even when encoder input or decoder output is configured at 8 kHz. A monitoring system that reports the RTP clock as captured acoustic bandwidth has promoted timing syntax into a hardware claim.

Compatibility can look like missing evidence

RFC 5188 adds recvmode and sendmode to EVRC-B registrations while preserving interoperability with RFC 4788 peers. A legacy implementation does not send those parameters and ignores them when received.

Absence therefore has several possible meanings. The peer may be legacy. It may be updated but omit an optional declaration. A middlebox may have lost or normalized the attribute. Or the observer may hold an incomplete SDP version. Treating absence as mode 0, rejection or noncompliance invents a default the evidence did not establish.

Unknown parameters follow a deliberate extension rule: ignore them in an offer and do not echo them in the answer. Echoing an unknown field can create the appearance of shared semantics where none exists. Dropping it is not necessarily feature failure; it is a boundary against accidental agreement.

The fixed-mode exception sharpens the receipt

EVRCWB1 has a stronger invariant: the entire session must use the same fixed rate and mode. That rule does not make the receive preference an execution receipt. It tells operators what must be verified over the session's media timeline.

A mid-session encoder transition in EVRCWB1 cannot be excused merely because a new SDP blob looks valid. The evidence must show whether a new session or payload binding was established, whether the old fixed-mode interval ended, and which packets belong to which configuration. Session identity is doing real work here.

For other EVRC-WB forms, mode changes are permitted and do not inherently create decoder failure. Monitoring should not mistake expected transitions for faults. It should verify that declarations, directions and observed media remain attributable to the correct version.

The receipt leadership should require

A durable mode receipt starts with the immutable session and change identity. It records endpoint roles, media direction, offer and answer versions, selected payload type, media subtype, RTP clock and the raw rtpmap, fmtp, ptime and maxptime lines.

It then records the receiver preference and its owner; the sender's policy decision to honour or ignore it; each sendmode declaration and arrival time; the encoder configuration before and after transition; and the sequence, timestamp and inferred or decoded mode of the relevant RTP frames. Legacy capability, unknown-parameter handling and EVRCWB1's fixed-mode invariant belong in the same chain.

Finally, it records decoder acceptance, output status and application result without treating any one of them as perceived quality. Successful decoding proves that the decoder produced output under its rules. It does not prove the receiver's preferred mode, the expected bandwidth, the microphone's sampling configuration or a human listening outcome.

Leadership decision

The governing question is not “did SDP contain the right value?” It is “which party had authority over the next state, what did it decide, and which execution evidence closes the loop?”

Keep preference as preference. Keep announcement as announcement. Give the encoder transition and the media frame their own receipts. This preserves interoperability without allowing a negotiator, dashboard or compliance report to claim that a remote action occurred merely because local text requested it.

Sources

  1. RFC 5188 HTML
  2. RFC 5188 text
  3. RFC Editor information for RFC 5188
  4. IETF Datatracker RFC 5188
  5. RFC 5188 history
  6. RFC 5188 references
  7. RFC 5188 errata
  8. RFC 4788
  9. RFC Editor information for RFC 4788
  10. RFC 3558
  11. RFC Editor information for RFC 3558
  12. RFC 3264 offer-answer model
  13. RFC Editor information for RFC 3264
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. IANA media type audio/EVRCWB
  17. IANA RTP parameters
  18. Heng Lu — reality layers and symbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running code primary