ROB Posted October 17, 2012 Report Share Posted October 17, 2012 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 18, 2012 Report Share Posted October 18, 2012 Looks like the gateway is not sending the ACK back. What gateway are you using? Can you provide use with the SIP packets for the 192.168.18.48 address (Put the address in the SIP logging area of the PBX)? Quote Link to comment Share on other sites More sharing options...
Great Office - Hummig KG Posted July 27, 2013 Report Share Posted July 27, 2013 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? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 27, 2013 Report Share Posted July 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
Great Office - Hummig KG Posted July 27, 2013 Report Share Posted July 27, 2013 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 27, 2013 Report Share Posted July 27, 2013 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? Quote Link to comment Share on other sites More sharing options...
Great Office - Hummig KG Posted July 27, 2013 Report Share Posted July 27, 2013 Sent the full Logfile as PM. Operating system is Windows Server 2008 R2 Standard SP1. (VMware Environment) Quote Link to comment Share on other sites More sharing options...
Great Office - Hummig KG Posted July 29, 2013 Report Share Posted July 29, 2013 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 29, 2013 Report Share Posted July 29, 2013 Thanks for the update, interesting! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.