From: Laurean Stefenel (laureans@hotmail.com)
Date: Sun Jul 08 2007 - 18:41:00 ART
Hi Antonio,
Just to add to your summarization:
I used AutoQoS as Gustavo suggested to se what Cisco is covering under call
signalling and I came out with the following ACL:
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
permit tcp any any range 1024 4999
The only thing that I added in top of what AutoQoS generated was the last
line and I picked up the line from Tim Szigheti book, I put it in just to
cover all the bases.
Regarding voice payload I usually use:
Match ip rtp 16384 16383
this covers even ports in range 16384-32767.
Regards,
Laurean
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Antonio Soares
Sent: Sunday, July 08, 2007 4:27 PM
To: 'Gustavo Novais'; 'Gary Duncanson'
Cc: ccielab@groupstudy.com
Subject: RE: QoS for Voice Calls - Should we care about Signaling ?
Thank you guys, that helped a lot.
Here's the summary of i have found:
Interactive Voice
-----------------
match protocol rtp voice
Telephony Signaling
-------------------
match protocol rtcp
match protocol h323
match protocol mgcp
match protocol sip
match protocol skinny
Interactive Voice
-----------------
match ip dscp ef
Telephony Signaling
-------------------
match ip dscp cs3
Interactive Voice
-----------------
access-list 102 permit udp any any range 16384 32767
Telephony Signaling
-------------------
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
Telephony Signaling
-------------------
access-list 104 permit tcp any any range 2000 2002
Sources:
http://www.gossamer-threads.com/lists/cisco/voip/51465
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c
/part50/hautoq2.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hqos_r
/qos_m1h.htm
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080
094660.shtml
-----Original Message-----
From: Gustavo Novais [mailto:gustavo.novais@novabase.pt]
Sent: domingo, 8 de Julho de 2007 20:30
To: Gary Duncanson; Antonio Soares
Cc: ccielab@groupstudy.com
Subject: RE: QoS for Voice Calls - Should we care about Signaling ?
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