1 / 50

Implementing IP Video Conferencing for Teaching

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

Rita
Download Presentation

Implementing IP Video Conferencing for Teaching

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing IP Video Conferencing for Teaching Case Study Central Queensland University Shaune Sinclair & Merv Connell

  2. 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”

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

  4. Video conferencing @ CQU • A typical video conference lecture room

  5. Video conferencing @ CQU • Real-time, interactive

  6. Video conferencing @ CQU • User interface - AMX touch panel

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

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

  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 CQU’s 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. Dual stream video transmission VS single stream video transmission ?T.120 ?Voice-activated switching or continuous presence ?

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

  23. …..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 ?

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

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

  26. The solution

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

  28. Document camera - old system

  29. Document camera - new system

  30. PC - old system

  31. PC - new system

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

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

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

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

  36. Network Design Issues • What was in place • What were the options • Final design • QoS issues • QoS results • Network Testing • Must Do’s

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

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

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

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

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

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

More Related