| Previous | Next |
| RTC_E_STATUS_CLIENT_GONE | RTC_E_STATUS_CLIENT_REQUEST_ENTITY_TOO_LARGE |
RTC_E_STATUS_CLIENT_LENGTH_REQUIRED
Operational meaning: RTC_E_STATUS_CLIENT_LENGTH_REQUIRED
This code belongs to a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the server requires an explicit Content-Length body framing it received. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF019B in the RTC SIP-status facility carrying status 411 together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you inspect the serialized message boundary, Content-Length header, byte count after encoding, and transport; the diagnostic distinction is that Length Required is a framing problem, not proof that the content itself is invalid.
Signals worth preserving
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: inspect the serialized message boundary, Content-Length header, byte count after encoding, and transport.
- Correlation key: status-specific headers.
- Protocol or object snapshot: retry or alternate-target decision.
- Last completed transition: request method and Request-URI.
- Expected output: responding Via hop.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Condition to prove | the server requires an explicit Content-Length body framing it received |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | fix serialization so the length matches the transmitted octets and resend as a new valid request |
Verification workflow
- Start from
0x80EF019B, then find the method/event pair that first exposed it. - To verify this, inspect the serialized message boundary, Content-Length header, byte count after encoding, and transport.
- Keep the analysis at the right boundary: Length Required is a framing problem, not proof that the content itself is invalid.
- After you fix serialization so the length matches the transmitted octets and resend as a new valid request, repeat the smallest reproducer rather than restarting the entire application environment.
Do not confuse it with
Comparison point: 413 Says the body is too large even when correctly framed.
RTC_E_STATUS_CLIENT_UNAUTHORIZED | the user agent server or registrar requires end-server authentication |
|---|---|
RTC_E_STATUS_GLOBAL_BUSY_EVERYWHERE | the user is busy at every known location and further branching should stop |
RTC_E_STATUS_CLIENT_PROXY_AUTHENTICATION_REQUIRED | an intermediary proxy requires authentication before forwarding the request |
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, fix serialization so the length matches the transmitted octets and resend as a new valid request, while preserving ownership of cleanup and any bounded retry.
Example: A custom SIP sender omits Content-Length on a request body accepted by neither the proxy nor the endpoint.
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.