Step 1 Capture packets on the SoftCo uplink ports. Analyze the captured network packets. It is found that the information indicating that the called party is busy has been sent to the SoftCo but the SoftCo does not play the information to the sub-box user.
Step 2 Configure the user on the IAD and capture packets on the IAD (this operation is to facilitate packet capture and analysis). It is found that the IMS has sent the RBT indicating that the called party is busy to the IAD and the IAD receives the RTP streams from the SoftCo at the same time.
Step 3 Primarily determine the cause of the problem. The cause is that the port is occupied by the SoftCo and the RTP packets from the IMS are discarded after entering the IAD. As a result, the calling party can still hear the RBT even after the outgoing call is rejected.
Step 4 Analyze the network packets captured from the SoftCo. It is found that the peer device sends a 183 message with the SDP, a 180 message without the SDP and then another 183 message without the SDP to the SoftCo.
Step 5 Based on RFC3261 standards, the SoftCo plays an announcement after receiving a 180 message and the peer device is required to send a 183 message with the SDP if the peer device needs to play an announcement. Because the second 183 message sent by the peer device does not carry the SDP, the user connected to the SoftCo can still hear the RBT played by the SoftCo when the user's call is rejected by the calling party. To solve the problem, ask the peer device to carry the SDP on the second 183 message.