1 / 10

SIPREC Recording Metadata Model for SRS in Virtual Meetings - Insights and Next Steps

This document outlines the metadata model for SIPREC recording sessions (RS) within the SRS for virtual meetings. It discusses various components such as the Recording Session Groups, Communication Sessions (CS), Recorded Media Streams, and Received Media Streams. The agenda includes identifying open issues, metadata requirements for participants, and defining attributes necessary for effective tracking and encoding of multiple media streams. The team, led by Paul Kyzivat, seeks to clarify these elements and establish next steps for improving metadata management in SIPREC environments.

oberon
Télécharger la présentation

SIPREC Recording Metadata Model for SRS in Virtual Meetings - Insights and Next Steps

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. SIPRECRecording Metadata Model for SRS SIPREC Virtual Meeting 28-sep-2010 Paul Kyzivat on behalf of the team Team: Paul Kyzivat, Ram Mohan R, R Parthasarathi

  2. Agenda • Recording Metadata model for SRS • Open Issues • Next Steps

  3. Metadata Model Recording Session Group 1 0..* 1..* Recording Session(RS) 1 1..* 0..* Communication Session(CS) 1 Application Data 1 0..* 0..* Recorded Media Stream 1 1 1..* Received Media Stream 1 1..* 1..* Participant 1

  4. Metadata Model: Recording Session Group • These are optional • Used when multiple RS are related • (e.g. recording initiated by multiple participants.) • Do we need them? • What attributes? type/usage/reason? 1 0..* Recording Session Group ?? Application Data 0..* 1..* Recording Session(RS)

  5. Metadata Model: Recording Session Recording Session Group • 0 or more CS per RS • 0 for persistent recording where there has been no CS • What other attributes are needed? 0..* 1..* 1 0..* Recording Session (RS) • Recording Requestor ID (SRC/SRS) • Recording Reason • Recording Type (Selective/Persistant) Application Data 1..* 0..* Communication Session (CS)

  6. Metadata Model: Communication Session Recording Session (RS) • 1 or more RS per CS • Recording of same CS initiated by multiple SRC • 0 or more Recorded Media Stream per CS • Different media • Starting/stopping media? • What attributes?(This needs attention) 1..* 0..* 1 0..* Communication Session (CS) ?? Application Data 1 0..* Recorded Media Stream

  7. Metadata Model: Recorded Media Stream Communication Session (CS) • 1 or more CS per Recorded Media Stream • Does >1 make sense? • 1 or more Received MS per Recorded MS • Historical tracking of data sources otherwise lost in the mix • Permits the recorded data to be encoded differently from the received media • This may be enough 1 0..* 1 0..* Recorded Media Stream • Type (audio/video/…) • Recorded Encoding • Actual Recorded Data (real data, not meta) Application Data 1 1..* Received Media Stream

  8. Metadata Model: Received Media Stream Recorded Media Stream • 1 or more Participants • When mixing done before delivery to SRS (e.g. conf focus) • Do we need the codec info, distinct from the recorded encoding? • How do we represent codec params (SDPsnipits?) • Media stream reference only needed while recording 1 1..* 1 0..* Received Media Stream • Start Time • End Time • Codec (& codec params) • Media Stream Reference Application Data 1..* 1..* Participant

  9. Metadata Model: Participant Received Media Stream • 1 or more Received Media Streams per Participant • Same participant provides multiple streams (e.g. audio & video) • Is there other data we could plausibly get about a participant? 1..* 1..* 1 0..* Participant • AoR • Name Application Data

  10. Metadata Model: Application Data • Allowing any number of application data objects attached to any of the others. • Any we can eliminate? • We need a type identifier. • What namespace? • What assignment rules? • Do we need a data encoding type separate from type id? • How do we represent / transmit the opaque data? • Text/binary 1 0..* Application Data • Type Identifier • Data Encoding? • Opaque Data

More Related