Weird problem with Thomson tg784n router

Discussion in '3CX Phone System - General' started by MikeMelga, Jan 31, 2014.

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

    Joined:
    Mar 15, 2011
    Messages:
    77
    Likes Received:
    0
    Hi.

    I am using 3CX at home and I have, since the start, a strange problem: I've configured 3CX with 3 voip providers and 3 voip gateways. Everything works perfectly: I make an receive calls from all with no problem. I do the firewall tests and it passes all of them.

    The problem is that after a few days (2..3 days...sometimes more, sometimes less) I loose my communication with the VOIP providers. The still show as green and registered in 3CX but dialing in or out just fails. I run the firewall checker and it fails on the one-to-one port mapping. I reboot the router and everything gets back to normal for a few days.

    The router has VOIP functions but are turned off. SIP ALG is also turned off.

    This happened also with another D-Link router and still happens now with a Thomson tg784n.

    Any ideas on what the problem may be?

    Thanks.

    P.S. - The gateways (SPA-3102 and Portech GSM) still work fine even when the providers fail.
     
  2. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    First, with the providers you have, are the settings for each set to require registration for both in- and out-bound calls? if they are set to where registration is not required, then the registration light will always show green regardless of the actual state of the connection.

    The question is really about what part of the call is failing. Is it the SIP aspect and that a connection is never negotiated or is the RTP streams simply not traversing the firewall after the negotiation?

    You do not mention if you have a fixed IP, using STUN, have your domain name set or how the carriage to the providers is accomplished - cable, DSL, etc.

    You indicated that the firewall checker fails, which is also of concern, but we need more info. Have you tried it with the Windows FIrewall or other 3rd party firewall, if applicable, turned off?
     
  3. MikeMelga

    Joined:
    Mar 15, 2011
    Messages:
    77
    Likes Received:
    0
    lneblett,

    Thanks for your reply. Indeed I have provided very little information. Sorry for that.

    So...all my 3 VOIP providers are set to require registration for both in and outgoing calls.
    I have my windows firewall turned off.
    I am using stun (stun.3cx.com).
    I do not have a fixed IP. I use dynamic IP service. I am on DSL.
    Firewall checker is ok after router restart. it only fails after some more time.

    About the part of the call that is failing.... I've just dialed one of my VOIP provider numbers from an outside line and it doesn't even gets a ringing tone. 3CX port/trunk doesn't even blink from green. So...I guess the call never reaches me.

    What can it be?

    Thanks.
     
  4. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,360
    Likes Received:
    226
    At first it would appear to be a router issue, except, it is happening with more than one (and two different makes/models to boot). the fact that it happens with more than one VoIP provider sort of eliminates an issue at their end.

    Going through the 3CX logs, does it show the successful registrations, for the VoIP trunks, just before you have to re-boot the routers? Just before a re-boot, have you confirmed that your dynamic DNS service is aware of your correct public IP?
     
  5. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    I agree with Leejor on the point about the IP changing.

    In our area, DSL is the cheaper broadband connection available, but also the slower and more difficult to work with. They will not issue a static IP unless you subscribe to their fastest service and then the fastest service can only be had by those that are closest to the CO. Some what of a catch 22 for most as you simply cannot even offer to buy the IP independently regardless of the need unless you can get the fastest offering.

    In any event, it sounds like you are initially registering with the assigned IP and then things likely go quite and the DSL modem, not having any activity releases the IP. When the need arises, the modem will acquire an IP, but it will different and therefore likely to be out-of-sync with the providers. Timing will likely play an issue as well as it is assumed that you are registering with the providers on a scheduled basis, but until that occurs, it may be that the provider still has the old IP and not the new hence; your inbound calls are getting directed to an IP that has no home or to a home that has no SIP server.

    Either check and see if you can get a static IP from your provider or Google for DDNS providers to get a FQDN subscription started. IN the meantime, you might try and shorten the registration period for the providers so as to try and keep the IP (busy and assigned) and you might also look into your DSL modem web interface as many also have a setting that attempts to keep the connection alive. Also check your port forwarding settings again and turn-off SIP ALG if available and enabled.
     
  6. MikeMelga

    Joined:
    Mar 15, 2011
    Messages:
    77
    Likes Received:
    0
    @lneblett,

    Thanks for your reply.

    I have the fastest DSL plan I am allowed to have, since I live somewhat distant from the CO. It does not include a static IP but they offer an internal Dynamic DNS service so I guess I have an always updated FQDN. I use it to access my security cameras, files, everything.

    I am doing now a small test. I have disabled stun on the advanced/network section and added my FQDN to the static public IP field. I've also lowered the registration time of the VOIP providers to 180 sec and set the contact field to my FQDN.

    Let's see how it goes and if it affects it's behaviour.

    If it is in fact an IP problem...would the firewall checker fail on the one-to-one port mapping as it does?

    Thanks!

    @leejor

    Yes, the DDNS service is from my provider. It always keeps the IP updated.
     
  7. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    Read the link for info regarding the checker. It may address your question.

    I would also ping your fqdn and see if the response comes back and shows your current as then public IP.
    You should verify with the VoIP providers that the settings on their end accommodate your dynamic situation.

    On the surface, I am inclined to think that the firewall checker is not or should not be impacted by the IP given what you have indicated, but it could be as we don't know the timing of when things were checked, changed, etc.
    Run the ping test as suggested (assuming it passes) and try the checker and if it fails, then try with STUN back on.

    there is one other thing to consider and that is the possibility that your DSL provider is blocking ports, I have heard reports of such, but I have never come across this so I am somewhat skeptical, but I would not rule it out.
     
  8. MikeMelga

    Joined:
    Mar 15, 2011
    Messages:
    77
    Likes Received:
    0
    Ok....I did some more tests.

    My ip changes a lot. I've confirmed this by monitoring it and it changed one time just this morning.
    The FQDN given by the ISP keeps tracks of these changes... so it always points to correct IP.
    I have 3 VOIP lines: 1 from freevoipdeal and 2 given by my DSL provider, so I'm pretty sure they don't block ports.

    In my current setup (no stun - using FQDN) I have noticed one thing thought: only the 2 voip lines from my provider fail. The freevoipdeal one never fails.

    When I say that they fail.....I really don't know how to call it: they appear both registered on 3CX ports/trunks page (both are green and idle). 3CX logs also show that it registered sucessfully:
    03-Feb-2014 14:29:11.845 [CM504004]: Registration succeeded for: Lc:10000(@Sapo VOIP - 302XXXXXX[<sip:+351302XXXXXX@voip.sapo.pt:5060>])

    However...I can't make any outgoing call (from server event: Call or Registration to Sapo VOIP - 302XXXXXX has failed. sip:+351302XXXXXX@voip.sapo.pt:5060 replied: 401 Unauthorized; from IP:213.13.89.67:5070) giving me an unauthorized error.
    When I try dialing in.... it doesn't even recognizes the number as a valid one.

    I know all the numbers and passwords are correct because they work perfectly using stun (well...until the IP changes, that is)

    Any ideas? :roll:
     
  9. MikeMelga

    Joined:
    Mar 15, 2011
    Messages:
    77
    Likes Received:
    0
    If it helps, here are the asterisk settings for those voip lines:

    host=proxy.voip.sapo.pt
    canreinvite=no
    context=from-trunk
    from=+351302xxxxxx
    fromdomain=voip.sapo.pt
    insecure=port,invite
    outboundproxy=proxy.voip.sapo.pt
    port=5070
    qualify=yes
    secret=password
    type=friend
    username=+351302xxxxxx
    authname=+351302xxxxxx
    fromuser=+3513020273xx
    dtmfmode=rfc2833
    disallow=all
    allow=ulaw&alaw
    registername=+351302xxxxxx
    call-limit=2
    t38pt_udptl=yes


    And here are my 3CX configs for those (same for both lines):

    SIP server hostname or IP: voip.sapo.pt
    SIP server port: 5060
    Outbound proxy hostname or IP: proxy.voip.sapo.pt
    Outbound proxy port: 5070
     
  10. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    AT this point, you will likely need to contact SAPO and inquire as they should be able to indicate what it is in the stream that is not meeting their needs. Conversely, you might also run a wireshark and compare the streams when running STUN and not running STUN but with the FQDN.
     
  11. MikeMelga

    Joined:
    Mar 15, 2011
    Messages:
    77
    Likes Received:
    0
    lneblett,

    I've tried an inquiry without success. It seems I have to sort things out myself.

    I've thougth of something else. In case I can't get the voip lines to work without stun, I guess I could make a script to check if my ip gets updated and restart the 3CX service. It is not an elegant solution but...

    Is there any way I can force the stun update otherwise?
     
Thread Status:
Not open for further replies.