| Previous | Next |
| RTC_E_SECURITY_LEVEL_NOT_DEFINED | RTC_E_DUPLICATE_BUDDY |
RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT
Protocol boundary: RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT
This result is useful only when preserved with its producing phase; in applying client policy, authorized domains, transport requirements, and negotiated media security levels, it denotes a participant cannot support the security level selected for the session.
The machine-readable identity of this result is 0x80EE0049 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 participant, media type, requested level, and capability response; The result must be separated from nearby conditions because this scopes the incompatibility to a participant and matters especially in multiparty sessions.
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 | a participant cannot support the security level selected for the session |
| Safe corrective direction | exclude or upgrade the incompatible participant, or select an allowed common level before joining |
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.
How to prove the condition
- Start from
0x80EE0049and this result, 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 identify the participant, media type, requested level, and capability response.
- keep the analysis at the right boundary: this scopes the incompatibility to a participant and matters especially in multiparty sessions.
- after you exclude or upgrade the incompatible participant, or select an allowed common level before joining, 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.
Minimum incident record
Correlate it 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: identify the participant, media type, requested level, and capability response.
- Owning object for this HRESULT: requested media security level.
- Wire evidence for this HRESULT: peer capability result.
- Lifecycle generation for this HRESULT: transport selected for signaling.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not bypass policy by editing generated profile XML in memory.
- also do not downgrade security without an explicit product policy and user-visible result.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Correct application response
The owning RTC component should exclude or upgrade the incompatible participant, or select an allowed common level before joining; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
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 third participant lacks the secure-media mode already required by the conference.
Nearby failure modes
It is tied to the condition “a participant cannot support the security level selected for the session”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SECURITY_LEVEL_NOT_DEFINED | the application has not defined the media security level required for the operation |
|---|---|
RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE | local and remote media security requirements have no compatible negotiated level |
RTC_E_UDP_NOT_SUPPORTED | the requested feature or profile combination is incompatible with at least one server using UDP transport |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A regression test for this HRESULT should reproduce “a participant cannot support the security level selected for the session” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0049, 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 — definitions relevant when reproducing it.
- IRTCClientProvisioning::CreateProfile — API or protocol rules used to interpret it.
- SIP security considerations — authoritative context for the boundary.
Looking for a different code? Search another status or error code.