| Previous | Next |
| RTC_E_STATUS_SERVER_SERVER_TIMEOUT | RTC_E_STATUS_GLOBAL_BUSY_EVERYWHERE |
RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED
Operational meaning: RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED
In the RTC Client API, this result separates one failure or completion path from its neighbors because it denotes the server does not support the SIP protocol version in the request.
At the HRESULT layer, this result appears as 0x80EF01F9 in the RTC SIP-status facility carrying status 505; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
A defensible diagnosis of this result requires you to capture the exact request line, serializer version token, and any intermediary that rewrote it; in the case, Version Not Supported concerns SIP-Version, not an unsupported extension option or media version.
Signals worth preserving
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: capture the exact request line, serializer version token, and any intermediary that rewrote it.
- Correlation key for this HRESULT: status-specific headers.
- Protocol or object snapshot for this HRESULT: retry or alternate-target decision.
- Last completed transition for this HRESULT: request method and Request-URI.
- Expected output for this HRESULT: responding Via hop.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Recovery and control flow
The owning RTC component should use a protocol version supported by both sides and fix any component emitting a malformed version token; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A custom transport sends an invalid SIP version in the request line to a compliant server.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the server does not support the SIP protocol version in the request |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | use a protocol version supported by both sides and fix any component emitting a malformed version token |
The surrounding protocol rule for this HRESULT is that 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; in addition, the path requires 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.
Verification workflow
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to capture the exact request line, serializer version token, and any intermediary that rewrote it.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- test the competing explanation explicitly, because Version Not Supported concerns
SIP-Version, not an unsupported extension option or media version. - perform the narrow correction — use a protocol version supported by both sides and fix any component emitting a malformed version token — and validate both protocol completion and object cleanup.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Actions that do not address this condition
- With it, do not show a reason phrase as trusted server identity or authorization evidence.
- Do not retry every 4xx or 5xx response with the identical request.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Do not confuse it with
Use the following contrast when classifying it: 420 is for mandatory extensions, while 505 is for the base protocol version; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_STATUS_CLIENT_TOO_MANY_HOPS | the request exhausted its Max-Forwards allowance before reaching a final destination |
|---|---|
RTC_E_STATUS_SERVER_NOT_IMPLEMENTED | the server does not implement the SIP method needed |
RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE | the server does not support the media type or encoding of the request body |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
Keep two tests: one that intentionally produces “the server does not support the SIP protocol version in the request”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF01F9, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP response semantics — authoritative context for the boundary.
Looking for a different code? Search another status or error code.