| Previous | Next |
| RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | RTC_E_SIP_CALL_DISCONNECTED |
RTC_E_SIP_NEED_MORE_DATA
What RTC_E_SIP_NEED_MORE_DATA means in RTC
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 should show that you retain byte count, header terminator position, parsed Content-Length, and connection identity; the diagnostic distinction is that this is a streaming/framing continuation state, not malformed syntax.
Minimum incident record
- Code-specific proof: retain byte count, header terminator position, parsed Content-Length, and connection identity.
- Owning object: message direction and transport.
- Wire evidence: start-line plus header names.
- Lifecycle state: Content-Type and Content-Length.
Protocol and object state
| RTC area | SIP message and SDP negotiation |
|---|---|
| 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 |
SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP. 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; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A TCP read ends halfway through the message body and the parser requests the remaining octets.
How to prove the condition
- Confirm the distinction that this is a streaming/framing continuation state, not malformed syntax.
- Start a fresh operation 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.
Nearby failure modes
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 |
Actions that do not address this condition
- 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.
Technical references
Looking for a different code? Search another status or error code.