implementing ip video conferencing for teaching
Download
Skip this Video
Download Presentation
Implementing IP Video Conferencing for Teaching

Loading in 2 Seconds...

play fullscreen
1 / 50

Implementing IP Video Conferencing for Teaching - PowerPoint PPT Presentation


  • 319 Views
  • Uploaded 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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

Implementing IP Video Conferencing for Teaching

Case Study

Central Queensland University

Shaune Sinclair & Merv Connell

outline
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
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
Video conferencing @ CQU
  • A typical video conference lecture room
video conferencing @ cqu5
Video conferencing @ CQU
  • Real-time, interactive
video conferencing @ cqu6
Video conferencing @ CQU
  • User interface - AMX touch panel
video conferencing @ cqu7
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
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
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
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
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
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 requirements13
Solution requirements

Desirable:

  • Support for SIP endpoints (e.g. Windows Messenger)
  • Extension to delivery of self-serve user video conference services
solution requirement
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
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
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
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
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

Internal

(on CQU’s IP network)

solution requirement20
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
Dual stream video transmission VS single stream video transmission ?T.120 ?Voice-activated switching or continuous presence ?
slide23
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
…..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 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
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
outcomes
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.)
outcomes33
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)
outcomes34
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)
outcomes35
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
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
Network Design Issues
  • What was in place
  • What were the options
  • Final design
  • QoS issues
  • QoS results
  • Network Testing
  • Must Do’s
qos issues
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 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

QoS results

  • 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

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
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
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
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
ad