Strange call disconnect after 32 seconds

Discussion in '3CX Phone System - General' started by kliker, Jul 24, 2009.

Thread Status:
Not open for further replies.
  1. kliker

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

    regards,
    Boris
     
  2. bluetel2

    bluetel2 Member

    Joined:
    Oct 16, 2008
    Messages:
    377
    Likes Received:
    6
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. thenua

    Joined:
    Jun 5, 2009
    Messages:
    38
    Likes Received:
    0
    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
     
  4. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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
     

    Attached Files:

  5. meshad

    Joined:
    Aug 5, 2009
    Messages:
    41
    Likes Received:
    0
    #5 meshad, Aug 26, 2009
    Last edited by a moderator: Feb 21, 2017
  6. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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
     
  7. LeonidasG

    LeonidasG Support Team
    Staff Member 3CX Support

    Joined:
    Nov 19, 2008
    Messages:
    1,455
    Likes Received:
    92
    Did you try Disabling Stun and using your public IP in the Stun Setting Instead?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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:14@192.168.100.25:5060
    12:43:54.220 [CM503007]: Call(5): Device joined: sip:+46705399857@213.50.75.168: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:11@192.168.100.47: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:15@192.168.100.25: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:14@192.168.100.25:5060
    12:43:49.641 [CM503024]: Call(5): Calling RingAll64:14Ext.1424Ext.2425Ext.2511Ext.1115Ext.15@[Dev:sip:15@192.168.100.25: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:11@192.168.100.47: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:14@192.168.100.25: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:14@192.168.100.25:5060, Dev:sip:11@192.168.100.47:1024;line=i5ww7gif, Dev:sip:15@192.168.100.25:5062]
    12:43:49.407 [CM503010]: Making route(s) to <sip:64@192.168.100.23: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:64@192.168.100.23: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:46856474000@192.168.100.23: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:+46705399857@213.50.75.168:5060;transport=tcp>
    To: "0856474000"<sip:+46856474000@217.10.96.45;user=phone>
    From: "0705399857"<sip:+46705399857@skt-sbc2.leica.tdcsong.se;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:+46705399857@skt-sbc2.leica.tdcsong.se>;privacy=off
    X-Ecan: On

    12:43:34.547 [CM503008]: Call(4): Call is terminated
     
  9. thenua

    Joined:
    Jun 5, 2009
    Messages:
    38
    Likes Received:
    0
    Hi MatsW,

    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
     
  10. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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.
     
  11. thenua

    Joined:
    Jun 5, 2009
    Messages:
    38
    Likes Received:
    0
    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 ...

    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 ***
     
  12. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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
     
    #12 MatsW, Aug 28, 2009
    Last edited by a moderator: Feb 21, 2017
  13. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    #13 SY, Aug 28, 2009
    Last edited by a moderator: Feb 21, 2017
  14. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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.
     
  15. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  16. thenua

    Joined:
    Jun 5, 2009
    Messages:
    38
    Likes Received:
    0
    Hi Mats (and any future readers of this thread), I think disregard my previous advice :
    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
     
  17. thenua

    Joined:
    Jun 5, 2009
    Messages:
    38
    Likes Received:
    0
    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
     
  18. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    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?
     
  19. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  20. MatsW

    Joined:
    Mar 10, 2009
    Messages:
    50
    Likes Received:
    0
    - 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.
     

    Attached Files:

Thread Status:
Not open for further replies.