| Previous | Next |
| RTC_E_REDIRECT_PROCESSING_FAILED | RTC_E_INVALID_LISTEN_SOCKET |
RTC_E_LISTENING_SOCKET_NOT_EXIST
Operational meaning: RTC_E_LISTENING_SOCKET_NOT_EXIST
Read this result as an RTC state-machine result: at this point in registering listening sockets and supplying internal/external media mappings before session establishment, code attempted to stop or use a listening address/port registration that is not active.
Log this result as 0x80EE007A in the RTC interface facility 0xEE, not only as a signed decimal; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration for this HRESULT, record local tuple, transport, registration handle/generation, and prior stop or interface-change event; the RTC codes surrounding this result are not equivalent because no registered RTC listen socket differs from a socket existing but using invalid address parameters.
Signals worth preserving
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: record local tuple, transport, registration handle/generation, and prior stop or interface-change event.
- Correlation key for this HRESULT: local and external address/port.
- Protocol or object snapshot for this HRESULT: port type and allowed range.
- Last completed transition for this HRESULT: mapping owner and lifetime.
- Expected output for this HRESULT: listen registration state.
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.
Recovery and control flow
The corrective direction for this HRESULT is to make stop idempotent or register the tuple before depending on incoming requests; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: Network-change cleanup removes a listener, then a second cleanup path removes it again.
Protocol and object boundary
| RTC area | RTC listening and NAT port-mapping boundary |
|---|---|
| Condition to prove | code attempted to stop or use a listening address/port registration that is not active |
| Objects to correlate | IRTCClientPortManagement, IRTCSessionPortManagement, IRTCPortManager, address/port range and mapping lifetime |
| Safe corrective direction | make stop idempotent or register the tuple before depending on incoming requests |
Two RTC rules frame it: first, For outgoing sessions the port manager must be set before adding the participant; for incoming sessions it must be set before acceptance; second, for this HRESULT, The address advertised in SDP and the local socket receiving media are different values when NAT mapping is involved.
Verification workflow
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to record local tuple, transport, registration handle/generation, and prior stop or interface-change event.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that no registered RTC listen socket differs from a socket existing but using invalid address parameters.
- create a fresh operation generation after you make stop idempotent or register the tuple before depending on incoming requests, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Actions that do not address this condition
- With it, do not set or replace the port manager after session initiation has consumed the mapping.
- Another non-solution for this HRESULT is to do not advertise an external mapping before confirming that it belongs to the current local socket.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Do not confuse it with
It is tied to the condition “code attempted to stop or use a listening address/port registration that is not active”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_PORT_MAPPING_UNAVAILABLE | the port manager cannot provide a usable internal/external mapping for the requested media flow |
|---|---|
RTC_E_INVALID_LISTEN_SOCKET | the address and port supplied for RTC listening cannot be bound or accepted as a valid listen tuple |
RTC_E_PORT_MAPPING_FAILED | the port manager returned a concrete failure while creating or retrieving a mapping |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “code attempted to stop or use a listening address/port registration that is not active”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- IRTCClientPortManagement — API or protocol rules used to interpret it.
- RTC address mapping — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SDP syntax — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.