| Previous | Next |
| RTC_E_SIP_HEADER_NOT_PRESENT | RTC_E_SDP_PARSE_FAILED |
RTC_E_SDP_NOT_PRESENT
What the RTC value marks: RTC_E_SDP_NOT_PRESENT
The useful interpretation of this result is narrower than “SIP error”; within parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, it means the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body.
The stored value is 0x80EE0006 in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Collect enough state to inspect method/status, Content-Type, Content-Length, and whether delayed offer was intentionally used; the result evidence should demonstrate why absence of SDP can be legal in some SIP flows, so the calling RTC method and offer/answer phase are decisive.
A safe diagnostic sequence
- Record this result and
0x80EE0006at the first RTC method or event that returns it. - Place this result in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Prove the condition by ensuring the trace can inspect method/status, Content-Type, Content-Length, and whether delayed offer was intentionally used.
- Apply one controlled change: supply
SDPat the documented phase or use the API path that supports delayed offer; then verify the result return value and resulting RTC state.
Evidence that separates the cause
- Code-specific proof: inspect method/status, Content-Type, Content-Length, and whether delayed offer was intentionally used.
- Identity and target: start-line plus header names.
- State at production: Content-Type and Content-Length.
- Timing and ordering:
SDPo= version and c= address.
Protocol and object state
| RTC area | SIP message and SDP negotiation |
|---|---|
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Condition to prove | the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body |
| Safe corrective direction | supply SDP at the documented phase or use the API path that supports delayed offer |
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.
Related RTC results
RTC_E_SIP_NEED_MORE_DATA | the receive buffer contains only part of a complete SIP message |
|---|---|
RTC_E_SIP_CODECS_DO_NOT_MATCH | the local offer and remote answer have no common codec for an active media line |
RTC_E_SIP_HEADER_NOT_PRESENT | an RTC operation requires a SIP header that is absent from the parsed message |
How to handle the result
To correct this, supply SDP at the documented phase or use the API path that supports delayed offer.
Example: An application expects a 200 response to contain the answer, but the peer used a flow the legacy RTC API does not support.
Actions that do not address this condition
- Do not log credentials or an unredacted SDP body from production calls.
- Do not repair malformed signaling by silently deleting unknown headers or media sections.
Technical references
Looking for a different code? Search another status or error code.