| Previous | Next |
| RTC_E_PINT_STATUS_REJECTED_PL_FAILED | RTC_E_PINT_STATUS_REJECTED_CANCELLED |
RTC_E_PINT_STATUS_REJECTED_SW_FAILED
What the RTC value marks: RTC_E_PINT_STATUS_REJECTED_SW_FAILED
This result marks a specific boundary in a PINT gateway reporting the PSTN-side result of a requested telephone service: the telephone switch or gateway switching function failed while executing the service; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80F00009 in the RTC PINT-status facility together with this result; for it, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to record switch/gateway identity, cause code, leg states, and whether partial connections remain; the important the boundary is that a switch failure is infrastructure-side and should not be reported as a bad telephone number.
Protocol and object boundary
| RTC area | PINT telephone-service outcome boundary |
|---|---|
| Objects to correlate | PINT request, gateway, primary and secondary PSTN legs, switch outcome and cancellation state |
| Condition to prove | the telephone switch or gateway switching function failed while executing the service |
| Safe corrective direction | tear down partial legs, route to another healthy gateway when allowed, and preserve carrier diagnostics |
The surrounding protocol rule for it is that PINT extends SIP/SDP to request telephone-network services; these status values describe PSTN execution rather than ordinary SIP proxy routing; in addition, the path requires that A signaling request can be accepted by the gateway yet later fail because one leg is busy, unanswered, invalid, or rejected by the switch.
Evidence that separates the cause
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for it, this keeps later retries from obscuring causality.
- Code-specific proof for it: record switch/gateway identity, cause code, leg states, and whether partial connections remain.
- Identity and target for it: cancellation or final indication.
- State at production for it:
PINTrequest/correlation ID. - Timing and ordering for it: service and telephone number hashes.
A useful it trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
A safe diagnostic sequence
- Record it and
0x80F00009at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can record switch/gateway identity, cause code, leg states, and whether partial connections remain.
- Apply one controlled change for it: tear down partial legs, route to another healthy gateway when allowed, and preserve carrier diagnostics; then verify the result return value and resulting RTC state.
Use RTC event state to interpret the protocol trace for it, and use the trace to verify what left or reached the host; for it, this two-sided correlation identifies the producing layer.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, tear down partial legs, route to another healthy gateway when allowed, and preserve carrier diagnostics, while preserving ownership of cleanup and any bounded retry.
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: The PINT server accepts a request but its PSTN switch cannot bridge the two call legs.
Actions that do not address this condition
- With it, do not do not reinterpret a PSTN leg result as a SIP transport outage.
- It is not corrected when operators do not expose complete telephone numbers in general application logs.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Related RTC results
The practical separator for it is this: Primary Leg Failed scopes the problem to the first service leg; for it, compare that boundary with these related RTC values.
RTC_E_PINT_STATUS_REJECTED_PL_FAILED | the primary telephone leg failed before the requested PINT service could be completed |
|---|---|
RTC_E_PINT_STATUS_REJECTED_NO_ANSWER | the PSTN call attempt rang or progressed but was not answered within the service window |
RTC_E_PINT_STATUS_REJECTED_BUSY | the selected PSTN destination returned a busy indication |
Telemetry for it should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the telephone switch or gateway switching function failed while executing the service”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- PINT service protocol — authoritative context for the boundary.
Looking for a different code? Search another status or error code.