| Previous | Next |
| RTC_E_SIP_CODECS_DO_NOT_MATCH | RTC_E_SIP_STREAM_NOT_PRESENT |
RTC_E_SIP_STREAM_PRESENT
Operational meaning: RTC_E_SIP_STREAM_PRESENT
This result should be investigated at the point where RTC handles parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, and the condition to prove for it is code attempted to start a media stream already represented in the current RTC session state.
This result is represented as 0x80EE0001 in the RTC interface facility 0xEE; for it, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
A defensible diagnosis of this result requires you to record media type, direction, stream ID, and the completion event from the earlier AddStream/start request; in the case, an existing stream is a state/ownership result, not evidence that media packets are flowing correctly.
Signals worth preserving
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for it: record media type, direction, stream ID, and the completion event from the earlier AddStream/start request.
- Correlation key for it:
SDPo= version and c= address. - Protocol or object snapshot for it: each m= line and codec mapping.
- Last completed transition for it: message direction and transport.
- Expected output for it: start-line plus header names.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for it, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Condition to prove | code attempted to start a media stream already represented in the current RTC session state |
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Safe corrective direction | reuse or modify the existing stream and serialize further media transitions |
Interpreting it requires both of these facts: SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; also, the result branch assumes 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
0x80EE0001and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to record media type, direction, stream ID, and the completion event from the earlier AddStream/start request.
- keep the analysis at the right boundary: an existing stream is a state/ownership result, not evidence that media packets are flowing correctly.
- after you reuse or modify the existing stream and serialize further media transitions, repeat the smallest reproducer rather than restarting the entire application environment.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “code attempted to start a media stream already represented in the current RTC session state”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_SDP_CONNECTION_ADDR | an SDP media description has no usable connection address at session or media level |
|---|---|
RTC_E_SDP_MULTICAST | the SDP describes a multicast connection that the RTC Client API path does not support |
RTC_E_SIP_NO_STREAM | the operation requires at least one active media stream but the session currently has none |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Recovery and control flow
Recovery from it should be narrow: reuse or modify the existing stream and serialize further media transitions; 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: Two callbacks both react to the same call event and attempt to start the audio stream.
Actions that do not address this condition
- A it investigation should not do not log credentials or an unredacted SDP body from production calls.
- also do not do not repair malformed signaling by silently deleting unknown headers or media sections.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
Keep two tests: one that intentionally produces “code attempted to start a media stream already represented in the current RTC session state”, and one that applies the narrow correction; for it, check the callback sequence, 0x80EE0001, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP message and transaction rules — definitions relevant when reproducing it.
- SDP syntax — API or protocol rules used to interpret it.
- SDP offer/answer — authoritative context for the boundary.
Looking for a different code? Search another status or error code.