1 siprec recording metadata model for srs ietf 79 meeting ram mohan r on behalf of the team team:...
TRANSCRIPT
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