| Previous | Next |
| RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE | RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE |
RTC_E_STATUS_CLIENT_BAD_EXTENSION
What RTC_E_STATUS_CLIENT_BAD_EXTENSION means in RTC
Diagnosis begins inside a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, where the relevant condition for this HRESULT is the server requires removal of a SIP extension it does not understand.
The numeric form of this result is 0x80EF01A4 in the RTC SIP-status facility carrying status 420; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
The quickest way to localize this result is to preserve the Unsupported header and compare it with every option tag in Require or Proxy-Require; the important boundary is that Bad Extension identifies mandatory extension negotiation rather than general malformed syntax.
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 requires removal of a SIP extension it does not understand |
| Safe corrective direction | remove or replace only the unsupported mandatory option when the feature can safely degrade |
How to prove the condition
- Record this result and
0x80EF01A4at the first RTC method or event that returns it. - Prove the condition by ensuring the trace can preserve the Unsupported header and compare it with every option tag in Require or Proxy-Require.
- Apply one controlled change: remove or replace only the unsupported mandatory option when the feature can safely degrade; then verify the result return value and resulting RTC state.
Nearby failure modes
For this HRESULT, 400 is generic syntax failure; 420 names an unsupported required extension; the neighboring results below require different control-flow decisions.
RTC_E_STATUS_CLIENT_AMBIGUOUS | the Request-URI can match more than one destination and the server cannot choose unambiguously |
|---|---|
RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED | the legacy SIP endpoint returned the reserved Payment Required status |
RTC_E_STATUS_CLIENT_REQUEST_ENTITY_TOO_LARGE | the request body exceeds the size the server is willing or able to process |
Minimum incident record
- Code-specific proof: preserve the Unsupported header and compare it with every option tag in Require or Proxy-Require.
- Owning object: responding Via hop.
- Wire evidence: Call-ID/CSeq/tags.
- Lifecycle state: status-specific headers.
Correct application response
Recovery should be narrow: remove or replace only the unsupported mandatory option when the feature can safely degrade; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: An endpoint rejects an INVITE requiring an option tag absent from its implementation.
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.