| Previous | Next |
| RTC_E_LISTENING_SOCKET_NOT_EXIST | RTC_E_PORT_MANAGER_ALREADY_SET |
RTC_E_INVALID_LISTEN_SOCKET
What the RTC value marks: RTC_E_INVALID_LISTEN_SOCKET
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, the address and port supplied for RTC listening cannot be bound or accepted as a valid listen tuple.
Log this result as 0x80EE007B in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check is to record address family, interface ownership, port range, existing bind, transport, and socket state. The result must be separated from nearby conditions because invalid listen tuple is local configuration; it is not failure to connect to a remote SIP server.
A safe diagnostic sequence
- Start from
0x80EE007Band this result, 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 address family, interface ownership, port range, existing bind, transport, and socket state.
- Keep the analysis at the right boundary: invalid listen tuple is local configuration; it is not failure to connect to a remote
SIPserver. - After you choose an active local address and allowed free port before registering it, 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 this result, avoid treating packet capture and HRESULT logging as substitutes for one another.
Evidence that separates the cause
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: record address family, interface ownership, port range, existing bind, transport, and socket state.
- Identity and target: listen registration state.
- State at production:
SDPaddress derived from mapping. - Timing and ordering: local and external address/port.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Protocol and object boundary
| RTC area | RTC listening and NAT port-mapping boundary |
|---|---|
| Objects to correlate | IRTCClientPortManagement, IRTCSessionPortManagement, IRTCPortManager, address/port range and mapping lifetime |
| Condition to prove | the address and port supplied for RTC listening cannot be bound or accepted as a valid listen tuple |
| Safe corrective direction | choose an active local address and allowed free port before registering it |
For outgoing sessions the port manager must be set before adding the participant; for incoming sessions it must be set before acceptance; the second rule relevant to it is that The address advertised in SDP and the local socket receiving media are different values when NAT mapping is involved.
Related RTC results
Use the following contrast when classifying it: it is tied to the condition “the address and port supplied for RTC listening cannot be bound or accepted as a valid listen tuple”; preserve that producing boundary before choosing recovery; similar subsystem names do not imply identical recovery.
RTC_E_PORT_MANAGER_ALREADY_SET | the session already has a port-manager callback and RTC forbids replacing it at this stage |
|---|---|
RTC_E_PORT_MAPPING_UNAVAILABLE | the port manager cannot provide a usable internal/external mapping for the requested media flow |
RTC_E_LISTENING_SOCKET_NOT_EXIST | code attempted to stop or use a listening address/port registration that is not active |
How to handle the result
Recovery should be narrow: choose an active local address and allowed free port before registering it; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
A retry is safe only after the prior transaction’s outcome is reconciled; reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: The application asks RTC to listen on an address not assigned to any current interface.
Actions that do not address this condition
- The following shortcut is unsafe: do not advertise an external mapping before confirming that it belongs to the current local socket.
- Do not set or replace the port manager after session initiation has consumed the mapping.
- A wrapper handling this result should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Keep two tests: one that intentionally produces “the address and port supplied for RTC listening cannot be bound or accepted as a valid listen tuple”, and one that applies the narrow correction; check the callback sequence, 0x80EE007B, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- IRTCClientPortManagement — definitions relevant when reproducing it.
- RTC address mapping — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SDP syntax — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.