1

SIPRECRecording Metadata Model for SRS

IETF 79 MEETING Ram Mohan R

On behalf of the team

Team: Paul Kyzivat, Ram Mohan R, R Parthasarathi

sendsreceives0.. *

1

1

11

0..*

Metadata Model

2

Recording Session(RS)

Communication Session(CS) Group

Media Stream

ApplicationData

Communication Session(CS) 1

Participant

0.. *2..*

11..*

1

1..*0..*

0..*

1.. *

0..*

Metadata Model InterpretationThe 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

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.

Metadata Model: Recording Session

5

Communication Session Group (CS Group)

Recording Session (RS)

•Recording Requestor ID• Recording Reason•Recording Type (Selective/Persistent)

Application Data

1 0..*

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

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?

Metadata Model: Communication Session Group

7

Communication Session

Communication Session Group (CS Group)

CS Group Identifier

Application Data

1 0..*

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

11..*

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 ?

0..*2..*

Metadata Model: Communication Session

9

Participant

Communication Session (CS)

DirectionInitiator Application

Data1 0..*

• 1 or more CS per CS Group

• 2 or more Participants per CS

• What other attributes ?– Retention– Force deletion

Communication Session Group (CS Group)

11..*

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.

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 ?

Metadata Model: Participant

12

Participant

•AoR•Name•Type

Application Data

1 0..*

• 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 Session0..*2..*

Media Stream

sendsreceives0.. *

0..*

1.. *

0..*

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

Metadata Model: Media Stream

14

Media Stream

•Start Time•End Time•Codec (& codec params)•Media Stream Reference

Application Data

1 0..*

• 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

sendsreceives0.. *

0..*

1.. *

0..*

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 ?

Metadata Model: Application Data

16

Application Data

•Type Identifier•Data Encoding?•Opaque Data

1 0..*

• 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

Next steps

• Update draft-ram-siprec-metadata-01 with the modified model

• Add Use cases to the draft (object instances)• What should be the next steps for

draft-ram-siprec-metadata-01 draft ?• The delivery mechanism of metadata from

SRC to SRS shall be a separate draft