Implementing ip video conferencing for teaching
1 / 50

Implementing IP Video Conferencing for Teaching - PowerPoint PPT Presentation

  • Updated On :

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Implementing IP Video Conferencing for Teaching' - Rita

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Implementing ip video conferencing for teaching l.jpg

Implementing IP Video Conferencing for Teaching

Case Study

Central Queensland University

Shaune Sinclair & Merv Connell

Outline l.jpg

  • 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 l.jpg
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 @ cqu4 l.jpg
Video conferencing @ CQU

  • A typical video conference lecture room

Video conferencing @ cqu5 l.jpg
Video conferencing @ CQU

  • Real-time, interactive

Video conferencing @ cqu6 l.jpg
Video conferencing @ CQU

  • User interface - AMX touch panel

Video conferencing @ cqu7 l.jpg
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 @ cqu8 l.jpg
Video conferencing @ CQU


  • 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 l.jpg
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 ip10 l.jpg
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 l.jpg
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

Solution requirements l.jpg
Solution requirements


  • 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 requirements13 l.jpg
Solution requirements


  • Support for SIP endpoints (e.g. Windows Messenger)

  • Extension to delivery of self-serve user video conference services

Solution requirement l.jpg
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 requirement15 l.jpg
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 requirement16 l.jpg
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 requirement17 l.jpg
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 requirement18 l.jpg
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

Slide19 l.jpg


(on CQU’s IP network)

Solution requirement20 l.jpg
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

Slide22 l.jpg
Dual stream video transmission VS single stream video transmission ?T.120 ?Voice-activated switching or continuous presence ?

Slide23 l.jpg

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

Slide24 l.jpg

…..continued. video transmission

  • 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 l.jpg
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 l.jpg
The solution context

  • 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 solution27 l.jpg
The solution context

Outcomes l.jpg
Outcomes context

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

Outcomes33 l.jpg
Outcomes context

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)

Outcomes34 l.jpg
Outcomes context

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)

Outcomes35 l.jpg
Outcomes context

  • Reduced connection time (< 2 seconds)

  • ISDN-to-IP in-dial

  • IP-to-ISDN dialing

  • SIP functionality (e.g. can connect Windows Messenger clients)

Consider l.jpg
Consider context

  • 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 l.jpg
Network Design Issues context

  • What was in place

  • What were the options

  • Final design

  • QoS issues

  • QoS results

  • Network Testing

  • Must Do’s

Qos issues l.jpg
QoS Issues context

  • 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 supportPA-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)

Slide46 l.jpg

QoS results context

  • No QoS regularly saw 5 – 10% loss

  • Current QoS < 1%

  • Catalyst 4006 / 3548output buffer failures 3548pool 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

Slide47 l.jpg

FastEthernet0/4 is up, line protocol is up context

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 l.jpg
Network testing context

  • 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 l.jpg
Must Do’s context

  • 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 l.jpg
From here context

  • 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