| Previous | Next |
| RTC_E_SIP_STREAM_PRESENT | RTC_E_SIP_NO_STREAM |
RTC_E_SIP_STREAM_NOT_PRESENT
Operational meaning: RTC_E_SIP_STREAM_NOT_PRESENT
Diagnosis begins inside parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, where the decisive condition for it is code attempted to stop or remove a stream that is not active in the current session generation.
The numeric form of this result is 0x80EE0002 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.
The quickest way to localize this result is to compare the requested media type with the session’s actual stream list and prior completion events; the important the boundary is that a missing stream differs from a device failure because there is no active RTC stream to operate on.
Signals worth preserving
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: compare the requested media type with the session’s actual stream list and prior completion events.
- Correlation key for it: start-line plus header names.
- Protocol or object snapshot for it: Content-Type and Content-Length.
- Last completed transition for it:
SDPo= version and c= address. - Expected output for it: each m= line and codec mapping.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for it, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Recovery and control flow
Recovery from it should be narrow: make teardown idempotent and stop issuing removal after the stream-ended event has been processed; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for it: A hang-up path and a device-removal path both try to remove the same video stream.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Condition to prove | code attempted to stop or remove a stream that is not active in the current session generation |
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Safe corrective direction | make teardown idempotent and stop issuing removal after the stream-ended event has been processed |
SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; the second rule relevant to it is that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Verification workflow
- Start from
0x80EE0002and it, then find the method/event pair that first exposed it. - the proof step is to compare the requested media type with the session’s actual stream list and prior completion events.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: a missing stream differs from a device failure because there is no active RTC stream to operate on.
- after you make teardown idempotent and stop issuing removal after the stream-ended event has been processed, repeat the smallest reproducer rather than restarting the entire application environment.
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.
Actions that do not address this condition
- With it, do not do not repair malformed signaling by silently deleting unknown headers or media sections.
- also do not do not log credentials or an unredacted SDP body from production calls.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Do not confuse it with
Use the following contrast when classifying it: it is tied to the condition “code attempted to stop or remove a stream that is not active in the current session generation”; preserve that producing boundary before choosing recovery; for it, similar subsystem names do not imply identical recovery.
RTC_E_SDP_CONNECTION_ADDR | an SDP media description has no usable connection address at session or media level |
|---|---|
RTC_E_SDP_NO_MEDIA | the SDP contains no enabled media description usable for the requested RTC session |
RTC_E_SIP_NO_STREAM | the operation requires at least one active media stream but the session currently has none |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A regression test for it should reproduce “code attempted to stop or remove a stream that is not active in the current session generation” with the smallest profile, message, session, presence, media, or PINT fixture; for it, assert 0x80EE0002, the responsible method/event, and the object state after the result; then, for it, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.