Site icon EfmSoft

What does HRESULT 0x80F00009 (RTC_E_PINT_STATUS_REJECTED_SW_FAILED) mean?

 
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 code belongs to 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.

For correlation, retain 0x80F00009 in the RTC PINT-status facility together with this result; 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 boundary is that a switch failure is infrastructure-side and should not be reported as a bad telephone number.

Protocol and object state

RTC areaPINT telephone-service outcome
Objects to correlatePINT request, gateway, primary and secondary PSTN legs, switch outcome and cancellation state
Condition to provethe telephone switch or gateway switching function failed while executing the service
Safe corrective directiontear down partial legs, route to another healthy gateway when allowed, and preserve carrier diagnostics

PINT extends SIP/SDP to request telephone-network services; these status values describe PSTN execution rather than ordinary SIP proxy routing. 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

  • Code-specific proof: record switch/gateway identity, cause code, leg states, and whether partial connections remain.
  • Identity and target: cancellation or final indication.
  • State at production: PINT request/correlation ID.
  • Timing and ordering: service and telephone number hashes.

A safe diagnostic sequence

  1. Record it and 0x80F00009 at the first RTC method or event that returns it.
  2. Prove the condition by ensuring the trace can record switch/gateway identity, cause code, leg states, and whether partial connections remain.
  3. Apply one controlled change: 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.

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.

Example: The PINT server accepts a request but its PSTN switch cannot bridge the two call legs.

Actions that do not address this condition

  • Do not reinterpret a PSTN leg result as a SIP transport outage.
  • Do not expose complete telephone numbers in general application logs.

Related RTC results

Comparison point: Primary Leg Failed scopes the problem to the first service leg.

RTC_E_PINT_STATUS_REJECTED_PL_FAILEDthe primary telephone leg failed before the requested PINT service could be completed
RTC_E_PINT_STATUS_REJECTED_NO_ANSWERthe PSTN call attempt rang or progressed but was not answered within the service window
RTC_E_PINT_STATUS_REJECTED_BUSYthe selected PSTN destination returned a busy indication

Technical references


Looking for a different code? Search another status or error code.

Exit mobile version