| Previous | Next |
| RTC_E_SDP_MULTICAST | RTC_E_SDP_NO_MEDIA |
RTC_E_SDP_CONNECTION_ADDR
What the RTC value marks: RTC_E_SDP_CONNECTION_ADDR
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 an SDP media description has no usable connection address at session or media level.
The stored Value is 0x80EE000A 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 check inheritance of the session-level c= line and each media-level override; the result evidence should demonstrate why a media line can list codecs and ports yet remain unroutable without a connection address.
A safe diagnostic sequence
- Locate the earliest this result producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to check inheritance of the session-level c= line and each media-level override.
- test the competing explanation explicitly, because a media line can list codecs and ports yet remain unroutable without a connection address.
- perform the narrow correction — generate a valid unicast connection address from the correct interface or NAT mapping — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Evidence that separates the cause
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: check inheritance of the session-level c= line and each media-level override.
- Identity and target for this HRESULT: each m= line and codec mapping.
- State at production for this HRESULT: message direction and transport.
- Timing and ordering for this HRESULT: start-line plus header names.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
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 | an SDP media description has no usable connection address at session or media level |
| Safe corrective direction | generate a valid unicast connection address from the correct interface or NAT mapping |
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.
Related RTC results
It is tied to the condition “an SDP media description has no usable connection address at session or media level”; 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_SIP_CODECS_DO_NOT_MATCH | the local offer and remote answer have no common codec for an active media line |
RTC_E_SIP_PARSE_FAILED | the RTC SIP parser could not construct a valid message from the received or generated bytes |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
How to handle the result
Recovery from it should be narrow: generate a valid unicast connection address from the correct interface or NAT mapping; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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: A custom SDP builder writes m= and a= lines but omits every c= line.
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.
- also do not repair malformed signaling by silently deleting unknown headers or media sections.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A regression test for this HRESULT should reproduce “an SDP media description has no usable connection address at session or media level” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE000A, 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 — 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.