Subject: [siprec] Recording a conference

From: Brian Rosen <[email-masked]>
Date: Tue, 28 Sep 2010 12:04:42 -0400

The normal way a conference is recorded is that the recorder is added as a participant in the conference.  For an xcon style conference, there is a great deal of control, and metadata, that is associated with a conference.  An important issue to be considered is that one participant's "view" of a conference may not be the entirety of the media in the conference, and recording a conference is much different from recording an individual participant's "view" of a conference.

I would like to avoid having the equivalent of the SRC having to have entirely different mechanisms and capabilities when recording a conference from recording a simple session.  Of course it is always possible to have a participant act as an SRC and send its conference media to the SRS if it wanted to.

To make this work, the SRC has to instruct the SRS to join the conference, and the metadata has to include the xcon common data model.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 12:41:46 -0400

> To make this work, the SRC has to instruct the SRS to join the conference, and the metadata has to include the xcon common data model.

While I think this makes some sense, I'm concerned that it will require 
both the SRC and SRS to have two rather distinct modes of operation, 
which may make it more difficult to get people to implement them, and 
more difficult to test.

In its "normal" mode of operation, the SRS gets all its media streams 
via O/A with the SRC. And the SRC will be sending it metadata keyed to 
those streams.

In this "conference" mode, *something* will cause the SRS to be brought 
into a session with the focus. I guess this would either be the SRC 
instructing it (perhaps using REFER), or it might be an SRS initiated RS.

Alternatively, the SRC might *be* the focus, and treat the SRS as a 
"special" participant. But I don't think that is the case Brian is 
proposing.

In the "normal" mode, the SRC will be negotiating the streams to be sent 
to the SRS differently than a conference focus would construct the 
streams for a normal participant. It may well intentionally not mix 
them. And it will be sending metadata describing the streams it is offering.

In this new "conference" mode, presumably the focus will be treating the 
SRS as a "normal" participant. (But the SRS will probably indicate it is 
not sending any media, which will affect the mixing policies of the 
focus.) It will presumably indicate isFocus, but it won't know to use 
any siprec-specific mechanisms for sending metadata. The SRS might 
prefer to get the streams unmixed, but its not evident how that could be 
arranged.

Meanwhile, the SRC may still have a responsibility to send metadata 
about the RS, but will need somewhat different mechanisms to do so, and 
may have difficulty. Perhaps it could send *some* metadata with the 
REFER, about the conference as a whole, it won't have visibility to the 
RS, nor with the specific media streams between the focus and the SRS, 
so it will have difficulty saying anything further. And it likely will 
have trouble controlling the RS. For instance pausing and resuming could 
be difficult.

ISTM the most promising approachs are:
- the SRC is a participant in the conference, and maps all available
   conference info to media streams and metadata for the SRS. There
   should be appropriate metadata definitions for things available
   from conferences.

- the conference focus is an SRC. As such, it may alter its mixing
   policies toward the SRS, and may send siprec-specific metadata.
   It also indicates isFocus. The SRS can detect the isFocus and
   subscribe to conference-specific info which it captures as metadata.

I don't think these are mutually exclusive - they can coexist to be used 
when appropriate.

	Thanks,
	Paul

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 28 Sep 2010 23:27:29 +0200

On Tue, 28 Sep 2010 12:04:42 -0400

> To make this work, the SRC has to instruct the SRS to join the conference, and the metadata has to include the xcon common data model.

The conference object (data model instance) is not static in the lifetime of a conference, is the metadata going to include its changes as well (each event/related change) or are you envisaging a specific "picture" in time?

L.

> Brian
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

