Microsoft Teams Direct Routing - Call forwarding isn't working

[DominikA9522]

Hello all, 

we have a problem with forwarding a call to an external number: 

We're using an Unify OpenScape Voice with an OpenScape SBC for the connection between MS and our local PBX

Teams User A with Direct Routing

Teams User B with Direct Routing -- call forward to User C

User C ( external device - doesnt matter if external number or registered to our local PBX )

Scenario 1: 

Teams User A calls the E164 number in Teams of User B. Call will be forwarded to User C

-- Works fine

Scenario 2: 

Teams User A choose the Name of Teams User B. C phone is ringing. User A sees that the call is forwared but then User A is shown an error "We can not connect you"

In the Trace I can see that our SBC got a BYE Message from the Microsoft SIP Proxy: 

REASON: Q.850;cause=79;text="b5630f10-1117-4a37-9208-dc10a476f35a;FinalAnswerError"

Does anybody has an idea what causes this issue or a hint i can search for? 

Thank you very much 

Best regards, 

Dominik

[#2]

Hi @DominikA9522 ,

The error message "We cannot connect you" with the reason "Q.850;cause=79;text="b5630f10-1117-4a37-9208-dc10a476f35a;FinalAnswerError"" indicates that there is an issue with the call forwarding configuration or the interaction between Microsoft Teams and your local PBX.

To troubleshoot this issue, here are some steps you can follow:

1. Verify call forwarding configuration: Double-check the call forwarding settings for User B in Microsoft Teams. Ensure that the forwarding number or User C's external device is correctly entered.

2. Check PBX configuration: Verify the configuration of your local PBX (OpenScape Voice). Ensure that the necessary routes and rules are in place to handle call forwarding properly. Review the call forwarding settings for User B in the PBX and confirm they are correctly configured.

3. Review SBC configuration: Examine the configuration of your OpenScape SBC. Ensure that it is properly configured to handle call forwarding scenarios between Microsoft Teams and your local PBX. Check for any error logs or configuration issues that might be causing the problem.

4. Analyze SIP signaling: Use packet capture or logging tools to capture and analyze the SIP signaling between Microsoft Teams, the SBC, and your local PBX. Look for any error messages or unexpected behavior during the call forwarding process. Pay attention to any specific error codes or messages that may provide further insights into the issue.

5. Engage vendor support: If you are unable to resolve the issue with the above steps, it would be advisable to reach out to the support teams of Unify (manufacturer of OpenScape Voice) or your SBC provider. They will have specific knowledge of their systems and can assist you in troubleshooting the call forwarding problem.

By following these steps and involving the appropriate support channels, you should be able to identify and resolve the issue with call forwarding to an external number or device in your Teams and PBX configuration.

If I have answered your question, please mark your post as Solved

If you like my response, please give it a Like 

Appreciate your Kudos! Proud to contribute! :)

[#3]

Thank you @Deleted
I will review your answers and let you know when the issue is solved.

[#4]

@DominikA9522 did you figure out the root cause? If so can you please share some insights.

[#5]

Hello @MangnusPrem 

This issue is still under investigation by MSFT and our SBC Vendor. 

I'll share the results whenever we got a solution.

[#6]

Hello,

meanwhile this issue was located between Microsoft and Atos/Unify as SBC manufacturer:

The SBC id disabling the video channel by setting a port of 0.
Then it is also providing a RTCP port on a disabled channel.

69577 00068222 2023-06-30 09:01:05.822 24064 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] m=video 0 RTP/SAVP 122 125 107 99 123
69578 00068223 2023-06-30 09:01:05.822 24064 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] c=IN IP4 10.*4.*08.*1
69579 00068224 2023-06-30 09:01:05.822 24064 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=rtcp:1
69582 00068227 2023-06-30 09:01:05.822 24064 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=rtcp-mux
69583 00068228 2023-06-30 09:01:05.822 24064 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=candidate:2146435078 1 UDP 2122317696 81.*96.*71.*66 0 typ host
69584 00068229 2023-06-30 09:01:05.822 24064 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=sendonly
69585 00068230 2023-06-30 09:01:05.823 24064 MEDIAMGR_CORE TL_ERROR CSDPParser::Parse_ma() [AA431FDA70]: invalid rtcp port 1 (../src/mediamgr/src/SDPParser.cpp:2912)
69586 00068231 2023-06-30 09:01:05.823 24064 MEDIAMGR_CORE TL_ERROR CSDPParser::Parse() [AA431FDA70]: parse sdp error (../src/mediamgr/src/SDPParser.cpp:1718)
69588 00068233 2023-06-30 09:01:05.823 24064 MEDIAMGR_CORE TL_ERROR GetSessionFromSdp() [00000000]: Failed to parse sdp 0x80ee0007 (../src/mediamgr/src/SDPParser.cpp:9734)

This failure is causing the client to fail and what is killing the call.

Vs the working call

Everything is the same, except a rtcp port 1 of is not being provided.
If the customer updates the SBC so it is not doing this, it should resolve the issue.

36223 00035693 2023-06-30 09:04:06.006 18524 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] m=video 0 RTP/SAVP 122 125 107 99 123
36224 00035694 2023-06-30 09:04:06.006 18524 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] c=IN IP4 192.*68.*01.*26
36227 00035697 2023-06-30 09:04:06.006 18524 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=rtcp-mux
36228 00035698 2023-06-30 09:04:06.006 18524 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=candidate:2146435078 1 UDP 2122317696 212.*85.*8.*45 0 typ host generation 0
36229 00035699 2023-06-30 09:04:06.006 18524 MEDIAMGR_CORE TL_INFO CSDPParser::LogSdp() [00000000]: [sdp][remote] a=sendonly

##########################

The external Call Forwarding by name includes Video codecs which are not included by calling with number. 

In general MS describes thats DirectRouting calls does not include Video codecs

https://answers.microsoft.com/en-us/msteams/forum/all/teams-direct-routing-video-support/ce7a9878-6a... & https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#media-traffic-port-ranges

But in this special case they send Video request. The C-Party does not support Video and the SBC disabled this Media stream for video with answering those m-lines which are requested , so also the video line, where the port is set to 0

The MS Client could not parse this and rejects the call. 

The SBC manufacturer implements now a workaround with deletes the rtcp port:0

But also MS has to check in their view that now Video is requested in the Invite by external call forwarding. 

For us this point is closed and the call forwarding is working.