Subject: [siprec] RS Group / Recording Object issue from interim meeting

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 9 May 2011 16:10:48 -0700

I am attempting to summarize the discussion we had around this issue,
and provide what I understood to be the accepted proposal. First, let me
settle on a single term. The term RS Group will be used to mean a
collection of RS elements that comprise a single recording. For example,
RS1 and RS2 may be two independent sessions that together form a single
recording. In such a case, the media streams associated with RS1 and RS2
are combined into a single recording.

Question1: Do we need an RS Group element within the metadata model?
Question2: If the answer to Q1 is no, do we need an RS element in the
metadata model?

Use Cases:
t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with
UA1 or UA2 or may be somewhere in between, decides to record CS1
t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new
recording.
t2: At some point in time, RS1 is terminated for whatever reason (e.g.
network issue, SRS failure, etc.)
t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the
recording.

Option1 (using new RS Group element):
If there was a metadata element for an RS Group, RSG1, it could have
been created containing RS1 at time t1, then referenced at time t3 to
cause RS2 to be added to RSG1 rather than creating RSG2.

Option2 (using globally unique CS ID):
Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the
same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1
that is being recorded. Since CS1 is globally unique, SRS1 could
recognize this as being an attempt to continue the same recording. 

If SRC1 instead prefers to have two separate recordings, SRC1 could
indicate in RS1 that it is CS1 that is being recorded, and in RS2
indicate that it is CS2 that is being recorded. CS1 and CS2 may contain
the same actual media, but by using different globally unique IDs within
each RS, SRC1 can force them to be two independent recordings.

In this case, there is no need for an RS Group element, nor is there a
need for an RS element.

I previously favored Option1. Following the discussion up to and
including that in the interim meeting, I am okay with Option2.

Cheers,
Charles

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 10 May 2011 11:00:48 +0530

To me it seems the unique CS ID should suffice to continue a (broken)
recording as well as correlate disparate recordings, so I am inclined to
option2.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Charles Eckel (eckelcu)
|Sent: Tuesday, May 10, 2011 4:41 AM
|To: [email-masked]
|Subject: [siprec] RS Group / Recording Object issue from interim
meeting
|
|I am attempting to summarize the discussion we had around this issue,
|and provide what I understood to be the accepted proposal. First, let
me
|settle on a single term. The term RS Group will be used to mean a
|collection of RS elements that comprise a single recording. For
example,
|RS1 and RS2 may be two independent sessions that together form a single
|recording. In such a case, the media streams associated with RS1 and
RS2
|are combined into a single recording.
|
|Question1: Do we need an RS Group element within the metadata model?
|Question2: If the answer to Q1 is no, do we need an RS element in the
|metadata model?
|
|Use Cases:
|t0: UA1 and UA2 establish CS1, and SRC1, which may be co-located with
|UA1 or UA2 or may be somewhere in between, decides to record CS1
|t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a new
|recording.
|t2: At some point in time, RS1 is terminated for whatever reason (e.g.
|network issue, SRS failure, etc.)
|t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing the
|recording.
|
|Option1 (using new RS Group element):
|If there was a metadata element for an RS Group, RSG1, it could have
|been created containing RS1 at time t1, then referenced at time t3 to
|cause RS2 to be added to RSG1 rather than creating RSG2.
|
|Option2 (using globally unique CS ID):
|Alternatively, if SRC1 wants RS1 and RS2 to be considered part of the
|same recording, SRC1 could indicate in both RS1 and RS2 that is it CS1
|that is being recorded. Since CS1 is globally unique, SRS1 could
|recognize this as being an attempt to continue the same recording.
|
|If SRC1 instead prefers to have two separate recordings, SRC1 could
|indicate in RS1 that it is CS1 that is being recorded, and in RS2
|indicate that it is CS2 that is being recorded. CS1 and CS2 may contain
|the same actual media, but by using different globally unique IDs
within
|each RS, SRC1 can force them to be two independent recordings.
|
|In this case, there is no need for an RS Group element, nor is there a
|need for an RS element.
|
|I previously favored Option1. Following the discussion up to and
|including that in the interim meeting, I am okay with Option2.
|
|Cheers,
|Charles
|
|
|
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 10 May 2011 11:49:48 +0530