-- 
Lorenzo Miniero <[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 28 Sep 2010 17:33:59 -0400

I don't think metadata is always static, so I am thinking it may change over time.

I don't think that is specific to conferencing.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 22:00:49 -0400

> I don't think that is specific to conferencing.

Does somebody really think it is static???

All it takes is a transfer of one party in the CS to make it dyanmic.

	Thanks,
	Paul

>> Brian Rosen<[email-masked]>  wrote:
>>
>> Lorenzo Miniero<[email-masked]>
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 29 Sep 2010 08:00:10 +0200

On Tue, 28 Sep 2010 22:00:49 -0400

> All it takes is a transfer of one party in the CS to make it dyanmic.

I'm sorry, I haven't made myself clear: of course I don't think it's static, otherwise the xcon examples document I've contributed to would be two pages long. My question is related to the current proposal for siprec metadata, which is more a DB-like approach, including the list of all involved participants in the lifetime of a recorded session and related media with start-end times, how they relate to a specific session and so on: this approach is currently different from the data model one, which is more like a series of pictures of the conference, and this picture gets updated as a whole when something changes.

That's why I was wondering: is the siprec metadata going to capture all these xcon data model changes somehow? how should they be stored to be compliant with the current siprec metadata model? I guess that, if you don't save the conference object per se but a mapping with siprec is rather to be involved, not all the information and the updates will need to be captured.

L.

---

From: Leon Portman <[email-masked]>
Date: Wed, 29 Sep 2010 10:16:28 +0200

We had discussions in Maastaricht about that. From protocol point of view (data on the wire) SIPREC is supposed to define event based mechanism to report changes in metadata. From metadata model point of view, we are describing the final state that will be maintained and store for application usages by SRC. BTW our today implementation is using SMIL based format to represent the playlist for such usages.

Back to two mode of operations: today SRS is aware for example that for inbound/outbound calls it should use Sbc for example for recording and for internal calls to use some conference server. So it is ok from my point of view that SRS can directly integrate with xcon in case of centralized conference, however it is not common in today's enterprise environments except for web meetings that have different recording use cases.

Leon

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 29 Sep 2010 11:16:56 +0200

Hi,

when talking about metadata, I think that two ingredients are generally 
needed:

1- media-related information: e.g. audio/video stream format, image 
sequences for a shared presentation, edited text for a chat, 
descriptions of objects/shapes for a whiteboard, etc;
2- time-related information: e.g. start/end time for a stream, time 
instant associated to a slide change in a presentation, time associated 
with a sentence in a chat from a certain participant, time associated 
with a "drawing/annotation" action from a certain participant sharing a 
whiteboard, etc.

I guess that, while the first point can be looked after through some 
more or less "off-the-shelf" standard means (e.g. SIP/SDP signaling for 
audio and vdeo, XMPP for chat, etc.), the second definitely calls for an 
event-based approach aimed at recording timing and synchronization 
information. If you also use SMIL to represent playlists, I think you 
already had to face the above issue.

Cheers,
Simon

Il 29/09/2010 10.16, Leon Portman ha scritto:
> On Sep 29, 2010, at 8:00 AM, Lorenzo Miniero<[email-masked]>  wrote:
>
>    
>> Paul Kyzivat<[email-masked]>  wrote:
>>
>>      
>>>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 29 Sep 2010 11:56:30 +0200

Hi Leon,

thanks for the clarification, this is what I was trying to understand.

So, the data model updates could actually be mapped onto the
current siprec metadata (its final state), e.g. "the conference had
these participants (when they joined, when they left) and these media
(when they appeared, when they went away)". Of course this might imply
loosing some information, considering it would mean "flattening"
the richness of the data model on a less descriptive model: which is
not necessarily bad, if that's the only info that is considered
relevant.

Just to contribute to the discussion, another approach might be
extending the current siprec metadata model to include the whole
conferencing information, e.g.:

    1) a starting point (the conference object at the beginning), having
a 0..1 relation with the Communication Session (unless we want more
conferences to be recorded in the same session: sidebars?)

    2) all the updates (the changes on the conference object as they
would be notified to participants themselves) including info on when
they occurred, and having a 0..* relation with the related conference
object.

which I guess may be accomplished by making use of the opaque
application data as well.

Of course, this might be seen as too much information: if all that's
relevant are participants and media, just mapping is ok for me.

L.

On Wed, 29 Sep 2010 10:16:28 +0200

-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2010 08:43:18 -0400

OK, this is really one for me to answer. See inline.

> That's why I was wondering: is the siprec metadata going to capture all these xcon data model changes somehow? how should they be stored to be compliant with the current siprec metadata model? I gu…

Since the goal is to capture a *recording*, in the end the data will be 
static and complete. But it doesn't get there all at once. Every time 
there is a change in a call being recorded there will likely be a change 
to the accumulated metadata as well.

For the most part the changes will all be *additions*, since its still 
necessary to remember what happened previously. The exception is to the 
extent that we explicitly allow stuff to be removed.

So for instance if a new participant is added to a conference, there 
will be a new received media stream with the new participant attached. 
Its start time will indicate when the participant joined.

If the SRS has been receiving a mixed stream from the focus, then IMO 
the old received media stream that previously represented it will end, 
and a new received media stream will begin, with the added participant.

If the focus is sending unmixed media streams, one per participant, then 
there would just be a new one added.

At least that is how I imagined it working. Its certainly worthy of 
discussion.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 29 Sep 2010 08:44:06 -0400

Let's take a simple case:

3 parties are in a conference, one of them starts recording, then another one drops out, leaving two parties.

I would think the metadata has to record who dropped out when.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Sep 2010 14:38:12 -0500

