VoIP calls drop after 30 seconds

It may happen that a call from a VoIP operator falls inexplicably and systematically after a precise time (typically 30 seconds). The phenomenon is very clear and we will try to explain it below. Let’s say immediately that the author of the disconnection is the VOIspeed switchboard, which is “forced” to close the call due to the lack of particular signals required by the standard.

An incoming VoIP call always occurs according to this sequence (SIP 2.0 standard):

1. the operator’s INVITE message arrives at the PBX (Incoming SIP request “INVITE” FROM 83.211.227.21:5060)
2. the PBX communicates to the operator that it is trying to manage the call with the 100 Trying (Outgoing SIP response “100 Trying” to request INVITE TO 83.211.227.21:5060);
3. when the call is accepted, the PBX sends the operator the message 200 OK (Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060). Within this message, the IP address on which the operator must respond is communicated. The IP address in question is nothing more than the public IP address with which the PBX presents itself to the outside world and which is indicated in the Contact tag of the 200 OK response packet (see below).
4. After 200 OK, the PBX expects, as per standard, the ACK message from the operator to indicate that it “understands” that the call has been accepted.

The anomaly occurs when the ACK message is never received by the PBX. You can notice this because in the call trace you can see a long series of 200 OK messages repeated in rapid succession to the operator. After 30 seconds, in the absence of answers, the PBX is forced to end the call.

Here is how the 200 OK message sent from the PBX to the operator might appear (the IP addresses and other package details may differ according to your PBX, call status and operator:

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 83.211.227.21;branch=z9hG4bKbd33.9b6523b1.0
Via: SIP/2.0/UDP 62.94.71.98:5060;rport=62061;received=62.94.71.98;x-route-tag=”tgrp:Slot6″;branch=z9hG…
From: <sip:num_chiamante@62.94.71.98>;;tag=84D579C0-24C6
To: <sip:username@voip.eutelia.it>;;tag=56CB67A8
Call-ID: CC6193A1-FF6D11E3-8433A80D-2E4E112F@62.94.71.98
CSeq: 101 INVITE
Contact: <sip:username@82.100.101.102:5060>
User-Agent: UAVoispeed

… (altre informazioni omesse per brevità) …

CAUSES

The problem almost certainly affects a connectivity node (your router / firewall or equipment on the operator side). In fact, after the response from the PBX (200 OK) sent to the operator as confirmation of having established the conversation (the audio stream is opened in this phase and you can already speak, before confirming the operator), the PBX itself does not receive the ‘ACK of the operator, necessary to continue the conversation, otherwise, after 30 seconds, the timeout is triggered which cuts down the call.
Failure to receive these packets can be caused by ALG functions active in your router, or by an incorrect configuration of the NAT of the router itself, where the opening of ports 5004-5060 is required (especially in the presence of remote terminals to the PBX) UDP to the private IP address of the PBX.
The failure to receive the response (ACK) from the operator is external to the PBX: this means that probably the response from the PBX (200 OK) arrives correctly to the operator, and the operator responds, but on an IP: wrong port because your router has the problems already mentioned; or the operator never receives the 200 OK from the PBX and therefore never sends his response.

HOW TO DIAGNOSTIC

As previously mentioned, the diagnosis of this problem is quite simple: just take a trace of a call and see the presence of numerous 200 OK messages sent by the PBX (outgoing), messages that are never answered (incoming) ACK …

Oggi 11:14:52.332 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:52.472 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:52.873 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:53.679 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:55.284 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:14:58.529 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:02.551 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:02.551 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:06.598 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:10.697 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060
Oggi 11:15:18.916 Outgoing SIP response “200 Ok” to request INVITE TO 83.211.227.21:5060

HOW TO SOLVE

It is necessary to verify that the public IP address resolved by the PBX coincides with that indicated by the Contact field of the 200 OK message.
Disable the SIP ALG functions, or any other functions related to the SIP protocol. Check that you have not misconfigured the NAT of the router. Where required, the UDP ports 5004-5060 must be opened to the private IP of the PBX.
The operator should check where he sends the response (ACK) or if he ever receives the 200 OK of the PBX (in particular from the public IP of the PBX). If the operator cannot solve and if there are no anomalies on your router, the last check to be carried out to investigate the responsibility of the phenomenon is to activate a sniffer external to VOIspeed on the server machine (eg. WireShark) to actually check the flow of data. SIP packets.

At this point, a check of your router and the correct setting of the VoIP-related configurations should be enough. It is therefore suggested to:

• disable all functions related to VoIP / SIP (also called ALG);
• reconfigure any static NAT mappings on the new VOIspeed IP;
• check that the router does not present itself with more than one public IP address (for example when there are two or more ADSL in balancing) or if you have several public IPs assigned on as many WAN network interfaces;
• Always restart the router after the changes and check that they have been implemented.