| Previous | Next |
| RTC_E_STATUS_CLIENT_BAD_REQUEST | RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED |
RTC_E_STATUS_CLIENT_UNAUTHORIZED
Where the state changes: RTC_E_STATUS_CLIENT_UNAUTHORIZED
The operational meaning of this result is tied to a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the user agent server or registrar requires end-server authentication.
Log this result as 0x80EF0191 in the RTC SIP-status facility carrying status 401, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, preserve the WWW-Authenticate scheme, realm, nonce metadata, and challenged method without logging credentials; the RTC codes surrounding this result are not equivalent because 401 challenges the target-server relationship; 407 is issued by a proxy and uses Proxy-Authenticate.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Condition to prove | the user agent server or registrar requires end-server authentication |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | select an allowed credential for the exact realm, increment CSeq as required, and retry through the authentication state machine |
Comparison with adjacent codes
Comparison point: 407 Challenges proxy traversal rather than the destination server.
RTC_E_STATUS_NOT_ACCEPTABLE_HERE | the target cannot accept the session description or other negotiated session parameters for this resource |
|---|---|
RTC_E_STATUS_SERVER_BAD_GATEWAY | the responding gateway or proxy received an invalid response from an upstream server |
RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | the Request-URI lacks information required to identify or route the destination |
Telemetry and packet evidence
- Code-specific proof: preserve the WWW-Authenticate scheme, realm, nonce metadata, and challenged method without logging credentials.
- Addressing context: status-specific headers.
- RTC callback state: retry or alternate-target decision.
- Transaction boundary: request method and Request-URI.
- Media or profile detail: responding Via hop.
Step-by-step isolation
- Collect enough evidence to preserve the WWW-Authenticate scheme, realm, nonce metadata, and challenged method without logging credentials.
- Test the competing explanation explicitly, because 401 challenges the target-server relationship; 407 is issued by a proxy and uses Proxy-Authenticate.
- Apply the targeted fix — select an allowed credential for the exact realm, increment CSeq as required, and retry through the authentication state machine — and validate both protocol completion and object cleanup.
Actions that do not address this condition
- Do not retry every 4xx or 5xx response with the identical request.
- Do not show a reason phrase as trusted server identity or authorization evidence.
Recovery
To correct this, select an allowed credential for the exact realm, increment CSeq as required, and retry through the authentication state machine.
Example: A registrar challenges REGISTER with Digest; the client locates credentials for that realm and resends the request.
Technical references
Looking for a different code? Search another status or error code.