I am having alot of issues with VOIP and the Mikrotik.
Setup:
We have VOIP phones all over the country. At each remote site we have a Mikrotik router. A VPN tunnel is created from the remote Mikrotik router to our corporate headquarters which also has a Mikrotik router.
When I am talking to a user on the VOIP system. The data connection crawls yet there is plenty of spare bandwidth its not even using 10 % of the pipe. Once the call is dropped the connection speed immediately is increased. I do have QOS setup on the routers. The call quality is still good but if I try to remotely manage a workstation, remotely browse files on users machine, remotely look at event viewer etc then its unbearably slow. Like I said once the call is dropped the speed goes back to normal. So I figured maybe it was an issue of how the QOS/firewall settings were configured on the router. I removed all of the settings and was still getting the same problem.
I am brand new to Mikrotik routers I took a job were they use them so bear with me
If I am on a VOIP call the bandwidth test shows the circuit start off strong then fall down to about 10 times slower. Its a T1 line so it starts at 1.5Mbps then falls to 120Kbps Once I get off a VOIP call the bandwidth test is a steady 1.4-1.5Mbps
Is there a bug on the Mikrotik router that kills SIP connections or something. I am running 3.14 on all of the routers. This same problem is happening to every single remote office. The remote offices are using different ISP’s so I dont think its a rate limiting issue on the ISP end.
I will try upgrading to 3.15 but I dunno something is weird.
I’m running 3.11 And with EOIP tunnels i can never push or pull more then 2mb/s from it.
friend has a very fast connection and over the tunnel he can’t push me more then 2mb/s but when we do it just normal over the net its like 7-9Mb/s
I’ve been working with PxPx to solve the problem for a few days, the SIP helper was not a factor as there is no NAT, in fact we need the SIP helper for the mangle rule connection-type=sip for the QoS settings (which are working flawlessly). The problem has been tracked down to the T1 circuts provided by AT&T. Many of the offices have cable modems for regular internet traffic and one AT&T T1 (or 2 bonded) that carries the site to site VPN, including the VoIP. We changed some of the sites to use their cable modem for the VPN and all problems immeaditly went away.
The best explanation I have been able to come up with so far is below:
My best guess is that the problem is in AT&T’s QoS settings in their Cisco routers at the offices, although it could be anywhere on their network.
Despite the fact that the VoIP calls are fully encrypted and encapsulated inside the VPN tunnel, it is still possible for them to be identified as VoIP calls by pattern matching the constant stream of identically sized packets, even though it is impossible to see what is in those packets. It seems that once the AT&T router identifies there is a VoIP call passing through the router, it is imposing bandwidth and connection limits on any traffic going inside the VPN tunnel, trying to make it fit into the steady pattern of a VoIP call, and effectively breaking any non VoIP connection currently in place. Once this was happening, the router at the remote office did what it was supposed to do and maintain the priority of the VPN traffic over the regular internet traffic and the since the router had a backlog of VPN traffic it was trying to push though, it interpreted this backlog as a bandwidth limitation and did the only thing it was able to do, slow down the rest of the internet traffic in attempt to reduce the load on the connection and deliver the VPN traffic. Thus causing the users to experience the slow connection speeds when web-browsing. It is likely this connection and rate limiting by AT&T only applies to the inbound traffic to Northbrook, and they impose no restriction on the data transmitted, otherwise we would have seen connection slowdown issues at the main office just like the remote offices experienced when the router ran into a backlog of traffic trying to send out.
