Voice and Data as combined SSID

[Anthony Poli]

Attempting to combine voice and data into single SSID with the goal of reducing total SSIDs to - 1: Corp voice/data, 2:Guest, 3: Legacy corp device.

We are bringing on Cisco 7925G phones and following Rasika's notes for voice support (http://mrncciew.com/2013/05/05/wlc-config-for-vowlan/).  We're leveraging ISE to return interface and QoS policies based on client profile/credentials - data client gets a silver QoS policy, voice gets platinum, etc.

Any thoughts/considerations/gotchas from others who have tried or considered this approach?

Thanks for your time!

Anthony

[Leo Laohoo]

Do you know why Voice SSID should always be separate?   QoS.  

You do not want to mix Voice QoS with regular data.  It's not good practice and it's a recipe for a disaster to your wireless VoIP.  I tried it once and it sure was not good.

[Ashish Chandra]

Eating while talking is never good.

So i agree with Leo keep it seperate, it will do more harm then good if on same SSID.

[abwahid]

Hi,

Yes, agree with Leo, it's not good to combine voice and data into single SSID.

Your voice quality and availability downgrade if you wouldn't create separate SSID.

[Anthony Poli]

First, thank you all for your answers. 

The reason we are exploring this path is mainly to reduce SSID's and the associated overhead with an additional SSID used for Voice only.

We've had good results so far deploying 7925G's on our data SSID and managing QoS via ISE (.1X authentication).  Via ISE we can specify QoS policies per user, so when phone's authenticate they get the platinum profile and .1p tag of 6.  When a data client authenticates they are handed the silver/best effort policy.  We've performed captures over the air and on the wire (at WLC ingress/egress) to confirm the proper tagging per client type.

The WLAN and global 5GHz radio configuration has been set up per the 7925 deployment guide and we've seen no negative impact on data clients.

Then 7925's are using CCKM for roaming and call quality is at or below the 50ms requirement throughout.

However, just because I have had favorable results I thought I should ask if anyone else had tried this and what types of hurdles were faced, if any. 

Again, thank you for your feedback.  If you have any other thoughts or details on why this failed in the past, I appreciate the responses.

Anthony

[Rasika Nayanajith]

Here is a very good wireless QoS presentation you should watch (if you haven't being to this in Ciscolive US) which discusses some of considerations with AireOS controllers.

BRKRST-2515 - QoS Design for Wireless LANs (2014 San Francisco)

With Jabber/Lync & all other apps, you cannot differentiate voice & data SSID going forward (as single client device will do everything). So your approach is prudent in my opinion (though you could have dedicated voice SSID as long as you keep 7925G for voice).

HTH

Rasika

**** Pls rate all useful responses ****

[Anthony Poli]

Rasika,

Thank you for your response and the link - this answered several of my questions.

One follow-up: should it be necessary to leverage the alloy QoS mechanisms if you can return a specific QoS profile based on who/what device authenticates?  For instance, if I return the radius attribute Airespace-QOS-Level = 2 for a CCX v5 voice client and Level = 0 for a non wmm-capable barcode scanner, would this have the same net effect as the alloy QoS configuration mentioned in the presentation?  I want to be sure I am not duplicating configuration.

Thanks again!

Anthony

[Abha Jha]

Voice traffic on the Wireless LAN, like data traffic, is susceptible to delay, jitter, and packet loss. These issues do not impact the data end user, but have serious implications for a voice call. To ensure that voice traffic receives timely and reliable treatment with low delay and low jitter, you must use Quality of Service (QoS), and use separate virtual LANs (VLANs) for voice and data. By isolating the voice traffic onto a separate VLAN, you can use QoS to provide priority treatment for voice packets when traveling across the network. Also, use a separate VLAN for data traffic, not the default native VLAN which is typically used for all network devices.