I’ve been seeing this issue now over multiple routers (core, balance 20, etc).
When we use it for SIP traffic, every couple of weeks the SIP traffic will all of a sudden stop and the phones report a 408 timeout to the server. The server is pingable and all other services are fine, just no sip traffic can pass. Rebooting the router clears it for another couple of weeks.
Have you tried disabling SIP ALG in the support.cgi page?
Many hosted SIP providers look at this as their first port of call when routers are acting as an application layer gateway, many session border controllers simply don’t like it.
One provider I work with insist on ALG being disabled on any device we connect to them with.
Tried SIP ALG disabled. 5 days later the same thing happened. All our VoIP phones all of a sudden showed “SIP 408 not reachable”. I could still ping the server, access the web gui, etc. Just no SIP traffic was allowed to pass. Rebooting the router brings everything back up right away for 5 days or so. Running firmware 7.1.0. Anything else I can try?
What is your internet source? Rebooting the router would also cause your device to re-initialize with its facing modem if there is one. Possibly some other issue on your LAN, that rebooting causes the ARP table to re-initialize. I use SIP with numerous Peplink routers. Its just not an issue.
what is your VoIP phones make and model?
I’ve seen this with AAstra i53-55-57
It’s something how AAstra interprets wrong with timeouts and stop try to reconnect.
In my case I saw failing over WANs or cycle through it by manually disconnect helped in 90% of the cases.
This caused us to switch to polycoms and phase out AAstras.
They are Aastra phones actually. That’s really strange that it happens to multiple peplink routers and only every now and then. I’ve never seen this with any other router and we’ve deployed thousands of Aastra’s. It must be something in aastra => peplink?
What method is easiest for a packet capture? Is that able to be run right on the router? When I run one on the voip server I don’t see any packets destined for it. Strangely enough HTTP and FTP work to the same server during the time the phone is down.
You can do a packet capture from the support.cgi page on the Balance 20. You’ll need to change index.cgi to support.cgi in the address bar. It should look something like this <IP_ADDRESS>/cgi-bin/MANGA/induex.cgi to <IP_ADDRESS>/cgi-bin/MANGA/support.cgi
The packet capture is limited to 20 Mb on the device. If you check the Remote Capture option the limit becomes the size of the hard drive you’re sending the capture to.
I don’t think this is purely an Aastra issue. We’re a hosted PBX provider with thousands of Aastras deployed, this only showes up when we are using Peplink routers.
I have a router now that’s exhibiting this exact behaviour. We have 13 phones behind a peplink router. 3 of them are showing 408 not found. Wireshark shows that the SIP register packets are getting to the server, and the server is responding to the external IP of the peplink, but the peplink doesn’t pass the packets back to the internal IP. It’s almost like a NAT issue of some sort. If we reboot the Peplink, the problem 3 phones will register just fine, but then another 2 or 3 phones will randomly drop offline with 408 and the same issue happens.
Hm, we ran into SIP issues not sure if this related or will help.
In Balance 710/MF750 sometimes SIP traffic just stop passing and we saw software SIP clients fail to register, or registered SIP desk phones wont ring.
Few things seemed to contribute to this issue:
Firmware 7.0.1-2 Jumbo frame check box on the LAN was hidden but jumbo frames was enabled by default and looks like there was frame size mismatch to cause SIP deskphones do not ring
MediaFast disable seemed to help for no explanation why on MF750
Across 7.0.1-7.1.1 we see sometimes Bria Software SIP client fails to register and reboot the GW fixes this issue.
I know this is a year old thread but I have this exact same issue. It only happens about once every other month. I have never experienced this issue with any other type of router.
For SIP connection issue , please open support ticket for support team to check. SIP connection is too complex that need to further verify which part that cause the issue and the necessary fine tune for the SIP applications especially when the application run in multiple WAN connections.
Ben_Uecker
we had ticket open for over a year but problem is even with special debugging firmware version
support unable to see root cause of this issue.
It happens every 3-6 weeks.
Reboot fixes this for sure, but feeling when our call center goes down is not good.
P.S. we migrated our Cloud PBX solution to a different provider over this summer and not yet seen another incident yet.