Different behaviour of shaper between 1.2.2 and 1.2.3
I have one installation of pfsense 1.2.2 and one of pfsense 1.2.3 with a similar configuration:
- same voip provider
- traffic shaping configured to prioritize voip traffic, using the wizard
I've noticed the following:
- the RTP traffic coming from the voice provider is marked with Differentiated Services Field: 0xb8 (DSCP 0x2e: Expedited Forwarding; ECN: 0x00)
In pfsense 1.2.2 everything works as expected (voip traffic coming from the provider flows through qVOIPDown queue), in pfsense 1.2.3 the incoming voip (RTP) traffic goes through the qlanacks queue.
Is there a way to restore in version 1.2.3 the same behaviour of 1.2.2?
I don't think so. Unfortunately, it seems like anything low-delay causes the packets to go in the ack queue. If this is one (or a small number) of hosts, you could just put them in the VOIP box and go that way (that was what I did, although I am now on 2.0, but that works the same way I think…)
Thanks for your reply danswartz!
With "If this is one (or a small number) of hosts, you could just put them in the VOIP box and go that way", do you mean the if the hosts behind pfsense are a small number I could simply let the low delay/ACK and VOIP traffic mix toghether in the qlanacks queue?
Does version 2.0 solve this problem?
No, sorry for being unclear. What I meant was: if you have a small number of hosts (more than one), you can put them in an alias, and use the alias in the IP field for VOIP host. I believe the behavior you see is still in 2.0 - I think it is not considered a bug, but a feature :) Thing is, tcp packets with ACK set are considered above-average priority, so they go in the ACK queue. I am not sure why packets with low-delay (or diffserv equivalent) go there too, but that is how it works, so…
Thank you Danswartz.
I've put my provider's network in an alias and used it as the voip host but nothing has changed.
I dont' understand why low-delay packets go into qlanacks even when they ar not ACKs..
I think it's a bug that has appeared in 1.2.3. Maybe it's better if I file a bug report.
Thanks for your help,
I wouldn't bother,since 1.2.3 is not being actively maintained. I am wondering if you did it right, since I did that trick and it worked?
stuck last edited by
Sorry to dig up an old thread…
In my case where I am running 1.2.3 and experiencing the same problem, I can get the up packets to go into the qvoipup if I remove the tos_audio=ef line in asterisk. But I'm wondering if this is the proper way to resolve this particular qos issue? Or are there any other suggestions short of going back to 1.2.2?
Thanks in advance