As I mentioned in the meeting yesterday, CS Unique ID should suffice to
correlate disparate recordings and hence we don't need RS-Group element.
How SRC(s) share this CS Unique ID is something that is currently left
to implementers(out of scope).

so I favor Option2 

Regards,
Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Sent: Tuesday, May 10, 2011 4:41 AM
> To: [email-masked]
> Subject: [siprec] RS Group / Recording Object issue from interim
> meeting
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 10 May 2011 12:55:17 +0530

Charles,

Just adding to Ram mentioned, draft-jones-ipmc-session-id-01
Session-UUID or draft-kaplan-dispatch-session-id-03 Session-id or other
proprietary unique-id may be used in CS to make your proposed solution
work. IMO, it is outside the scope of SIPREC and I favor OPTION 2.

The reason for having RS element in the model is to show the model from
SRS perspective and in case of metadata format, SIP Message information
(Dialog-id, Date header) shall be re-used instead of having separate RS
specific XML elements.

Thanks
Partha   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ram Mohan R (rmohanr)
Sent: Tuesday, May 10, 2011 11:50 AM
To: Charles Eckel (eckelcu); [email-masked]
Subject: Re: [siprec] RS Group / Recording Object issue from interim
meeting

so I favor Option2 

Regards,
Ram

> and provide what I understood to be the accepted proposal. First, let 
> me settle on a single term. The term RS Group will be used to mean a 

> the same actual media, but by using different globally unique IDs 
> within each RS, SRC1 can force them to be two independent recordings.
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 10 May 2011 09:02:08 -0700

Hi Partha,

The problem for me was that I started thinking of the RS as being
equivalent to a recording. If we leave the RS in the model, it would be
good to clarify the distinction.

Cheers,
Charles 

> From: Parthasarathi R (partr)
> Sent: Tuesday, May 10, 2011 12:25 AM
> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [siprec] RS Group / Recording Object issue from interim
meeting
> Just adding to Ram mentioned, draft-jones-ipmc-session-id-01
Session-UUID or draft-kaplan-dispatch-
> session-id-03 Session-id or other proprietary unique-id may be used in
CS to make your proposed
> solution work. IMO, it is outside the scope of SIPREC and I favor
OPTION 2.
> 
> The reason for having RS element in the model is to show the model
from SRS perspective and in case of
> metadata format, SIP Message information (Dialog-id, Date header)
shall be re-used instead of having
> separate RS specific XML elements.
> 
> Thanks
> Partha
> 
Behalf Of Ram Mohan R (rmohanr)
meeting
> 
> As I mentioned in the meeting yesterday, CS Unique ID should suffice
to correlate disparate recordings
> and hence we don't need RS-Group element.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 10 May 2011 21:41:14 +0530

Hi Charles,

I agree with you to add the text which helps to distinct RS from
recording. 

Thanks
Partha 

-----Original Message-----
From: Charles Eckel (eckelcu) 
Sent: Tuesday, May 10, 2011 9:32 PM
To: Parthasarathi R (partr); Ram Mohan R (rmohanr); [email-masked]'
Subject: RE: [siprec] RS Group / Recording Object issue from interim
meeting

Hi Partha,

Cheers,
Charles 

> CS to make your proposed solution work. IMO, it is outside the scope
of SIPREC and I favor OPTION 2.
> from SRS perspective and in case of metadata format, SIP Message 
> information (Dialog-id, Date header) shall be re-used instead of
having separate RS specific XML elements.
> to correlate disparate recordings and hence we don't need RS-Group
element.
> > I am attempting to summarize the discussion we had around this 
> > issue, and provide what I understood to be the accepted proposal. 
> > First, let me settle on a single term. The term RS Group will be 
> > used to mean a collection of RS elements that comprise a single 
> > recording. For example,
> > Question2: If the answer to Q1 is no, do we need an RS element in 
> > the metadata model?
> >
> > Use Cases:
> > t1: SRC1 establishes RS1 toward SRS1 for the purpose of starting a 
> > new recording.
> > t3: SRC1 establishes RS2 toward SRS1 for the purpose of continuing 
> > the recording.
> >

