RT-N66U and Republic Wireless

[marnold]

I have an RT-N66U with the latest firmware and a Republic Wireless Moto X. They use VOIP as much as possible to cut down on cellular costs. The problem I'm having is with receiving calls via wifi. Calls end up going straight to voicemail. Their tech support is saying that their Invites are being rejected by the router which means the call gets sent to voicemail. If I make a wifi call with the Moto X and then call it with my house phone, the call will go through. Sounds like there's not enough traffic typically for the firewall to "realize" that there's a connection there and so after a while it just rejects their packets. At least that's my theory.

FWIW, I do have wifi on the Moto X set to be always on with wifi optimizations disabled. I'm using the 5 Ghz channel and there are no other 5 Ghz routers in my neighborhood so there's no interference there.

Thanks in advance for any help.

 

[marnold]

I got a follow up email from their tech support today. Here's the pertinent information:

Here are some settings that you should look out for in your router:

Some routers modify SIP (session initiation protocol) packets if set on default configuration. This may cause problems with our service.
SIP ALG (Application Layer Gateway) and SPI (Stateful Packet Inspection) usually need to be disabled on most routers and firewalls, if equipped. This is usually found on the Security/Firewall tab in the device’s web interface.

The only SIP setting I saw was in WAN->NAT Passthrough which is "SIP Passthrough" that is marked "enabled." I tried switching it to disabled last night but that didn't help. FWIW, Republic Wireless uses port 5090 for SIP registrations.

 

[marnold]

Even more of a follow-up. I tried to call my phone again this morning and it went straight to voicemail. I then put my phone in the DMZ and tried again. The call went right through. Now the big question is: how do I set up port forwarding on this thing? I would think that if I permanently forward 5090 to my phone, then it should work. Unfortunately, that means if we have more than one Republic Wireless phone in the house, only one will be able to receive calls. Is there a better way? Is there some way I can punch a hole in the firewall for just port 5090?

 

[sinshiva]

under 'tools' > 'other settings', have you tried playing with the UDP settings?

suggestions i found;

UDP Timeout Unreplied: 10 s
UDP Timeout Assured: 300 s

http://www.linksysinfo.org/index.php?threads/default-tomato-timeouts-break-voip.33471/

presumably, you could get rid of DMZ/port fowarding if this worked properly

 

[marnold]

under 'tools' > 'other settings', have you tried playing with the UDP settings?

suggestions i found;



http://www.linksysinfo.org/index.php?threads/default-tomato-timeouts-break-voip.33471/

presumably, you could get rid of DMZ/port fowarding if this worked properly

I'll try that. I finally figured out port forwarding and confirmed that the phone works that way. Obviously it's a good temporary solution, but it won't help if I get more than one RW phone in the household.

One of the techs on Republic Wireless' forums added this:

It is more about if the network goes to sleep. We keep the phone alive, no matter what. If the network stops being stateful and starts blocking inbound requests, then inbound calls will fail and we will send the call to cell. this is how our hybrid calling works.

Is there some reason the router's statefulness would "time out" after a certain period of time? Making an outbound call will get it working again for a while, but if I wait about an hour or so, those Invite requests will get blocked again.

 

[marnold]

under 'tools' > 'other settings', have you tried playing with the UDP settings?

suggestions i found;



http://www.linksysinfo.org/index.php?threads/default-tomato-timeouts-break-voip.33471/

presumably, you could get rid of DMZ/port fowarding if this worked properly

I can't find that option. Is that a Merlin-only thing?

 

[sinshiva]

I can't find that option. Is that a Merlin-only thing?

might be, i haven't used official in a long time

 

[marnold]

Unfortunately changing those two items that way didn't help. Thanks, though.

 

[marnold]

I ended up giving my phone a static IP and using port forwarding to forward all traffic on port 5090 to my phone. That'll work as a temporary work-around, but it won't help if I get more Republic Wireless phones in my household.

Does Merlin or anyone else have any other ideas? I'm fresh out.

 

[marnold]

I discovered today that even forwarding port 5090 doesn't help. I'm really at my wits end over this.

 

[sinshiva]

i still think tuning udp and possibly tcp is probably your best bet, but i'm finding very little else on the interwebz for tuning the stack for SIP. maybe you could get ahold of some Very Senior Engineer at their company for suggested settings.

 

[sinshiva]

just for fun, you might try the following;

iptables -I INPUT -p udp --sport 5090 -j ACCEPT
iptables -I FORWARD -p udp --dport 5090 -j ACCEPT

 

[marnold]

Well, I had high hopes for this, but unfortunately it didn't help either. I posted on the Republic Wireless forums with everything I've tried thus far: https://community.republicwireless.com/message/224291#224291

 

[marnold]

OK, with the help of a fellow Republic Wireless customer who also owns an RT-N66U, I can confirm that this router works fine with firmware 3.0.0.4.374.4422. Now I just need to figure out which of the two most recent firmwares broke it and how it broke it. I plan on getting a dump of the iptables rules. Is there anything else that I should look at? Does Merlin (or anybody else) know what has changed since 3.0.0.4.374.4422 that might have caused that?

My thought is that if 3.0.0.4.374.4561 breaks it too if there is some issue with the merging of Merlin's IPv6 stuff. I can't imagine any of the recent web gui changes would have any effect on this.

At this point, I'm just happy that I've gotten somewhere. I want to thank sinshiva for all the help in this thread and via PMs. I owe you some beers.

 

[marnold]

Unfortunately, I have to partially rescind what I said. I left wi-fi on my phone all night and tried calling it at 7:20 A.M. After one ring, it went straight to voicemail. I waited between 15-30 seconds and tried again and the call went through. I tried calling again at 8:30 and it went through. I tried at about 11:45 and the same thing happened as at 7:20. The first time it went to voicemail but the second time 15-30 seconds later it went through.

I'm not sure what to make of all of this. Basically I can say that it works much better with 4422, it's just not foolproof.

 

[marnold]

4561 is worse than 4422. I tried to call my phone just now after several hours and I couldn't get through. Perhaps some changes occurred behind the scenes? The only thing mentioned in the changelog is the IPv6 stuff.

 

[marnold]

I compared the output of iptables between 4422 and 4561. There are no changes between the firewall rules for the two which means that the problem is deeper in the firmware.

 

[marnold]

Well, I turned on all packet logging on the router and then tried calling my phone. Indeed, my router is blocking the packets. Here is the expurgated info (I replaced my router's MAC address with "router" and my IP with x.x.x.x)

May 26 20:28:51 kernel: DROP <4>DROP IN=eth0 OUT= MAC=router <1>SRC=108.168.254.32 DST=x.x.x.x <1>LEN=1174 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=35517 LEN=1154
May 26 20:28:52 kernel: DROP <4>DROP IN=eth0 OUT= MAC=router <1>SRC=108.168.254.32 DST=x.x.x.x <1>LEN=1174 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=35517 LEN=1154
May 26 20:28:53 kernel: DROP <4>DROP IN=eth0 OUT= MAC=router <1>SRC=108.168.254.32 DST=x.x.x.x <1>LEN=1174 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=35517 LEN=1154

The source IP I'm assuming is the RW servers. The big question is, why have none of the solutions I've tried successfully worked around this? This shouldn't be as hard as I'm finding it to be.

 

[marnold]

I got a log from another failed call. The only difference I noted is that the destination port is different. This time it is 51725. Could that be the reason that port forwarding, etc., don't work reliably?