| Previous | Next |
| RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE | RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE |
RTC_E_STATUS_CLIENT_BAD_EXTENSION
Protocol boundary: RTC_E_STATUS_CLIENT_BAD_EXTENSION
Diagnosis begins inside a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, where the decisive 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 the boundary is that Bad Extension identifies mandatory extension negotiation rather than general malformed syntax.
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 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 |
At the boundary, 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; separately, this result must be read with the rule that 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
- Record this result and
0x80EF01A4at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- 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 for this HRESULT: remove or replace only the unsupported mandatory option when the feature can safely degrade; then verify the result return value and resulting RTC state.
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.
Nearby failure modes
For this HRESULT, 400 is generic syntax failure; 420 names an unsupported required extension; for this HRESULT, 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 |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Minimum incident record
Correlate it at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: preserve the Unsupported header and compare it with every option tag in Require or Proxy-Require.
- Owning object for this HRESULT: responding Via hop.
- Wire evidence for this HRESULT: Call-ID/CSeq/tags.
- Lifecycle generation for this HRESULT: status-specific headers.
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.
Correct application response
Recovery from it should be narrow: remove or replace only the unsupported mandatory option when the feature can safely degrade; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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: An endpoint rejects an INVITE requiring an option tag absent from its implementation.
Actions that do not address this condition
- An investigation should not 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.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the server requires removal of a SIP extension it does not understand”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP response semantics — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.