Toggle sidebar Toggle sidebar

Strange call disconnect after 32 seconds

Status
Not open for further replies.

kliker

Joined
Mar 16, 2009
Messages
8
Reaction score
0
Hi,
I have strange call disconnect after exactly 32 seconds? What could be the problem?

regards,
Boris
 
hello,

it's difficult to resolve your problem. no log, no 3cx system version, no gateway version.

please give more information about your system.

have good day
 
Hi kliker,

It sounds very suspiciously like a firewall problem to me.

I had a 31 second problem (that occurred 100% time) when a remote extension was not able to make it through a firewall. In that case its NAT traversal was not properley setup and it was not getting its external address from the STUN server.

Maybe check quickly that your STUN is working and the firewall rules are all setup correctly (on every firewall) between yourself, 3CX and the your SIP provider before losing too much time.

Hope that helps,
thenua
 
I have the same problem, and it only occurs occationally with incoming calls to a Grandstream GXW-4008. Incoming calls to my SNOM-370 phone doesn't disconnect. 3CX server version is 7.1.7139.0
Attached logfile shows that "ACK is not received", but it doesn't say from which party. It seems like the missing ACK is the reason why the call is disconnected, but I can't say if it is my service provider that doesn't ACK, or if it is GXW-4008.
What's the best way to debug this? Wireshark?

Regards
Mats
 

Attachments

Last edited by a moderator:
My Cisco-Asa is corectly configured for
SIP port 5060 TCP+UDP
SIP-tunnel 5090 TCP
RTP 9000-9015 UDP

and Stun-server is turned off as I have a public IP address

When I run Firewall Checker then I get

3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.

<11:13:27>: Phase 1, checking servers connection, please wait...
<11:13:27>: Stun Checker service is reachable. Phase 1 check passed.
<11:13:27>: Phase 2a, Check Port Forwarding to UDP SIP port, please wait...
<11:13:27>: UDP SIP Port is set to 5060. Response received correctly with no translation. Phase 2a check passed.

<11:13:27>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
<11:13:27>: TCP SIP Port is set to 5060. Response received correctly with no translation. Phase 2b check passed.

<11:13:27>: Phase 3. Check Port Forwarding to TCP Tunnel port, please wait...
<11:13:28>: TCP TUNNEL Port is set to 5090. Response received WITH TRANSLATION 3422::5090. Phase 3 check passed with WARNINGS. Some functionality will be LIMITED. For more information, please visit http://www.3cx.com/support/firewall-checker.html

<11:13:28>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
<11:13:30>: UDP RTP Port 9000. Response received correctly with no translation. Phase 4-01 check passed.
<11:13:30>: UDP RTP Port 9001. Response received correctly with no translation. Phase 4-02 check passed.
<11:13:30>: UDP RTP Port 9002. Response received correctly with no translation. Phase 4-03 check passed.
<11:13:30>: UDP RTP Port 9003. Response received correctly with no translation. Phase 4-04 check passed.
<11:13:30>: UDP RTP Port 9004. Response received correctly with no translation. Phase 4-05 check passed.
<11:13:30>: UDP RTP Port 9005. Response received correctly with no translation. Phase 4-06 check passed.
<11:13:30>: UDP RTP Port 9006. Response received correctly with no translation. Phase 4-07 check passed.
<11:13:30>: UDP RTP Port 9007. Response received correctly with no translation. Phase 4-08 check passed.
<11:13:30>: UDP RTP Port 9008. Response received correctly with no translation. Phase 4-09 check passed.
<11:13:30>: UDP RTP Port 9009. Response received correctly with no translation. Phase 4-10 check passed.
<11:13:30>: UDP RTP Port 9010. Response received correctly with no translation. Phase 4-11 check passed.
<11:13:30>: UDP RTP Port 9011. Response received correctly with no translation. Phase 4-12 check passed.
<11:13:30>: UDP RTP Port 9012. Response received correctly with no translation. Phase 4-13 check passed.
<11:13:30>: UDP RTP Port 9013. Response received correctly with no translation. Phase 4-14 check passed.
<11:13:30>: UDP RTP Port 9014. Response received correctly with no translation. Phase 4-15 check passed.
<11:13:30>: UDP RTP Port 9015. Response received correctly with no translation. Phase 4-16 check passed.


