| Previous | Next |
| RTC_E_SIP_AUTH_HEADER_SENT | RTC_E_SIP_AUTH_FAILED |
RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED
What RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED means in RTC
When RTC returns this result, the relevant contract is selecting an allowed authentication method, validating the challenge realm, and establishing a protected SIP transport, and it says that the challenge requests an authentication scheme the RTC profile or stack cannot use.
The stored value is 0x80EE0010 in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Collect enough state to record challenge scheme, transport, profile authentication setting, and responding hop; the result evidence should demonstrate why unsupported scheme differs from bad credentials because no valid authentication calculation can be attempted.
Minimum incident record
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: record challenge scheme, transport, profile authentication setting, and responding hop.
- Owning object: authentication scheme and realm.
- Wire evidence: credential identity without secret material.
- Lifecycle state: certificate subject and validation failure.
Protocol and object state
| RTC area | SIP authentication and TLS identity |
|---|---|
| Objects to correlate | profile authentication method, challenge headers, realm, credential source, TLS certificate and tunnel |
| Condition to prove | the challenge requests an authentication scheme the RTC profile or stack cannot use |
| Safe corrective direction | configure a mutually supported scheme and transport or use a compatible server |
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.
Correct application response
Recovery from this result should be narrow: configure a mutually supported scheme and transport or use a compatible server; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A server challenges with an authentication mechanism absent from the legacy RTC implementation.
How to prove the condition
- Confirm the distinction that unsupported scheme differs from bad credentials because no valid authentication calculation can be attempted.
- Start a fresh operation after you configure a mutually supported scheme and transport or use a compatible server, and compare its final state with the failing run.
Nearby failure modes
RTC_E_SIP_AUTH_HEADER_SENT | the RTC authentication state already sent authorization for this challenge path and will not repeat it blindly |
|---|---|
RTC_E_SIP_AUTH_TIME_SKEW | SIP authentication validation failed because client and server time differ beyond the accepted window |
RTC_E_BASIC_AUTH_SET_TLS | the profile allows Basic authentication without selecting the TLS transport required by RTC |
Actions that do not address this condition
- Do not disable certificate checking or lower transport security to make authentication appear successful.
- Do not record Authorization header contents or plaintext passwords.
Technical references
Looking for a different code? Search another status or error code.