Re: QoS for Voice Calls - Should we care about Signaling ?

From: Gary Duncanson (gary.duncanson@googlemail.com)
Date: Sun Jul 08 2007 - 15:49:00 ART


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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART