| Previous | Next |
| RTC_E_INVALID_ADDRESS_LOCAL | RTC_E_INVALID_PROXY_ADDRESS |
RTC_E_DESTINATION_ADDRESS_MULTICAST
Operational meaning: RTC_E_DESTINATION_ADDRESS_MULTICAST
This result marks a specific boundary in resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed: the signaling destination resolves to a multicast address unsupported for this RTC operation; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE0015 in the RTC interface facility 0xEE together with this result; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you capture the original hostname/URI and final resolved address set; the diagnostic distinction for this HRESULT is that this concerns signaling destination, whereas RTC_E_SDP_MULTICAST concerns media addresses inside SDP.
Signals worth preserving
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: capture the original hostname/URI and final resolved address set.
- Correlation key for this HRESULT: original
SIPURI and selected next hop. - Protocol or object snapshot for this HRESULT: DNS query type and answers.
- Last completed transition for this HRESULT: local/remote socket tuple.
- Expected output for this HRESULT: proxy tunnel response.
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 transport and reachability boundary |
|---|---|
| Condition to prove | the signaling destination resolves to a multicast address unsupported for this RTC operation |
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Safe corrective direction | correct DNS/profile routing to a unicast SIP endpoint |
Interpreting it requires both of these facts: DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”; also, the result branch assumes that A retry is safe only after the application identifies whether any request bytes were transmitted and whether the previous client transaction still exists.
Verification workflow
- Locate the earliest it 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 capture the original hostname/URI and final resolved address set.
- test the competing explanation explicitly, because this concerns signaling destination, whereas
RTC_E_SDP_MULTICASTconcerns media addresses insideSDP. - perform the narrow correction — correct DNS/profile routing to a unicast
SIPendpoint — 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.
Do not confuse it with
It is tied to the condition “the signaling destination resolves to a multicast address unsupported for this RTC operation”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | the requested SIP transport is not implemented or allowed by the RTC profile/platform path |
|---|---|
RTC_E_INVALID_PROXY_ADDRESS | the profile’s proxy address is syntactically invalid or unusable as a SIP next hop |
RTC_E_SIP_STACK_SHUTDOWN | an operation targeted an RTC SIP stack that has already entered shutdown |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Recovery and control flow
Recovery from it should be narrow: correct DNS/profile routing to a unicast SIP endpoint; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: A misconfigured DNS entry for the registrar returns a multicast address.
Actions that do not address this condition
- An investigation should not do not switch transports without checking profile policy and authentication constraints.
- Another non-solution for this HRESULT is to do not retry rapidly across every resolved address without preserving the failure phase.
- 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 signaling destination resolves to a multicast address unsupported for this RTC operation” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0015, 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 — authoritative context for the boundary.
- SIP transport behavior — definitions relevant when reproducing it.
- Locating SIP servers — API or protocol rules used to interpret it.
- SIP and TEL URLs in RTC — authoritative context for the boundary.
Looking for a different code? Search another status or error code.