| 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 boundary is that the destination SIP address may be unicast while the proposed media address is multicast.
Protocol and object state
| RTC area | SIP message and SDP negotiation |
|---|---|
| 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 |
SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP. An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Comparison with adjacent codes
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 |
Telemetry and packet evidence
- Code-specific proof: inspect c= address scope and per-media connection data instead of only the destination
SIPURI. - Addressing context: message direction and transport.
- RTC callback state: start-line plus header names.
- Transaction boundary: Content-Type and Content-Length.
- Media or profile detail:
SDPo= version and c= address.
Step-by-step isolation
- Confirm the distinction that the destination
SIPaddress may be unicast while the proposed media address is multicast. - Start a fresh operation 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.
Actions that do not address this condition
- Do not log credentials or an unredacted SDP body from production calls.
- Do not repair malformed signaling by silently deleting unknown headers or media sections.
Recovery
Recovery should be narrow: use a supported unicast media topology or a component that explicitly implements multicast RTP; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A session announcement SDP supplies a multicast c= address to a unicast RTC call client.
Technical references
Looking for a different code? Search another status or error code.