| 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; 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; 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 instance and one transaction or media transition.
- Code-specific proof: record media type, session creation path, default-policy lookup, and when SetSecurityLevel was expected.
- Correlation key: transport selected for signaling.
- Protocol or object snapshot: policy name/source and effective value.
- Last completed transition: profile/server domain.
- Expected output: requested media security level.
Protocol and object state
| RTC area | RTC policy and media-security |
|---|---|
| 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 occurrence.
- Place the result 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: set the level before negotiation begins and keep it stable for the media type; then verify the result return value and resulting RTC state.
Diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; avoid treating packet capture and HRESULT logging as substitutes for one another.
Do not confuse it with
Use “the application has not defined the media security level required for the operation” as the discriminator when comparing the related RTC results below.
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 |
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 is safe only after the prior transaction’s outcome is reconciled; reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: A custom call path bypasses the initialization code that assigns audio security policy.
Actions that do not address this condition
- Do not bypass policy by editing generated profile XML in memory.
- Do not downgrade security without an explicit product policy and user-visible result.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “the application has not defined the media security level required for the operation”; the failing 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 this result.
- 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.