> > been created containing RS1 at time t1, then referenced at time t3 
> > to cause RS2 to be added to RSG1 rather than creating RSG2.
> >
> > Alternatively, if SRC1 wants RS1 and RS2 to be considered part of 
> > the same recording, SRC1 could indicate in both RS1 and RS2 that is 
> > it CS1 that is being recorded. Since CS1 is globally unique, SRS1 
> > could recognize this as being an attempt to continue the same
recording.
> > In this case, there is no need for an RS Group element, nor is there

> > a need for an RS element.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 10 May 2011 18:37:29 +0200

This thread looks like it is heading in a direction that is acceptable to me. Keeping RS in the model should not necessarily imply that it has to be reflected in XML, if the SIP dialog itself is sufficient.

John (as individual) 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 10 May 2011 17:11
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); [email-masked]
> Subject: Re: [siprec] RS Group / Recording Object issue from 
> interim meeting
> 
> Hi Charles,
> 
> > > recording. In such a case, the media streams associated 
> with RS1 and
> > > RS2

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 10 May 2011 22:17:19 +0530

Hi John / Charles,

I will update the text in metadata model draft
(draft-ietf-siprec-metadata-00) in the next revision to reflect this.

Here is the text I suggest to be modified in Section 4.1 of draft.
Please comment on this and edit/refine the text:

Current text is 
"A Recording Session element represents one instance of a Recording
Session."

Proposed text is : 
"A Recording Session element represents the SIP session created between
an SRC and SRS for the purpose of recording a Communication Session. The
SIP RS dialog SHALL be mapped to this element and hence there is no need
for this element to be reflected in XML"

Regards,
Ram

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, May 10, 2011 10:07 PM
> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Ram Mohan R
> (rmohanr); [email-masked]
> This thread looks like it is heading in a direction that is acceptable
> to me. Keeping RS in the model should not necessarily imply that it
has
> to be reflected in XML, if the SIP dialog itself is sufficient.
> 
> John (as individual)
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 10 May 2011 10:39:25 -0700

The proposed text works better for me if you change both instances of
"the" to "a" to remain consistent with the many to many relationship of
CS to RS.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Tuesday, May 10, 2011 9:47 AM
> To: Elwell, John; Parthasarathi R (partr); Charles Eckel (eckelcu);
[email-masked]
meeting
> I will update the text in metadata model draft
(draft-ietf-siprec-metadata-00) in the next revision to
> reflect this.
Please comment on this and
> edit/refine the text:
Session."
> 
> Proposed text is :
> "A Recording Session element represents the SIP session created
between an SRC and SRS for the purpose
> of recording a Communication Session. The SIP RS dialog SHALL be
mapped to this element and hence
> there is no need for this element to be reflected in XML"
> 
> Regards,
> Ram
> 
has
> > > > > RS1 and RS2 may be two independent sessions that together form
a
> > > > single
> > > > > t0: UA1 and UA2 establish CS1, and SRC1, which may be
co-located
> > > > > with
> > > > > t2: At some point in time, RS1 is terminated for whatever
reason
> > > (e.g.
> > > > > indicate that it is CS2 that is being recorded. CS1 and CS2
may
> > > > contain

---

From: Leon Portman <[email-masked]>
Date: Tue, 10 May 2011 20:52:48 +0300

I agree with below. Just additional comment that the actual fact how recordings are stored in the file system; one file or multiple chunks are implementation details of SRS. What is important that SRS will have all relevant information (like unique CS ID) to be able to find, display and of course playback all relevant RS pieces

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Tuesday, May 10, 2011 8:39 PM
To: Ram Mohan R (rmohanr); Elwell, John; Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] RS Group / Recording Object issue from interim meeting

