<div>Thanks for your Input,I am not using GRE with IPSEC ,it's only IPSEC.I did apply the inital QOS configuration and will do some testing this week,will keep you updated about the results.</div>
<div> </div>
<div>Aman<br><br> </div>
<div><span class="gmail_quote">On 9/10/06, <b class="gmail_sendername">Lee Pedder</b> <<a href="mailto:lee.pedder@gmail.com">lee.pedder@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Consider using IP DSCP values as they tend to make your QoS policy<br>easier to manage. Cisco phones will set some DSCP values by default.
<br>E.g.<br><br>class-map match-all VOICE<br>description IP Phones mark Voice to EF by default<br>match ip dscp ef<br>class-map match-all CALL-SIGNALING<br>description Call Signalling Marked Packets from Phones<br>match ip dscp cs3
<br><br>Also, if you are using GRE over IPsec be aware of the packetization<br>overhead this can add. For a G.729 call using 20ms packetization<br>intervals, this results in a 56kbps stream on the WAN when adding UDP,<br>
IP, GRE, ESP and IP headers. You can reduce this slightly by changing<br>codec settings to 30ms but this increases call latency. I have not<br>tried this personally.<br><br>Also, ensure you set up the phones in a location with the appropriate
<br>bandwidth setting in CCM. This should allow the exact number of calls<br>your QoS policy can handle, and present users with a "not enough<br>bandwidth" message on subsequent calls. Because of overhead, this will
<br>need some tweaking as the bandwidth you tell callmanager will not take<br>this into account.<br></blockquote></div><br>