Subject: Re: [siprec] Recording a conference

From: "Elwell, John" <[email-masked]>
Date: Fri, 1 Oct 2010 12:41:47 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> Sent: 30 September 2010 15:04
> 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.
> 
> 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.
[JRE] In addition, a given participant may not have visibility of all recordable information from the conference (e.g., sidebars in which that particular user is not participating, media that particular user is not involved in).

> 
> 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.
[JRE] Yes, I think they are both valid - we should not preclude either possibility - they achieve different aims.

> 
> 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.
[JRE] I do think a particular user (perhaps only the conference administrator) should be able to initiate and control recording from the conference focus. However, non-SIPREC means could be used for this, e.g., web page. I don't really see the necessity for a SIP-based approach (e.g., REFER).

John (as individual)

> 
> I certainly agree that metadata is not static.
> 
> Regards
> Andy
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> > Sent: 30 September 2010 09:56
> > To: Brian Rosen; Lorenzo Miniero
> > Cc: [email-masked]
> > Subject: Re: [siprec] Recording a conference
> > 
> > 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
> > 
> > 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
> > 
> > On Sep 29, 2010, at 2:00 AM, Lorenzo Miniero wrote:
> > 
> > > On Tue, 28 Sep 2010 22:00:49 -0400
> > > Paul Kyzivat <[email-masked]> wrote:
> > > 
> > >> 
> > >> 
> > >> On 9/28/2010 5:33 PM, Brian Rosen wrote:
> > >>> 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.
> > >> 
> > >> Does somebody really think it is static???
> > >> 
> > >> 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.
> > > 
> > > 
> > >> 	Thanks,
> > >> 	Paul
> > >> 
> > >>> Brian
> > >>> 
> > >>> On Sep 28, 2010, at 5:27 PM, Lorenzo Miniero wrote:
> > >>> 
> > >>>> On Tue, 28 Sep 2010 12:04:42 -0400
> > >>>> Brian Rosen<[email-masked]>  wrote:
> > >>>> 
> > >>>>> 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
> > >>>>> 
> > >>>>> _______________________________________________
> > >>>>> siprec mailing list
> > >>>>> [email-masked]
> > >>>>> https://www.ietf.org/mailman/listinfo/siprec
> > >>>> 
> > >>>> 
> > >>>> --
> > >>>> Lorenzo Miniero<[email-masked]>
> > >>> 
> > >>> _______________________________________________
> > >>> siprec mailing list
> > >>> [email-masked]
> > >>> https://www.ietf.org/mailman/listinfo/siprec
> > >>> 
> > >> _______________________________________________
> > >> siprec mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/siprec
> > > 
> > > 
> > > -- 
> > > Lorenzo Miniero <[email-masked]>
> > > _______________________________________________
> > > siprec mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/siprec
> > 
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> > 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 1 Oct 2010 08:54:23 -0400

I don't recall any discussion of SRC to SRS protocols that result in the SRS having the media streams and the necessary details, but I guess I had in my head that this was simple SIP.  If it is, then a REFER from SRC to the focus with an INVITE from the focus to the SRS to get into the conference rather than an INVITE that creates media flow between SRC and SRS is a pretty easy extension.

If we are anticipating some new protocol that establishes a media session between SRC and SRS, then having the addition of generating a REFER and resulting INVITE is more work.

However, I either way, I think we have to do it.

Brian

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 4 Oct 2010 12:17:24 +0530

Brian,

I guess that the same issue exists with B2BUA as well. For example

                          -------------SIP-------------   
                         |                             |
       UAC---SIP------B2BUA & SRC---SIP---UAS          SRS
        |                                  |            | 
         -------------------RTP------------------------- 

In the above topology, B2BUA & SRC co-exists in the same device but the
media is not terminated in B2BUA. This is very much applicable for
Enterprise and call center solutions where B2BUA is IP PBX or Contact
Center server. The following interfaces are outside the scope of SIPREC
for now:

1) Mechanism for UAC or UAS to request B2BUA for initiating the
recording session
2) B2BUA to request UAC or UAS to start the recording towards SRS for
media (RTP).

In case you and entire team thinks that these interfaces have to be
standardized, we will explore for the solution in general rather than
specific to conference. Please let me know your thought processing on
the same.

Thanks
Partha       

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Friday, October 01, 2010 6:24 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Recording a conference