At 07:44 AM 9/29/2010, Brian Rosen wrote:
>3 parties are in a conference, one of them starts recording, then 
>another one drops out, leaving two parties.
>

I think this is important info to retain as part of the overall 
recording (i.e., who joined when, and who dropped when), creating a 
timeline for the recording.

James

> > I'm sorry, I haven't made myself clear: of course I don't think 
> it's static, otherwise the xcon examples document I've contributed 
> to would be two pages long. My question is related to the current 
> proposal for siprec metadata, which is more a DB-like approach, 
> including the list of all involved participants in the lifetime of 
> a recorded session and related media with start-end times, how they 
> relate to a specific session and so on: this approach is currently 
> different from the data model one, which is more like a series of 
> pictures of the conference, and this picture gets updated as a 
> whole when something changes.
> >
> > That's why I was wondering: is the siprec metadata going to 
> capture all these xcon data model changes somehow? how should they 
> be stored to be compliant with the current siprec metadata model? I 
> guess that, if you don't save the conference object per se but a 
> mapping with siprec is rather to be involved, not all the 
> information and the updates will need to be captured.
> >
> > L.
> >
> >
> >>      Thanks,
> >>      Paul
> >>
> >>> Brian
> >>>
> >>>>> The normal way a conference is recorded is that the recorder 
> is added as a participant in the conference.  For an xcon style 
> conference, there is a great deal of control, and metadata, that is 
> associated with a conference.  An important issue to be considered 
> is that one participant's "view" of a conference may not be the 
> entirety of the media in the conference, and recording a conference 
> is much different from recording an individual participant's "view" 
> of a conference.
> >>>>>
> >>>>> I would like to avoid having the equivalent of the SRC having 
> to have entirely different mechanisms and capabilities when 
> recording a conference from recording a simple session.  Of course 
> it is always possible to have a participant act as an SRC and send 
> its conference media to the SRS if it wanted to.
> >>>>>
> >>>>> To make this work, the SRC has to instruct the SRS to join 
> the conference, and the metadata has to include the xcon common data model.
> >>>>>
> >>>>
> >>>>
> >>>> The conference object (data model instance) is not static in 
> the lifetime of a conference, is the metadata going to include its 
> changes as well (each event/related change) or are you envisaging a 
> specific "picture" in time?
> >>>>
> >>>> L.
> >>>>
> >>>>
> >>>>> Brian
> >>>>>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Sep 2010 10:54:30 +0200

Whilst most of this thread is to do with architecture and metadata, I think there is at least some impact on the requirements document, which currently doesn't explicitly mention conferences at all (although "parties" is mentioned in a couple of places, which could suggest the possibility of >2). I think in particular we need to capture requirements concerning recording the view of a single participant, versus recording the entire conference. I have raised ticket #43 on this. Please respond to that new mailing list thread.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: 28 September 2010 17:05
> To: [email-masked]
> Subject: [siprec] Recording a conference
> 
> is added as a participant in the conference.  For an xcon 
> style conference, there is a great deal of control, and 
> metadata, that is associated with a conference.  An important 
> issue to be considered is that one participant's "view" of a 
> conference may not be the entirety of the media in the 
> conference, and recording a conference is much different from 
> recording an individual participant's "view" of a conference.
> 
> recording a conference from recording a simple session.  Of 
> course it is always possible to have a participant act as an 
> SRC and send its conference media to the SRS if it wanted to.
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 30 Sep 2010 14:26:29 +0530

Hi Brian,

The metadata will have all information about the call. But it doesn't
get accumulated all at once. Every time there is a change (like
participants added, dropping out) in a call that is being recorded there
will likely be a change to the accumulated metadata as well.

Most of  the changes (including participants dropping out) will all be
*additions* to metadata, since it's still necessary to remember what
happened previously. 

So if a new participant is added to a conference, there will be a new
received media stream with the new participant attached. 
Its start time will indicate when the participant joined. If a
participant drops from conference the media stream corresponding to that
participant will be removed from the metadata sent from SRC to SRS. All
this information will be recorded in the accumulated metadata at SRS.

Regards,
Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Wednesday, September 29, 2010 6:14 PM
To: Lorenzo Miniero
Cc: [email-masked]
Subject: Re: [siprec] Recording a conference

Brian

On Sep 29, 2010, at 2:00 AM, Lorenzo Miniero wrote:

