Jump to content

All incoming calls terminate after 38 seconds


ROB
 Share

Recommended Posts

All calls through any gateway are terminating after 38 seconds:

 

[7] 2012/10/17 16:18:34: Call de4c6373@pbx: Clear last INVITE

[5] 2012/10/17 16:18:34: INVITE Response 487 Request Terminated: Terminate de4c6373@pbx

[8] 2012/10/17 16:18:34: Remove leg 535: call port 22, SIP call id de4c6373@pbx

[8] 2012/10/17 16:18:34: Clearing call port 22, SIP call id de4c6373@pbx

[6] 2012/10/17 16:18:34: Call port 17: Different Codecs (local , remote pcmu/8000), callid call-7141227A-9FFA-2F10-0803-86@192.168.18.8, falling back to transcoding

[8] 2012/10/17 16:18:37: Packet authenticated by transport layer

[5] 2012/10/17 16:18:42: The call port 21 - 30 seconds callback set for force cleanup

[8] 2012/10/17 16:18:42: Packet authenticated by transport layer

[8] 2012/10/17 16:18:47: Last message repeated 7 times

[9] 2012/10/17 16:18:47: Resolve 13590: aaaa udp 192.168.18.48 5060

[9] 2012/10/17 16:18:47: Resolve 13590: a udp 192.168.18.48 5060

[9] 2012/10/17 16:18:47: Resolve 13590: udp 192.168.18.48 5060

[9] 2012/10/17 16:19:03: Resolve 13591: aaaa udp 192.168.18.48 5060

[9] 2012/10/17 16:19:03: Resolve 13591: a udp 192.168.18.48 5060

[9] 2012/10/17 16:19:03: Resolve 13591: udp 192.168.18.48 5060

[9] 2012/10/17 16:19:08: Resolve 13592: aaaa udp 192.168.18.48 5060

[9] 2012/10/17 16:19:08: Resolve 13592: a udp 192.168.18.48 5060

[9] 2012/10/17 16:19:08: Resolve 13592: udp 192.168.18.48 5060

[9] 2012/10/17 16:19:08: Resolve 13593: aaaa udp 192.168.18.48 5060

[9] 2012/10/17 16:19:08: Resolve 13593: a udp 192.168.18.48 5060

[9] 2012/10/17 16:19:08: Resolve 13593: udp 192.168.18.48 5060

[8] 2012/10/17 16:19:12: Clearing call port 21, SIP call id eb81f86f@pbx

[5] 2012/10/17 16:19:12: Terminating call 21

[5] 2012/10/17 16:19:12: The call port 21 was erased forcefully

Link to comment
Share on other sites

  • 9 months later...

Hello, since a few hours we have EXACTLY the same problem. All incomping calls terminate after 38 seconds and we see it is caused by "The call port 104 was erased forcefully".

 

The system is working since many months without any problem. Absolutely nothing has been changed. PBX is running in a datacenter so we do not have any access to routers and gateways.

 

OK. I see it might be an issue at the network environment and I will inform the tech-support of the datacenter.

 

It doesn't seem to be a problem with the trunk provider. The incoming caller can wait some minutes in the queue, but as soon an agent takes the call, the 38 seconds are counting after the call will be disconnected.

 

Any other ideas?

Link to comment
Share on other sites

Service providers do change their setup from time to time. That does cause such effects. The "was erased forcefully" means that the call was already in disconnected state, and the PBX was waiting for the final handshake which did not come in.

 

Anyway, I would look at the SIP log for the call. If you are getting emails for disconnected calls, they should be in the attachment. Otherwise set up the logging (filter by the service provider IP address). If you can share the messages for the INVITE transaction with us, we can probably see what the problem is.

Link to comment
Share on other sites

Service providers do change their setup from time to time. That does cause such effects. The "was erased forcefully" means that the call was already in disconnected state, and the PBX was waiting for the final handshake which did not come in.

 

Anyway, I would look at the SIP log for the call. If you are getting emails for disconnected calls, they should be in the attachment. Otherwise set up the logging (filter by the service provider IP address). If you can share the messages for the INVITE transaction with us, we can probably see what the problem is.

 

Thanks a lot for the fast response!!

 

I think we can exclude the SIP-Serviceprovider for this issue, as we get the problem on all SIP-Trunks (different providers!) as well as internal calls, too. Again, incoming calls aren't interrupted during Auto-Attendand and Queue. The 38-seconds begins as soon someone picks up the phone. Also it is neither only a problem of the SIP-Phone nor only a problem of the local IP-Infrastructure (LAN / Gateway). We have the issues on different phones and different locations (and different public IP-Addresses). Even the call is answered on mobile-phone (meaning without any LAN, only Trunk-in Trunk-out) we have the same situation.

 

But we think that obviously the issues are only on one (first) of four tenants. Currently we are testing this deeper. We've set a multi-tenant PBX. By the way, we have a 2011-4.5.0.1050 Coma Berenicids (Win64) (SnomOne Blue) running.

 

I've attached three Logfiles:

 

Logfile_Internal_Call.txt

One extension called another extension. Call was disconnected after 38 seconds after the call was completed.

 

Logfile_Trunk_Call.txt

An external call (from pbx into pbx using public phone number and connected over Auto Attendand). Call was disconnected 38 seconds after the call was completed by extension

 

Logfile_Test_Call.txt

One extension called a Agent Group. No one answers the call, caller hears Music on Hold. Call isn't interrupted at all.

 

Neither restarting the PBX, nor restarting the Windows OS (Firewall disabled completely) does resolve this problem. Datacenter Support assure that they didn't made any changes and don't limiting the server communication in any way (e. g. port restriction).

 

Never had such a big problem before. We are using SnomOne / PBXnSIP for five years without any bigger problem.

 

Hope you can help me!

 

Best regards

Logfile_Test_Call.txt

Logfile_Internal_Call.txt

Logfile_Trunk_Call.txt

Link to comment
Share on other sites

Okay if internal calls get disconnected yes we can exclude the sip service providers. Do you also have a log with the SIP messages included for the call? Also, set the log level to 9 on media, sip, and general so that we don't miss any important message. What operating system is this?

Link to comment
Share on other sites

Hello,

 

the problem seems to be solved. Suddenly, the issue disappeared and we might have found the reason. An Android Smartphone was registered to the extension, which had this issue. Obviously the registered smartphone didn't answered fast enough or not at all due to slow internet connection (GPRS). Another phone had a registration to this extension too (forgot that this was done for experimental purposes a few month ago). So it seemed to be a problem of the whole system, but wasn't.

 

LH

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.

 Share

×
×
  • Create New...