| Previous | Next |
| RTC_E_SECURITY_LEVEL_ALREADY_SET | RTC_E_SIP_REFER_OPERATION_PENDING |
RTC_E_UDP_NOT_SUPPORTED
What the RTC value marks: RTC_E_UDP_NOT_SUPPORTED
The operational meaning of this result is tied to applying client policy, authorized domains, transport requirements, and negotiated media security levels: the requested feature or profile combination is incompatible with at least one server using UDP transport.
The machine-readable identity of this result is 0x80EE007E in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check for this HRESULT is to identify the UDP server entry, requested roaming/authentication feature, and cross-field rule; The result must be separated from nearby conditions because UDP itself may be supported for basic signaling while this particular feature is not.
Protocol and object boundary
| RTC area | RTC policy and media-security boundary |
|---|---|
| Objects to correlate | enabled profile, policy source, authorized domain, media type, local and remote security level |
| Condition to prove | the requested feature or profile combination is incompatible with at least one server using UDP transport |
| Safe corrective direction | switch the affected server to TCP/TLS or disable only the incompatible feature |
Policy refusal is distinct from transport failure: the requested operation may be technically possible but prohibited for the current profile or platform; the second rule relevant to this result is that Media security must be compatible for each participating endpoint and should not be silently downgraded after negotiation begins.
Evidence that separates the cause
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: identify the
UDPserver entry, requested roaming/authentication feature, and cross-field rule. - Identity and target for this HRESULT: policy name/source and effective value.
- State at production for this HRESULT: profile/server domain.
- Timing and ordering for this HRESULT: requested media security level.
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.
Related RTC results
Use the following contrast when classifying it: it is tied to the condition “the requested feature or profile combination is incompatible with at least one server using UDP transport”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_DUPLICATE_REALM | more than one enabled profile defines the same authentication realm in a conflicting way |
|---|---|
RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE | local and remote media security requirements have no compatible negotiated level |
RTC_E_SECURITY_LEVEL_ALREADY_SET | the media security level has already been fixed for this media type and cannot be changed in the current session state |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
A safe diagnostic sequence
- 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 identify the
UDPserver entry, requested roaming/authentication feature, and cross-field rule. - test the competing explanation explicitly, because
UDPitself may be supported for basic signaling while this particular feature is not. - perform the narrow correction — switch the affected server to
TCP/TLSor disable only the incompatible feature — and validate both protocol completion and object cleanup.
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.
How to handle the result
The corrective direction for this HRESULT is to switch the affected server to TCP/TLS or disable only the incompatible feature; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: A roaming profile includes a UDP registrar even though presence roaming requires a connection-oriented transport.
Actions that do not address this condition
- An investigation should not do not bypass policy by editing generated profile XML in memory.
- Do not downgrade security without an explicit product policy and user-visible result.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Keep two tests: one that intentionally produces “the requested feature or profile combination is incompatible with at least one server using UDP transport”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE007E, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- IRTCClientProvisioning::CreateProfile — definitions relevant when reproducing it.
- SIP security considerations — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.