csipsimple: not accepting incoming VOIP calls from Draytek Vigor

Discussion in 'UK VOIP' started by Allan, Jan 22, 2014.

  1. Allan

    Allan Guest

    I am having an issue that csipsimple on android (4.3 on Samsung Galaxy
    S4) isn't getting incoming calls from an ATA/SIP phone on a Draytek
    Vigor 2830Vn (via voipbuster): the calls gets the engaged tone. Calls
    could be made from csipsimple back to the phone/Vigor. Calls can also
    be made from voipbuster's Windows client to csipsimple.

    Thanks to Bodincus for advising of the native SIP client on Android.
    I've tried the native SIP client on android and it works a treat. Am
    getting VOIP calls both ways between Samsung Galaxy and Vigor now. So
    I've got a work round if necessary.

    So: would anyone have any suggestions why csipsimple is not getting
    incoming calls from the Vigor, noting:
    * the android native SIP client can receive the calls from the Vigor
    * csipsimple can receive calls from the voipbuster Windows client

    All calls are data/VOIP (so no PSTN); it's the the same whether the
    phone is running Wi-Fi or 3G (although I'm sticking to Wi-Fi where poss!)

    I've posted on the csipsimple user forum, cos that's probably the first
    place to post. I thought I'd post here in case anyone had any bright
    ideas, or experienced something similar elsewhere/before.
    Allan, Jan 22, 2014
    1. Advertisements

  2. Allan

    Graham. Guest

    I tend to tackle these issues in an empirical manner, rather than
    through a deep knowledge of SIP.

    I am assuming the Android client, the Draytek and the Windows client
    are all registering with voipbuster behind the same NATted address, I
    am wondering if that is the issue, even if there are three separate

    Can you turn off registration on all but the Android phone? You will
    still be able to make calls from the others.

    I don't think you can do that on the voipbuster (Betamax) client so
    you will need to close it. If needed you can replace it with a generic
    client such as x-lite, that has much more configurability.
    Graham., Jan 22, 2014
    1. Advertisements

  3. Allan

    ßodincus Guest

    | · : · : · : · : · : · : · Original Message · : · : ·: · : · : · : ·
    | From: Bob L
    | Date: 23/01/14 09:27
    And to be compliant with the SIP RFCs, the SIP ports must be at least
    two apart (5060, 5062, 5064...).
    I also recommend to use different UDP ranges for the RTP traffic
    (10000-10998, 11000-11998, 12000-12998...) on each endpoint.
    If the router has anything that names "SIP" and "ALG/Application Layer
    They horribly mangle the content of SIP packets, but also slow down your
    network, as the router has to do DPI (Deep Packet Inspection) to see if
    it has to alter the data that flows in and out.
    ßodincus, Jan 23, 2014
  4. Allan

    Allan Guest


    Resolved. If was an issue with the codecs on the Samsung Galaxy. Added
    a couple to the handful configured in csipsimple by default, and I'm now
    getting calls both ways.

    Very good support from both Draytek (e-mail) and csipsimple (forum).
    Allan, Jan 25, 2014
  5. Allan

    Allan Guest

    Happily working now, and enjoying VOIP to a mobile. Sweet!

    Thanks for the advice & comments.

    I got it sorted with codecs, but I've seen elsewhere that Draytek's SIP
    ALG might be a factor, and it may be worth considering switching it off.
    Allan, Jan 27, 2014
  6. Allan

    Graham. Guest

    Received wisdom seems to be you should always disable SIP ALG on a
    domestic grade router as it creates more problems than it solves.

    It does rather beg the question as to why this feature is retained
    across subsequent firmware releases if it is so broken.
    Graham., Jan 27, 2014
  7. Allan

    ßodincus Guest

    | · : · : · : · : · : · : · Original Message · : · : ·: · : · : · : ·
    | From: Graham.
    | Date: 27/01/14 13:56
    Until we're stuck with IPv4 we cannot assign public IPs to devices
    inside a LAN and have to deal with it through NAT/PAT.

    NAT is a problem for VoIP, so both endpoint and server manufacturers
    have pushed RFCs to get around the problem that was fixed with STUN at
    first, then with the use of Outbound Proxies, and now with SBCs.

    Router manufacturers have come too late to the party, and developed
    their own little system to circumvent NAT problems, but it's redundant
    when you use STUN / OB Proxies or other SIP-native trickery.

    SIP ALGs have the nasty habit to mangle the SIP packets in both
    directions replacing ports and addresses in the messages, with a
    two-fold problem:

    1) To do this they need to do DPI (Deep Packet Inspection) to read the
    traffic content and alter it, so there is a layer 7 app running on a
    device that should be on layer 2-3 and is sapping computational power
    from the - often underpowered - on-board CPU, with the result that RTP
    traffic is delayed.

    2) Changing the IP addresses and ports on the packets "on the fly", they
    confuse the hell out of endpoints, SBCs, Proxies and Registrars that end
    up ACK'ing the wrong port and then dropping the call after 30 or so
    seconds because there is no SIP dialog between them and the endpoint.

    In the end, SIP ALGs pretend to be SBCs, but they're too stupid,
    rudimentary and slow to be of any use.

    Yes, I'm surprised too, but I'll let you know a secret: all Vonage
    <spit> kit relies on the router to have the SIP ALG active to work.

    So - as that's where the consumer VoIP monies sits in the USofA -
    routers manufacturers saddle their consumer grade routers with the damn
    SIP ALG.
    ßodincus, Jan 28, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.