| Previous | Next |
| RTC_E_SIP_STREAM_NOT_PRESENT | RTC_E_SIP_PARSE_FAILED |
RTC_E_SIP_NO_STREAM
Where the state changes: RTC_E_SIP_NO_STREAM
Diagnosis begins inside parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, where the decisive condition for it is the operation requires at least one active media stream but the session currently has none.
The numeric form of this result is 0x80EE0003 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 it should show that you enumerate negotiated and locally enabled media types before invoking stream-dependent work; the diagnostic distinction for it is that no active stream can be a valid signaling state, especially for text-only or held sessions.
Telemetry and packet evidence
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for it, this keeps later retries from obscuring causality.
- Code-specific proof for it: enumerate negotiated and locally enabled media types before invoking stream-dependent work.
- Addressing context for it: each m= line and codec mapping.
- RTC callback state for it: message direction and transport.
- Transaction boundary for it: start-line plus header names.
- Media or profile detail for it: 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 |
|---|---|
| Condition to prove | the operation requires at least one active media stream but the session currently has none |
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Safe corrective direction | add or negotiate the required stream, or skip the media-only operation for this session type |
Two RTC rules frame this result: first, SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; second, for it, An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Actions that do not address this condition
- The following shortcut is unsafe for it: do not do not log credentials or an unredacted SDP body from production calls.
- Another non-solution for it is to do not repair malformed signaling by silently deleting unknown headers or media sections.
- Do not translate this result into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Step-by-step isolation
- Record it and
0x80EE0003at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can enumerate negotiated and locally enabled media types before invoking stream-dependent work.
- Apply one controlled change for it: add or negotiate the required stream, or skip the media-only operation for this session type; then verify the result return value and resulting RTC state.
Use RTC event state to interpret the protocol trace for it, and use the trace to verify what left or reached the host; for it, this two-sided correlation identifies the producing layer.
Remediation boundary
Recovery from it should be narrow: add or negotiate the required stream, or skip the media-only operation for this session type; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for it, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for it: An audio-control command is sent to an IM-only session with no audio media.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. It is tied to the condition “the operation requires at least one active media stream but the session currently has none”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_SDP_MULTICAST | the SDP describes a multicast connection that the RTC Client API path does not support |
|---|---|
RTC_E_SDP_UPDATE_FAILED | a new SDP description is incompatible with the prior negotiated offer/answer state |
RTC_E_SIP_STREAM_NOT_PRESENT | code attempted to stop or remove a stream that is not active in the current session generation |
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 operation requires at least one active media stream but the session currently has none”; 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 — definitions relevant when reproducing it.
- SIP message and transaction rules — API or protocol rules used to interpret it.
- SDP syntax — authoritative context for the boundary.
- SDP offer/answer — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.