Transcript Presentation - The QUESTnet Conference

Implementing IP Video
Conferencing for Teaching
Case Study
Central Queensland University
Shaune Sinclair & Merv Connell
Outline
 Video conferencing @ CQU
 Drivers for change to IP
 Key decisions - user / operational requirements
 Classic H.323 model VS the reality of educational context
 The new IP video conferencing system
 Experience
 Network design process – network, zone, numbering,
gatekeeper design
 “Funnies and gotchas”
Video conferencing @ CQU
 12 purpose-built video conference teaching facilities
 120+ hours/week teaching 10+ hours/week
administrative
 Interactive System-wide Learning
(ISL)
 Critical part of CQU’s teaching operation
Video conferencing @ CQU
 A typical video conference lecture room
Video conferencing @ CQU
 Real-time, interactive
Video conferencing @ CQU
 User interface - AMX touch panel
Video conferencing @ CQU
User (lecturer and student) experience:
 Conferences commence automatically on the
hour (scheduling/timetabling functionality)
 Lecturer controls the video and audio sources
during their presentation
 Students can interact via desk mic’s
 Cameras auto-zoom on students
Video conferencing @ CQU
Pre-IP:
 384k ISDN based
 PictureTel Montage 12-port ISDN MCU
 Tandberg 2000 endpoint units
 H.261 CIF (352 x 288 pixels) video resolution
Drivers for change to IP
Move away from old ISDN system
 MCU – reliability & support issues
 MCU 12-port limit – no room to grow
 CIF (352 x 288 pixels) video resolution limit – document
camera and PC video acceptable but not good
 Video conference calls competing with inter-campus
PABX-to-PABX calls
 Call dropout problems
Drivers for change to IP
Move towards IP-based system
 Greater bandwidth - better video and audio
 Better call reliability
 Much shorter call connection times
 Convergence - single network infrastructure
 Network reach – flexibility of location (no IMUXs
or NT1s required)
 Management – web interfaces, SNMP
 Cost effective carriage
Project Scope and Context
 2003 (this phase): Centrally scheduled and supported
CQU teaching video conferences
 2004: The next phase of the project is roll out of selfservice video conference services to the end user:
 Self- scheduling
 User guides
 “Desktop” video conferencing
 Access control
 Call tracking and re-charging
Solution requirements
Essential:
 Support and extend current operations
 Improve system reliability
 Enhance user support
 Improve video transmission quality
 Ability to include low-end, 3rd-party, ISDN,
and/or lower-bandwidth endpoints without
sacrificing video or audio quality
Solution requirements
Desirable:
 Support for SIP endpoints (e.g. Windows
Messenger)
 Extension to delivery of self-serve user video
conference services
Solution requirement
Support and extend current operations
 Support for current user paradigm
 AMX control in lecture theatres
 Ability to schedule lectures
 Ability to record lectures to VHS tape
 ISDN-to-IP in-dial
 IP-to-ISDN dialing
 (later) Ability to record lectures digitally for
transmission via video-on-demand (video
streaming)
Solution requirement
Improve system reliability
99% call completion rate
Fail-over / backup systems must be part of
the design
Backed by comprehensive support &
maintenance
Solution requirement
Enhance user support
 Web based interface for system administration
and operational support
 Ability for support staff to monitor conference
status in real time
 Ability for support staff to remotely observe
conferences without affecting the conference
 Alerts (e.g. SNMP support) on system failures /
call dropouts
Solution requirement
Improve video transmission quality
 PC and document camera used extensively
during lectures
 Under old (ISDN) system, far-end students
complained of blurry pictures
 “Blurry” pictures caused by:
SVGA –to- CIF conversion under old system (800 x
600 converted down to 352 x 288)
H.261 encoding under old system (video limited to
less than 384 kbps)
Solution requirement
Improve video transmission quality
 768kbps transmission
 As a minimum, 4CIF (704x576) end-to-end
transmission and display for document camera
and PC (no user intervention required)
 If possible, this should not be degraded if a non4CIF capable endpoint, or a slower-speed
endpoint should participate in the conference
Presenter
v
A
Main Camera
(transmitted at CIF)
eo
Vid
Video
Laptop computer
(transmitted at SVGA)
H.263 CIF + 4CIF
+ SVGA
MCU
Resolution autoswitches dependant
on video input used
SVG
A
768kbps
H.263 CIF +
4CIF + SVGA
H.323
Terminal
Document Camera
(transmitted at 4CIF)
768kbps
B
H.323
Terminal
H
4C .26
IF 3 C
+
76
SV IF +
8k
bp
GA
s
C
H.323
Terminal
Internal
(on CQU’s
IP network)
Solution requirement
Ability to include low-end, 3rd-party, ISDN, and/or
lower-bandwidth endpoints without sacrificing video
quality in high-end lecture theatres
 IP/ISDN gateway
 Video speed/rate matching
 Video codec transcoding (H.263 – H.261)
 Video resolution transcoding – as a minimum
4CIF down to CIF
 Audio codec transcoding
Presenter
A
F
Vid
v
eo
Video
H.323
Terminal
H.320
Terminal
Main Camera
(transmitted at CIF)
Document Camera
(transmitted at 4CIF)
SVG
A
H.263 CIF + 4CIF
+ SVGA
384kbps
MCU
E
B
H.323
Terminal
H
4C .26
IF 3 C
+ IF
76
SV +
8k
bp
G
s
A
C
D
H.320
Terminal
H.323
Terminal
ISDN
768kbps
H.261 CIF
H .2
61
CIF
12
8k
bp
s
768kbps
H.263 CIF +
4CIF + SVGA
+
3 CIF
H.26 SVGA
+
4CIF
s
bp
4k
38
H.320 - H.323
Gateway
Laptop computer
(transmitted at SVGA)
IP
H.323
Terminal
Resolution autoswitches dependant
on video input used
Dual stream video transmission
VS single stream video
transmission ?
T.120 ?
Voice-activated switching or
continuous presence ?
At this stage, opted for single stream,
voice-activated video transmission
No change to basic operational paradigm
for users
Dual stream video not standardised across
the industry –interop’ issues
Dual video streams present challenges
when recording to VHS tape or to a single
video stream media
…..continued.
Continuous presence mode does not
support the higher (SVGA) resolution
T.120 presents challenges when recording
to VHS tape or to a single-video-stream
media
Dual stream a positive from an interactivity
point of view – further consideration as the
technology matures
“Lecture mode” feature ?
Classic H.323 model VS the reality of
the educational context
“Classic” H.323 model:
 provides inter- and intra- zone bandwidth
control (gatekeeper) on an ad-hoc basis
How do you ensure that there are enough
network, gateway and MCU resources
available ahead of time?
 add resource-aware scheduling
(reservation) and enforce use
The solution
 MCU / Multipoint Bridge
 100 port Radvision ViaIP 400, H.323 & SIP support, Video & Audio transcoding
modules
 Gatekeeper
 Radvision ECS
 IP/ISDN Gateway
 Radvision PRI
 Endpoints
 Tandberg 2500
 Conference scheduling/reservation and monitoring
 VisionNex VCS
 Providers




Broadreach Services – Radvision/VisionNex, Installation, Network Testing
Logical – Project Management, Support & Maintenance front-end
Video Pro – Tandberg endpoints, AMX coding
CQU/Glint – QoS implementation
The solution
Gatekeeper &
Conference Management &
Scheduling Servers
Various ISDN
Videoconference
Units
Campuses:
Emerald
H.320
Pomona
Terminal
H.320
Singapore
Terminal
Malaysia
ISDN
16 x Tandberg
IP
Videoconference
Units
H.323
Terminal
MCU / Multipoint Bridge
IP
H.323
Terminal
H.323
Terminal
Campuses:
Rockhampton
Bundaberg
Gladstone
Mackay
ISDN - PRI
ISDN Gateway
Ericsson MD110 PABX
Outcomes
Improved video transmission quality
 768 kbps standard connection speed
 SVGA transmission end-to-end for PC
presentations
 4CIF transmission end-to-end for Doc Camera
presentations
 Newer video codecs (H.263+) – better video
 Can transcode video resolutions / mix speeds
without sacrificing quality of the higher-speed
higher-end video conference endpoints (4CIF
max.)
Document camera - old system
Document camera - new system
PC - old system
PC - new system
Outcomes
Improve system reliability
 Call completion ratio now 99%+
(old ISDN system approx. 90%)
 Fail-over / backup systems:
auto failover gatekeeper
auto failover scheduling server
Tandberg endpoints have built-in-MCUs, can be used in
case of problems with main Radvision MCU (albeit at
lower quality)
Outcomes
Enhance user support
 Web (Java) based interfaces on all systems
 Real-time conference monitoring interface
 Remote conference observation from support
staff offices
 Conference recording from support staff offices
 (later) Integration with video streaming
 Online monitoring capabilities (SNMP, alerts)
Outcomes
Reduced connection time (< 2 seconds)
ISDN-to-IP in-dial
IP-to-ISDN dialing
SIP functionality (e.g. can connect
Windows Messenger clients)
Consider
 Does the functionality work end-to-end, across
the entire solution?
 What happens when you introduce a third-party
(uncontrolled) system into the multipoint video
conference?
 Can the desired functionality be scheduled /
operated automatically (is user intervention
required)?
Network Design Issues
What was in place
What were the options
Final design
QoS issues
QoS results
Network Testing
Must Do’s
QoS Issues
 Design – Low Latency Queueing (WAN)
 Class of Service, Type of Service and Diff-Serv for QoS
(LAN)
 All devices supported :6509,7206VX,4006,2950, 3548
 Required E1/E3 in regional 7206
PA-A2-E1E3 – no QoS support
PA-A3-E3 QoS enabled – no E1
 No time or equipment to do VoIP trunking
 Multiple ATM PVC’s (was 25Mb VBR / 2Mb CBR)
 MCU Traffic (3.5 MB/s)
Voice CBR Circuit (2.3 Mb/s)
General data (11Mb/s)
QoS results
No QoS regularly saw 5 – 10% loss
Current QoS < 1%
Catalyst 4006 / 3548
output buffer failures 3548
pool buffers on 4006 (S,M,L,VL)
Link via a wireles bridge (350 AP’s)
384k : 8 – 40% loss
“Bulldog’s” : 3 – 10% loss
Tandberg 2500’s work better 10Mb FD
FastEthernet0/4 is up, line protocol is up
Hardware is Fast Ethernet, address is 0004.9a36.7284 (bia 0004.9a36.7284)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 3000 bits/sec, 4 packets/sec
4318986 packets input, 820037137 bytes
Received 41673 broadcasts, 0 runts, 0 giants, 0 throttles
3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 367 multicast
0 input packets with dribble condition detected
25916940 packets output, 781933980 bytes, 1681 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
1681 output buffer failures, 0 output buffers swapped out
Interface FastEthernet0/4 (up/up)
WARNING: There have been 1681 'underruns' reported.
This indicates the number of times that the transmitter has been running faster than
the router can handle.
TRY THIS: Monitor the level of underruns over time.
If they continue increasing, consider buffer and queue tuning or upgrading hardware.
Network testing
Before “go live” simulated multiple H.323
calls across the LAN/WAN
Simultaneously kicked off backup jobs to
flood WAN (both ways)
Verified QoS by observing end-to-end
H.323 packet loss and jitter statistics for all
simulated calls (Prolab – Broadreach)
Observed a “plateau” as per QoS design
Must Do’s
 Check and re-check QoS-related capabilities of all
network devices and interface modules
 Careful numbering and zone/gatekeeper topology design
(keeping in mind relationships to ISDN in-dial
numbering)
 Test and confirm H.323 network performance before
testing anything else
 Force speed & duplex settings on Ethernet interfaces (on
switches and on videoconference devices)
 Allow a decent pilot / test period – 5% packet loss is an
issue
From here
Self-serve video conference services
Interfacing with AARNet/Internet
Firewall traversal
IP video conferencing to Brisbane,
Sydney, Melbourne campuses via AARNet
Integration with video streaming
SIP