Transcript 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,

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..*
1..*
0..*
Communication
Session(CS)
Group
0..1
1..*
Communication Session(CS)
1.. *
2..*
1
1
1.. *
0..*
receives
0.. *
0.. *
Participant
1.. * 0..*
sends
Media
Stream
1
0..*
1
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
•AoR list
•Name
•Capability List
(or Parameter List)
1
0..*
Extension
Data
 Participant lifetime is within
the scope of CS or CSG ?
 Is Optional
associate/disassociate time
attribute needed?
–
–
0.. *
1.. *
receives
sends
0..*
0..*
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 AoR?
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
sends
0..*
0..*
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.
radix64 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.