Monday 5 November 2012

18 - Campus VoIP - Overview, Considerations, and AutoQoS



Alot to squeeze in here, but a quick nugget on the world of VoIP and Qos and other considerations needed to support the infrastructure.








There are different migration paths to changing the phone system, but a 2 phase plan could consist of the above/below:

If companies have invested heavily in the existing PBX, they may not want to change and WHY?! ...well you could keep the pbx and instead upgrade the WAN routers to support voice ports (3600 etc) which can then plug into the PBX systems which make the PBX systems believe there are directly connected to each other, however they are going via the cisco routers and over the WAN, with the added benefit of the voice codecs / voice compression.

Eventually everything then moves onto phase 2.....where everything starts life in an IP packet lol
You can have some of the offices in phase 1 and some in phase 2 thats the beauty, there is no rush as the routers will talk to the PBXs and keep the interoperability


The below slide shows how the magic works:

lets say we are using cisco 7960 ip phone (using stock image running skinny protocol)
phone sends msg to cisco call manager (ccm) / distributed architecture
the phone is dumb terminal

cisco uses skinny protocol (cisco propriety) but can use sip etc just need different image

need to get that RTP (audio) across the network as fast a possible (not issue over LAN with gig ports etc)
RTP = little delay is possible, issue arises when going over WAN
RTP flows between bob and sally

GOAL is to prioritise the RTP audio



A few things we need to know about:



so lets look at the dual VLANs, we can do this with the below config (if the IP phones support CDP)


daisy chain PC from Phone (only needs 1 cat5 data port)
need separate voice vlan to separate voice and data, otherwise HUGE security risk (tap the phone etc)

voice vlan
the switch uses cdp to talk/detect the ip phones via CDP
so when the ip phone is detected via CDP the packets are tagged in the voice vlan, if the phone is removed the CDP messages fail and it uses the access vlan configuration .... SWEET!

If the phone does not support CDP, you will have to go to each phone and manually config the voice VLAN






Now cisco knows that not everyone is going to know eveything about QoS, but they do allow you some simple commands to get started which setup a base level for QoS 

trusting cos markings

under interface
mls qos trust cos


Does what the command says, cisco phones can mark there own layer2/3 packets with cos/tos
by typing in this command it will trust the markings, so the router and switch dont need to inspect the packet ....... (however this could be a security issue)

so use the below command
mls qos trust device cisco-phone

the above only works with IP phones that use CDP...





however that is QoS done, we can now use autoqos (deploys all recommended/best pratices qos settings under the interface)



wrr (weighted round robin)
So AutoQos works on an interface by interface level ..... and lets you config QoS without really knowing all the ins and outs