| Previous | Next |
| RTC_E_SDP_NOT_PRESENT | RTC_E_SDP_UPDATE_FAILED |
RTC_E_SDP_PARSE_FAILED
Protocol boundary: RTC_E_SDP_PARSE_FAILED
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the message body is labeled or treated as SDP but violates the SDP grammar or field requirements.
At the HRESULT layer, this result appears as 0x80EE0007 in the RTC interface facility 0xEE; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
A defensible diagnosis of this result requires you to validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings; in the case, this differs from RTC_E_SIP_PARSE_FAILED because SIP framing succeeded and the body parser failed.
Minimum incident record
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings.
- Owning object for this HRESULT: start-line plus header names.
- Wire evidence for this HRESULT: Content-Type and Content-Length.
- Lifecycle generation for this HRESULT:
SDPo= version and c= address.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
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 message body is labeled or treated as SDP but violates the SDP grammar or field requirements |
| Safe corrective direction | fix the SDP producer and retain the original offer/answer transaction state |
At the boundary, SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; separately, this result must be read with the rule that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Correct application response
The corrective direction for this HRESULT is to fix the SDP producer and retain the original offer/answer transaction state; 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: A gateway emits an m= line with a nonnumeric port and the RTC SDP parser rejects the body.
How to prove the condition
- Start from
0x80EE0007and it, then find the method/event pair that first exposed it. - the proof step is to validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: this differs from
RTC_E_SIP_PARSE_FAILEDbecauseSIPframing succeeded and the body parser failed. - after you fix the
SDPproducer and retain the original offer/answer transaction state, repeat the smallest reproducer rather than restarting the entire application environment.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Nearby failure modes
It is tied to the condition “the message body is labeled or treated as SDP but violates the SDP grammar or field requirements”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SIP_INVITE_TRANSACTION_PENDING | another INVITE or re-INVITE transaction still owns the dialog’s offer/answer state |
|---|---|
RTC_E_SIP_PARSE_FAILED | the RTC SIP parser could not construct a valid message from the received or generated bytes |
RTC_E_SDP_NOT_PRESENT | the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Actions that do not address this condition
- With it, do not repair malformed signaling by silently deleting unknown headers or media sections.
- also 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.
Verification after a fix
A regression test for this HRESULT should reproduce “the message body is labeled or treated as SDP but violates the SDP grammar or field requirements” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0007, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.