Re: Voice Traffic

From: Kazi Junaid <junaidkazi76_at_gmail.com>
Date: Mon, 6 Sep 2010 02:48:59 +0300

Ryan,

It going to be Cisco Voice Solution, currently its only a pilot.
For Pilot we got a 2821 running CME, endpoints are cisco phones and waiting
for other brand sip phones.
All endpoints would be in one subnet, Voice_gateway in another Subnet. ( is
this recommended setup )

Thanks
Ryan

On Mon, Sep 6, 2010 at 2:35 AM, Ryan West <rwest_at_zyedge.com> wrote:

> Kazi,
>
>
>
> Unless your voice gateway is hairpinning all calls for the endpoints, this
> isnt likely going to match all your RTP streams. Youve described the
MPLS
> router config, can you describe the voice application now? Is this a Cisco
> solution? A typical smaller scale solution would involve voice servers and
> endpoints in the same /24 or /23; you want to match on that range if you
> would prefer the method listed below. I try to match on DSCP markings of
46
> since the switches and endpoints are under my control; phones are set to
> remark any packets to 0 from their PC port and the switches are set to
trust
> CoS and map CoS 5 to DSCP 46.
>
>
>
> You probably want to shape to your MPLS providers circuit speed and setup a
> parent child QoS policy-map as was recommended earlier. Apply your LLQ
> policy to the child.
>
>
>
>
>
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00801
14326.shtml
>
>
>
> -ryan
>
>
>
> *From:* Kazi Junaid [mailto:junaidkazi76_at_gmail.com]
> *Sent:* Sunday, September 05, 2010 7:23 PM
> *To:* Ryan West
> *Cc:* karim jamali; Cisco certification
> *Subject:* Re: Voice Traffic
>
>
>
> Hi,
>
> Does this looks ok?
>
> Voice_Gateway : 10.255.1.100/24
> access-list 100 permit udp host 10.255.1.100 any range 16384 32767
>
> class-map match-all VG
> match ip access-group 100
>
> policy-map VG
> class VG
> priority percentage 60
> class class-default
> fair-queue
>
> int f 0/0.99
> service-policy output VG
>
>
>
> On Mon, Sep 6, 2010 at 2:20 AM, Ryan West <rwest_at_zyedge.com> wrote:
>
> Kazi,
>
>
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On
> > Behalf Of karim jamali
> > Sent: Sunday, September 05, 2010 7:05 PM
> > To: Kazi Junaid; Cisco certification
> > Subject: Re: Voice Traffic
> >
> > Hi Kazi,
> >
> > I guess you are looking for LLQ solution and what it does is the
> following:
> > 1.Gives priority to voice traffic by putting it inside a priority queue
> which gets
> > serviced first.
> > 2.You wouldn't want your voice traffic to kill other applications, thus
> you will
> > need to put an upper limit to this prioritized traffic, i.e. you are
> saying I will
> > guarantee voice is service first with an upper limit of 1Mbps, if this
> limit is
> > exceeded, well it depends on how the link is doing, if it is fine than
> than you
> > will still have it working perfectly, if the link is congested, you are
> only
> > guaranteed up to 1Mbps of excellent service, more than that you will lose
> > the guarantee.
> >
> > Steps:
> > 1.You will need to match the traffic which I guess is the RTP (udp 16384
> > 32767)
>
> Assuming this a standards based VoIP solution, you could match on protocol
> RTP audio, DSCP 40/46, or ACL that specifies voice IP ranges and the UDP
> range listed above.
>
> However, above this all this, you need to work with your MPLS provider to
> ensure they are treating your voice as a gold/real-time/insert your
favorite
> most expensive marketing term for priority traffic here. You can queue
> outbound as much as like, but if your provider isn't doing the same it
could
> be in vain
>
> For LLQ:
>
>
>
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfwfq_ps183
5_TSD_Products_Configuration_Guide_Chapter.html#wp1022204
>
> From a carrier's perspective:
>
>
>
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2
Fwww.globalcrossing.com%2Fdocs%2Fipkc%2Fmpls_qos.ppt&ei=ViWETOjLB4L88Abs_6nzA
Q&usg=AFQjCNGr2ego_xozF_67wXLO7RUwGVrmWw
>
> -ryan

Blogs and organic groups at http://www.ccie.net
Received on Mon Sep 06 2010 - 02:48:59 ART

This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:05 ART