What type of QoS to be used for video conferencing and data on same T1?

admin_2 · ‎07-02-2002

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.

Report Inappropriate Content · ‎07-02-2002

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.

ryan.hicks · ‎07-03-2002

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

fmaisano · ‎09-09-2002

What is your source that says you cannot use HDLC on the P2P link?

jpstott · ‎09-09-2002

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?