Prerequisites

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

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.

• In a Screenconnect VM use Hepic to search for the samples provided.
• 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

Codecs Issue

In one case encountered, it was observed from the SBC traces that:

• The SBC sends an INVITE.
• AT&T is responding with 2 codecs in 200 OK SDP.
• The SBC sends the new INVITE with just one codec.
• AT&T answers with BYE.

The case was opened with AT&T, and in the end, AT&T concluded that they are having issues with the REINVITE signal following ACK too quickly, even though these were sent according to RFC standards.

The proposed solution by AT&T was to stop offering G.729.

Note: This is an internal change but has to be communicated and confirmed with the customer.

To not affect other customers, the actual implementation is changing the PSP profile used that has transcoder-free transparency enabled to Conditional. That will eliminate G729 from SDP. After getting the customer agreement, escalate to the corresponding team to action the change.

Details of communications for the case can be found in KDO-4630.