RTP Counter In Queue Trees

RouterOS Beginner Basics
1

Hello, I’m trying to prioritize my VoIP traffic with queue trees but I can’t tell if it’s working as intended. I’ve set up SIP and RTP marking in Mangle and it appears it’s working there because the counters are reporting numbers. But if I go into Queue Tree, I have zeros for my RTP traffic and SIP only has a small fraction of the total that is displayed in Mangle. Is this normal behavior for RTP or could it be a misconfiguration of my rules? Below is a snippet of the config.

snip.png
snip2.png

/interface bridge port
add bridge=bridge hw=no ingress-filtering=no interface=ether2-master
add bridge=bridge hw=no ingress-filtering=no interface=sfp1

/interface list member
add interface=bridge list=LAN
add interface=ether1 list=WAN

/queue tree
add limit-at=35M max-limit=35M name=UPLOAD parent=ether1 queue=default
add limit-at=2M max-limit=2M name=upload_pri_1 packet-mark=RTP parent=UPLOAD \
    priority=1 queue=default
add limit-at=2M max-limit=2M name=upload_pri_2 packet-mark=sip parent=UPLOAD \
    priority=2 queue=default
add max-limit=29M name=upload_pri_7 packet-mark=no-mark parent=UPLOAD \
    priority=7 queue=default
add limit-at=550M max-limit=550M name=DOWNLOAD parent=bridge queue=default
add limit-at=2M max-limit=2M name=download_pri_1 packet-mark=RTP parent=\
    DOWNLOAD priority=1 queue=default
add limit-at=2M max-limit=2M name=download_pri_2 packet-mark=sip parent=\
    DOWNLOAD priority=2 queue=default
add max-limit=500M name=download_pri_7 packet-mark=no-mark parent=DOWNLOAD \
    priority=7 queue=default
	
/ip firewall address-list
add address=208.73.144.0/21 comment="Nextiva IP Range 208.73.144.0/21" list=\
    Nextiva
add address=208.89.108.0/22 comment="Nextiva IP Range 208.89.108.0/22" list=\
    Nextiva
	
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
    established,related disabled=yes hw-offload=yes
add action=accept chain=forward comment="Nextiva allow" src-address-list=\
    Nextiva
add action=accept chain=input comment="Nextiva allow" src-address-list=\
    Nextiva
add action=accept chain=forward comment="Nextiva allow" dst-address-list=\
    Nextiva
add action=accept chain=input comment="Nextiva allow" dst-address-list=\
    Nextiva
	
/ip firewall mangle
add action=mark-connection chain=forward comment=SIP connection-state=new \
    dst-address=208.73.144.43 dst-port=5060 new-connection-mark=\
    nextiva-connection passthrough=yes protocol=tcp
add action=mark-packet chain=forward connection-mark=nextiva-connection \
    new-packet-mark=sip passthrough=yes
add action=mark-connection chain=forward comment=RTP connection-state=new \
    dst-address=208.73.144.43 log-prefix=RTP-Conn new-connection-mark=\
    rtp-connection passthrough=yes port=10000-26000 protocol=udp
add action=mark-packet chain=forward connection-mark=rtp-connection \
    log-prefix=RTP new-packet-mark=RTP passthrough=yes
add action=change-dscp chain=postrouting comment="DSCP 46" log-prefix=\
    change-dscp new-dscp=46 packet-mark=RTP passthrough=yes
2

It looks like it’s capturing SIP signaling, which wouldn’t be very much data. The problem may be the RTP doesn’t follow back through the SIP server/registrar, but your mangle rules assume the RTP is via the SIP server… but sometime SIP servers will establish a RTP media path different than the SIP server.

You want to look at the SIP signaling data are negotiated in the SDP info in SIP messages and/or use touch/sniffer/firewall-connections to see what RTP endpoints are actually being used.

3

In the Firewall > Connections the connections are marked correctly as rtp-connection. The counters work fine in there.

4

Fair point, I see the mangle rule getting hit. Your config looked right, and fast-track was disabled…

Do you know if it’s actually enforcing the 2M limit? e.g. is it a reporting issue, or queue not working.

5

Yes but queue tree works with packets not connections, maybe RTP marked packets in forward chain doesn’t reach queue tree:
mangle.png
Can you set

/interface bridge settings set use-ip-firewall=yes

and see how it works since bridge packet flow can skip chains without it and in your case if packet is marked in forward chain and doesn’t go to postrouting it will not reach queue tree.

6

Why waste time on protocol recognition when you can just use the DSCP values that any reasonable SIP application already sets?

7

That is a better idea.

8

It appears to be resolved. I had to turn of Fast Path and remove the rule that changed the DSCP to 46 in postrouting. I also went into my hard phones and manually set the voice DCSP to 46.