SPI = Stateful Packet Inspection and SIP ALG = SIP Application Layer Gateway.

(A) The router is setup using NAT, and I have a bunch of firewall rules and NAT rules.
Calls go through fine most of the time, but sometimes they will drop randomly. I have the VoIP service provider looking into this, and one of things they recommended was that we disable SPI and SIP ALG if we could.

I've done a bit of searching with "Stateful Packet Inspection" and "MikroTik", but most of the results are just "features of MikroTik include..." pages.

I've turned off the "SIP helper" / "SIP ALG" by disabling the 'Service Ports -> sip' entry.

Is it possible to disable SPI without disabling NAT?

Thanks!

is not possible to disable SPI without disabling NAT.
if drops are random, the causes could be:
1. not enough bandwidth (you must enanche your bandwidth)
2. bandwidth saturated from other traffic (you must implement qos)
3. cpu goes to 100% (you must enanche your routerboard)

regards

Thank you for the answers!

Bandwidth: We have 50Mb down, 5Mb up. At most, we have 5 callers at the same time. We are currently using g.711 (ulaw) as the codec. Even with that codec (the least compressed), our bandwidth should be fine. I monitor everything with 'The Dude', and can see that there are no massive upload/downloads going on during the call drops.

CPU usage also does not appear to be a problem. It sits around 0% - 10%.

The only abnormal thing I have on the router is a HUGE static list of DNS entries for ad server blocking.

I have our phones set up to add the QOS fields on the ip packets, and a router mangle rule which counts them (and adds a 'VoIP' mark to them), so I know that the packets do indeed have QOS (DSCP TOS = 46) on them, and I think that is the best to use. I need to review that thouh.

Thanks for the help! Here is the printout of the two rules that 'see' the voip packets:
Hmm... what I need is a VoIP guide for MikroTik. Any sources you'd recommend?

I capture all my voip traffic with mangle by simply marking any packets destined and sourced from the voip server ip. i think your UDP rule could be to broad and might capture all sorts of stuff. Once traffic is marked you can do things like bypass your firewall rules, give the traffic a higher priority on your out interface. The SIP helper is generally better disabled but trial and error will confirm this. Dropping calls sounds more like a network issue than a Nat issue. what is the route to your SIP server like?

My PBX is sitting a few feet from the switches and router, on the internal side.

The incoming path is like this:
ROUTER -> unmanaged GB switch -> managed GB switch -> VirtualHost ->

We've tried using SIP servers located in LA (voip.ms) and Seattle (callcentric.com). All of them do drop calls occasionally. The LA one seems to drop the most. The callcentric one has only dropped one (outgoing) today, so I'm going to switch our incoming POP (point of presence) on voip.ms to their POP in Seattle.

I think so too about the UDP rule. I'll redefine it and see what I can do.

Thanks for your help so far!

if the phones marks all packets with tos 46 it is enough:
chain=forward action=mark-packet new-packet-mark=VoIP passthrough=no dscp=46

this, only marks the traffic but does not prioritize it.
you need to implement queue tree.

dscp=46 marks all voip or are needed to mark also other diffserv?

you can use the tos you want. it is not important if it is (i.e.) 11 or 46.
this value is necessary only to mangle the traffic, then queue it.

Thank you for the help. I've set it up like the example at the bottom of

http://wiki.mikrotik.com/wiki/Voip, substituting 'ether3' for 'ether0-gateway', and the 192. address for my SIP provider address (as captured with TORCH during active calls).

I also modifed the OUT mangle rules so that they were TOS = 46 and TOS != 46.

Why?

Because I have two VOIP providers.

The other approach (would this be smarter??) is to apply the mangle rules to the ether1-local-master, and set the IP addresses to that of my internal PBX?

I'm not sure if it would be smarter to apply them to the INTERNET port, or to the INTERNAL port. Using the internal one would enable to to make the mangle rules using only the IP address of the PBX.

Using the INTERNET port makes me use TOS for outbound and the using our VOIP Providers IP for inbound, and is a little more complicated.

I know that 'filter close to source' is always the best approach, so wouldn't I want to tell INCOMING voip traffic it has a higher priority when I first see it on the gateway interface? (as opposed to waiting till it's heading out the -local-master interface)

Hmm. Interesting. The outbound audio is still a little choppy when doing two charter-bandwidth tests (totally maxing our connection), even when I mark the priority of the packet as it comes into the ether1-local-master interface.

