This document addresses basic network setup and configuration of
Polycom ViewStation128 (video conference unit) with Cisco routers for video
over IP applications. It also covers adding QoS and troubleshooting the
real-time video quality across the LAN and the WAN media.
The Polycom Viewstation interfaces to a TV for display of captured
video and audio; it also has a connection to the LAN to pass compressed video
packets over IP. The Polycoms are the H323 endpoints just as any other gateway.
Video over IP uses the following protocols:
H.225 for messaging of call control signaling
H.245 for opening and closing of media stream channels
H.263 and H.261 for video codec with picture
G.723 for audio codecs, at 5.3kpbs or 6.3kpbs modes
The software for the Polycom ViewStation128 should be recent and can be
downloaded from the Polycom website over LAN. The latest firmware available at
the time of publication of this document was 7.0.1.
The ViewStation can send the compressed video and audio call at 128k,
256k, 384k, 512k, 576k, or 768k rates. This compression rate does not include
the IP and LAN/WAN headers added, so when reserving bandwidth in QoS, remember
to account for that overhead. For instance, Audio (64kbps)+ Video
The optimal delay for video applications is similar to voice:
125-150msec round-trip time for optimal results. Added latency is tolerable,
but reported on the Polycom as an error when you telnet into it.
There are no specific requirements for this document.
The setup below was tested in the lab with Cisco IOS® Software Release
12.1(5)T and 12.2(1a) on the Cisco 7200 routers. The Polycom ViewStation 128
had firmware release 7.0.1.
The information presented in this document was created from devices in
a specific lab environment. All of the devices used in this document started
with a cleared (default) configuration. If you are working in a live network,
ensure that you understand the potential impact of any command before using
For more information on document conventions, see the
Technical Tips Conventions.
This document uses the network setup shown in the diagram below. The
Polycoms are hard coded at half-duplex and 10Mbps. The 2900XL in this case has
all ports hard-coded to auto/auto, so no change was necessary on the Cisco 7200
FE (fast ethernet interface), so it is set to 100/Full. If the Polycoms in some
cases directly attach to the router or to catalyst switches, the ports must be
configured to match duplex/speed accordingly.
Under System Info > Admin Setup, perform these
Under LAN/H.323, and LAN/Intranet, configure the IP address of the
Polycom and the default Gateway.
Under LAN/H.323, and H323, configure the H323 name for this
ViewStation and any E164 ID, if desired.
(Optional) Under LAN/H.323, and H323, QoS can be specified for
specific UDP or TCP ports. The range of fixed TCP ports is 3230-3231 and fixed
UDP ports is 3230 to 3235 for video traffic. You can set the IP precedence to
critical on the packets here, too.
Under General Setup, configure the standard options such as system
name, auto answer, auto dial, language.
All calls here are made using the remote IP address; you can also use
E.164 numbers if using a gatekeeper to make video calls. Under the main screen,
type in the IP address for remote polycom, then select the compression speed;
this should match up to what you have set as default on the remote side.
One of the most effective QoS methods to use for VideoOverIP over WAN
is Low Latency Queuing (LLQ). The policymap can be based on a few different
parameters, discussed below. The necessary bandwidth can be dedicated and video
over other IP applications can be prioritized using LLQ. Also, the ATM link
should be VBR-NRT or CBR for higher video quality.
class-map match-all video
match access-group 101
!--- Class map used to associate access-list 101 to the LLQ class video.
!--- Definition of the policy map for the LLQ Configuration
!--- This is the priority class/queue assigned for video traffic.
!--- It reserves 900 Kbps for video traffic
!-- All other non-video traffic uses fair-queuing policing.
ip address 192.168.3.100 255.255.255.0
no cdp enable
!--- This is the LAN interface that connects to the Polycom ViewStation
!--- No QoS (LLQ) was applied here.
no ip address
no atm ilmi-keepalive
interface ATM6/0.1 point-to-point
ip address 10.1.105.1 255.255.255.0
!--- atm pvc defined
!--- Layer 2 encapsulation type for atm packets
service-policy out video-police
!--- Applies LLQ (defined above) to the subinterface for
!--- layer 3 (Video over IP)traffic shaping and priotization
vc-class atm VBR-NRT
!--- atm traffic shaping class defined
vbr-nrt 1500 1400 100
!--- Maximum bandwidth at 1500Kbps and nominal at 1400Kbps with 100Kbps burst
access-list 101 permit tcp any any range 3230 3231
access-list 101 permit udp any any range 3230 3235
!--- These access-lists are used by the LLQ class-map.
!--- These access-lists are based on the fixed UDP (3230-3235)
!--- and TCP (3230-3231) ports for the ViewStation VideoOverIP
Alternatively, the following access-list configurations could have been
Based on source/destination ip address of the ViewStation units:
access-list 101 permit ip host 192.168.3.90 host 192.168.1.90
access-list 101 permit ip host 192.168.1.90 host 192.168.3.90
Based on IP precedence 5:
access-list 101 permit ip any any precedence 5
There is currently no verification procedure available for this
When a call is established, Polycom keeps track of all video packets.
You can telnet into the polycom and monitor this close-up. The Polycom reports
the latency in H323 packets, the lost video or audio packets. The Polycom
debugs are readable and indicate problems when it may be hard to notice them on
a video screen.
Some of the most common video problems, such as freezing, come from
Ethernet duplex and/or speed mismatch. If the Ethernet counters indicate large
number of CRC/frame/deferred packets, video quality will degrade considerably,
so the first checkpoint is making sure all LAN interfaces run error-free.
This section provides information you can use to troubleshoot your
You can check the configs on the polycom by the initial info display.
There are informational debugs turned on for every action. When you have a
video call, the Polycoms automatically report calculated latency in packets:
any lost packets, and resequenced packets as a result of the lost
!--- Action: Telnetting to the Polycom ViewStation unit to capture information
!--- and debug output.
!--- When a call is established, the Polycom unit keeps track of video packets.
!--- The Polycom reports h323 packet latency and lost video and voice packets.
Trying 10.122.3.90 ... Open
Hi, my name is : Polycom166-regnl
Here is what I know about myself:
Serial Number: 011B12
Software Version: Release 7.0.1 - 16 Jun 2001
Network Interface: ISDN_UNKNOWN
MP Enabled: No
H323 Enabled: Yes
IP Address: 192.168.3.90
Time In Last Call: 0:08:41
Total Time In Calls: 44:20:06
Total Calls: 171
Switch Type: Nortel DMS-100
Country Code: 1
Area Code: 919
ISDN 1 a is: 9913293
ISDN 2 a is: 9913294
Before QoS was applied, when video and data were run at the same time,
the telnet result into the polycom would report the following; this is a clear
indication of problems in the network and should reflect in the video quality
RTP: Video Packet Lost
RTP: Reseting last_seq_num from 23397 to 23398
RTP: Send FastVideoPicture_MSG
RTP: last eBit 6 plus new sBit 0 not equal 8! (instance 0)
...VideoFastUpdatePictureHandler() time 469850
RTP: Max. video packets stored = 4
RTP: Minimum/MaximumThreshold = 4 0/256, 4 0/256
UI:UI msg from VidDec: S VD1 ReceivedFreezeRelease 0
Received a Picture Fast Update request from the other side
Audio Packet(s) lost - last_seq_num = 15147, new_seq_num = 15149
Transfer 1 duplicate packets
Received a Picture Fast Update request from the other side
RTP: Max. video packets stored = 1
RTP: Minimum/MaximumThreshold = 4 0/256, 4 255/256
Certain show commands are supported by the
Output Interpreter Tool
(registered customers only)
, which allows you to view an
analysis of show command output.
The following output was captured in the Cisco IOS Routers LLQ was
applied on the ATM interfaces and then flooded pings were sent to create
congestion during the video call. When there is contention for bandwidth, LLQ
dynamically prioritizes the video traffic.
MS-7206VXR-12A#show queue atm 6/0.1
Interface ATM6/0.1 VC 1/138
Queuing strategy: weighted fair
Total output drops per VC: 22863
Output queue: 66/512/64/22863 (size/max total/threshold/drops)
Conversations 3/4/64 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 0 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 1/4626/0/0/0
Conversation 1, linktype: ip, length: 54
source: 10.122.3.100, destination: 10.1.105.2, id: 0x002B, ttl: 255,
TOS: 192 prot: 6, source port 23, destination port 11032
(depth/weight/total drops/no-buffer drops/interleaves) 1/5397/0/0/0
Conversation 51, linktype: ip, length: 308
source: 10.122.3.90, destination: 10.122.1.90, id: 0x51AB, ttl: 59,
TOS: 160 prot: 17, source port 49206, destination port 3232
Notice in the following output that there are no packet drops in the
MS-7206VXR-12A#show policy-map int atm 6/0.1
ATM6/0.1: VC 1/138 -
Service-policy output: video-police
Class-map: video (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 101
Weighted Fair Queueing
Output Queue: Conversation 72
Bandwidth 900 (kbps) Burst 22500 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
290307 packets, 252480609 bytes
30 second offered rate 2951000 bps, drop rate 2341000 bps
Weighted Fair Queuing
Flow Based Fair Queuing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 67/35584/0