Dropped Calls - PBXnSIP version 3.4

[John]

Hello,

 

I would like to describe you a serious problem that we have with our PBXnSIP installation (3.4.0.3201hosted pro plus - Linux version) and kindly ask you for your quick response.

 

Very often calls are dropped during the conversation. This happen both in external calls and in internal calls (calls between pbxnsip extensions).

 

I'm attaching a tcpdump in order to help you to find the reason.

 

Please respond as soon as possible providing us the solution.

 

Best Regards,

Michael Aslanoglou

Dropped_Calls.zip

[mattlandis]

you pretty confident of your network infrastructure?

 

problem is likely there.

 

also Is there a reason you still on version 3.4?

 

matt

[Vodia PBX]

It seems that the call terminates after the phone puts the call on hold after 540-13=527 seconds and then sends a REFER:

 

REFER sip:147@62.205.34.2:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.1.23:5062;branch=z9hG4bK675160821
From: "2113110124" <sip:302113110124@62.205.34.2;user=phone>;tag=943082977
To: <sip:00302831028982@62.205.34.19;user=phone>;tag=921271490
Call-ID: [email="804d25e5@pbx"]804d25e5@pbx[/email]
CSeq: 30106 REFER
Contact: <sip:147@192.168.1.23:5062;transport=TCP>
Max-Forwards: 70
User-Agent: Yealink SIP-T20P 9.50.0.50
Refer-To: <sip:123@112467.z1.vpbx.gr>
Referred-By: "2113110124" <sip:302113110124@62.205.34.2;user=phone>
Event: refer
Content-Length: 0

 

The PBX then starts a blind transfer and disconnects that call. That is how it should be. Did the user really transfer the call?

[John]

you pretty confident of your network infrastructure?

 

problem is likely there.

 

also Is there a reason you still on version 3.4?

 

matt

 

Thank you very much for your response. Could you please be more specific. What would you suggest us to check?

 

As for the version, we haven't yet tested version 4 thoroughly. Do you think that the problem can be solved by upgrading?

[jlumby]

As for the version, we haven't yet tested version 4 thoroughly. Do you think that the problem can be solved by upgrading?

In my personal experience, 3.4 is the most stable/reliable version available. I have tried various versions of 4 and I am not ready to take the leap. 4 has a ton of cool new features, however I have found it to be very buggy as well. The biggest issue that is holding me back from upgrading is it seems like 1 out of every few hundred calls has no audio. It is very difficult to reproduce for a packet capture, however in downgrading back to 3.4 the problem completely goes away. I am continuing to follow the V4 release sequence, and will probably revisit it in a few months, unless I hear of the no audio issue has been fixed on the forum.

[Vodia PBX]

In my personal experience, 3.4 is the most stable/reliable version available. I have tried various versions of 4 and I am not ready to take the leap. 4 has a ton of cool new features, however I have found it to be very buggy as well. The biggest issue that is holding me back from upgrading is it seems like 1 out of every few hundred calls has no audio. It is very difficult to reproduce for a packet capture, however in downgrading back to 3.4 the problem completely goes away. I am continuing to follow the V4 release sequence, and will probably revisit it in a few months, unless I hear of the no audio issue has been fixed on the forum.

 

Version 4 has the huge advantage that it automatically black list IP addresses that try to hack the system. This is a tremendeous advantage for hosted systems that offer service to all the public Internet. For example, call drops might have happened because the system was under attack at this time and you might not even really know about it.

 

I would set up a test system first with a couple of friendly users. Then you get a better feeling if version 4 is ready for you or not.

[John]

It seems that the call terminates after the phone puts the call on hold after 540-13=527 seconds and then sends a REFER:

 

[...]

 

The PBX then starts a blind transfer and disconnects that call. That is how it should be. Did the user really transfer the call?

 

Looking at the tcp dump it seems you're right. The user says otherwise (he says that the transfer completed and the second extension was able to talk for a few seconds). I'll wait for another incident and a new trace to look at it again.