07-02-2002 11:17 AM - edited 03-12-2019 07:36 PM
In this scenario there is a T-1 between a 3660 and a 2611 that all data and video conferencing travel across. There are video conferencing problems if a large data file is being transmitted. What is the best QoS method for this.
07-02-2002 11:17 AM
Video , Audio or Voice are constant stream of rtp packet and same QOS applies. The best way to gois to clasify all udp rtp packet in the real-tine application prt rangeand pre-allocate a certain amount of bandwidth to the video traffic.
Claculation of bandwidth used by codec :
[Codec Bandwidht used for video _ (1+ overhead/payload-size)] + additional 5 KB saftey margin.
interface serial 0/0:23
ip address 1.1.1.1 255.255.255.252
encapsulation ppp
ppp multilink
ppp multilink interleave
ppp multilink fragement-delay 10
ip rtp priority ip rtp priority 655535 16383 960
fair-queue
The above would queue any rtp packet ranging from video, voice or audion in a high PQ which will be dequeued (emptied) first before going to service data waiting
in the WFQ.
It is necessary to calculate the bandwidth require for one video confrecing session and multiply by x for the bandwidht reservation. x is the number of session that will be carried over the T1 link.
07-03-2002 07:13 AM
Low lantency queueing.
Just make a policy map that marks
Polycom video..... usually set with IP precedence 5 and
(others you may have to find out?)
The following example sows llq over a 512k link with LLQ
The example marks IP video as TCP and UDP (Polycom uses these!)
H.323 on TCP 1720
TCP 3230 3231
UDP 3230 3235
or IP Precedence 5
RTP Voice traffic,
MGCP or H3.23
Or call control traffic
Only 8k of bandwidth is needed for call control on hundreds of phones. The policy example reserves this!
Video and RTP voice are set with a priorty of 100 percent. All other traffic falls into the weighted fair queue.
The access-list also take into account any QOS marking you LAN switch may or may not do.
dscp ef
precedence critical
precedence flash
dscp af31
--------------------------------------------------------------------------------------
NOTE THE DIFFERENCE BETWEEN FRAME-RELAY AND PPP!
---------------------------------------------------------------------------------------
ip cef
!
class-map Voice+Video
match access-group 110
class-map VoIP-Control
match access-group 111
!
policy-map QOS-Policy
class Voice+Video
priority percent 100
class VoIP-Control
bandwidth 8
class class-default
fair-queue
!
!
!
____________________________
#Over PPP
interface serial3/0
encap ppp
#cannot be done over HDLC !!!
ip policy route-map QOS-Policy
!
!
!
---------------------------------
# Over frame
!
!
map-class frame-relay Voice+Video
frame-relay cir 512000
frame-relay mincir 512000
service-policy output video-police
!
!
Int serial 0
frame-relay traffic-shaping
!
!
int serial0/0.100
frame-relay class Voice+Video
-----------------------------------
!
!
access-list 110 permit udp any any range 16384 32767
access-list 110 permit tcp any any range 3230 3231
access-list 110 permit udp any any range 3230 3235
access-list 110 permit tcp any any eq 1720
access-list 110 permit ip any any precedence 5
access-list 110 permit ip any any dscp ef
access-list 110 permit ip any any precedence critical
access-list 110 permit ip any any precedence flash
access-list 110 permit ip any any dscp af31
!
access-list 111 permit tcp any any range 2000 2002
access-list 111 permit tcp any any eq 1720
access-list 111 permit tcp any any range 11000 11999
access-list 111 permit udp any any eq 2427
09-09-2002 07:47 AM
What is your source that says you cannot use HDLC on the P2P link?
09-09-2002 09:26 AM
Ditto with the HDLC comment above. I use LLQ over HDLC links all the time.
Also, I wouldn't necessarily put voice and video in the same queue. Give video a lower priority - voice traffic takes up a relatively small amount of bandwidth per call, where video can sometimes take up large amounts of bandwidth. The result is that you will have video traffic stepping on your phone calls.
Regarding the 'priority 100 percent' - I think this is a bad practice as well. You never want to commit more than 75% of your bandwidth according to all the QoS documentation out there.
Other comments, anyone?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide