| 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; for this HRESULT, 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. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this this result occurrence.
- 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 for this HRESULT: supply
SDPat the documented phase or use the API path that supports delayed offer; 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 this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Evidence that separates the cause
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: inspect method/status, Content-Type, Content-Length, and whether delayed offer was intentionally used.
- Identity and target for this HRESULT: start-line plus header names.
- State at production for this HRESULT: Content-Type and Content-Length.
- Timing and ordering for this HRESULT:
SDPo= version and c= address.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
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 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; the second rule relevant to it is that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Related RTC results
The practical separator for this HRESULT is this: it is tied to the condition “the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
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 |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
How to handle the result
The corrective direction for this HRESULT is to supply SDP at the documented phase or use the API path that supports delayed offer; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: 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
- The following shortcut is unsafe for this HRESULT: do not log credentials or an unredacted SDP body from production calls.
- Another non-solution for this HRESULT is to do not repair malformed signaling by silently deleting unknown headers or media sections.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP message and transaction rules — API or protocol rules used to interpret it.
- SDP syntax — authoritative context for the boundary.
- SDP offer/answer — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.