Hello, possible for some advice please.

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.

1 UDP 192.168.0.0 255.255.255.0 10000 20000 WAN3 Yes
2 UDP 192.168.0.0 255.255.255.0 5060 5060 WAN3 Yes
3 UDP 192.168.0.0 255.255.255.0 5061 5061 WAN3 Yes

When we removed the Mikrotik gateway and connect network directly to the vigor the Vonage VoIP works fine, calls ring, and everything is perfect..

I have disabled the hotspot we are running just to see if that had anything to do with it.


/ip firewall nat
add action=passthrough chain=unused-hs-chain comment=\
"place hotspot rules here" disabled=yes
add action=masquerade chain=srcnat comment="" disabled=no
add action=redirect chain=dstnat comment="" disabled=no dst-port=80 protocol=\
tcp to-ports=8080
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
disabled=yes src-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
disabled=yes src-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
disabled=yes src-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
disabled=yes src-address=192.168.0.0/24
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
disabled=yes src-address=192.168.0.0/24

However when we plug the Mikrotik back in the call goes through, but the person calling can’t hear it ring or the call connecting again.

I am well stuck, don’t even know what to post in here to be good information?

Can someone help me?

Thanks

Darren

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)

D

Hello thanks for the reply.

Yes, the call connects to the person that you are calling, but does not ring on the person calling side.

On the vonage system there is no nat settings which i can find.

Totally lost....

Works fine without the Mikrotik, soon as you put it on all calls go wrong, so its got to be a setup issue, just dont know what that issue is?

Any ideas?

Darren

Try and disable the sip helper .

Tried that, and still the same, i have also turned on upnp... But still no ringing..

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!

Yeah i think it is something i am doing as i am sure loads of people use this kind of setup.... Just tying to find out whee the problem could be.

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!