| Previous | Next |
| RTC_E_SIP_TIMEOUT | RTC_E_SIP_INVITE_TRANSACTION_PENDING |
RTC_E_SDP_FAILED_TO_BUILD
Protocol boundary: RTC_E_SDP_FAILED_TO_BUILD
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the RTC stack could not serialize the current media/session state into an SDP offer or answer.
At the HRESULT layer, this result appears as 0x80EE000D 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 record requested media types, terminal formats, port mappings, addresses, and security requirements before serialization; in the case, generation failure occurs locally before a valid SDP body exists; it is not a peer rejection.
Minimum incident record
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: record requested media types, terminal formats, port mappings, addresses, and security requirements before serialization.
- Owning object for this HRESULT:
SDPo= version and c= address. - Wire evidence for this HRESULT: each m= line and codec mapping.
- Lifecycle generation for this HRESULT: message direction and transport.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
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 RTC stack could not serialize the current media/session state into an SDP offer or answer |
| Safe corrective direction | correct incomplete or contradictory local media state and rebuild once |
Two RTC rules frame this result: first, SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; second, for this HRESULT, An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Correct application response
The appropriate response to it is not a blanket reconnect. Instead, correct incomplete or contradictory local media state and rebuild once, while preserving ownership of cleanup and any bounded retry.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: The application requests secure audio but supplies no compatible terminal or mapped media address.
How to prove the condition
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to record requested media types, terminal formats, port mappings, addresses, and security requirements before serialization.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- test the competing explanation explicitly, because generation failure occurs locally before a valid
SDPbody exists; it is not a peer rejection. - perform the narrow correction — correct incomplete or contradictory local media state and rebuild once — and validate both protocol completion and object cleanup.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Nearby failure modes
It is tied to the condition “the RTC stack could not serialize the current media/session state into an SDP offer or answer”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SIP_NO_STREAM | the operation requires at least one active media stream but the session currently has none |
|---|---|
RTC_E_SDP_UPDATE_FAILED | a new SDP description is incompatible with the prior negotiated offer/answer state |
RTC_E_SIP_UDP_SIZE_EXCEEDED | the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
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.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
A regression test for this HRESULT should reproduce “the RTC stack could not serialize the current media/session state into an SDP offer or answer” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE000D, 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.