Ring back if there's no answer - Expected behavior after transfer fails

Question

Ring back if there's no answer - Expected behavior after transfer fails

Steven Deferme 20

Hello, We use an Oracle eSBC to route telephone calls to/from MS Teams We have following scenario:

External telephone call to Teams User "Bob".
Bob answers the call.
Bob transfers the call to Teams User "Alice", with "Ring back if there's no answer" enabled --> At this moment, MS Teams sends a REFER to the SBC.
Upon receiving the REFER, the SBC starts a new call, and sends an INVITE to MS Teams for Alice. The SBC sends NOTIFY requests (in the original call dialog) to MS Teams reporting the status of the transfer. MS Teams sends 200 OK responses for these NOTIFY requests.
Alice doesn't answer the call: MS Teams sends a 480 Temporarily Unavailable, with Reason: "Call cancelled on timeout.", which ends the transfer.
The SBC sends a final NOTIFY to MS Teams, signaling the 480 Temporarily Unavailable in the original call dialog.
MS Teams responds to this NOTIFY request with 200 OK.
After this, the SBC doesn't receive any SIP requests from MS Teams. So, the call is ended by SBC after the non-transaction timer has expired: SBC sends a BYE to MS Teams and to the external caller.

So my question: how is the ring back initiated after the 480 response and final NOTIFY? Without MS Teams sending a new request, SBC doesn't now what to do with the call. Shouldn't MS Teams send a RE-INVITE, a new REFER,... if the call needs to be reconnected to Bob?

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Allison-H 2,825 Microsoft External Staff Moderator

Hi Steven Deferme

Welcome to Microsoft Q&A forum

Regarding your scenario, When "Ring back if no answer" is enabled, Teams handles the recall internally and does not involve the SIP trunk or SBC. If Alice doesn’t answer, Teams sends a 480 Temporarily Unavailable and ends the transfer without sending a new Re-invite or Refer. Since the SBC receives no further instructions, it eventually times out and ends the call. This is expected behavior by design.

Due to this situation, Personally, I’m totally agree that your idea of allowing Teams to continue the call in this situation is excellent. It would be a valuable improvement to the current capabilities of Microsoft 365 and could make the experience much smoother for many users.

To ensure your suggestion gets to the right team, please Visit the Microsoft Feedback Portal:

Go to: Microsoft 365 Feedback Hub > Send Feedback > Describe your proposal in detail

User's image

Upvote & collaborate:

Check existing suggestions and upvote similar ones. The more votes an idea gets, the higher its priority

Your suggestion truly matters and we are excited to see ideas like yours help shape the future of Microsoft Teams

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Steven Deferme 20 Reputation points

2025-10-20T11:50:23.13+00:00

The desired behavior after a failed transfer is described in RFC5589, which is part of a list of RFCs the SBC needs to comply with when connected to Direct Routing (https://free.blessedness.top/en-us/microsoftteams/direct-routing-protocols).
So I wonder why MS Teams itself doesn't comply with this RFC?
Allison-H 2,825 Reputation points Microsoft External Staff Moderator

2025-10-21T14:40:35.33+00:00

Dear Steven Deferme

Thank you for sharing your concern. Based on RFC 5589, Microsoft Teams appears to have correctly fulfilled its role as the Transferee by sending 480 Temporarily Unavailable and NOTIFY to report the failed call transfer, without requiring an additional RE-INVITE or new REFER. The Oracle eSBC (Transferor) is expected to send an INVITE (unhold) to resume the call with Bob ("ring back"), but in this case, the eSBC sent a BYE instead. This could potentially stem from the configuration or handling of the 480 response code.

Recommendation:

-Review the eSBC configuration to check its handling of the 480 response code and support for "ring back."

-Analyze SIP logs to verify the contents of the REFER request from MS Teams.

-Contact Oracle’s support team for further assistance with integration and RFC 5589 compliance.

-Ensure smooth integration between MS Teams and the eSBC.

You can also reach out to Microsoft Support team if needed by create support ticket. For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin.   

Note:

-If you’re an end-user, please coordinate with your IT Administrator to create support ticket on your behalf

-If you’re unsure who the Global Admin is within your organization, you can find guidance on locating them here: How do I find my Microsoft 365 admin? - Microsoft Support.  
Steven Deferme 20 Reputation points

2025-10-23T08:02:23.66+00:00

Hello,

I would say the SBC has fulfilled its role, because it's the SBC that sends the NOTIFY to MS Teams.
A 480 is a final response, so the transfer call is ended. If MS Teams wants to reconnect the first call it should send a RE-INVITE to the SBC, but after the SBC sends the NOTIFY, MS Teams sends nothing. Hence the call is closed after the transaction timer has ended.

Share via

Ring back if there's no answer - Expected behavior after transfer fails

0 additional answers

Your answer