Given the fact that this is voice, I would gaurantee voice and also
strict police it, ie I would use priority percent 40
On 7/23/09, 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 - 17:19:51 ART
This archive was generated by hypermail 2.2.0 : Sat Aug 01 2009 - 13:10:23 ART