| Previous | Next |
| RTC_E_OPERATION_WITH_TOO_MANY_PARTICIPANTS | RTC_E_SIP_HIGH_SECURITY_SET_TLS |
RTC_E_BASIC_AUTH_SET_TLS
Operational meaning: RTC_E_BASIC_AUTH_SET_TLS
This result should be investigated at the point where RTC handles selecting an allowed authentication method, validating the challenge realm, and establishing a protected SIP transport, and the condition to prove for this HRESULT is the profile allows Basic authentication without selecting the TLS transport required by RTC.
This result is represented as 0x80EE003F 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, inspect each server entry’s transport and authentication method before enabling the profile; this matters because the credential may be correct; the profile is rejected to prevent Basic use on an unprotected transport.
Signals worth preserving
- Code-specific proof: inspect each server entry’s transport and authentication method before enabling the profile.
- Correlation key: client/server UTC time and
TLSphase. - Protocol or object snapshot: 401 or 407 challenge source.
- Last completed transition: authentication scheme and realm.
- Expected output: credential identity without secret material.
Protocol and object state
| RTC area | SIP authentication and TLS identity |
|---|---|
| Condition to prove | the profile allows Basic authentication without selecting the TLS transport required by RTC |
| Objects to correlate | profile authentication method, challenge headers, realm, credential source, TLS certificate and tunnel |
| Safe corrective direction | set TLS for that server or choose a different supported authentication method |
RTC profile rules tie some authentication methods to TCP or TLS; Basic authentication requires TLS in the legacy API contract. A certificate failure, a challenge mismatch, and invalid credentials occur at different layers and need different remediation.
Verification workflow
- Use protocol and object evidence to inspect each server entry’s transport and authentication method before enabling the profile.
- Confirm the distinction that the credential may be correct; the profile is rejected to prevent Basic use on an unprotected transport.
- Start a fresh operation after you set
TLSfor that server or choose a different supported authentication method, and compare its final state with the failing run.
Do not confuse it with
RTC_E_SIP_TLS_INCOMPATIBLE_ENCRYPTION | client and server TLS capabilities or configured cipher/security requirements cannot establish a compatible protected channel |
|---|---|
RTC_E_SIP_AUTH_TIME_SKEW | SIP authentication validation failed because client and server time differ beyond the accepted window |
RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED | the challenge requests an authentication scheme the RTC profile or stack cannot use |
Recovery and control flow
Resolve it at its producing layer: set TLS for that server or choose a different supported authentication method; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: Provisioning specifies Basic over TCP and CreateProfile rejects the cross-field combination.
Actions that do not address this condition
- Never record Authorization header contents or plaintext passwords.
- Do not disable certificate checking or lower transport security to make authentication appear successful.
Technical references
Looking for a different code? Search another status or error code.