What does HRESULT 0x80EF019F (RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE) mean?

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 relevant 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 boundary is that Unsupported Media Type rejects payload representation; 488 rejects session parameters such as an SDP offer.

Signals worth preserving

• Code-specific proof: record Content-Type, Content-Encoding, method, body purpose, and Accept/Accept-Encoding hints.
• Correlation key: retry or alternate-target decision.
• Protocol or object snapshot: request method and Request-URI.
• Last completed transition: responding Via hop.
• Expected output: Call-ID/CSeq/tags.

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; it should also settle or cancel its previous operation before callers begin a replacement.

Example: A NOTIFY carries an XML type the subscriber did not advertise or implement.

Protocol and object state

Verification workflow

1. Use protocol and object evidence to record Content-Type, Content-Encoding, method, body purpose, and Accept/Accept-Encoding hints.
2. Confirm the distinction that Unsupported Media Type rejects payload representation; 488 rejects session parameters such as an SDP offer.
3. Start a fresh operation 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.

Actions that do not address this condition

• 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 confuse it with

Comparison point: 406 Concerns acceptable response formats; 415 concerns the incoming request body.

Technical references

• Microsoft RTC return constants.
• SIP response semantics.