| Previous | Next |
| RTC_E_SIP_INVITE_TRANSACTION_PENDING | RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED |
RTC_E_SIP_AUTH_HEADER_SENT
What RTC_E_SIP_AUTH_HEADER_SENT means in RTC
Diagnosis begins inside selecting an allowed authentication method, validating the challenge realm, and establishing a protected SIP transport, where the relevant condition for this HRESULT is the RTC authentication state already sent authorization for this challenge path and will not repeat it blindly.
The numeric form of this result is 0x80EE000F in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
The quickest way to localize this result is to compare realm, nonce, method, CSeq, stale indication, and the previous Authorization attempt; the important boundary is that this guards against an authentication loop rather than proving that credentials are valid.
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 RTC authentication state already sent authorization for this challenge path and will not repeat it blindly |
| Safe corrective direction | refresh challenge state or surface authentication failure instead of resending the same header indefinitely |
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.
How to prove the condition
- Record this result and
0x80EE000Fat the first RTC method or event that returns it. - Apply one controlled change: refresh challenge state or surface authentication failure instead of resending the same header indefinitely; then verify the result return value and resulting RTC state.
Nearby failure modes
RTC_E_SIP_AUTH_FAILED | the selected SIP authentication attempt was rejected or could not validate for the challenge |
|---|---|
RTC_E_SIP_AUTH_TIME_SKEW | SIP authentication validation failed because client and server time differ beyond the accepted window |
RTC_E_SIP_INVALID_CERTIFICATE | the certificate presented or selected for SIP TLS does not satisfy RTC validation requirements |
Minimum incident record
- Code-specific proof: compare realm, nonce, method, CSeq, stale indication, and the previous Authorization attempt.
- Owning object: certificate subject and validation failure.
- Wire evidence: client/server UTC time and
TLSphase. - Lifecycle state: 401 or 407 challenge source.
Correct application response
Recovery should be narrow: refresh challenge state or surface authentication failure instead of resending the same header indefinitely; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A proxy repeats the same Digest challenge after the client has already answered it.
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.