| Previous | Next |
| RTC_E_STATUS_CLIENT_REQUEST_URI_TOO_LARGE | RTC_E_STATUS_CLIENT_BAD_EXTENSION |
RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE
Operational meaning: RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE
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 does not support the media type or encoding of the request body.
The numeric form of this result is 0x80EF019F in the RTC SIP-status facility carrying status 415; 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 record Content-Type, Content-Encoding, method, body purpose, and Accept/Accept-Encoding hints; the important the boundary is that Unsupported Media Type rejects payload representation; 488 rejects session parameters such as an SDP offer.
Signals worth preserving
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: record Content-Type, Content-Encoding, method, body purpose, and Accept/Accept-Encoding hints.
- Correlation key for this HRESULT: retry or alternate-target decision.
- Protocol or object snapshot for this HRESULT: request method and Request-URI.
- Last completed transition for this HRESULT: responding Via hop.
- Expected output for this HRESULT: Call-ID/CSeq/tags.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Recovery and control flow
The owning RTC component should serialize the body in a supported format or remove it when the method permits, then create a new request; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: A NOTIFY carries an XML type the subscriber did not advertise or implement.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the server does not support the media type or encoding of the request body |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | serialize the body in a supported format or remove it when the method permits, then create a new request |
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; the second rule relevant to it is 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
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to record Content-Type, Content-Encoding, method, body purpose, and Accept/Accept-Encoding hints.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that Unsupported Media Type rejects payload representation; 488 rejects session parameters such as an
SDPoffer. - create a fresh operation generation after you serialize the body in a supported format or remove it when the method permits, then create a new request, and compare its final state with the failing run.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Do not confuse it with
The practical separator for this HRESULT is this: 406 concerns acceptable response formats; 415 concerns the incoming request body; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_STATUS_CLIENT_TOO_MANY_HOPS | the request exhausted its Max-Forwards allowance before reaching a final destination |
|---|---|
RTC_E_STATUS_GLOBAL_DECLINE | the user or authoritative service globally declined the request |
RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | the Request-URI lacks information required to identify or route the destination |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the server does not support the media type or encoding of the request body”; 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 — 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.