Site icon EfmSoft

What does HRESULT 0x80EE0000 (RTC_E_SIP_CODECS_DO_NOT_MATCH) mean?

 
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 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 state

RTC areaSIP message and SDP negotiation
Objects to correlateSIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation
Condition to provethe local offer and remote answer have no common codec for an active media line
Safe corrective directionoffer at least one mutually supported codec with compatible parameters or select a media mode both endpoints implement

SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP. 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

  • Code-specific proof: compare payload types and rtpmap/fmtp values per m= section rather than comparing codec names globally.
  • Identity and target: message direction and transport.
  • State at production: start-line plus header names.
  • Timing and ordering: Content-Type and Content-Length.

A safe diagnostic sequence

  1. Record it and 0x80EE0000 at the first RTC method or event that returns it.
  2. Apply one controlled change: 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.

How to handle the result

To correct this, offer at least one mutually supported codec with compatible parameters or select a media mode both endpoints implement.

Example: 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

  • Do not repair malformed signaling by silently deleting unknown headers or media sections.
  • Do not log credentials or an unredacted SDP body from production calls.

Related RTC results

RTC_E_SDP_NO_MEDIAthe SDP contains no enabled media description usable for the requested RTC session
RTC_E_SIP_HEADER_NOT_PRESENTan RTC operation requires a SIP header that is absent from the parsed message
RTC_E_SIP_UDP_SIZE_EXCEEDEDthe serialized SIP datagram exceeds the size accepted by the RTC UDP transport path

Technical references


Looking for a different code? Search another status or error code.

Exit mobile version