| Previous | Next |
| RTC_E_STATUS_CLIENT_UNAUTHORIZED | RTC_E_STATUS_CLIENT_FORBIDDEN |
RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED
Protocol boundary: RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED
This result marks a specific boundary in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the legacy SIP endpoint returned the reserved Payment Required status; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF0192 in the RTC SIP-status facility carrying status 402 together with this result; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you capture the complete method, responder product/version, and any extension headers or body defining local semantics; the diagnostic distinction for this HRESULT is that RFC 3261 reserves 402 without standard operational behavior, so the reason phrase alone is insufficient.
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 legacy SIP endpoint returned the reserved Payment Required status |
| Safe corrective direction | treat it as an extension-specific terminal response unless the deployed service contract defines a safe next step |
Two RTC rules frame this result: first, 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; second, for this HRESULT, 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
- Start from
0x80EF0192and this result, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to capture the complete method, responder product/version, and any extension headers or body defining local semantics.
- keep the analysis at the right boundary: RFC 3261 reserves 402 without standard operational behavior, so the reason phrase alone is insufficient.
- after you treat it as an extension-specific terminal response unless the deployed service contract defines a safe next step, repeat the smallest reproducer rather than restarting the entire application environment.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Minimum incident record
The earliest callback or return site is the most valuable; later it cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: capture the complete method, responder product/version, and any extension headers or body defining local semantics.
- Owning object for this HRESULT: status-specific headers.
- Wire evidence for this HRESULT: retry or alternate-target decision.
- Lifecycle generation for this HRESULT: request method and Request-URI.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not retry every 4xx or 5xx response with the identical request.
- also 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.
Correct application response
The corrective direction for this HRESULT is to treat it as an extension-specific terminal response unless the deployed service contract defines a safe next step; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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 proprietary gateway uses 402 to signal an account-billing condition; the application routes it to gateway-specific handling.
Nearby failure modes
For this HRESULT, 403 has standard authorization-denied semantics; 402 depends on the deployed extension; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE | the resource cannot produce a response representation acceptable under the request’s Accept constraints |
|---|---|
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | the addressed user or endpoint is temporarily unavailable at all currently known contacts |
RTC_E_STATUS_CLIENT_LENGTH_REQUIRED | the server requires an explicit Content-Length body framing it received |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
Keep two tests: one that intentionally produces “the legacy SIP endpoint returned the reserved Payment Required status”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF0192, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP response semantics — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.