| Previous | Next |
| RTC_E_SECURITY_LEVEL_NOT_DEFINED | RTC_E_DUPLICATE_BUDDY |
RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT
What RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT means in RTC
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 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 state
| RTC area | RTC policy and media-security |
|---|---|
| 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. - 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.
Minimum incident record
- Code-specific proof: identify the participant, media type, requested level, and capability response.
- Owning object: requested media security level.
- Wire evidence: peer capability result.
- Lifecycle state: transport selected for signaling.
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.
Correct application response
The owning RTC component should exclude or upgrade the incompatible participant, or select an allowed common level before joining; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A third participant lacks the secure-media mode already required by the conference.
Nearby failure modes
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 |
Technical references
Looking for a different code? Search another status or error code.