I don't recall any discussion of SRC to SRS protocols that result in the
SRS having the media streams and the necessary details, but I guess I
had in my head that this was simple SIP.  If it is, then a REFER from
SRC to the focus with an INVITE from the focus to the SRS to get into
the conference rather than an INVITE that creates media flow between SRC
and SRS is a pretty easy extension.

If we are anticipating some new protocol that establishes a media
session between SRC and SRS, then having the addition of generating a
REFER and resulting INVITE is more work.

Brian

On Oct 1, 2010, at 6:41 AM, Elwell, John wrote:

>> 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.
> [JRE] In addition, a given participant may not have visibility of all
recordable information from the conference (e.g., sidebars in which that
particular user is not participating, media that particular user is not
involved in).
> 
>> 
>> 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.
> [JRE] Yes, I think they are both valid - we should not preclude either
possibility - they achieve different aims.
> 
> 
>> 
>> 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.
> [JRE] I do think a particular user (perhaps only the conference
administrator) should be able to initiate and control recording from the
conference focus. However, non-SIPREC means could be used for this,
e.g., web page. I don't really see the necessity for a SIP-based
approach (e.g., REFER).
>>> participants added, dropping out) in a call that is being recorded 
>>> there will likely be a change to the accumulated metadata as well.
>>> 

>>> 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
>>> 
>>> [mailto:[email-masked]] On Behalf Of Brian Rosen
>>> 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
>>> 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
>>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 4 Oct 2010 08:49:19 -0400

Generally, I don't think we should document how a B2BUA works here, primarily because I can't see trying to make interoperable B2BUAs for this.  We know they will be used, but they should look like an SRC to us.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 4 Oct 2010 08:36:10 -0400

Brian

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 4 Oct 2010 15:05:58 +0200

See below.

Regards
Andy 

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: 01 October 2010 13:54
> To: Elwell, John
> Cc: Hutton, Andrew; Ram Mohan R (rmohanr); Lorenzo Miniero; 
> [email-masked]
> I don't recall any discussion of SRC to SRS protocols that 
> result in the SRS having the media streams and the necessary 
> details, but I guess I had in my head that this was simple 
> SIP.  If it is, then a REFER from SRC to the focus with an 
> INVITE from the focus to the SRS to get into the conference 
> rather than an INVITE that creates media flow between SRC and 
> SRS is a pretty easy extension.

The architecture the we have proposed so far clearly makes the SRC the source of the media and the SRS the sink. It  is I believe envisaged that there will/could be extension to SIP/SDP on this interface including possible SDP extensions to meet the following requirement.

REQ-014 The mechanism MUST support the ability to deliver multiple
   media streams for a given Communication Session over a single
   Recording Session to the SRS

This is likely to require SDP extensions to handle for example multiple audio streams and link them to metadata for identification. I see possible synergies with the telepresence work in this area and I agree we have not discussed mechanism in detail so far. However the result could be that the SRC/SRS interface is not just "simple SIP".

I think we should therefore keep the architecture clean by keeping the definition that the SRC is the source of the media. Therefore in the case of the conference if the focus is to provide the media to the SRS then the focus must also be an SRC.

> 
> If we are anticipating some new protocol that establishes a 
> media session between SRC and SRS, then having the addition 
> of generating a REFER and resulting INVITE is more work.
> 
> > [JRE] In addition, a given participant may not have 
> visibility of all recordable information from the conference 
> (e.g., sidebars in which that particular user is not 
> participating, media that particular user is not involved in).
> > 
> >> 
> > [JRE] Yes, I think they are both valid - we should not 
> preclude either possibility - they achieve different aims.
> > 
> > 
> >> 
> > [JRE] I do think a particular user (perhaps only the 
> conference administrator) should be able to initiate and 
> control recording from the conference focus. However, 
> non-SIPREC means could be used for this, e.g., web page. I 
> don't really see the necessity for a SIP-based approach (e.g., REFER).
> > 
> > John (as individual)
> > 
> > 
> >>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 4 Oct 2010 09:38:12 -0400

Not sure I buy that, but I'll go with whatever consensus arises on this.

What I think you are proposing is that recording conferences is different from recording simpler sessions, and I think that is a mistake.  Something as simple as having the SRS accept an INVITE from the conference bridge instead of the SRC, when the SRC tells it to allow that, seems really simple.  Then the SRC has to arrange for the bridge to do that.

