This is a question I get quite often, so I thought it might be useful to write a quick summary about it: Voice traffic is divided into the voice flow itself and some control traffic (mainly statistics). Voice traffic is usually (in the Cisco world) tagged CoS 5 (802.1p), or DSCP 46, AKA Expedited Forwarding (EF). This is 802.11 AC_VO priority level 6. But what about Voice control? You will read in some places that it should be tagged DSCP 26, and in other places that it should be tagged DSCP 24... so what should we do in the wireless world?
First of all, the easy part. Voice control is less time sensitive than the voice flow, because it does not carry voice sound, just statistical information about the voice flow. So you can miss a packet or 2, no big deal. But if you miss too many of them, the phones won't be able to interpret the quality of the line anymore, and your call will drop. So this information is "critical" but "less urgent" than the voice flow. It is tagged 802.1p 3, and belongs to the AC_VI tag 4 for the wireless side.
Now the more delicate part: what DSCP should it have? So here is the story behind it, as I remember it (am I that old?): Cisco used to recommend setting voice signaling to AF 31 (DSCP 26). They thought that tagging voice control this way was appropriate, because it allowed for the same class 3 as the 802.1p value, while still setting a drop precedence (1), which is what the strength of DSCP is about.
But they were criticized because people were saying that systems using IP precedence instead of DSCP could not really use the drop precedence (value 1) and just the IP precedence PHB part (3), so using AF31 was not the best choice ever.
After years of hearing that complaint, Cisco released new good practices and new tables showing that in fact voice signaling should slowly be changed to DSCP 24, which is CS3 (so there is no drop precedence and a complete match between the DSCP value, the IP precedence value and the 802.1p priority level). That was a couple of years ago. But of course in between the same complaining customers had already implemented the AF31 tag, and started complaining again, this time about migration issues, stating that if the systems were fully DSCP it didn't really matter, etc.
So today, the new recommendation is DSCP 24 for voice control, DSCP 26 being still largely accepted for migrated implementations.
So which one should we use in a training scenario?
The bottom line is that in a lab environment, 24 is better but both 24 and 26 are fine.
If you know the story, you can decide that this is a new implementation and you set 24, or this is a migrated implementation and you keep 26, or you can ask which one is preferred to your dear proctor... but he may then remind you that this is the CCIE Wireless, not Voice, and that it does not really matter to judge your wireless skills... :-)
Subscribe to:
Post Comments (Atom)
Posts
I found that in code 4.2, DSCP 24 doesnt translate properly - it goes to 802.11e=3 same
ReplyDeleteDSCP 26 works fine and it gets translated to 802.11e=4
Oliver
Your site is awesome!! I'll have to disagree with the low importance of CS3/AF31 packets. These isn't just statistical information, but include keepalives and other critical control info to the phones such as keys pressed, onhook/offhook, etc. Thanks for all your information.
ReplyDeleteThanks Anonymous! I should rephrase this sentence to say that CS3/AF31 is "less important" than EF, simply because we can afford losing more CS3/AF31 than EF packets for the same audio call (same quality or MoS feedback). But you are right, they are not of "low importance", if we lose too many of them the call will drop! :-)
ReplyDeleteI understand this is an old topic already... but I think my question is somehow related to it, so I'll ask :) Hopefully you have an answer for me and I won't need to go deep in my readings.
ReplyDeleteWe have our signaling traffic marked as CS3 for years and we don't want to change it anyhow. But, I am struggling with Wireless QoS now. The main driver for Wireless QoS in our infrastructure is Microsoft Lync. We mark Lync's traffic using GPO as Voice - DSCP 48, Video - DSCP 40 and Signaling - DSCP 32. This is mainly because Microsoft Windows only consults IP Precedence and not DSCP when it creates WMM header. So, basically our DSCP values are being converted to Voice - WMM UP 6, Video - WMM UP 5 and Signaling - WMM UP 4.
APs convert those WMM UP values back to DSCP (and place new markings into outer CAPWAP headers)... and mapping here still behaves like it was for Wired ages ago. WMM UP 6 becomes DSCP EF, WMM UP 5 becomes AF41 but WMM UP 4 is being converted to AF31...
You cannot change this mapping, can't you? It is being re-mapped few times after that - when the packed is unpacked on the WLC and sent back to the switch, we trust CoS (remember, original marking was absolutely not inline with Cisco QoS Baseline - Voice DSCP 48)... so we trust CoS as it is based on the outer DSCP value. This is where we can change AF31 to CS3, using CoS to DSCP mapping on the switch...
Because of this mapping, I have "CAPWAP tunneled" signaling traffic flowing with AF31... which becomes true-CS3 signaling after it leaves WLC... and guess what? I don't like it!
We use AF31 for Mission Critical... and I just don't like to mess statistics for different classes, it complicates my troubleshooting efforts.
Any suggestions on this topic are highly welcomed :)
I’m glad to locate so much of informative data in your blog.
ReplyDeleteZero Up 2.0