Re: QOS for VOICE

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
Received on Thu Jul 23 2009 - 08:47:03 ART