Brian

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 4 Oct 2010 15:46:05 +0200

Hi Brian,

I thought I was arguing for handling conferences the same as simpler sessions so we seem to have some kind of misunderstanding.

Of course a conference participant can REFER the bridge to the SRS which can then record the conference the question I have then is who is the SRC is it the bridge or is it the participant who issues the REFER. In my mind it is the bridge that is now the SRC and if it understands SIPREC and knows it is talking to an SRS it can provide metadata etc.  

Regards
Andy

> Sent: 04 October 2010 14:38
> To: Hutton, Andrew
> Cc: Elwell, John; Ram Mohan R (rmohanr); Lorenzo Miniero; 
> [email-masked]
> What I think you are proposing is that recording conferences 
> is different from recording simpler sessions, and I think 
> that is a mistake.  Something as simple as having the SRS 
> accept an INVITE from the conference bridge instead of the 
> SRC, when the SRC tells it to allow that, seems really 
> simple.  Then the SRC has to arrange for the bridge to do that.
> 
> Brian
> 
> > The architecture the we have proposed so far clearly makes 
> the SRC the source of the media and the SRS the sink. It  is 
> I believe envisaged that there will/could be extension to 
> SIP/SDP on this interface including possible SDP extensions 
> to meet the following requirement.
> > 
> > This is likely to require SDP extensions to handle for 
> example multiple audio streams and link them to metadata for 
> identification. I see possible synergies with the 
> telepresence work in this area and I agree we have not 
> discussed mechanism in detail so far. However the result 
> could be that the SRC/SRS interface is not just "simple SIP".
> > 
> > I think we should therefore keep the architecture clean by 
> keeping the definition that the SRC is the source of the 
> media. Therefore in the case of the conference if the focus 
> is to provide the media to the SRS then the focus must also be an SRC.
> > 
> > 
> >>

---

From: Leon Portman <[email-masked]>
Date: Mon, 4 Oct 2010 17:36:53 +0200

There is also a third option were B2BUA will insert itself or another Media Server into the media flow by updating SDPs for UAC and UAS (for example by using MEDIACTL).
And if I remember correctly, we decided that it is out of scope how SRC manages to initiate media forking. It is very  implementation specific.

Regards

Leon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Monday, October 04, 2010 8:47 AM
To: Brian Rosen; Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Recording a conference

Brian,

                          -------------SIP-------------   
                         |                             |
         -------------------RTP------------------------- 

Thanks
Partha       

-----Original Message-----

Brian

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 4 Oct 2010 21:31:37 +0530

Andy,
 
I have the same opinion as yours. REFER from participant to focus entity for starting the recording is outside the scope of SIPREC and in the same way, the mechanism by which UAC/UAS initiates the recording in B2BUA is outside the scope of SIPREC.
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Hutton, Andrew
Sent: Mon 10/4/2010 7:16 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [siprec] Recording a conference

Hi Brian,

Regards
Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Oct 2010 13:25:47 -0400

I am neutral on this. I understand Brian's point and agree it has merit. 
But its also an extra complication that will make it harder to get the 
work done. And I think it can be added at a later date.

	Thanks,
	Paul

On 10/4/2010 12:01 PM, Parthasarathi R (partr) wrote:
> Andy,
> I have the same opinion as yours. REFER from participant to focus entity
> for starting the recording is outside the scope of SIPREC and in the
> same way, the mechanism by which UAC/UAS initiates the recording in
> B2BUA is outside the scope of SIPREC.
> Thanks
> Partha
>
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Hutton, Andrew
> *Sent:* Mon 10/4/2010 7:16 PM
> *To:* Brian Rosen
> *Cc:* [email-masked]
> *Subject:* Re: [siprec] Recording a conference
>
> Hi Brian,
>
> I thought I was arguing for handling conferences the same as simpler
> sessions so we seem to have some kind of misunderstanding.
>
> Of course a conference participant can REFER the bridge to the SRS which
> can then record the conference the question I have then is who is the
> SRC is it the bridge or is it the participant who issues the REFER. In
> my mind it is the bridge that is now the SRC and if it understands
> SIPREC and knows it is talking to an SRS it can provide metadata etc.
>
> Regards
> Andy
>
>