Overview

Calls to MS Teams numbers made from a particular third-party SIP device fail. The call rings for an MS Teams user but fails after the user attempts to answer the call.

<supportagent>

Prerequisites

• Screenconnect access
• Hepic access
• TCPdump/Wireshark to collect/review SIP messages
• Knowledge of protocols and how to read and analyze SIP flow messages

</supportagent>

Solution

Please note that one of the known root causes of such behavior is the device offering video codec in the invite, which is not supported by SBC. Check that no video is set up on the device profile (if needed, verify with Microsoft that video codecs are not offered from this particular device).

If you are sure that video is not offered, but the issue persists, to start with troubleshooting, we will need fresh call samples. Reproduce the issue and open a ticket with Support, making sure to describe the issue and any symptoms you observe, and add at least two call samples in the following format:

• Calling From Number:
• Calling To Number:
• Date of call: dd/mm/yy
• Time of call: xx:xx am/pm (time zone)
• Trouble observed: Inbound or Outbound
• Description of the failing scenario

<supportagent>

Such issues are rare, and the impact of this type of case is medium. Once you have the details and call samples from the customer, proceed with the steps below.

1. In a Screenconnect VM use Hepic to search for the samples provided.
2. If you see any failures in SIP signaling, see where these come from (our SBC, AT&T, customer side) and reach out to the SaaS, AT&T, or the customer with the findings. If no failures are found, open a ticket with AT&T to verify what they are seeing on their end.

Known Cases

Video Codec in the Invite

In this case, the issue was with the doorbell as a SIP device.

Upon analyzing the call flow, an abnormal packet was found that deviated from the expected SIP flow. The sample below shows that the message was sent by the IP address 52.114.132.46, which belongs to Microsoft Teams.

2023-01-17 05:38:00 -0800 : 52.114.132.46:5061 -> 198.17.84.84:5061
SIP/2.0 488 Not Acceptable Here
FROM: "Front Door";tag=gK006792e8
TO: ;tag=8db60f3effffffff144a942b0efc9bdc
CSEQ: 917805 INVITE
CALL-ID: 104903443_127178351@198.17.84.84
VIA: SIP/2.0/TLS 198.17.84.84:5061;branch=z9hG4bK00B0f0ca975481330b5
REASON: Q.850;cause=79;text="8fe32bab-0520-44c4-bfb1-0861bff2920c;There are no ICE candidates in the SDP. Non-ice endpoints cannot use bypass."
...

We can see MS Teams is sending a 488 Not Acceptable Here and complaining about ICE:

REASON: Q.850;cause=79;text="3e235746-95ba-4e38-996e-fe049ad1d631;There are no ICE candidates in the SDP. Non-ice endpoints cannot use bypass.

The 488 Not Acceptable Here indicates that some aspect of the proposed session is not acceptable and may contain a Warning header field indicating the exact reason. Usually, this is a local error and is sent when rejecting a request for a resource identified within the request.

Once the message and ACK are received, Microsoft terminates the call with a BYE message.

After checking the flow again, ICE that the error was referred to was introduced in the Invite:

01/17/2023 09:49:32.682 -05:00: 52.114.132.46:5061 --> 198.17.84.84:5061
SIP/2.0 200 OK
FROM: "Front Door"sip:+12023137681@iu45b2fvksm2igui.sbc.cul.sbcaas.com;tag=gK080fe701
TO: sip:+15714734576@sip.pstnhub.microsoft.com;tag=41b8c75649338176493312bc12bc4933
CSEQ: 438017 INVITE
...
a=ice-ufrag:WzFO
a=ice-pwd:44PfCTFGB37bG+NQqi+8KMZX

So the device called "Front Door" was calling the MS Teams number and offering video as well as audio. It was sending a video codec in the invite, which is not supported by our SBC. As part of the re-negotiation, our SBC sent the video offer but no ice candidate. This triggered the MS 488 response indicating that it can’t satisfy the request in our media bypass mode.

The customer reached out to Microsoft and then removed the video on the phone profile, which fixed the issue.

</supportagent>

Based on the troubleshooting, the Support team will either take action to fix the issue on our side or reach back with findings and any next steps required from you.

Verification

Once the root cause is fixed, try to replicate the issue to confirm that it is no longer there.