On the catalysts it looks like you're pretty light on what you can do for QoS, I've never worked with this platform so I can only go off of what Cisco indicates in their documentation: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2900-xl-series-switches/23060-139.html
In interface config you can try auto qos voip cisco-softphone but I suspect it won't exist. You're not going to have much fun or luck configuring QoS for softphones on these switches, you can do priority queuing for output on these but since these are softphones the PC data would end up in the priority queue as well, not at all a good thing. These switches don't support COS to DSCP mappings either. On top of this the switches don't support voice VLANs, so I'm going to say as far as the switches you're out of luck for the most part. That being said according to the Cisco docs the switches will just leave the DSCP value untouched, so assuming the soft phone is marking it's packets (Cisco IPC will) you can match these values at your router...
It can be really simple on the router as mentioned earlier, just go into interface config for you Cisco router and type "auto qos voip". This tells the router to generate a bunch of config that does the following:
- Match on DSCP values already present for voice signalling and bearer
- Also match RTP using NBAR, and signalling using access lists for port matching, in case the soft phone isn't marking it's traffic. If you added the "trust" keyword onto the end of the command above it would not look at protocols, just for DSCP markings present.
- Puts voice bearer traffic into a priority queue and provides a minimum bandwidth guarantee, but also provides a maximum. (http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html)
- Guarantees a minimum bandwidth for voice signalling traffic.
- Sets DSCP values which your ISP will probably promptly ignore (depending on your agreement with them).
And voila, you have a simple but working QoS configuration. To test this configuration is matching properly, use "sh policy-map interface xxx" where xxx is your WAN interface. Look for matches in the classes. You should also test this during times of congestion, so use a traffic generator of sorts on the LAN and check voice quality between a soft phone and a PSTN caller. There should be minimal delay in the caller hearing your voice, anything over 150ms delay one way is generally considered unacceptable.
The above is all based on my experience, and my understanding of Cisco's recommended practices, others may provide a different take or have some suggestions on how to get something useful out of the switches.
