Jump to content

Dropped Calls - PBXnSIP version 3.4


John
 Share

Recommended Posts

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...