We have a Mikrotik Gateway running in NAT-Masquerade and a draytek vigor 3300v with 4WAN connections which we load balance over and setup have a static udp/tcp rules so call VoIP goes down one of the WANs, when it is configured like this none of the VOIP ring, however the person they are calling phone rings.
Hi, Do you mean: When a call is made the far end phone rings but you don’t hear any ringing sound?
If so it means that the signaling is working (UDP to destination port 5060) but the problem is with the RTP stream (to you I guess?)
Make sure that you have any NAT settings in your ATA enabled and that your SIP proxy has the far-end IP specified.
SIP can be awkward with NAT but it does work on a Mikrotik network with two levels of NAT (one NAT as the customer’s router and another at the gateway to the Internet)
I’ve had this problem a couple of times and both times it wasn’t ROS which was at fault - simply stupid errors on my part
However, I was able to investigate and detect the cause of the problem using ROS to monitor the traffic being received and transmitted by both parties.
Sorry, not much help, just thought I’d throw in my 2p!
The problem may be in the Draytek itself. They have a lot of really basic IP bugs in some of their routers, which they don’t seem interested in fixing. Mainly because they don’t know what an RFC is. I recommend not buying Draytek.
Need an example? Some of their products have a command: “wan DF_check on”. This turns on checking of the DF-bit in an IP packet. According to the IP protocol, it is NOT optional to check the DF flag. Therefore, this feature shouldn’t exist. Yet in Draytek land, it is DEFAULT to ignore the DF-bit.
There are more stupid errors like this in their IP processing, depending on the model.
In case this helps you, here is a list of current bugs (for example) in the Draytek 2200E+, 2100g, and 2110n models. As you can see, any of these could be your problem, especially if you are sending the packets through a VPN or tunnel of any kind that causes the MTU to decrease along the path. If you are doing this in the Mikrotik, that is why the problem disappears when you remove the Mikrotik.
Complete list of bugs (tested using PPTP VPN Internet Access method. Results may vary with your MTU):
Router does not deliver fragmented packets to connected CPU: 2200E+
Router does not deliver fragmented packets to connected CPU[intermittent]: 2110n
Router unable to deliver whole packets larger than 1436 bytes: 2110n
Router unable to reassemble fragmented packets larger than 1436 bytes: 2110n
Router ignores DF-bit, even when ridiculous ‘DF_check’ option is on: 2110n
Router inserts wrong MSS larger than MTU into TCP headers: 2100g (others untested)
Router sends packets larger than MTU without fragmenting: 2200E+, 2100g (2110n untested due to DF bug)
Router sends packets larger than MTU with DF-bit set, instead of returning Type 3, Code 4: 2110g
Router sends Type3,Code 4 packet with advised MTU larger than the triggering packet: 2200E+, 2100g
Router will not deliver a Type 3, Code 4 from the Internet to a connected CPU: 2100g, 2200E+ (2110n not tested)
Router drops packets greater than 1456 bytes sent by connected CPU, instead of fragmenting and forwarding: 2200E+
In the 2100g v2.6.1 firmware and earlier and 2200E+ prior to v2.5.7, PPTP mode does not encrypt the outgoing stream. It only compresses. HAHA!
