Re: QOS for VOICE

*"Also note that the port range of 16384 to 32767 is very Cisco centric,
other vendors may choose ranges lower or as high as 65535. "
*

Hey Ryan,

Just relating to that from some real world experiance. The position I am
working at has had Avaya or its resellers install voice setups and we do the
QoS policies and network changes to accomidate it. There has been no
predicability to what port numbers they use. It seems like they just make
them up on every install! :)

2000-3000, 10000-30000. Whatever the SS feels like putting in that field
that day.

Chris

On Thu, Jul 23, 2009 at 9:42 AM, Ryan West <rwest_at_zyedge.com> wrote:

> Rameez,
>
> In the scope of the lab, your approach is not too far off. Don't forget
> that an access will work just the same with a UDP port range. The more
> sophisticated matching techniques that you listed are just that, they aren't
> relying on ranges of ports, but the underlying payload contained within a
> particular RTP packet, in your case payloads 0-23. Also note that the port
> range of 16384 to 32767 is very Cisco centric, other vendors may choose
> ranges lower or as high as 65535. With as much focus as the R&S has on
> voice still (not very much), vendor workbooks don't seem to concern
> themselves with the most common type of voice traffic, trusted pre-marked
> packets from endpoints. So, in the real world you would probably be queuing
> of DSCP 46 / CoS 5 (assuming your cos-dscp maps have been properly
> configured) and providing a guaranteed bandwidth for DSCP 26 / CoS 3.
>
> Signaling can take on many more forms than just H323 as well, so you would
> want to include SCCP and SIP as well, based on the requirements of the task.
> You are correct on the retransmission aspects, if a portion of a phone call
> is lost its lost. I hope I haven't complicated the situation too much. I
> think the main focus is take in what they are asking in the question and
> come up with best possible solution and there are a ton of ways to configure
> QoS. Don't lock yourself into just ip rtp audio or classification using
> nBAR, be vaguely familiar with them all.
>
> Here is the white paper I was referencing:
>
>
> http://www.cisco.com/en/US/products/ps6616/products_white_paper09186a0080110040.shtml
>
> -ryan
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Rameez Khan
> Sent: Thursday, July 23, 2009 6:24 AM
> To: Cisco certification
> Subject: QOS for VOICE
>
> I want to confirm my approach for QOS over VOICE.
>
> If i come across a question in CCIE R/S lab exam asking to Gaurantee 40% of
> banwidth for VOICE Traffic, i would use the following solution :
>
> First, i will classify RTP VOICE payload packets either by:
>
> match ip rtp 16384 16383 ----> This will match all the EVEN UDP ports in
> the range 16384 - 32767 ( It does NOT classify RTCP 1720)
>
> or
>
> match protocol rtp audio ----- > this will serve the same funcionality as
> of "match ip rtp 16384 16383"
>
> Then, i will apply policy map to the VOICE class-map by using "bandwidth
> percent 40"
>
> lastly, i will appy the Service Policy in the appropriate directon.
>
> Please note that i am not classifying RTCP port 1720(TCP Port) for VOICE as
> its a TCP port and it will get Reliable service by Acknowledgment,
> Re-transmission in case if there is Drop.
>
> But the Voice Payload traffic is UDP, and there is no benefit of
> retransmission for dropped packets. Thats the reason i Classify and
> Gaurantee Bandwidth to VOICE Payload Packets.
>
> Please give me feedback if my approach is valid?
>
> Also, suggest if there is any need to classify and gaurantee bandwitch to
> RTCP 1720 traffic??
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Jul 23 2009 - 23:21:00 ART