The proposed text works better for me if you change both instances of "the" to "a" to remain consistent with the many to many relationship of CS to RS.

Cheers,
Charles

[email-masked]
meeting
Session."
has
> > > equivalent to a recording. If we leave the RS in the model, it 
> > > would be good to clarify the distinction.
> > >
> > > Cheers,
> > > Charles
> > >
> > >
a
co-located
reason
may

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 11 May 2011 10:39:59 -0700

Agreed with below as well.

An additional comment is that we may want to point out that one or more
SRC may reference the same CS by referring to the same global unique ID.
How the SRC figure out the same reference to the CS belongs to an
external mechanism which is out of scope for this group.

Likewise for the CSG, and I see that in section 4.1.2 (the last
sentence) that indicates a CSG may only belong to a single SRC. We
should clarify that a CSG may be referenced by one or more SRCs as long
as they refer to the same unique identifier.

Henry

> Behalf Of Leon Portman
> Sent: Tuesday, May 10, 2011 1:53 PM
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Elwell, John;
> Parthasarathi R (partr); [email-masked]
> I agree with below. Just additional comment that the actual fact how
> recordings are stored in the file system; one file or multiple chunks
> are implementation details of SRS. What is important that SRS will
have
> all relevant information (like unique CS ID) to be able to find,
> display and of course playback all relevant RS pieces
> 
> Leon
> 
> > > > > > From: [email-masked] [mailto:siprec-
> [email-masked]]
> On
> > > > > > First, let me settle on a single term. The term RS Group
will
> be
> > > > > > Question2: If the answer to Q1 is no, do we need an RS
> element
> in
> > > > > > the metadata model?
> > > > > >
> > > > > > Use Cases:
> > > > > > Alternatively, if SRC1 wants RS1 and RS2 to be considered
> part
> of
> > > > > > indicate in RS1 that it is CS1 that is being recorded, and
in
> > > > > > the same actual media, but by using different globally
unique
> IDs

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 May 2011 09:27:00 +0200

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 10 May 2011 17:47
> To: Elwell, John; Parthasarathi R (partr); Charles Eckel 
> (eckelcu); [email-masked]
> Subject: RE: [siprec] RS Group / Recording Object issue from 
> interim meeting
> 
> Hi John / Charles,
> 
[JRE] This will do as a placeholder, but may need some attention later. For example, at present this is the sole mention of "XML" in the entire draft, although that will change when we integrate the format stuff in due course. Also we probably need a consistent strategy how we use RFC 2119 language in connection with the model. I will start a separate thread on that, however.

John (as individual)

> [mailto:[email-masked]] On
> > > > > RS1 and RS2 may be two independent sessions that 
> together form a
> > > > single
> > > > > t2: At some point in time, RS1 is terminated for 
> whatever reason
> > > (e.g.
> > > > > indicate that it is CS2 that is being recorded. CS1 
> and CS2 may
> > > > contain

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 16 May 2011 15:50:18 +0530

Henry,

Thanks for these comments. I will incorporate them in the next version
of the draft.

Ram

> From: Henry Lum [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2011 11:10 PM
> To: Leon Portman; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);
> Elwell, John; Parthasarathi R (partr); [email-masked]
(eckelcu);
> interim
> > interim
> > interim
> > > > > > CS to make your proposed solution work. IMO, it is outside
> the
> > > > scope
> > > > > > information (Dialog-id, Date header) shall be re-used
instead
> > > > > > > UA1 or UA2 or may be somewhere in between, decides to
> record
> > CS1
> > > > > > > it CS1 that is being recorded. Since CS1 is globally
> unique,
> > SRS1
> > > > > > > I previously favored Option1. Following the discussion up
> to
> > and
-----------------------------------------------------------------------
> --------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is
> authorized. Any liability arising from any party acting, or refraining
> from acting, on any information contained in this e-mail is hereby
> excluded. If you are not the intended recipient, please notify the
> sender immediately, destroy the original transmission and its
> attachments and do not disclose the contents to any other person, use
> it for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
> and/or its affiliated entities.
>