1

SIPRECRecording Metadata Model for

SRSIETF-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 TimeEnd Time

CodecMedia Stream

Reference

AoRName

1..*0..*

10..* 1..*

1..*

11..*

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: http://www.ietf.org/mail-archive/web/siprec/current/msg00546.html

– 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