| Previous | Next |
| RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED | RTC_E_STATUS_CLIENT_NOT_FOUND |
RTC_E_STATUS_CLIENT_FORBIDDEN
Protocol boundary: RTC_E_STATUS_CLIENT_FORBIDDEN
Read this result as an RTC state-machine result: at this point in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, the server understood the request but refuses to authorize or perform it for this identity or policy.
Log this result as 0x80EF0193 in the RTC SIP-status facility carrying status 403, not only as a signed decimal; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check for this HRESULT is to record the authenticated identity, target, method, responding hop, and policy-safe reason data; The result must be separated from nearby conditions because Forbidden is not an authentication challenge and usually should not trigger repeated credential prompts.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the server understood the request but refuses to authorize or perform it for this identity or policy |
| Safe corrective direction | stop identical retries, surface the policy/account boundary, and change authorization or request scope only with evidence |
The surrounding protocol rule for this HRESULT is that The facility code preserves the SIP status number; diagnosis should start with the method and responding hop rather than treating every value as a local COM failure; in addition, the path requires that Some responses invite a modified request or authenticated retry, while others are terminal for the current target or even global for the addressed user.
How to prove the condition
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to record the authenticated identity, target, method, responding hop, and policy-safe reason data.
- confirm the distinction that Forbidden is not an authentication challenge and usually should not trigger repeated credential prompts.
- create a fresh operation generation after you stop identical retries, surface the policy/account boundary, and change authorization or request scope only with evidence, and compare its final state with the failing run.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Nearby failure modes
The practical separator for this HRESULT is this: 401 asks for authentication; 403 says the understood request is not permitted; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED | the server does not support the SIP protocol version in the request |
|---|---|
RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE | the server is temporarily unable to process the request because of overload or maintenance |
RTC_E_STATUS_CLIENT_REQUEST_TIMEOUT | the server could not produce a response within its transaction timing window |
Keeping this result separate from these neighbors improves both user messaging and automated retry policy.
Minimum incident record
Correlate it at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: record the authenticated identity, target, method, responding hop, and policy-safe reason data.
- Owning object for this HRESULT: responding Via hop.
- Wire evidence for this HRESULT: Call-ID/CSeq/tags.
- Lifecycle generation for this HRESULT: status-specific headers.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Correct application response
Recovery from it should be narrow: stop identical retries, surface the policy/account boundary, and change authorization or request scope only with evidence; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: A conferencing server accepts the user’s credentials but forbids adding another participant under the meeting policy.
Actions that do not address this condition
- An investigation should not 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.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the server understood the request but refuses to authorize or perform it for this identity or policy”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP response semantics — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.