Re: QOS for VOICE

LLQ will be goo.! PQ for Voice and CBWFQ for other traffic~!

On Thu, Jul 23, 2009 at 9:17 PM, Craig Miller
<ripperthejack2001_at_yahoo.com>wrote:

> Also, if you match the RTP protocol data, make sure that cef is enabled.
>
> Alternatively, you can also match incoming DCSP EF bits as an option.
>
> And as Molomo suggested, change bandwidth to priority for strict policing /
> LLQ.
>
> Craig
>
> --- On Thu, 7/23/09, Molomo <letjedilakopa_at_gmail.com> wrote:
>
> > From: Molomo <letjedilakopa_at_gmail.com>
> > Subject: Re: QOS for VOICE
> > To: "Ryan West" <rwest_at_zyedge.com>
> > Cc: "Rameez Khan" <rameezk1999_at_gmail.com>, "Cisco certification" <
> ccielab_at_groupstudy.com>
> > Date: Thursday, July 23, 2009, 10:19 AM
> > 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
> >
> > _______________________________________________________________________
> > 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 - 21:22:12 ART