| 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 this HRESULT 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; 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
- Code-specific proof: record media type, direction, stream ID, and the completion event from the earlier AddStream/start request.
- Correlation key:
SDPo= version and c= address. - Protocol or object snapshot: each m= line and codec mapping.
- Last completed transition: message direction and transport.
- Expected output: start-line plus header names.
Protocol and object state
| RTC area | SIP message and SDP negotiation |
|---|---|
| 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
0x80EE0001, then find the method/event pair that first exposed it. - To verify this, 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.
Do not confuse it with
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 |
Recovery and control flow
Recovery should be narrow: reuse or modify the existing stream and serialize further media transitions; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: Two callbacks both react to the same call event and attempt to start the audio stream.
Actions that do not address this condition
- Do not log credentials or an unredacted SDP body from production calls.
- Do not repair malformed signaling by silently deleting unknown headers or media sections.
Technical references
Looking for a different code? Search another status or error code.