From: Gustavo Novais (gustavo.novais@novabase.pt)
Date: Sun Jul 08 2007 - 16:30:18 ART
Hi,
Take a look at AutoQos for routers documentation on Doc CD, they
contemplate both RTP streams and control protocol.
Look at the way cisco recommends doing it, and then see how many other
ways there are for doing it.
HTH
Gustavo Novais
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gary Duncanson
Sent: domingo, 8 de Julho de 2007 19:49
To: Antonio Soares
Cc: ccielab@groupstudy.com
Subject: Re: QoS for Voice Calls - Should we care about Signaling ?
Antonio,
Found this on call signalling if this helps.
Gary
http://www.gossamer-threads.com/lists/cisco/voip/51465
Consider using IP DSCP values as they tend to make your QoS policy
easier to manage. Cisco phones will set some DSCP values by default.
E.g.
class-map match-all VOICE
description IP Phones mark Voice to EF by default
match ip dscp ef
class-map match-all CALL-SIGNALING
description Call Signalling Marked Packets from Phones
match ip dscp cs3
Also, if you are using GRE over IPsec be aware of the packetization
overhead this can add. For a G.729 call using 20ms packetization
intervals, this results in a 56kbps stream on the WAN when adding UDP,
IP, GRE, ESP and IP headers. You can reduce this slightly by changing
codec settings to 30ms but this increases call latency. I have not
tried this personally.
Also, ensure you set up the phones in a location with the appropriate
bandwidth setting in CCM. This should allow the exact number of calls
your QoS policy can handle, and present users with a "not enough
bandwidth" message on subsequent calls. Because of overhead, this will
need some tweaking as the bandwidth you tell callmanager will not take
this into account.
----- Original Message -----
From: "Antonio Soares" <amsoares@netcabo.pt>
To: "'Ben'" <bmunyao@gmail.com>
Cc: "'Cisco certification'" <ccielab@groupstudy.com>
Sent: Sunday, July 08, 2007 7:26 PM
Subject: RE: QoS for Voice Calls - Should we care about Signaling ?
> Hello Ben,
>
> I hope someone else joins us in this discussion. I'm really unsure how
to
> deal with this in the lab.
>
> Your ACL is better (more specific) since RTP uses even UDP ports in
that
> range as source and destination. RTCP uses odd ports in the same
range. I
> think the only way to differentiate these two is with NBAR:
>
> !
> class-map match-all RTCP
> match protocol rtcp
> !
> class-map match-all RTP-VOICE
> match protocol rtp audio
> !
>
> But the signaling, i really don't know how to do.
>
> In the meanwhile i found that NBAR could help us here:
>
> !
> class-map match-any VOICE-SIGNALING
> match protocol h323
> match protocol mgcp
> match protocol sip
> match protocol skinny
> !
>
>
>
> Thanks,
> Antonio
>
>
>
> _____
>
> From: Ben [mailto:bmunyao@gmail.com]
> Sent: domingo, 8 de Julho de 2007 16:57
> To: Antonio Soares
> Cc: Cisco certification
> Subject: Re: QoS for Voice Calls - Should we care about Signaling ?
>
>
>
> Thats a good question. I have also seen some examples where the ACL
method
> is implemented as follows:
>
> access-list 100 permit udp any range 16384 32767 any range 16384 32767
>
> Would it matter if one specifies or does not specify the source port
> range?
>
> TIA
>
> Ben
>
>
>
>
> On 7/8/07, Antonio Soares <amsoares@netcabo.pt> wrote:
>
> Hello group,
>
> I know that there are at least 2 ways to match RTP/RTCP packets:
>
> !
> class-map match-all RTP-and-RTCP
> match access-group 100
> !
> access-list 100 permit udp any any range 16384 32767
> !
>
> OR
>
> !
> class-map match-all RTP
> match protocol rtp audio
> match protocol rtcp
> !
>
> But what about call signaling ? In the real world i know we must take
it
> into account but in the lab, should we care about it ? I found the
list
> bellow on a CCO document:
>
> H.323/H.225 = TCP 1720
> H.323/H.245 = TCP 11xxx (Standard Connect)
> H.323/H.245 = TCP 1720 (Fast Connect)
> H.323/H.225 RAS = TCP 1719
> Skinny = TCP 2000-2002 (CM Encore)
> ICCP = TCP 8001-8002 (CM Encore)
> MGCP = UDP 2427, TCP 2428 (CM Encore)
> SIP= UDP 5060, TCP 5060 (configurable)
>
>
>
> Thanks,
> Antonio
>
>
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART