Implementing IP Video Conferencing for Teaching

1
Implementing IP Video Conferencing for Teaching

• Case Study
• Central Queensland University
• Shaune Sinclair Merv Connell

2
Outline

• Video conferencing _at_ 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

3
Video conferencing _at_ CQU

• 12 purpose-built video conference teaching
  facilities
• 120 hours/week teaching 10 hours/week
  administrative
• Interactive System-wide Learning(ISL)
• Critical part of CQUs teaching operation

4
Video conferencing _at_ CQU

• A typical video conference lecture room

5
Video conferencing _at_ CQU

• Real-time, interactive

6
Video conferencing _at_ CQU

• User interface - AMX touch panel

7
Video conferencing _at_ 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 mics
• Cameras auto-zoom on students

8
Video conferencing _at_ 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

9
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

10
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

11
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 self-service video conference services to the
  end user
• Self- scheduling
• User guides
• Desktop video conferencing
• Access control
• Call tracking and re-charging

12
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

13
Solution requirements

• Desirable
• Support for SIP endpoints (e.g. Windows
  Messenger)
• Extension to delivery of self-serve user video
  conference services

14
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)

15
Solution requirement

• Improve system reliability
• 99 call completion rate
• Fail-over / backup systems must be part of the
  design
• Backed by comprehensive support maintenance

16
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

17
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)

18
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
  non-4CIF capable endpoint, or a slower-speed
  endpoint should participate in the conference

19
Internal (on CQUs IP network)
20
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

21
(No Transcript)
22
Dual stream video transmission VS single stream
video transmission ?T.120 ?Voice-activated
switching or continuous presence ?
23

• 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

24

• ..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 ?

25
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

26
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

27
The solution
28
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.)

29
Document camera - old system
30
Document camera - new system
31
PC - old system
32
PC - new system
33
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)

34
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)

35
Outcomes

• Reduced connection time (lt 2 seconds)
• ISDN-to-IP in-dial
• IP-to-ISDN dialing
• SIP functionality (e.g. can connect Windows
  Messenger clients)

36
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)?

37
Network Design Issues

• What was in place
• What were the options
• Final design
• QoS issues
• QoS results
• Network Testing
• Must Dos

38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
41
(No Transcript)
42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
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 7206PA-A2-E1E3 no
  QoS support PA-A3-E3 QoS enabled no E1
• No time or equipment to do VoIP trunking
• Multiple ATM PVCs (was 25Mb VBR / 2Mb CBR)
• MCU Traffic (3.5 MB/s)Voice CBR Circuit (2.3
  Mb/s)General data (11Mb/s)

46
QoS results

• No QoS regularly saw 5 10 loss
• Current QoS lt 1
• Catalyst 4006 / 3548output buffer failures
  3548pool buffers on 4006 (S,M,L,VL)
• Link via a wireles bridge (350 APs)384k 8
  40 lossBulldogs 3 10 loss
• Tandberg 2500s work better 10Mb FD

47
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.
48
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

49
Must Dos

• 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

50
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