| Previous | Next |
| RTC_E_SDP_UPDATE_FAILED | RTC_E_SDP_CONNECTION_ADDR |
RTC_E_SDP_MULTICAST
Where the state changes: RTC_E_SDP_MULTICAST
The legacy RTC Client API reports this result while working with parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it; the precise meaning of it is the SDP describes a multicast connection that the RTC Client API path does not support, not merely that a call or registration failed.
The numeric form of this result is 0x80EE0009 in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
The quickest way to localize this result is to inspect c= address scope and per-media connection data instead of only the destination SIP URI; the important the boundary is that the destination SIP address may be unicast while the proposed media address is multicast.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Condition to prove | the SDP describes a multicast connection that the RTC Client API path does not support |
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Safe corrective direction | use a supported unicast media topology or a component that explicitly implements multicast RTP |
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.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. It is tied to the condition “the SDP describes a multicast connection that the RTC Client API path does not support”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_SIP_CODECS_DO_NOT_MATCH | the local offer and remote answer have no common codec for an active media line |
|---|---|
RTC_E_SDP_NOT_PRESENT | the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body |
RTC_E_SIP_UDP_SIZE_EXCEEDED | the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Telemetry and packet evidence
The earliest callback or return site is the most valuable; later it cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: inspect c= address scope and per-media connection data instead of only the destination
SIPURI. - Addressing context for this HRESULT: message direction and transport.
- RTC callback state for this HRESULT: start-line plus header names.
- Transaction boundary for this HRESULT: Content-Type and Content-Length.
- Media or profile detail for this HRESULT:
SDPo= version and c= address.
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.
Step-by-step isolation
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to inspect c= address scope and per-media connection data instead of only the destination
SIPURI. - confirm the distinction that the destination
SIPaddress may be unicast while the proposed media address is multicast. - create a fresh operation generation after you use a supported unicast media topology or a component that explicitly implements multicast RTP, and compare its final state with the failing run.
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.
Actions that do not address this condition
- An investigation should not 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.
Remediation boundary
Recovery from it should be narrow: use a supported unicast media topology or a component that explicitly implements multicast RTP; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A session announcement SDP supplies a multicast c= address to a unicast RTC call client.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the SDP describes a multicast connection that the RTC Client API path does not support”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP message and transaction rules — definitions relevant when reproducing it.
- SDP syntax — API or protocol rules used to interpret it.
- SDP offer/answer — authoritative context for the boundary.
Looking for a different code? Search another status or error code.