From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Mon Nov 21 2005 - 17:56:30 GMT-3
I agree with you on the service provider front, although there's ways of
creating DiffServ aware MPLS networks, it relies on multiple LSP (label
switched paths) and can be cumbersome (E-LSP vs. L-LSP).
Most service providers only offer from 3 to 5 classes.
From an enterprise perspective:
permit tcp any any eq 1720
H.323 Call Control
permit tcp any any range 11000 11999
H.323 v1 and v2 w/o Fast Connect. Always enable Fast connect and everything
will go through TCP 1720
permit udp any any eq 2427
MGCP Primary. Always uses UDP 2427, but the Q.931 MGCP Backhaul channel to
the Call Manager is TCP based
permit tcp any any eq 2428
MGCP Backup. Always uses TCP 2428, same backhaul channel as above.
permit tcp any any range 2000 2002
SCCP = 2000, SDA=2001 and SAA=2002 (SDA and SAA are legacy and infrequently
used)
permit udp any any eq 1719
H.323 Registration channel. This is not call control, but needed for the
RRQ (registration request to go from the H.323 Gateway (or Call manager) to
the H.323 Gatekeeper.
permit udp any any eq 5060
5060 is SIP. SIP can use either UDP or TCP, but uses UDP by default. I
reccomend always changing this to 5060. In CM 4.x, SIP trunks need unique
port number in either direction.
Cheers,
Dennis J. Hartmann
White Pine Communications
dh8@pobox.com / 914-980-0316
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
_____
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Monday, November 21, 2005 3:48 PM
To: Dennis J. Hartmann; 'Chris Lewis (chrlewis)'; 'Kim, Edward B.';
ccielab@groupstudy.com
Subject: RE: Voice and Voice Signaling
Dennis,
If you run the auto qos voip macro on an interface, you will see that IOS
generates the folowing classification for call control packets.
ip access-list extended AutoQoS-VoIP-Control
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
This identifies a mix of TCP and UDP packets. On the UDP side, you will
probably find UDP 5060 for SIP gaining in importance and 1719 may be
important for Call Manager if you use that.
Regards putting these into the PQ.
I believe the SRND you quote specifies a separate queue (class) for call
signalling, so bandwidth is explicitly reserved for these packets.
The issue here is that this is an enterprise document and I work in the
service provider business. SPs generally do not like the 11 class model of
the QoS SRND, as many networks run MPLS and are restricted to the 8 values
of the EXP bit for QoS treatment. So given there are restrictions on the
number of classes available in a provider network, we recommend that call
control goes in the PQ to guarantee delivery, as it does not have any
negative impact on the PQ performance.
The net result is if you are working on enterprise deployments, the QoS SRND
is good, and it gives conservative recommendations. If you are active in
provider QoS the recommendations tend to be more tailored to the specific
customer and less effort is put in to producing generalized documents like
the QoS SRND.
Chris
"Dennis J. Hartmann" <dennisjhartmann@hotmail.com> wrote:
Sorry to bring up an old subject, but I have NEVER seen a
reccomendation that suggested putting voice in the priority queue.
This doesn't make sense either. We want to put delay-sensitive real
time protocol (RTP) like voice payload and video conferening payload (at T-1
speeds and above) because this traffic relies on UDP and is connectionless
(spray and pray).
Call Setup and teardown (call control) is completely different
because it's TCP based (SCCP, H.323 and MGCP backhaul). Call control
packets can be retransmitted if lost. If call setup packets are lost and it
takes a little bit longer to setup a call, it's not a big deal. But if
we're taking bandwidth away from bearer traffic to make new calls, it could
be detrimental (although it's not a big deal because call control is
measures in bps while bearer calls are measure in kbps).
Please post the reference because I didn't find this in the 3.1 QoS
SRND. Thanks.
-Dennis Hartmann
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis (chrlewis)
Sent: Wednesday, July 13, 2005 10:35 PM
To: Kim, Edward B.; ccielab@groupstudy.com
Subject: RE: Voice and Voice Signaling
Current recommendation is to put the signaling in the same LLQ as the voice
traffic. Without signaling packets arriving properly, the data flow will not
happen, and the performance impact on the LLQ of including them is
negligible. However, there are no laws of nature for this. If the queue you
put the signaling packets in always delivers, there's no real downside to
doing that either. However, if it is not a priority queue, that is a big if.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Kim,
Edward B.
Sent: Tuesday, July 12, 2005 10:25 PM
To: 'ccielab@groupstudy.com'
Subject: Voice and Voice Signaling
Guys,
I need your opinion.
We had a QoS Audit by a consultnat and his opinion was to have voice and
voice sinaling in a same queue. (in LLQ, don't differentiate them, but put
them in single queue) Even though I see the benefit of having one single
queue, I wanted to have 2 separate queues (different traffic) for
scalability (for different type of traffic/marking in the future) and
troubleshooting purposes (so we know which queue (type of traffic) is being
saturated, droped (i.e. show policy interface will show me which queue was
dropped and etc).
I wanted to know what your opinions are.
Please let me know.
Thank you.
Edward
Email Confidentiality Notice: The information contained in this transmission
is confidential, proprietary or privileged and may be subject to protection
under the law, including the Health Insurance Portability and Accountability
Act (HIPAA).
The message is intended for the sole use of the individual or entity to
whom it is addressed. If you are not the intended recipient, you are
notified that any use, distribution or copying of the message is strictly
prohibited and may subject you to criminal or civil penalties.
If you received this transmission in error, please contact the sender
immediately by replying to this email and delete the material from any
computer.
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:07 GMT-3