| Previous | Next |
| RTC_E_SIP_AUTH_HEADER_SENT | RTC_E_SIP_AUTH_FAILED |
RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED
Protocol boundary: RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED
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; for this HRESULT, 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
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: record challenge scheme, transport, profile authentication setting, and responding hop.
- Owning object for this HRESULT: authentication scheme and realm.
- Wire evidence for this HRESULT: credential identity without secret material.
- Lifecycle generation for this HRESULT: certificate subject and validation failure.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Protocol and object boundary
| RTC area | SIP authentication and TLS identity boundary |
|---|---|
| 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 |
The API and protocol context for this HRESULT is not optional: RTC profile rules tie some authentication methods to TCP or TLS; Basic authentication requires TLS in the legacy API contract; the related this result control-flow rule is that 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 it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: A server challenges with an authentication mechanism absent from the legacy RTC implementation.
How to prove the condition
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to record challenge scheme, transport, profile authentication setting, and responding hop.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that unsupported scheme differs from bad credentials because no valid authentication calculation can be attempted.
- create a fresh operation generation after you configure a mutually supported scheme and transport or use a compatible server, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Nearby failure modes
Use the following contrast when classifying it: it is tied to the condition “the challenge requests an authentication scheme the RTC profile or stack cannot use”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
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 |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Actions that do not address this condition
- With it, do not disable certificate checking or lower transport security to make authentication appear successful.
- Another non-solution for this HRESULT is to never record Authorization header contents or plaintext passwords.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the challenge requests an authentication scheme the RTC profile or stack cannot use”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft profile creation rules — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP authentication and TLS — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.