What does HRESULT 0x80EE0015 (RTC_E_DESTINATION_ADDRESS_MULTICAST) mean?

RTC_E_DESTINATION_ADDRESS_MULTICAST

Operational meaning: RTC_E_DESTINATION_ADDRESS_MULTICAST

This code belongs to 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.

For correlation, retain 0x80EE0015 in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.

Evidence should show that you capture the original hostname/URI and final resolved address set; the diagnostic distinction is that this concerns signaling destination, whereas RTC_E_SDP_MULTICAST concerns media addresses inside SDP.

Signals worth preserving

• Code-specific proof: capture the original hostname/URI and final resolved address set.
• Correlation key: original SIP URI and selected next hop.
• Protocol or object snapshot: DNS query type and answers.
• Last completed transition: local/remote socket tuple.
• Expected output: proxy tunnel response.

Protocol and object state

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

1. Collect enough evidence to capture the original hostname/URI and final resolved address set.
2. Test the competing explanation explicitly, because this concerns signaling destination, whereas RTC_E_SDP_MULTICAST concerns media addresses inside SDP.
3. Apply the targeted fix — correct DNS/profile routing to a unicast SIP endpoint — and validate both protocol completion and object cleanup.

Do not confuse it with

Recovery and control flow

Recovery should be narrow: correct DNS/profile routing to a unicast SIP endpoint; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Example: A misconfigured DNS entry for the registrar returns a multicast address.

Actions that do not address this condition

• Do not switch transports without checking profile policy and authentication constraints.
• Do not retry rapidly across every resolved address without preserving the failure phase.

Technical references

• Microsoft RTC return constants.
• SIP transport behavior.
• Locating SIP servers.
• SIP and TEL URLs in RTC.