Application exit code is 1
 
Did you try Disabling Stun and using your public IP in the Stun Setting Instead?
 
Stun-server has been disabled all the time. But I found a bug in the router config documentation:

The router configs that I've read (Cisco + WRT54GC) says that only TCP port 5090 should be forwarded. But UDP port 5090 should also be forwarded. I found this by looking at the logs in my Cisco-ASA where I could see that the Firewall Checker tried to build an outbound UDP connection on port 5090. This explains why I get a WARNING on step 3 when running Firewall Checker (see previous post).
So now when I've enabled UDP 5090 then Firewall Checker returns "Application exit code is 0"

But the disconnect still occurs after 32 seconds. Note that it doesn't always disconnect, but perhaps 50% of the incoming calls are disconnected, and the following log is then seen:

12:44:26.329 [CM503008]: Call(5): Call is terminated
12:44:26.283 [CM503008]: Call(5): Call is terminated
12:44:26.173 [CM503008]: Call(5): Call is terminated
12:44:26.173 [CM503020]: Call(5): ACK is not received
12:43:54.282 [CM503007]: Call(5): Device joined: sip:[email protected]:5060
12:43:54.220 [CM503007]: Call(5): Device joined: sip:[email protected]:5060;transport=tcp
12:43:54.095 [MS210003] C:5.1:Answer provided. Connection(transcoding mode):82.182.66.7:9008(9009)
12:43:54.079 [MS210001] C:5.2:Answer received. RTP connection: 192.168.100.25:7200(7201)
12:43:54.079 Remote SDP is set for legC:5.2
12:43:49.938 [CM505001]: Ext.11: Device info: Device Identified: [Man: Snom;Mod: 3xx series;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [snom370/7.3.14] Transport: [sip:192.168.100.23:5060]
12:43:49.938 [CM503002]: Call(5): Alerting sip:[email protected]:1024;line=i5ww7gif
12:43:49.782 [CM505001]: Ext.15: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Grandstream GXW-4008 V1.3A 1.0.1.35] Transport: [sip:192.168.100.23:5060]
12:43:49.782 [CM503002]: Call(5): Alerting sip:[email protected]:5062
12:43:49.735 [CM505001]: Ext.14: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Grandstream GXW-4008 V1.3A 1.0.1.35] Transport: [sip:192.168.100.23:5060]
12:43:49.735 [CM503002]: Call(5): Alerting sip:[email protected]:5060
12:43:49.641 [CM503024]: Call(5): Calling RingAll64:14Ext.1424Ext.2425Ext.2511Ext.1115Ext.15@[Dev:sip:[email protected]:5062]
12:43:49.641 [MS210002] C:5.4:Offer provided. Connection(transcoding mode): 192.168.100.23:7024(7025)
12:43:49.595 [CM503024]: Call(5): Calling RingAll64:14Ext.1424Ext.2425Ext.2511Ext.1115Ext.15@[Dev:sip:[email protected]:1024;line=i5ww7gif]
12:43:49.595 [MS210002] C:5.3:Offer provided. Connection(transcoding mode): 192.168.100.23:7022(7023)
12:43:49.563 [CM503024]: Call(5): Calling RingAll64:14Ext.1424Ext.2425Ext.2511Ext.1115Ext.15@[Dev:sip:[email protected]:5060]
12:43:49.548 [MS210002] C:5.2:Offer provided. Connection(transcoding mode): 192.168.100.23:7020(7021)
12:43:49.423 [CM503004]: Call(5): Route 1: RingAll64:14Ext.1424Ext.2425Ext.2511Ext.1115Ext.15@[Dev:sip:[email protected]:5060, Dev:sip:[email protected]:1024;line=i5ww7gif, Dev:sip:[email protected]:5062]
12:43:49.407 [CM503010]: Making route(s) to <sip:[email protected]:5060>
12:43:49.407 [MS210000] C:5.1:Offer received. RTP connection: 217.10.96.68:44168(44169)
12:43:49.407 Remote SDP is set for legC:5.1
12:43:49.407 [CM505003]: Provider:[NETatONCE privat] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [LEICA-1.8.28] Transport: [sip:192.168.100.23:5060]
12:43:49.313 [CM503001]: Call(5): Incoming call from +46705399857@(Ln.10002@NETatONCE privat) to <sip:[email protected]:5060>
12:43:49.298 [CM503012]: Inbound out-of-office hours rule (unnamed) for 10002 forwards to DN:64
12:43:49.298 Looking for inbound target: called=+46856474000; caller=+46705399857
12:43:49.220 [CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:5060;rinstance=4fa5683e507d6a13 SIP/2.0
Via: SIP/2.0/UDP 217.10.96.45;branch=z9hG4bK6cdd.585868e2.0
Via: SIP/2.0/UDP kst-sipp.sipgw.tdcsong.se:5060;rport=5060;received=213.50.75.168;branch=z9hG4bK-yxa-rxkzsynhgwckakimdjzkjq-UAC-olfwrse0qaynt9kfgtlyf6w
Via: SIP/2.0/TCP 213.50.75.172:5060;branch=z9hG4bK-d8754z-32dade19f1db1c2b-1---d8754z-;received=213.50.75.172;rport=46398
Max-Forwards: 68
Record-Route: <sip:217.10.96.68:5060;nat=yes;ftag=67ae5933;lr=on>
Record-Route: <sip:sipgw.tdcsong.se;lr>
Contact: <sip:[email protected]:5060;transport=tcp>
To: "0856474000"<sip:[email protected];user=phone>
From: "0705399857"<sip:[email protected];user=phone>;tag=67ae5933
Call-ID: ZmNmYmIyOTQyM2UxZDAyNTk0NGJiNmNmMGNiMzczNDE.
CSeq: 1 INVITE
Session-Expires: 9200;refresher=uac
Min-SE: 9200
Allow: INVITE, ACK, BYE, CANCEL
Supported: timer
User-Agent: LEICA-1.8.28
Content-Length: 0
Remote-Party-ID: "705399857"<sip:[email protected]>;privacy=off
X-Ecan: On

12:43:34.547 [CM503008]: Call(4): Call is terminated
 
Hi MatsW,

MatsW said:
and Stun-server is turned off as I have a public IP address
Click to expand...

The way I am reading the log it indicates that you are behind a firewall on a private network utilising the range 192.168.100.xxx .

To successfully get back in again through the firewall, the external party needs your public address not 192.168.100.xxx.

You need some sort of NAT traversal in addition to open ports. eg. typically one of STUN or "Keep Alive" with SIP provider or SIP-ALG, etc.

The 'default' is generally STUN. Otherwise at the 30sec mark (typically) the call is likely to cease when the other party tries to initiate a packet back to you.

I really think you need STUN.

Re. 5090, I think thats a red herring ! 5090 is needed for tunnelling and from what I can tell, you are not tunnelling. So as you suspected, I doubt 5090 is relevant.

I am not an expert "log" reader. Happy to see how others interpret you log also.

Cheers
thenua
 
Well, I've selected VOIP Provider / <Provider> / Advanced / Which IP to use in 'Contact field' for registration / Specified IP = my public fixed IP address.
And my Cisco router is set up to forward all VoIP-ports to my 3CX server so I should not need a STUN server even if the 3CX machine is behind the firewall with a private IP address.

I've also tested to select VOIP Provider / <Provider> / Advanced / Which IP to use in 'Contact field' for registration / External(STUN resolved), and Settings / Network / STUN server / Turn off stun server = unchecked, but it still diconnects.

And it still doesn't explain why it sometimes works and sometimes it doesn't. If the firewall was misconfigured or a STUN server was required then it ought to fail all the time, and not as now once in a while.

And regardless if I need 5090 or not, the 3CX router config documentation should be corrected so that one can run Firewall Checker without warnings.
 
Hi Mats,

Yes, I agree with the logic outlined in your last post. In theory, the NAT traversal problem seems dealt with. Also, the Firewall Test also seems good. So now I am puzzled what the problem could be. Like you, I am also puzzled as to why intermittent and why only the Grandstream. There is obviously something we are overlooking - but I don't know what.

One more question ... your are not Port Forwarding 9000-9015 to a particular address on your internal network by any chance are you ?

I am reviewing a previous post below ...

MatsW said:
My Cisco-Asa is corectly configured for
SIP port 5060 TCP+UDP
SIP-tunnel 5090 TCP
RTP 9000-9015 UDP
Click to expand...

My understanding is that 9000-9015 should not be Port Forwarded anywhere. eg. in a vanilla setup, any device (3CX, the Grandstream and the Snom) may all send out to the Internet on 9000-9015 and must be able to receive reply traffic. Just say you had inadvertantly port-forwarded this range to the IP address of the 3CX on your network. That could potentially explain the behaviour you are witnessing. (If the 3CX "stood in" to provide audio on some calls but not others - eg. due to codec mismatch say, that might explain why you had the problem with one handset only and only in some circumstances.)

Its a long shot. But as you can see, I am running out of ideas. Definitely worth checking though.

In summary, my understanding is :
  • 9000-9015 should not be blocked by the Router; and
    9000-9015 should not be port-forwarded anywhere either.

Cheers again,
thenua

*** CARE - thenua has since withdrawn this Post - refer later Post below ***
 
Yes, I'm forwarding port 9000-9015 to my 3CX server, just as the 3CX Cisco router config doc says that I shall do.

But thanks for the suggestion! I removed the port forwarding of 9000-9015 from my Cisco firewall, and now incoming calls don't disconnect (at least as far as I can conclude from the number of test-calls I've made).

