| Previous | Next |
| ERROR_SPACES_DRIVE_OPERATIONAL_STATE_INVALID | RTC_E_SIP_STREAM_PRESENT |
RTC_E_SIP_CODECS_DO_NOT_MATCH
What the RTC value marks: RTC_E_SIP_CODECS_DO_NOT_MATCH
This result is useful only when preserved with its producing phase; in parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, it denotes the local offer and remote answer have no common codec for an active media line.
The machine-readable identity of this result is 0x80EE0000 in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check for it is to compare payload types and rtpmap/fmtp values per m= section rather than comparing codec names globally; The result must be separated from nearby conditions because a codec mismatch is media negotiation failure; it does not mean SIP transport or the audio device failed.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Condition to prove | the local offer and remote answer have no common codec for an active media line |
| Safe corrective direction | offer at least one mutually supported codec with compatible parameters or select a media mode both endpoints implement |
The API and protocol context for it is not optional: SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; the related this result control-flow rule is that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Evidence that separates the cause
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for it: compare payload types and rtpmap/fmtp values per m= section rather than comparing codec names globally.
- Identity and target for it: message direction and transport.
- State at production for it: start-line plus header names.
- Timing and ordering for it: Content-Type and Content-Length.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for it, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
A safe diagnostic sequence
- Record it and
0x80EE0000at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can compare payload types and rtpmap/fmtp values per m= section rather than comparing codec names globally.
- Apply one controlled change for it: offer at least one mutually supported codec with compatible parameters or select a media mode both endpoints implement; then verify the result return value and resulting RTC state.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for it, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
How to handle the result
The corrective direction for it is to offer at least one mutually supported codec with compatible parameters or select a media mode both endpoints implement; for it, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
Distinguish local rejection from an operation that may already have reached the server; for it, use transaction identifiers and final events before replaying any non-idempotent action.
Example for it: One endpoint offers only a proprietary audio codec while the peer accepts only PCMU; signaling succeeds but the media offer cannot be completed.
Actions that do not address this condition
- With it, do not do not repair malformed signaling by silently deleting unknown headers or media sections.
- also do not do not log credentials or an unredacted SDP body from production calls.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Related RTC results
The practical separator for it is this: it is tied to the condition “the local offer and remote answer have no common codec for an active media line”; preserve that producing boundary before choosing recovery; for it, compare that boundary with these related RTC values.
RTC_E_SDP_NO_MEDIA | the SDP contains no enabled media description usable for the requested RTC session |
|---|---|
RTC_E_SIP_HEADER_NOT_PRESENT | an RTC operation requires a SIP header that is absent from the parsed message |
RTC_E_SIP_UDP_SIZE_EXCEEDED | the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the local offer and remote answer have no common codec for an active media line”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP message and transaction rules — authoritative context for the boundary.
- SDP syntax — definitions relevant when reproducing it.
- SDP offer/answer — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.