| Previous | Next |
| RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE | RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT |
RTC_E_SECURITY_LEVEL_NOT_DEFINED
Operational meaning: RTC_E_SECURITY_LEVEL_NOT_DEFINED
This result should be investigated at the point where RTC handles applying client policy, authorized domains, transport requirements, and negotiated media security levels, and the condition to prove for this HRESULT is the application has not defined the media security level required for the operation.
This result is represented as 0x80EE0048 in the RTC interface facility 0xEE; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, record media type, session creation path, default-policy lookup, and when SetSecurityLevel was expected; for this HRESULT, this matters because undefined local configuration differs from a peer rejecting a defined level.
Signals worth preserving
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record media type, session creation path, default-policy lookup, and when SetSecurityLevel was expected.
- Correlation key for this HRESULT: transport selected for signaling.
- Protocol or object snapshot for this HRESULT: policy name/source and effective value.
- Last completed transition for this HRESULT: profile/server domain.
- Expected output 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.
Protocol and object boundary
| RTC area | RTC policy and media-security boundary |
|---|---|
| Condition to prove | the application has not defined the media security level required for the operation |
| Objects to correlate | enabled profile, policy source, authorized domain, media type, local and remote security level |
| Safe corrective direction | set the level before negotiation begins and keep it stable for the media type |
Interpreting it 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.
Verification workflow
- Record it and
0x80EE0048at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can record media type, session creation path, default-policy lookup, and when SetSecurityLevel was expected.
- Apply one controlled change for this HRESULT: set the level before negotiation begins and keep it stable for the media type; then verify the result return value and resulting RTC state.
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.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “the application has not defined the media security level required for the operation”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
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 |
|---|---|
RTC_E_POLICY_NOT_ALLOW | effective RTC policy explicitly prohibits the requested action |
RTC_E_UDP_NOT_SUPPORTED | the requested feature or profile combination is incompatible with at least one server using UDP transport |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, set the level before negotiation begins and keep it stable for the media type, while preserving ownership of cleanup and any bounded retry.
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 custom call path bypasses the initialization code that assigns audio security policy.
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
Verify the result fix with a minimal deterministic case that reaches “the application has not defined the media security level required for the operation”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
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.