It sounds fine when only one person is doing the bandwidth testing.

In no case, however, did my test calls drop. I think we're safe to say that it's not the router / ISP bandwidth that is the dropped-calls issue.

Just to clarify, I'm marking my INBOUND VoIP packets based on their source ip address matching either of my VoIP providers POPs, and i'm doing this on the 'prerouting' chain on the 'ether0-gateway' interface.

I'm marking my OUTBOUND VoIP packets on the prerouting chain on the ether1-local-master interface, based on the source ip matching my internal PBX.

Unless you have some way to guarantee packet delivery and such all the way to an end point, then you have no guarantees about anything.

Some observations:
1) Callcentric and voip.ms are exceedinly cheap and somewhat unreliable SIP providers.
I'm not saying that to knock them, but it's simply the truth. Dropping some percentage of calls with them is completely unsurprising. It could be your bandwidth, but I'd guess not. If BW becomes a problem, you'll notice very poor call quality before you notice drops, typically.

2) You have no idea about fairly instantaneous bandwidth issues. You need to run something like STG with a single second update polling SNMP on a managed switch. That will tell you, with fairly high granularity if the _instantaneous_ bandwidth is too high. [It may well not be the issue, I'm just making the point that throughput updates on MTK equipment seem laggy and appear to average load over longer periods of time.] Using something like STG and/or MRTG for long-term stats and with short period values is invaluable in locating problems.

Even better would be something like Wireshark and watching total throughput on the WAN would be even better. [But this isn't a long term solution, it just lets you see exact bandwidth use during any arbitrary period of time - from fractions of a second to minutes - all depending on how long you are willing to capture the traffic.]

Another tool that would perhaps be useful would be ntop. It's not easy to configure, and it requires some skill, but that would also tell you a lot about bandwidth use and who is using what/when/where.

3) I said this before, but dropping calls is almost certainly due to other issues than over-utilization of bandwidth.
Given the data you've given, I'd guess you're doing VOIP over a cable connection - with no MPLS or anything else. This is fine, but also realize the limitations. You have no control over ISP over-subscription, peering, etc.

You may have a perfect network, but your ISP is overloading the cable head-end, or has router flaps dropping packets at their peering etc. I have clients running VOIP over consumer grade connections, but I also realize that stated bandwidth is an optimistic guarantee and that at any period I may not get that stated bandwidth [or packet loss, or bad peering etc] and will have to live with it.

Finally, smokeping would also be a great tool. Depending on what and where you can monitor, it can be a really useful tool to find pathways that are not stable and will cause you problems.

My belief is that you simply don't have enough data to make any reasonable assumptions on what's going right and what isn't. Doing a bunch of shaping etc isn't the solution here. Figuring out what's killing your SIP connections is. Once you understand the problem, you can craft a solution. Crafting solutions to problems you don't know you have is usually a waste of time.

-Greg

dscp=46 marks all voip or are needed to mark also other diffserv?

sip telephone service

I agree that crafting solutions to unknown problems is indeed a waste of time, however as you have just showed, finding the exact cause of the problem is very hard.

One of the things we will be doing (which we should have started with) is to move all the voip hardware (PBX and phones) to a separate physical network (they get their own switch), and subnet.

The problems we are having is audio drop out. Sometimes it comes back after 10-20 seconds, but even when it does, they can't hear us, and so we hang up the call. The logs sometimes show VOIP.MS UNREACHABLE and then REACHABLE a couple milliseconds later, right about the time the audio dropped.

I am also Experiencing this;
"The problems we are having is audio drop out. Sometimes it comes back after 10-20 seconds, but even when it does, they can't hear us, and so we hang up the call. "

Router OS 6.x - RB1200, 10/10Mbps SHDSL, Yealink T28p Handsets, Voip Provider = Faktortel

Sometimes miss the first 1-3 seconds of audio, and occasionally audio disappears from call, however the call remains "connected" just without audio

Moved all the handsets to a separate switch and dedicated ADSL2+ Connection with an RB433 and experience the same issues, replaced RB433 with a basic modem/router (Netgear DG834 I think, SIP ALG enabled), no issues

I am now testing/troubleshooting a couple of handsets via the RB1200 on the 10/10 SHDSL connection, will report if I can resolve

Any tips/pointers appreciated

this seems a bandwidth problem, or a disconnection.

Disabling sip alg. worked for me

/ip firewall service-port disable sip