I'd like to propose a data model for metadata as viewed by the SRS.
(This is the result of discussions between Ram, Partha, and I.)

IMO we need a model such as this as part of the architecture.
Establishing such a model will help to nail down the implications of 
many of the requirements that have now been gathered. The model is 
conceptual - there is no requirement for the SRS to instantiate this in 
any literal way. And in fact for now there will be no way to verify if 
the SRS collects *anything* about the sessions it is recording. At some 
time in the future I expect that there will probably be work on some 
sort of query interface against the recording metadata. At that point it 
should become possible to verify that this information has indeed been 
captured.

For now, the purpose of this model is as a basis for evaluating 
mechanisms for transporting metadata from the SRC to the SRS: those 
mechanisms must provide the means to convey the information that the SRS 
MAY then use to populate an instance of this model for each RS.

This should probably have been submitted as a draft, but we didn't 
manage to get to that in time. So I'm taking the easy way out of sending 
it as a message to the list. (If it seems appropriate, we can probably 
have a document ready to submit with submissions are opened up again on 
the first day of the upcoming meeting.)

This model is a straw horse - I have no allusions that it is "right". I 
expect people to want to make at least tweaks, and perhaps major revisions.

I'm using UML notation here.

        +-------------------------------+
        | Recording Session Group       |
        +-------------------------------+
                 | 0..*
                 |
                 | 1..*
        +-------------------------------+
        | Recording Session (RS)        |
        +-------------------------------+
                 | 1..*
                 |
                 | 0..*
        +-------------------------------+
        |   Communication Session (CS)  |
        +-------------------------------+
                 | 1
                 |
                 | 0..*
        +-------------------------------+
        |   Recorded Media Stream       |
        +-------------------------------+
        |  Type (audio/video/...)       |
        |  Recorded Encoding            |
        |  Recorded Bits                |
        +-------------------------------+
                 | 1
                 |
                 | 1..*
        +-------------------------------+
        |   Received Media Stream       |
        +-------------------------------+
        |  Start Time                   |
        |  End Time                     |
        |  Codec                        |
        |  Media Stream Reference       |
        +-------------------------------+
                 | 1..*
                 |
                 | 1..*
        +-------------------------------+
        |   Participant                 |
        +-------------------------------+
        |  AoR                          |
        |  Name                         |
        +-------------------------------+


    The model described above provides:

    o  One or more CS per RS, due to private side conversations e.t.c
    o  Multiple RS per CS, due to redundancy or whatever
    o  An optional grouping of multiple RS that are related in some way
    o  Information that describes the participants of Communication
       Session(s)
    o  Information to associate multiple media streams sent for a given
       Communication Session over separate Recording Sessions to the SRS.
    o  Information to associate multiple media streams for a given
       Communication Session over a single Recording Session to the SRS.
    o  Information to associate participants and their associated media
       streams.
    o  Information about media type(mixed or separate), time for each
       media stream.
    o  Received Media Streams will have one participant unless mixed
       before being sent to RS, in which case they can have several.  A
       Participant can of course supply multiple Received Media Streams.
    o  There could be one Received Media Stream per Recorded Media Stream
       if mixing is done before recording, or several if a separate
       unmixed stream per participant is supplied.  Or there could be
       multiple per source (with disjoint time intervals) due to codec
       changes.
    o  Communication Session can have multiple Recorded Media Streams for
       various reasons.  Distinct media might have theiir own.  (Or not -
       maybe audio/video together.)  Independent sources might be
       recorded separately.

The "Media Stream Reference" attribute of a Received Media Stream is a 
place holder. In an implemented mechanism this would be a reference to a 
particular m-line in SDP from the SRC to the SRS, identifying a 
particular media stream. This is clearly essential to the SRS so that it 
might record the stream, and get properties of it. But it isn't anything 
interesting once the recording is complete. So its transient metadata.

The Recording Session Group has been added to model correlation between 
multiple RSs, but I think that concept requires a lot more work. Its far 
from clear to me how the need to associate one RS with another can be 
denoted. And if two RSs to be correlated are captured by different SRSs, 
they might end up in different databases, so even referencing them can 
be problematic. So consider this to be simply a place holder for further 
work.

	Thanks,
	Paul