Mangle connection marking not working as expected for VoIP

RouterOS Beginner Basics
1

I’m trying to mark VoIP packets by the method in the Mangle manual page: first marking new connections, then marking packets by the connection mark. I’m doing this separately for SIP packets (port 5060) and RTP packets (ports 16384–32767). The purpose is to put them in queues by the packet marks.

Here are my rules (the IP address is the VoIP server):

/ip firewall mangle
add action=mark-connection chain=forward comment="VoIP control (SIP)" connection-state=new dst-address=111.222.333.444 \
    dst-port=5060 new-connection-mark=voip-control out-interface=ether1-gateway protocol=udp
add action=mark-packet chain=forward comment="VoIP control (SIP)" connection-mark=voip-control new-packet-mark=\
    voip-control passthrough=no
add action=mark-connection chain=forward comment="VoIP bearer (RTP)" connection-state=new dst-address=111.222.333.444 \
    dst-port=16384-32767 new-connection-mark=voip-rtp out-interface=ether1-gateway protocol=udp
add action=mark-packet chain=forward comment="VoIP bearer (RTP)" connection-mark=voip-rtp new-packet-mark=voip-rtp \
    passthrough=no

But all that seems to happen is an occasional connection mark for SIP, and then everything else getting packet marked as if it was in that marked connection:

/ip firewall mangle print stats      
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                     ACTION                            BYTES         PACKETS
 0    ;;; VoIP control (SIP)
      forward                                   mark-connection                     777               1
 1    ;;; VoIP control (SIP)
      forward                                   mark-packet                   2 321 859          11 511
 2    ;;; VoIP bearer (RTP)
      forward                                   mark-connection                       0               0
 3    ;;; VoIP bearer (RTP)
      forward                                   mark-packet                           0               0

And indeed, even the connections to the high port numbers are marked “voip-control” (SIP). See the connections during a phone call across the router (with a few connections from my PC removed):

/ip firewall connection print detail
Flags: S - seen-reply, A - assured 
 0 SA protocol=udp src-address=66.185.167.133:27857 dst-address=66.185.162.87:2239 reply-src-address=192.168.35.14:2239 
      reply-dst-address=66.185.167.133:27857 timeout=2m27s connection-mark="voip-control" p2p=none 

 1    protocol=udp src-address=66.185.167.133:5060 dst-address=66.185.162.87:5060 reply-src-address=66.185.162.87:5060 
      reply-dst-address=66.185.167.133:5060 connection-type="sip" timeout=48m57s p2p=none 

 3 SA protocol=udp src-address=66.185.167.133:27856 dst-address=66.185.162.87:2238 reply-src-address=192.168.35.14:2238 
      reply-dst-address=66.185.167.133:27856 timeout=2m28s connection-mark="voip-control" p2p=none 

 7 SA protocol=udp src-address=192.168.35.14:5060 dst-address=66.185.167.133:5060 reply-src-address=66.185.167.133:5060 
      reply-dst-address=66.185.162.87:1024 connection-type="sip" timeout=59m20s connection-mark="voip-control" p2p=none

Well, some of the RTP connections are marked “voip-control.” Some of them are completely unmarked. But nothing is ever marked “voip-rtp.” Why not? All I can think is that the RTP connections are related to the SIP connections, and somehow RouterOS is marking the former automatically, before it hits mangle.

2

I’m having the same issue an have with the last 5 or 6 RB750GLs we’ve deployed for VoIP. I don’t think it’s a configuration issue either, but I haven’t really studied yours. I’m currently stuck in the same boat with the queues and mangle set up properly (I know because I pasted the exported scripts from working RB750GLs (same versions etc.).

I have been able to fix this in the past by simply going over each option in the mangle statements and re-selecting the same exact marks, interfaces etc, and after hitting apply, I’d get a positive result. Packets would being to appear in the proper queues for sip and all was well.

In exchange for the high value MT delivers at the price, I was willing to put up with what I thought was some buggy stuff going on when pasting another config. BTW, all interfaces, bridges, etc are named correctly and no kick-outs on the pasting of the configs.

However, this last one we’ve deployed is different. Been through the hassle of re-selecting the same things through Winbox and/or the GUI, and no positive result this time.

What I’m investigating now is how MT’s new default config may have altered what I’m doing. I have been accepting it and have noticed some changes. For example, the bridge now shows only one port (ethernet2-master) as opposed to all ethernet ports 2 through 5. They’ve created what appears to be a hardware bridge by making ports 3-5 slaves to port 2. I don’t see why that’s affecting the queuing since my queue relates to bridge-local, which seems to logically include all ethernet ports by including the master at ethernet2. I don’t hold much hope for this as I have several of them working even with the new config.

I suppose I could have a faulty MT for the first time after deploying maybe 15 at this point, but I doubt that’s it.

3

After looking at your config, I’m wondering why you don’t use the Layer7 sip in your Mangle? Is it for overhead concerns? I use it with no issues with all my configs other than the one I’ve stated just now.