1. 1 SIPREC Recording Metadata Model for SRS IETF 79 MEETING Ram Mohan R On behalf of the team Team: Paul Kyzivat, Ram Mohan R, R Parthasarathi

2. sends receives 0.. * 1 1 1 1 Metadata Model 2 Recording Session(RS) Communication Session(CS) Group Media Stream Application Data Communication Session(CS) 1 Participant 0.. * 2..* 1 1..* 1 0..* 1.. * 0..*

3. Metadata Model Interpretation The metadata model described is: Metadata as viewed by SRS. UML class model. There can be several instance diagrams (objects) of this model. RS, CS Group, CS, Participants, Media Streams and App data are the different blocks that will be modeled. The cardinality between these boxes are shown in the diagram. Brief overview of the association between different boxes of the model: ( more described in later slides) Allows association of one or more CS-Groups for each RS. [ This is to accommodate Persistent RS cases] Allows each instance of CS-group has one or more Communication Sessions [ This is to accommodate different transactions like consult Transfers, call-forwarding e.t.c during a call] Allows each instance of Communication Session has at least two and more Participants. Also each participant can be associated with zero or more CS

4. Metadata model interpretation Each participant can send Zero or more Media Streams. Also each participant can receive Zero or more media Streams Allows any number of application data objects attached to any of the other blocks.

5. Metadata Model: Recording Session 5 Communication Session Group (CS Group) Recording Session (RS) Recording Requestor ID Recording Reason Recording Type (Selective/Persistent) Application Data 10..* One RS – There can be Zero or more instances of Communication Session Group. This is to accommodate persistent recording cases – Each CS Group can be associated with one or more RS [ setup potentially by multiple SRCs] Attributes – Recording Requestor ID shall be SRC (in future it can be SRS ) – Recording Reason What values do we want this attribute to have ? – Recording type can be Selective OR persistent 1..* 0..*

6. Metadata Model : Recording Session What other attributes are needed? Do we need Application data for RS. If yes, what should Application Data for RS have?

7. Metadata Model: Communication Session Group 7 Communication Session Communication Session Group (CS Group) CS Group Identifier Application Data 10..* 1 or more RS per CS Group. Each CS Group can be associated with one or more RS [ setup potentially by multiple SRCs] 1 or more CS per CS Group – e.g. Consult Transfer Each CS will be associated to one CS- Group Recording Session (RS) 1..* 0..* 1 1..*

8. Metadata Model: Communication Session Group attributes – CS Group Identifier [ Do we need an unique id like the Session ID ? Or can It be a locally generated Id by SRC ?] The current model requires to have a CS Group. Is this ok ? What application data is needed for CS Group ?

9. 0..* 2..* Metadata Model: Communication Session 9 Participant Communication Session (CS) Direction Initiator Application Data 10..* 1 or more CS per CS Group 2 or more Participants per CS What other attributes ? – Retention – Force deletion Communication Session Group (CS Group) 1 1..*

10. Metadata Model: Communication Session Cardinalities between CS and Participant allows – a CS can have two or more participants. – a participant may be associated with zero or more CS’s (It is possible, though unlikely, that there are participants who are not part of any CS). Examples are : – participants in a premixed media stream. The SRC may have knowledge of such, yet not have any signaling relationship with them. This might arise if one participant in CS is a conf focus. Debatable whether these participants are part of the CS or just the media. – if one UA in CS works in 3pcc mode to acquire an MoH media stream, this might be reflected as unique source for media stream without having a reported signaling relationship to it.

11. Metadata Model: Communication Session The model also allows participants in CS that are not participants in the media. Examples are – The identity of a 3pcc controller that has initiated a CS to two or more participants of the CS. – The identity of a conference focus. Of course a focus is probably in the media, but since it may only be there as a mixer, it may not report itself as a participant in any of the media streams. Attributes – Direction /Initiator – "Direction" and "Initiator" are not well defined concepts. IMO the best we can do in that regard is identify the roles of the participants to the extent we know those. There could be cases where we don't know. – Direction can have values "inbound" or "outbound“ or “Don’t know” – What about initiator ? What other attributes? (e.g. Call Termination Reason) What app data do we need ?

12. Metadata Model: Participant 12 Participant AoR Name Type Application Data 10..* 2 or more Participants per CS Participants can be same across CS’s – Participants can be same across CS-groups too. Is it needed to represent these in the model ? Attributes – AoR – Name – Type ( can have values as “internal” or “external” or “don’t know “ ) Communication Session 0..* 2..* Media Stream sends receives 0.. * 1.. * 0..*

13. Metadata Model: Participant What other attributes do we need ? What about App data ? Cardinalities between participant and Media Stream allows – a participant receives zero or more media streams. – a participant sends zero or more media streams. (Same participant provides multiple streams e.g. audio & video) – a media stream is received by zero or more participants. (Its possible, though perhaps unlikely, that a stream is generated but sent only to the SRC and SRS, not to any participant. E.g. In conferencing where all participants are on hold and the SRC is collocated with the focus.) Further a media stream may be received by multiple participants (Whisper calls, side conversations) – a media stream is sent by one or more participants (pre-mixed streams) Example – A participant can send 1 or more media streams [ like Agent, Customer, Supervisor e.t.c] – A participant may receive Zero or more streams [For e.g. a Supervisor may have side conversation with Agent, while Agent converses with customer. ]

14. Metadata Model: Media Stream 14 Media Stream Start Time End Time Codec (& codec params) Media Stream Reference Application Data 10..* Media Stream block shall have properties of media Different instances of Media Stream block would be created whenever there is a change in media (e.g. dir change like pause/resume and/or codec change and/or participant change) Attributes – Start Time ( Represents Media Start time at SRC) – End Time (Media end Time). Are these needed ? Participant sends receives 0.. * 1.. * 0..*

15. Metadata Model: Media Stream – How do we represent codec params (SDP snipits?) – Media stream reference (In implementations this can reference to m-line ) What other attributes are needed ? What App Data is needed ? Open items: – Is it required to model media streams that are not recorded[ e.g SRC offered certain media types but SRS choose to accept only subset of them] ? – Should we represent the Information that the SRC has regarding privacy/access of information(media) being recorded as an attribute in Media Stream OR can this be app data ?

16. Metadata Model: Application Data 16 Application Data Type Identifier Data Encoding? Opaque Data 10..* 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

17. Next steps Update draft-ram-siprec-metadata-01 with the modified modeldraft-ram-siprec-metadata-01 Add Use cases to the draft (object instances) What should be the next steps for draft-ram- siprec-metadata-01 draft ?draft-ram- siprec-metadata-01 The delivery mechanism of metadata from SRC to SRS shall be a separate draft