Overview

• Problem Symptom
• Problem Analysis
  • Why it is 30 seconds?
  • How can we check and analyze the issue?
    • 1 - General Troubleshooting Advice
    • 2 - Problem Information Collection
    • 3 - Log Capture
    • 4 - VoIP Call Analysis in Wireshark.
• Problem Resolution
  • Resolution
  • How do the PBX NAT settings work?
• The other Typical Case
  • Problem Description
  • Problem Analysis
  • Problem Resolution

Problem Symptom

Sometimes the users would report that the calls would hang up at 30 seconds after the call answered. This type of issue might involve one-way audio or no audio, but in this article, we mainly talk about the hangup problem.

This issue mostly happens on the SIP remote/Linkus extension. Also, it is possible for the extension registered from different segment of your local network, or VPN network.

The call made through SIP trunks might have the issue as well. Especially in the “SIP dedicated trunk solution”.

Problem Analysis

Why it is 30 seconds?

Precisely, it should be 32 seconds. Well, 1-2 seconds is not a big matter. As people usually would just count the estimated time.

Basically, it's a SIP timer F issue. Because the 200 OK packet doesn't receive the ACK response packet in a SIP call flow. Then it triggers the SIP timer F which leads to the call hangup.

So What is SIP Timer?

There are three basic SIP timer parameters – T1, Timer B, and Timer F.

T1 is the estimated round trip time of an IP packet. By default, T1 is set to 500 milliseconds which for many networks can be a little on the high side.

Timer B is the maximum amount of time that a sender will wait for an INVITE message to be acknowledged.

Timer F is the maximum amount of time that a sender will wait for a non-INVITE message to be acknowledged. SIP messages such as REFER, INFO, MESSAGE, BYE, and CANCEL fall into this category.
The way that Timer B and Timer F function is pretty straightforward. Both timers default to 64 times T1. So if you take the T1 default of 500ms, Timer B and Timer F will be 32 seconds. In other words, if an INVITE is sent and no response message is received, that INVITE will timeout in 32 seconds.

Problem Example

For example, this is an issue about Timer F. The 200 OK did not receive a response from the remote device. The following is the screenshot of the call flow of the issue in Wireshark. (Later we would talk about how to review a SIP call flow in Wireshark.)

The normal call flow should be like the following, ACK is not lost.

How can we check and analyze the issue?

1 - General Troubleshooting Advice

Firstly, let’s take a brief view of the troubleshooting checklist about the 30 seconds hangup problem.

1.1 Checklist

• Understand and get user's call scenario and network topology information.
• Capture the PCAP log both on PBX and SIP clients at the same time for the same call. (We would talk about it later.)
• Analyze the call by referring to the following analysis example. (we would talk about it later.)
• Check the SIP NAT settings in PBX. And understand the function of NAT settings if needed.

1.2 Support Advice

If the issue persists after the checklist. Try to post us the following information.

• Problem description including the network information and call scenario.
• The result of the checklist.
• The PCAP log both on PBX and SIP clients for the same call. 

2 - Problem Information Collection

Now we know what to do before the problem analyzing.

Let’s take a typical case that the client reports the call from a Linkus PC to the IP phone in the company network would be disconnected at about 30 seconds after the call was answered. Note that Linkus PC and IP phone are located in different segments.

On the other hand, the user tells us the basic settings and network information about the issue.

• PBX IP address: 192.168.9.126.
• The desktop IP phone is used in a wired network with IP address: 192.168.9.36.
• Linkus PC is used in a wireless network with IP address 192.168.202.104.
• SIP NAT Setting was set for the remote extension.
• The public IP address of PBX is 132.56.33.33.

3 - Log Capture

Firstly we need to replicate the issue and capture the log during the period of replication both on PBX and the Linkus at the same time.

Log capture on PBX

Go to the menu: Maintenance>Troubleshooting> Ethernet Capture Tool

• Then follow the procedure:
• Choose both Interface (if there is only LAN, choose LAN, if you are not sure, choose both), click 'Start' button.
• Start to make a call or start to replicate the issue.
• If the issue is replicated, stop your test. If the issue not replicated, continue the test until you replicate it.
• Click 'Stop' button and download the package

Log capture on SIP client – Linkus PC & IP Phone.

Refer to this guide to learn how capture log on a PC: How to Use Wireshark

And follow the procedure:

• Open Wireshark on the computer to capture the log.
• Select the network interface and start capture
• Enter “sip” in the Filter bar to display SIP packets only.
• Start to make a call or start to replicate the issue.
• If the issue is replicated, stop your test. If the issue not replicated, continue the test until you replicate it.
• Click 'Stop' button to stop the capture.
• Save it as *.pcap format.

This part also applies to the softphone. While for IP phone, try to refer the IP phone guide to learn how to get the network capture. Usually, it would use the same Wireshark file format *.pcap or *.pcapng.

4 - VoIP Call Analysis in Wireshark.

When we get the log, let’s review it in the Wireshark. Wireshark is a quite popular network packets analysis tool. You can learn how to analyze SIP calls in the Wireshark by this article How to Analyze SIP Calls in Wireshark.

4.1 Call Flow Review for the PBX Log

