| Previous | Next |
| RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED | RTC_E_STATUS_CLIENT_NOT_FOUND |
RTC_E_STATUS_CLIENT_FORBIDDEN
What RTC_E_STATUS_CLIENT_FORBIDDEN means in RTC
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; the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check 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 state
| RTC area | SIP final response |
|---|---|
| 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 |
How to prove the condition
- 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.
- Start a fresh operation 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.
Nearby failure modes
Comparison point: 401 Asks for authentication; 403 says the understood request is not permitted.
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 |
Minimum incident record
- Code-specific proof: record the authenticated identity, target, method, responding hop, and policy-safe reason data.
- Owning object: responding Via hop.
- Wire evidence: Call-ID/CSeq/tags.
- Lifecycle state: status-specific headers.
Correct application response
Recovery should be narrow: stop identical retries, surface the policy/account boundary, and change authorization or request scope only with evidence; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A conferencing server accepts the user’s credentials but forbids adding another participant under the meeting policy.
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.
Technical references
Looking for a different code? Search another status or error code.