| 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; 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. - To verify this, 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.
Evidence that separates the cause
The evidence set should begin at the first failing or completing RTC operation; reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof: correlate upstream target, transport result, response framing, and gateway logs at both hops.
- Identity and target: status-specific headers.
- State at production: retry or alternate-target decision.
- Timing and ordering: request method and Request-URI.
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 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 |
Related RTC results
For this HRESULT, 504 means the upstream did not answer in time rather than answered invalidly; 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 |
How to handle the result
To correct this, repair or bypass the failing upstream route and reconcile whether it processed the request.
Example: A SIP gateway forwards an INVITE to a trunk peer that returns an unreadable response.
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.