Skip to main content
Question

Clarification on Differentiating Rejected, Missed, and Interrupted Transfers in the Call Log API

  • August 5, 2026
  • 0 replies
  • 8 views

Hi RingCentral Support,

We're using the RingCentral Softphone SDK to answer inbound calls and perform attended/blind transfers to other RingCentral extensions.

We've encountered a scenario where we'd like to understand how to reliably determine the outcome of a transfer using the Call Log API or any other available API.

Scenario

  1. An inbound call is answered using our application via the Softphone SDK.

  2. The application transfers the call to another RingCentral extension.

  3. The destination user receives the transfer in the RingCentral Desktop App.

  4. The destination user explicitly clicks Reject on the incoming transfer.

When we retrieve the call using the Detailed Call Log API, the transfer leg is recorded with:

  • Action: VoIP Call

  • Result: Stopped

There is no indication that the destination user explicitly rejected the transfer.

Our concern is that the same Stopped result could also occur in other situations, such as:

  • The destination user rejects the transfer.

  • The original caller hangs up while the transfer is ringing.

  • The transfer fails for another reason.

Could you please clarify:

  1. Is Result = Stopped the expected value when a destination user explicitly rejects a transferred call? Is the response same if we use physical device to reject the call?

  2. Is there any field in the Call Log API (such as Reason, Reason Description, SIP response code, or another attribute) that allows us to distinguish between:

    • User rejected the transfer

    • Caller hung up during the transfer

    • Transfer timed out / no answer

  3. If the Call Log API does not expose this information, is there another API that provides the exact reason a transfer leg ended?

  4. Is it possible to obtain the SIP response code (for example, 486 Busy Here or 603 Decline) associated with the transfer attempt?

Our goal is to reliably identify whether a transferred call was explicitly rejected by the destination user or was missed or caller hungup mid-trasnfer or ending for another reason.

Any guidance or recommended approach would be greatly appreciated.

Thank you.