1 / 8

Vidmid VC working group: Scenarios & workplan

This workgroup aims to identify important capabilities for the R&E community in video conferencing and categorize them into problem sets. It will help with middleware issues and provide typical cases of video conferencing use. The goal is to analyze the four most important scenarios.

loriroberts
Download Presentation

Vidmid VC working group: Scenarios & workplan

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. Vidmid VC working group:Scenarios & workplan Egon Verharen, SURFnet

  2. Scenarios • Purpose: • cast a wide net for important capabilities for the R&E community • categorize those needs into problem sets and prioritize • help with identifying middleware issues • Identification, authentication, authorization, directory services, security, resource discovery, … • describe typical cases of videoconferencing use • Format: title, example, generic format, needed components • Cases: point-to-point, multipoint, interrealm • based on input from vidmid participants • accessible through vidmid website • http://middleware.internet2.edu/video/ • Goal: pick 4 most ‘important’ ones and analyze them

  3. Scenario Process • Work out scenarios • Requirements from prioritized scenarios • Designs from requirements • Implementations, white papers, standards • Testbeds for implementations • Dissemination from implementations and testbeds

  4. Basic scenario • Person A, working on a conferencing capable device, that is registered at organisation X’s ‘gatekeeper’ and directory server, looks up contact information in an authoritative directory to set up a (video)conference connection with person B, registered elsewhere. With a simple click on the presented information and after checking user A’s credentials a call request is send to person B. Person B can check the incoming request on validity and answers if satisfied, after which a conference is initiated, securely if desired. The systems negotiate the best quality available to them.

  5. Architectural issues • Discussed in BoF • For instance • Authentication of users happens to their own security domains, I.e. the client authenticates to their home service. • Authorization decisions are usually made at the target. The target requests attributes from the source to make the authorization decision. • How to authenticate • through web interface • direct access from client • use of existing credentials (cookies, K tickets, certs) • What identifier to authenticate against?What identifier to pass to target for authorization decision? • Interrealm resource discovery

  6. Workplan - goals • Workplan, due 11/15 • Short term goals • Final set of scenarios, including priorities, due 10/15 • Extracted requirements, due 12/1 • Other goals • To develop a set of simple, authenticated desktop videoconference clients, along with the associated directory and authentication components • To identify network-based infrastructure to support community video • To foster interoperability at the identifier, security and video stream levels

  7. Workplan - deliverables • Deliverables • required directory objectclasses and attributes • recommended relationship of video directory to enterprise directory • a SIP video client that can initiate video by target user identifier and present an authenticated initiator identifier to target for access control • (specs for) a H.323 client that can … • a H.323 to SIP gateway • make VRVS directory-enabled • develop protocols for interrealm SIP • Set up testbed • Timelines • Total: 1.5 yr. • Resource requirements • People, equipment

  8. Discussion • What do YOU think ? • Goals • Deliverables • Tyler’s suggestion: to develop models for H.323, as it is the more mature technology, but do so in such a way that they can largely be duplicated in SIP • Michael: do not develop new authentication scheme. Need to accommodate a variety of means of authentication • Timeline • Resources • Come forward • UAB

More Related