Firstly, let’s review the call flow of the PBX log.

Why check the PBX log first?

Because usually, the PBX log would include the 2 legs of the call which could help us identify which call party has a problem.

Extract the compressed log file and open the *.pcap file by Wireshark. Then follow the procedure:
Use the menu entry 'Telephony > VOIP Calls', then you can see the SIP call list.

Select the calls you want to check, then we can see the invalid option Flow Sequence becomes available. Click the Flow Sequence button we can see the graph of this call with some basic details:

• From Party, To Party
• Call duration
• Protocol
• State

Basically, we could know the call is made from 5003 to 5005 by the From and To column.
In this case we select the 2 calls because the PBX handles the 2 legs of the call.

4.2 Problem Phenomenon Confirmation

We already know the IP address in the beginning, so we can easily identify the party role in the call flow.
Then we could verify the call duration is 32 seconds by the following 2 packets.

• The 200 OK packet means the call is answered.
• The BYE packet means the call is hangup.

You can calculate the duration between these 2 packets (200 OK and BYE) is about 32 seconds which is close to the duration the client reported. We understand the problem exists between the Linkus and PBX. Therefore there is no need to check the log captured on the IP phone.

We understand that the issue is the 200 OK packet as per the information. It is a SIP timer issue
But why 200 OK doesn’t have a response. It is the problem of 200 OK or ACK packet?

4.3 Call Analysis for the log captured for Linkus PC.

Let’s turn to the call analysis for the log captured for Linkus PC. to check where the ACK is sent to.

Open the *.pcap file you’d captured and review the call flow.

We can see the ACK packets were sent to the public address.

So why? We need to look into the 200 OK packet the PBX sent to Linkus first.

4.4 200 OK Packet Analysis on both parties

Basically, the issue is related to the contact header of the 200 OK packet. The IP address of the contact header URI would guide the Linkus where to send the ACK. The IP address of contact header URI of 200 OK packet in Linkus log shows a private IP address.

Then let’s check the contact URI of the 200 OK packet in PBX log, and check whether it is correct or not.

We can see the IP address is a public address rather than a private address. So the Linkus could not send ACK back to PBX.

4.5 Why it is related to Contact header?

You might wonder how does the Contact header work?

The Contact header basically contains the SIP URI of the caller, that the called party can use to send future requests to. That is, the requests that belong to the same dialog, such as re-INVITE, BYE and ACK messages. In other words, it says where a party can be reached.

Let's see how Contact is used within particular messages:

During a SIP session establishment process, the caller sends an INVITE, including a Contact header that contains the caller's URI, informing in this way, the called party about where to send a future BYE request if they decide to release the call or a re-INVITE if they want to re-negotiate the session.

When the recipient receives the initial INVITE, they will process it and eventually send back a 200 OK response. In that 200 OK, the called party has the opportunity to include their own Contact header allowing the caller to know where to send future requests. Particularly, it is necessary for the caller to know the called party's contact information, in order to send back an ACK which acknowledges/confirms the reception of 200 OK and completes the session establishment.

Refer to this article to get more details: Understand the PBX NAT Settings

Get an understanding of Contact header, huh? Now, let’s see the resolution of this problem.

Problem Resolution

Resolution

Check the NAT settings of the PBX. We found the client did not configure the NAT setting correctly.
The resolution is to add the IP address to the Local Network Identification.

You might wonder how these options would affect the SIP packets.

How do the PBX NAT settings work?

For PBX NAT settings, it work would modify the IP address and port in the specific headers of the SIP packet. PBX would use the IP you filled in the fields (External IP Address/ External Host/ STUN) to replace.

There are 2 headers in 2 type SIP methods (INVITE and 200 OK) that are mainly to be modified.

• Contact Header
• SDP Connection Information

We already knew the function of Contact Header in the previous talk.

Well, the SDP Connection Information function is to tell the other party of the call where the media (voice packets) should send.

If the SIP packet destination is not within the local network identification, PBX would modify the IP address for the 2 Headers above.

For more details, refer to this article: How Do the PBX NAT Settings Work?

The other Typical Case

Commonly, the case is not related to the PBX NAT settings. It would be the router settings. For this type of case, the PBX in front of PBX could VPN gateway, firewall, or router and so on.

Problem Description

Here is a case of Linkus (used in the external network) call hangs up at 30 seconds. The call scenario Linkus calls to the local extension.

Problem Analysis

In this case, the problem is the Contact Header IP address in 200 OK is changed to private by the router.
See PCAP log capture on PBX:

First, we can see PBX send 200 OK, but the Linkus does not reply ACK to PBX. It is a public IP address in the Contact header which seems fine in the remote registration scenario.
Then we check the logs captured on Linkus mobile.

We would find the Contact Header URI IP address has been modified to a private IP address. For the Linkus it is not a reachable address on the Internet. So call would be hung up.

Problem Resolution

Disable the SIP ALG option on the router. For example:

Or you refer to this article to see if you can find your router settings: The Router Settings Relevant with One Way Audio & 30 Seconds Call Hang up Issue

To check more cases: Call Hangs up at 30 Seconds

 

Attachments are the packets for the first case.