| Previous | Next |
| RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | RTC_E_SIP_CALL_DISCONNECTED |
RTC_E_SIP_NEED_MORE_DATA
Protocol boundary: RTC_E_SIP_NEED_MORE_DATA
The legacy RTC Client API reports this result while working with parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it; the precise meaning of it is the receive buffer contains only part of a complete SIP message, not merely that a call or registration failed.
The numeric form of this result is 0x80EE0018 in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
Evidence for this HRESULT should show that you retain byte count, header terminator position, parsed Content-Length, and connection identity; the diagnostic distinction for this HRESULT is that this is a streaming/framing continuation state, not malformed syntax.
Minimum incident record
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: retain byte count, header terminator position, parsed Content-Length, and connection identity.
- Owning object for this HRESULT: message direction and transport.
- Wire evidence for this HRESULT: start-line plus header names.
- Lifecycle generation for this HRESULT: Content-Type and Content-Length.
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.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Condition to prove | the receive buffer contains only part of a complete SIP message |
| Safe corrective direction | continue reading on the same transport until the declared message length is available, with size limits |
At the boundary, SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; separately, this result must be read with the rule that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Correct application response
The owning RTC component should continue reading on the same transport until the declared message length is available, with size limits; 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 TCP read ends halfway through the message body and the parser requests the remaining octets.
How to prove the condition
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to retain byte count, header terminator position, parsed Content-Length, and connection identity.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that this is a streaming/framing continuation state, not malformed syntax.
- create a fresh operation generation after you continue reading on the same transport until the declared message length is available, with size limits, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Nearby failure modes
It should not be grouped with every value from the same facility. It is tied to the condition “the receive buffer contains only part of a complete SIP message”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_SIP_STREAM_NOT_PRESENT | code attempted to stop or remove a stream that is not active in the current session generation |
|---|---|
RTC_E_SIP_INVITE_TRANSACTION_PENDING | another INVITE or re-INVITE transaction still owns the dialog’s offer/answer state |
RTC_E_SDP_NO_MEDIA | the SDP contains no enabled media description usable for the requested RTC session |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Actions that do not address this condition
- With it, do not repair malformed signaling by silently deleting unknown headers or media sections.
- Do not log credentials or an unredacted SDP body from production calls.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the receive buffer contains only part of a complete SIP message”; 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 message and transaction rules — authoritative context for the boundary.
- SDP syntax — definitions relevant when reproducing it.
- SDP offer/answer — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.