1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

1.13 and VoIP issues....

Discussion in 'Tomato Firmware' started by paped, Jan 6, 2008.

  1. paped

    paped LI Guru Member

    I seem to have had a few issues since upgrading to 1.13 some of which I have now sorted others that I have found posted by other people on this forum. However I have one issue that I cannot understand and fix. I use sipgate.co.uk for VoIP via a Sipura 3000 unit I have not made any changes to the Sipura for months and it worked fine, but after upgrading to 1.13, I can make outbound calls but inbound calls ring but never connect to the caller when answered on my home phone.

    All the ports that were forwarded before are forwarded now and enabled i.e sip 5060, rtp 5004, stun 10000 and 100 ports for the voice channels as recommended by sipgate.

    I have tried going back the 1.11 and reset the router and reinstalled all settings still had the same problem, I have upgraded back to 1.13 and reset and reinstalled the settings but still the same problem exists. I have played about with the NAT loopback setting between "enabled" and "Forward only" but it makes no difference. I have checked the log file on the router and the connections appear to be coming in to the router and being accepted.

    It is as if port 5060 and 5004 is working to get the ringing and for the registration to work but either the 100 voice channels are not being forwarded correctly or if Stun is used, port 10000 or the data within the tunnel is some how not being forwarded correctly to the Sipura. I have syslogged the sipura but the output is not helpful as to if or what data is reaching it as this level of detail is not shown.

    I emailed sipgate support who confirmed that they have no known problems but the other help they gave is what I have already tried.... so I am a bit stuck.

    As such any help from anybody would be appreciated...

    P.S. I have checked that it is not the sipura by placing a call across my LAN directly to the sipura and it worked....
  2. JensG

    JensG Network Guru Member

    The ports you forward to your ATA should be the same as you have set up in the ATA.

    RTP 5004 is afair not the SPA3000 default?
  3. Reiper

    Reiper LI Guru Member

    Make sure the ports you're forwarding are UDP not TCP... Also when you say "reset" what do you mean? I suggest that you clear the NVRAM and start from scratch. Seems to fix a lot of problems, even when just upgrading from on version to another!
  4. paped

    paped LI Guru Member

    Sorry for the confusion, the term reset that I used was clearing the NVRAM I tried this and manually retyped the setting both when I downgraded to 1.11 and re upgraded to 1.13....

    Re the ports, sipgate uses Stun to tunnel the ports though a NAT firewall so when set up in this configuration, which is the normal operating configuration you forward 10000, 5060 and 5004 (UDP only) to the sipura. I have tried setting these to UDP and Both but each time I get the same issue. I have also tried it without stun using just port forwarding on 5004, 5060 and the 100 RTP "voice ports" that sipura uses and again the same problem. I have even put the sipura on the DMZ IP and the same problem occurs. As such I am thinking that it must be one of 2 things either on the same evening that I upgraded to 1.13 and by a great coinsidence my sipgate account became faulty as well so I have emailed them to check this. Or the 1.13 upgrade has caused some major issue with my router (or with the DNS/connection issues I had, with my ISP account/internet access) that even a downgrade to 1.11 and NVRAM clear cannot remove.... I am total stumped with this one as it appears to be defying fault finding logic.... but thanks very much for your suggestions, greatly appreciated.......
  5. JensG

    JensG Network Guru Member

    Well, it's not a general fault with 1.13 firmware.

    I have a Sipura SPA2000 setup for using two VOIP providers.
    I don't use STUN, but have forwarded the SIP ports UDP 5060-5070, and the RTP ports UDP 16384-16483 to the SPA2000's IP. And it works fine.

    Could you be forwarding to a wrong IP?
  6. paped

    paped LI Guru Member

    I have double checked the IP if using dhcp .20 is reserved on the router and I have confirmed that .20 is being picked up, I have also manual set .20 on the sipura and all the forwards go to .20 as they have for the past 18 months or so.... Hence why this is so perplexing and its got me baffled. To me it is looking more and more like it is something outside my network and beyond my control and it is just a coinsidence that whatever it is happened the same night I upgraded....

    Anyway sent some more details to sipgate today so hopefully they can shed some more light on what is causing the problem.....
  7. JensG

    JensG Network Guru Member

    To check if it's a local problem with your setup, you could try to set up a softphone on your computer.

    Also, if sipgate has an option to choose if RTP always goes through their proxy, you could try to check or uncheck that option. But I think that would only have an effect with VOIP to VOIP calls.

    If your ATA supports Syslog, you could try that and see what it gives.
    There is a guide for SPA2000 here, hopefully it's similar for SPA3000:
  8. roadkill

    roadkill Super Moderator Staff Member Member

    I bet softphone will work I'm having those issues with Kamikaze too...
  9. paped

    paped LI Guru Member

    Finally got it sorted and I am presuming that Sipgate may have changed something. As per the previous posts I tried my softphone that I configured and tested last year and found that yes it does work, meanwhile Sipgate support came back and asked me to change my codec from G729a. So I checked the softphone found that it was configured to G711u changed the Sipura to match and it works.

    Strange though that the Sipura has been configured with G729a since I installed it and everything was fine until a few weeks ago, so I don't really know what the problem is or was but it's works on the G711 codec so I will leave it at that.

    Thank you to everybody who has posted ideas and comments about this, greatly appreciated!!!!!
  10. JensG

    JensG Network Guru Member

    Glad you got it sorted out.
    I would never have guessed that it could be a codec problem.
  11. paped

    paped LI Guru Member

    Same here, all I can think of is that they use a soft voice switch with different IP to PSTN gateways for inbound and outbound calls, which my Sipura peers to via IP and the outbound is configured to allow either codec and the inbound is now G711 only.....

Share This Page