| Previous | Next |
| RTC_E_PORT_MAPPING_FAILED | RTC_E_SECURITY_LEVEL_NOT_DEFINED |
RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE
What the RTC value marks: RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE
When RTC returns this result, the relevant contract is applying client policy, authorized domains, transport requirements, and negotiated media security levels, and it says that local and remote media security requirements have no compatible negotiated level.
This result carries 0x80EE0047 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to compare required/maximum levels per media type and the peer’s advertised capabilities; the result evidence should demonstrate why this is negotiation incompatibility, not absence of a local security setting.
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 | local and remote media security requirements have no compatible negotiated level |
| Safe corrective direction | use a mutually supported level that still satisfies policy or fail the media session explicitly |
Interpreting this result requires both of these facts: Policy refusal is distinct from transport failure: the requested operation may be technically possible but prohibited for the current profile or platform; also, the result branch assumes that Media security must be compatible for each participating endpoint and should not be silently downgraded after negotiation begins.
Evidence that separates the cause
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: compare required/maximum levels per media type and the peer’s advertised capabilities.
- Identity and target for this HRESULT: requested media security level.
- State at production for this HRESULT: peer capability result.
- Timing and ordering for this HRESULT: transport selected for signaling.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Related RTC results
It should not be grouped with every value from the same facility. It is tied to the condition “local and remote media security requirements have no compatible negotiated level”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_POLICY_NOT_ALLOW | effective RTC policy explicitly prohibits the requested action |
|---|---|
RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT | a participant cannot support the security level selected for the session |
RTC_E_UDP_NOT_SUPPORTED | the requested feature or profile combination is incompatible with at least one server using UDP transport |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
A safe diagnostic sequence
- Start from
0x80EE0047and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to compare required/maximum levels per media type and the peer’s advertised capabilities.
- keep the analysis at the right boundary: this is negotiation incompatibility, not absence of a local security setting.
- after you use a mutually supported level that still satisfies policy or fail the media session explicitly, repeat the smallest reproducer rather than restarting the entire application environment.
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.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, use a mutually supported level that still satisfies policy or fail the media session explicitly, while preserving ownership of cleanup and any bounded retry.
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: One endpoint requires protected media while the peer offers only an unprotected mode.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A regression test for this HRESULT should reproduce “local and remote media security requirements have no compatible negotiated level” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0047, 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.
- 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.