SIPREC Recording Metadata for SRS draftietfsiprecmetadata03 July 28

SIPREC Recording Metadata for SRS (draft-ietf-siprec-metadata-03) July 28, 2011 IETF 81 meeting Ram Mohan R On behalf of the team Team: Paul Kyzivat, Ram Mohan R, R Parthasarathi 1

Agenda Ø Changes in draft-ietf-siprec-metadata from version 01. Ø Discuss Open items in Metadata model Ø Discuss open items in the format (XML) Ø Next Steps

Changes from Previous version Ø The new version of draft has following changes (Most of which were agreed in last interim meeting and rest over mailer) : – Merged format (XML schema) with model – Modified the linkages between Extension Data class and other classes in the model to indicate that Extension data class is contained inside other classes. – Added a new attribute in MS class to describe the content of an MS based on types defined in RFC 4796 registry. – Modified the XML schema to show extension data element contained inside the other elements.

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

Changes to linkages in the model Ø As per the agreement in last meeting, Extension data for a class shall be sent with in the parent class to which it belongs. Ø The linkages between Extension data class and all other classes has been modified to show the same.

Metadata Model: Communication Session Group Recording Session (RS) Open Items: 1. . * 0. . * Communication Session Group (CS Group) CS Group unique ID 1 0. . 1 1. . * 0. . * Extension Data Ø Any objection for addition of Optional associate/disassociate time attribute ? – Associate-time for CS-Group shall be calculated by SRC as the time when a CS-Group is formed. – Disassociate-time for CSGroup shall be calculated by SRC as the time when CSGroup ends. Communication Session 6

Metadata Model: Participant Open Items: Communication Session 1. . * 2. . * Participant • Ao. R list • Name • Capability List (or Parameter List) 0. . * 1. . * receives 0. . * sends 1 0. . * Extension Data Ø Participant lifetime is within the scope of CS or CSG ? Ø Is Optional associate/disassociate time attribute needed? – associate-time shall be calculated by SRC as the time it sees a new participant added to CS – Disassociate-time shall be calculated by SRC as the time it see a participant stopping participation from CS Ø How to handle capabilities? Ø Allow Name per Ao. R? Media Stream 7

Metadata Model: Participant Ø Recording Callee capabilities ( RFC 3840 defined capabilities) Each participant shall have Zero or more capabilities (Or include all Contact params, not just capabilities? ) How to represent in XML ? A participant may use different capabilities depending on the role it plays at a particular instance. Metadata shall report the capability of the participant at that instant. – IOW if a participants moves across different CSs ( due to transfer e. t. c) its role may change and hence the capability used. – ISSUE: How to represent participant that is simultaneously in multiple CSs with different capabilities/parameters? ? ? – –

Metadata Model : Participant Ø Paul has raised a suggestion that we allow multiple Names on the participant, since the sources of multiple AORs will typically provide multiple display names as well. So we could switch to a list of name/aor pairs, where the name is optional. Ø Use-case where multiple names to single AOR may be present: – if there are two values in P-A-ID, they could each have a display name, and those could be different. And the From could also have a display name. If so, how would the SRC know which one to include ? ? – By making provision to provide one with each AOR the SRC is relieved of deciding which one is the right one and leave it for the SRS or even the person who later uses the recorded information, to decide which name(s) to chose. This gives a lot of flexibility. – Alternatively we can simply declare that the SRC must have some policy for making this decision and avoid having this attribute in metadata. Ø Which way to go ? - Give all information to SRS and let SRS decide ? Or policy at SRC ?

Metadata Model: Participant Ø Is there a need to know the linkage between the participants to its contributing media stream in a mixed RS stream ? – NOTE: This is needed for only those cases where SRC acts as RTP mixer. – RS SDP shall provide the information of SSRC/CSRC – Participant XML element can have CSRC information (by means of new attribute). – Having this info can allow the SRS to determine which participants are part(contributors) of particular parts of the mixed stream. – NOTE: Not all SRC may have the capability to determine this and hence it can be a optional attribute – Even if that mapping isn't there, the recording is still useful. Its just lost some information

Metadata Model: Media Stream Closed Items: Participant 0. . * 1. . * receives 0. . * sends Media Stream CS 1. . * 0. . * • Start Time • End Time • Media Stream Reference • Content-type 1 0. . * Ø Added content-type attribute to describe the content of an MS based on types defined in RFC 4796 registry and represent the same in RS SDP. Ø IOW no XML representation Extension needed for content-type Data attribute. Open Items: Ø What is Start/Stop time for MS and what is its scope? 11

Metadata Model: Media Stream Ø Do we really need Start/stop time for MS ? Ø We already have <send> element in <participant> to indicate a participant participation in media. This can be used to indicate when a participant contributes/ stops contributing to a MS and hence we may not need another attribute. Ø Is this sufficient to indicate a participant has stopped sending a MS ? OR do we need explicit indication ? Ø The information on when the recording of a MS has stopped can be learnt from the m-line mapped to the MS class. Some cases include: – – Some different MS is mapped to that m-line The port of the m-line is set to zero The RS containing the m-line ends The dir attribute in m-line is set to inactive

Metadata model : Media Stream Ø In case we want to have explicit start/stop time for MS how do we determine its value: – – – Is start-time the time SRC sees the media for a participant for the first time ? What is start-time in mixed stream from SRC ? What about stop-time ? Is it the time a participant stops sending media (as seen by SRC). NOTE: a participant may re-start sending stream. How does an SRC knows a participant cannot send again ? What is stop-time in case of mixed stream? Should start/stop ( or rather participant participation in a MS ) be an attribute of participant rather than MS class ?

Metadata format: Unique ID format options Possible options: Ø A generic URN, with added constraint that equality is based only on lexical equivalence (as defined in rfc 2141) Ø UUID URN (rfc 4122) Ø UUID encoded more densely than the UUID URN. (e. g. radix 64 of the binary uuid form defined in 4122) – Based on the initial discussion on the mailer, there was an inclination for this approach. – How to represent radix in XML ? Use Big Endian notation ? Ø Can we go ahead with Option 3 ? Most folks favor this from the discussion in mailer. Any other alternatives ?

Metadata format: <recv> element Ø The current metadata draft says that when <recv> is not present, it is assumed that all participants receive a stream. Ø It has challenges to represent cases where a stream is not received by some participants of a CS [ e. g. whisper call, participants on hold during a call]. Ø A possible solution is to explicitly indicate <recv> element for each participant to give the list of streams received. Ø Any objections to go with above approach ? Any other better way to represent the relation of stream received/not-received to a participant ?

General Open items in metadata draft Ø Use of RFC 2119 language in the metadata model – Draft shall be modified to have normative language for the text related to XML schema and simple language for text related to Model. Any issues ? Ø Terminology usage in draft – Current draft has usage of block/element to indicate a metadata block (CS, CSGroup, Media Stream e. t. c). We will change it to “class” as per UML. So each block shall be called as metadata class and the linkages between them are “associations” or “composition”. – For XML schema we will retain the name “element” for each XML element (session, stream e. t. c).

Next steps Ø Close the remaining open items Ø Address the terminology, normative language issues with draft Ø Publish next version and ask for more review.