> I'm sorry, I haven't made myself clear: of course I don't think it's
static, otherwise the xcon examples document I've contributed to would
be two pages long. My question is related to the current proposal for
siprec metadata, which is more a DB-like approach, including the list of
all involved participants in the lifetime of a recorded session and
related media with start-end times, how they relate to a specific
session and so on: this approach is currently different from the data
model one, which is more like a series of pictures of the conference,
and this picture gets updated as a whole when something changes.
> 
> That's why I was wondering: is the siprec metadata going to capture
all these xcon data model changes somehow? how should they be stored to
be compliant with the current siprec metadata model? I guess that, if
you don't save the conference object per se but a mapping with siprec is
rather to be involved, not all the information and the updates will need
to be captured.
>>>>> The normal way a conference is recorded is that the recorder is
added as a participant in the conference.  For an xcon style conference,
there is a great deal of control, and metadata, that is associated with
a conference.  An important issue to be considered is that one
participant's "view" of a conference may not be the entirety of the
media in the conference, and recording a conference is much different
from recording an individual participant's "view" of a conference.
>>>>> 
>>>>> I would like to avoid having the equivalent of the SRC having to
have entirely different mechanisms and capabilities when recording a
conference from recording a simple session.  Of course it is always
possible to have a participant act as an SRC and send its conference
media to the SRS if it wanted to.
>>>>> 
>>>>> To make this work, the SRC has to instruct the SRS to join the
conference, and the metadata has to include the xcon common data model.
>>>>> 
>>>> 
>>>> 
>>>> The conference object (data model instance) is not static in the
lifetime of a conference, is the metadata going to include its changes
as well (each event/related change) or are you envisaging a specific
"picture" in time?

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 30 Sep 2010 16:03:55 +0200

Hi,

The SIPREC architecture as currently described in the architecture draft (draft-ietf-siprec-architecture-00) is such that the SRC is the source of the recorded media and metadata that is the definition of an SRC.

Therefore I see two mechanisms for recording a conference.

1. The SRC is a participant in a conference. In this case it is unlikely that the SRC will be able to provide the SRS with different media streams for each participant as it will be already mixed when the SRC receives the media. It may if it has access to for example the conference event package be able to provide information about the other participants in the conference within the recording metadata.

2. The SRC is co-located with the conference focus. In this case  the SRC can provide separate streams for each participant but it may not depending on it's capabilities. The SRC will be able to provide information about the conference participants in the recording metadata.

These two models are both valid and could co-exist maybe even for the same conference.

Within the current model I don't see the possibility of the SRC somehow instructing the SRS to join the conference  this would complicate the solution and I am not sure why it is necessary.

I certainly agree that metadata is not static.

Regards
Andy

> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 30 September 2010 09:56
> To: Brian Rosen; Lorenzo Miniero
> Cc: [email-masked]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 30 Sep 2010 22:46:10 +0530

Hi Andrew,
Please see inline <Ram>

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Thursday, September 30, 2010 7:34 PM
To: Ram Mohan R (rmohanr); Brian Rosen; Lorenzo Miniero
Cc: [email-masked]
Subject: RE: [siprec] Recording a conference

Hi,

The SIPREC architecture as currently described in the architecture draft
(draft-ietf-siprec-architecture-00) is such that the SRC is the source
of the recorded media and metadata that is the definition of an SRC.

1. The SRC is a participant in a conference. In this case it is unlikely
that the SRC will be able to provide the SRS with different media
streams for each participant as it will be already mixed when the SRC
receives the media. It may if it has access to for example the
conference event package be able to provide information about the other
participants in the conference within the recording metadata.

2. The SRC is co-located with the conference focus. In this case  the
SRC can provide separate streams for each participant but it may not
depending on it's capabilities. The SRC will be able to provide
information about the conference participants in the recording metadata.

These two models are both valid and could co-exist maybe even for the
same conference.

<Ram> I agree that these two model are valid. What kind of information
are we expecting the SRC to access from conference event package and
send to SRS as metadata ? Where should it be represented in Metadata
model ? Should it part of Application data or somewhere else ?

Within the current model I don't see the possibility of the SRC somehow
instructing the SRS to join the conference  this would complicate the
solution and I am not sure why it is necessary.

<Ram> I agree that SRC instructing SRS to join conference may not fit
well in to SIPREC solution. The very definition of RS will have to be
re-looked if SRS has to directly plug in to Conference as currently RS
is defined as a session setup from SRC to SRS.

Regards
Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Sep 2010 13:29:43 -0400

On 9/30/2010 1:16 PM, Ram Mohan R (rmohanr) wrote:
> Please see inline<Ram>

At the least, the roster of participants could be obtained and passed 
on. That would show up as specific metadata elements, not application 
data. Other stuff that is available this way should be seriously 
considered for adding to the model.

> is defined as a session setup from SRC to SRS.

Its a matter of requirements. If this is an important requirement that 
has just been discovered, then we may need to adjust the architecture to 
accommodate it. I'm not convinced one way or the other, though I'm 
inclined to omit this for now.

	Thanks,
	Paul