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

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

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

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

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

6. 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”?

7. Open Issues Insufficient definition of CS is causing modeling problems Policy Server on SRS: http://www.ietf.org/mail-archive/web/siprec/current/msg00546.html – Does this impact metadata? 7

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