| Previous | Next |
| RTC_E_PORT_MAPPING_UNAVAILABLE | RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE |
RTC_E_PORT_MAPPING_FAILED
What the RTC value marks: RTC_E_PORT_MAPPING_FAILED
The legacy RTC Client API reports this result while working with registering listening sockets and supplying internal/external media mappings before session establishment; the precise meaning of it is the port manager returned a concrete failure while creating or retrieving a mapping, not merely that a call or registration failed.
For correlation, retain 0x80EE0046 in the RTC interface facility 0xEE together with this result; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you preserve the port-manager HRESULT, requested tuple, NAT device response, and existing allocations; the diagnostic distinction for this HRESULT is that this code indicates an attempted mapping failed, stronger than merely unavailable capability.
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 port manager returned a concrete failure while creating or retrieving a mapping |
| Safe corrective direction | repair the mapping component or choose another allowed port and repeat before session initiation |
The surrounding protocol rule for this HRESULT is that For outgoing sessions the port manager must be set before adding the participant; for incoming sessions it must be set before acceptance; in addition, the path requires that The address advertised in SDP and the local socket receiving media are different values when NAT mapping is involved.
Evidence that separates the cause
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: preserve the port-manager HRESULT, requested tuple, NAT device response, and existing allocations.
- Identity and target for this HRESULT: mapping owner and lifetime.
- State at production for this HRESULT: listen registration state.
- Timing and ordering for this HRESULT:
SDPaddress derived from mapping.
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.
Related RTC results
Use the following contrast when classifying this result: it is tied to the condition “the port manager returned a concrete failure while creating or retrieving a mapping”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_PORT_MAPPING_UNAVAILABLE | the port manager cannot provide a usable internal/external mapping for the requested media flow |
|---|---|
RTC_E_PORT_MANAGER_ALREADY_SET | the session already has a port-manager callback and RTC forbids replacing it at this stage |
RTC_E_INVALID_LISTEN_SOCKET | the address and port supplied for RTC listening cannot be bound or accepted as a valid listen tuple |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
A safe diagnostic sequence
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to preserve the port-manager HRESULT, requested tuple, NAT device response, and existing allocations.
- test the competing explanation explicitly, because this code indicates an attempted mapping failed, stronger than merely unavailable capability.
- perform the narrow correction — repair the mapping component or choose another allowed port and repeat before session initiation — and validate both protocol completion and object cleanup.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, repair the mapping component or choose another allowed port and repeat before session initiation, while preserving ownership of cleanup and any bounded retry.
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: UPnP mapping creation is rejected by the gateway for the requested external port.
Actions that do not address this condition
- An investigation should not do not advertise an external mapping before confirming that it belongs to the current local socket.
- Another non-solution for this HRESULT is to do not set or replace the port manager after session initiation has consumed the mapping.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
A regression test for this HRESULT should reproduce “the port manager returned a concrete failure while creating or retrieving a mapping” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0046, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- IRTCClientPortManagement — authoritative context for the boundary.
- RTC address mapping — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SDP syntax — authoritative context for the boundary.
Looking for a different code? Search another status or error code.