1 SIPREC Recording Metadata Model for SRS IETF-78 MEETING Paul Kyzivat on behalf of the team Team: Paul Kyzivat, Ram Mohan R, R Parthasarathi

Agenda Recording Metadata model for SRS Open Issues Next Steps 2

Strawhorse Metadata Model 3 Recording Session Object Recording Session(RS) 0..* 1..* Communication Session(CS) Recorded Media Stream Received Media Stream Participant Type (audio/video/...) Recorded Encoding Recorded Bits Start Time End Time Codec Media Stream Reference AoR Name 1..* 0..* 1 0..* 1..* 1 1..*

Metadata Contd.. The model described above provides: 4  One or more CS per RS, due to private side conversations e.t.c  Multiple RS per CS, due to redundancy or whatever  An optional grouping of multiple RS that are related in some way  Information that describes the participants of Communication Session(s).  Information to associate multiple media streams sent for a given Communication Session over multiple Recording Sessions to the SRS.  Information to associate multiple media streams for a given Communication Session over a single Recording Session to the SRS.  Information to associate participants and their associated media streams.  Information about media type(mixed or separate), time for each media stream.

Metadata Contd..  Received Media Streams will have one participant unless mixed before being sent to RS, in which case they can have several. A Participant can of course supply multiple Received Media Streams.  There could be one Received Media Stream per Recorded Media Stream if mixing is done before recording, or several if a separate unmixed stream per participant is supplied. Or there could be multiple per source (with disjoint time intervals) due to codec changes.  Communication Session can have multiple Recorded Media Streams for various reasons. Distinct media might have their own. (Or not - maybe audio/video together.) Independent sources might be recorded separately. 5

Model Status Very Preliminary Inputs/comments from Dave, Henry, Leon – Some incorporated, some not – Dave has a significantly different model in mind Information that describes the Recording Session Potential additions – reason for recording, recording instructions, recording initiator – Retention/deletion attributes – Application data that is opaque to SRS How to identify/distinguish distinct “lumps” of this data? Where does it fit? Is it “event based” or “static”?

Open Issues Insufficient definition of CS is causing modeling problems Policy Server on SRS: – Does this impact metadata? 7

What Next? Shall we: – Add to architecture document? – Create a separate document? – Not bother with modeling of this sort? Relation to requirements for solution? – Do we want a requirement for solution to adhere to whatever data model we decide on? 8

9 Discussion