| Previous | Next |
| RTC_E_STATUS_SERVER_NOT_IMPLEMENTED | RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE |
RTC_E_STATUS_SERVER_BAD_GATEWAY
What the RTC value marks: RTC_E_STATUS_SERVER_BAD_GATEWAY
The useful interpretation of this result is narrower than “SIP error”; within a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, it means the responding gateway or proxy received an invalid response from an upstream server.
The stored Value is 0x80EF01F6 in the RTC SIP-status facility carrying status 502; for this HRESULT, keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Collect enough state to correlate upstream target, transport result, response framing, and gateway logs at both hops; the result evidence should demonstrate why Bad Gateway points to intermediary/upstream interaction, not necessarily a defect in the original client request.
A safe diagnostic sequence
- Start from
0x80EF01F6and 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 correlate upstream target, transport result, response framing, and gateway logs at both hops.
- keep the analysis at the right boundary: Bad Gateway points to intermediary/upstream interaction, not necessarily a defect in the original client request.
- after you repair or bypass the failing upstream route and reconcile whether it processed the request, repeat the smallest reproducer rather than restarting the entire application environment.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Evidence that separates the cause
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: correlate upstream target, transport result, response framing, and gateway logs at both hops.
- Identity and target for this HRESULT: status-specific headers.
- State at production for this HRESULT: retry or alternate-target decision.
- Timing and ordering for this HRESULT: request method and Request-URI.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
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 responding gateway or proxy received an invalid response from an upstream server |
| Safe corrective direction | repair or bypass the failing upstream route and reconcile whether it processed the request |
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.
Related RTC results
For this HRESULT, 504 means the upstream did not answer in time rather than answered invalidly; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_NOT_ACCEPTABLE_HERE | the target cannot accept the session description or other negotiated session parameters for this resource |
|---|---|
RTC_E_STATUS_CLIENT_REQUEST_URI_TOO_LARGE | the Request-URI is longer than the receiving element can process |
RTC_E_STATUS_CLIENT_BUSY_HERE | the particular contacted user agent is busy and will not accept the call now |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
How to handle the result
The corrective direction for this HRESULT is to repair or bypass the failing upstream route and reconcile whether it processed the request; 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 SIP gateway forwards an INVITE to a trunk peer that returns an unreadable response.
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.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A regression test for this HRESULT should reproduce “the responding gateway or proxy received an invalid response from an upstream server” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF01F6, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.