But this means that the 3CX router-setup config docs are all incorrect, becuase they explicilty state that incoming connections to port 9000-9015 shall be forwarded to the 3CX server (see Linksys WRT54GC wireless router config at https://www.3cx.com/blog/voip-howto/linksys-router-configuration/ (new link) or Cisco router config at https://www.3cx.com/blog/voip-howto/cisco-voip-configuration/ (new linjk) which says "Inbound UDP ports 9000 to 9015 mapped to the PBX internal IP".

This is clearly another fatal documentation bug, but I don't know how to get 3CX attension to this.

Anyway, thanks a lot for the help
 
Last edited by a moderator:
Last edited by a moderator:
Tell me the luck that lasts. Today I received an incoming call that disconnected after 32 seconds even with no port forwarding of port 9000-9015.

If I can get some more techical details on what this missing ACK is, then I can start WireShark on system and trace the incoming call traffic and perhaps get a clue on what is going on.
 
MatsW said:
Tell me the luck that lasts. Today I received an incoming call that disconnected after 32 seconds even with no port forwarding of port 9000-9015.

If I can get some more techical details on what this missing ACK is, then I can start WireShark on system and trace the incoming call traffic and perhaps get a clue on what is going on.
Click to expand...

Hi,

Technically speaking, "ACK is not received" means that PBX didn't receive a confirmation from remote side.
Question: Is this problem persistent or appears suddenly? Is there any correlation with call scenario or this problem appears suddently and even in case of direct routing to extension?

Thanks

P.S. You may search on forum for "ACK is not received". We already discussed this problem many times.
 
Hi Mats (and any future readers of this thread), I think disregard my previous advice :
thenua said:
In summary, my understanding is :
  • 9000-9015 should not be blocked by the Router; and
    9000-9015 should not be port-forwarded anywhere either.
thenua
Click to expand...

Mats, as this didn't work and I didn't realise it goes against 3cx documentation, then I think we need to accept the 3cx documentation instead. Even though this advice has always perplexed me and I don't personally forward any of the 9xxx ports on any of my own 3cx setups.

thenua
 
Hi Mats,

Can you check the state of the Microsoft Windows Firewall on the machine that is hosting 3cx ?

If you think its "off", check its currently off.

If intended to be on, check the "open ports" remain in place. (Particularly 9000 - 9015 UDP !!)

- thenua
 
Regarding the 3CX server Windows Firewall:
The 3CX server (XP SP 3) is member of a Windows 2003 server domain. So there is a group policy settings which enable the XP firewall. But there are local exceptions for the following apps
- 3CX operator panel service
- 3CX phone system
- 3CX phone system media server
- 3CX web-server SIP/RTP tunneling proxy. And if there was a firewall setup problem then I would never receive ACK. Not as now when ACK passes thru if there has been an incoming call recently.

The problem is persistent in that it always occurs when there hasn't been any incoming calls for a while (about 10 minutes). If there is an incoming call after this idle period to either my Snom370 or Grandstream 4008 then they disconnect after 32 seconds and there is a log for missing ACK. But if I make a new incoming call shortly ( < 10 minutes) after the first has disconnected then the call doesn't disconnect. So then I have to wait a while before I test again.

The really odd thing is that if I open Windows Explorer on the 3CX server and open "My network places / Entire network / Microsoft Windows Network" then the incoming call doesn't disconnect. And even if I close Windows Explorer and wait for more than 10 minutes doesn't incoming calls disconnect. It seems like I have to wait for about one hour before incoming calls start to disconnect according to the behaviour described above.

- Opening Windows Explorer / My Computer / Local disk (C:) doesn't prohibit calls from disconnecting.
- I have also tried to start "ping xxx -t" from 3CX server against the Windows 2003 Server before the incoming call is made, but it doesn't prohibit calls from disconnecting.
- I have used TcpView from SysInternals to check the port status, and I can't see any difference in open ports from when it works to when it doesn't.

I have also searched the forum for "ACK is not received" but I haven't found any discussion which describes the behaviour I'm seeing

Questions:
- It would be nice to get a clarification on UDP port 9000-9015. Is it correct that the firewall shall be setup with port forwarding on UDP 9000-9015 to the 3CX server?
- Shall UDP 5090 be forwarded or not? Documentation doesn't say so, but if it isn't forwarded then step 3 in Firewall Checked fails.
- Are there any threads in the 3CX server that terminate after 10 minutes of inactivity?
 
I see the TCP connection with "NETatONCE privat". Is it possible to use UDP there?
Do you have any specific power saving settings which can influence network functionality?
Do you use STUN or use static configuration of IP?

Thanks
 
- Provider settings can't be changed
- All power-saving functions in 3CX server disabled
- I'm not using a STUN server. I have a fixed IP-address, fw set up with NAT and port forwarding. But it's unclear what port settings really should be as I've indicated in my question above, why I would apprechiate some clarification of what the settings should be.

I have now attached a WireShark logger between the fw and Internet, and there I can see that there is a incoming SIP message designated "ACK sip" (see attachment) even when phone disconnects.

Question:
Is the attached SIP message the message 3CX server is looking for which, if it is missing, will cause the 3CX server to emit the log "ACK not received"?
If it is, then I know what to look for in my contuniued debug.
 

Attachments

Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
112,327
Messages
591,904
Members
165,480
Latest member
Jake_Southern
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom