Subject: [siprec] Consensus calls on requirements

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Dec 2010 08:31:33 +0100

In accordance with agreements at yesterday's interim virtual meeting, we intend to close tickets #59 and #60 by in each case adopting the proposed text changes.
http://trac.tools.ietf.org/wg/siprec/trac/ticket/59
http://trac.tools.ietf.org/wg/siprec/trac/ticket/60
If there are no objections, I will ask the editors to produce req-06 on Monday 2010-12-20, which will then be the basis for WGLC. The editors will also take the opportunity to renumber the requirements in sequence.

John

---

From: Leon Portman <[email-masked]>
Date: Mon, 20 Dec 2010 18:49:41 +0200

Andy, Hi

Thank you for the comments. 

Please see below. Adding siprec as well.

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Monday, December 20, 2010 10:55 AM
To: Elwell, John; Ken Rehor (krehor); Leon Portman; Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Hi All,

A couple of commens.

----

I am not sure we should have a definition for "SIPREC" the abbreviation is only used in one place.

"Both the signaling and media for the SIPREC needs the ability to be authenticated and protected from eavesdropping and non-repudiation".

In this context the word "SIPREC" could be replaced with "Recording Session" or "RS".

[Leon] Agree
-----

Is REQ-10 worded correctly? 

"REQ-010 The mechanism MUST support the ability to deliver multiple media streams for a given Communication Session over separate Recording Sessions to the SRS"

Does it really mean separate RS or is it meant to mean separate media streams within a single RS?

[Leon] yes, we have REQ-11 for single RS
-----

Regards
Andy

-----Original Message-----
From: Elwell, John 
Sent: 20 December 2010 07:35
To: Ken Rehor (krehor); Leon Portman; Hutton, Andrew; Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Ken,

Looks good. I would remove the sub-headings "SECURITY", "AUTHENTICATION", "INTEGRITY" and "CONFIDENTIALITY" from the list of requirements, since we don't have sub-headings for all the earlier requirements. Also please attend to Leon's comments, as qualified by my response to Leon.

I saw no objection to the consensus call, so please go ahead and publish -06 today, having made the suggested changes.

Thanks,

John

> -----Original Message-----
> From: Ken Rehor (krehor) [mailto:[email-masked]] 
> Sent: 17 December 2010 20:58
> To: Elwell, John; Leon Portman; Hutton, Andrew; Jain, Rajnish
> Subject: RE: [siprec] Consensus calls on requirements
> 
> Updated -06 and change list. Can you review and let me know if this is
> OK to post?
> 
> Thanks,
> 
> Ken
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > Elwell, John
> > Sent: Thursday, December 16, 2010 11:32 PM
> > To: [email-masked]
> > Subject: [siprec] Consensus calls on requirements
> > 
> > In accordance with agreements at yesterday's interim 
> virtual meeting,
> we
> > intend to close tickets #59 and #60 by in each case adopting the
> proposed
> > text changes.
> > If there are no objections, I will ask the editors to produce req-06
> on
> > Monday 2010-12-20, which will then be the basis for WGLC. 
> The editors
> will
> > also take the opportunity to renumber the requirements in sequence.
> > 
> > John
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Dec 2010 18:23:40 +0100

Hi Leon,

Regarding REQ-010 which states "The mechanism MUST support the ability to deliver multiple media streams for a given Communication Session over separate Recording Sessions to the SRS",

Does this really mean that we MUST define a mechanism to allow a single SRC to create multiple RS's each containing part of the media from the CS ?  If so can you give me an example use case for this ?

I don't have a strong objection to the requirement although I think it might make the metadata delivery more complex if the metadata is delivered with the RS dialog of which due to this requirement there might be multiple. However I am not sure why it is needed.

Regards
Andy

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: 20 December 2010 16:50
To: Hutton, Andrew; Elwell, John; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: RE: [siprec] Consensus calls on requirements

Andy, Hi

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Monday, December 20, 2010 10:55 AM
To: Elwell, John; Ken Rehor (krehor); Leon Portman; Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Hi All,

A couple of commens.

----

[Leon] Agree
-----

Regards
Andy

-----Original Message-----
From: Elwell, John 
Sent: 20 December 2010 07:35
To: Ken Rehor (krehor); Leon Portman; Hutton, Andrew; Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Ken,

Thanks,

John

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Tue, 21 Dec 2010 12:42:34 -0800

Before I post this, I'd like a final review,  particularly the change to
the Contributors/Acknowldgements section.

Ken

---

From: Leon Portman <[email-masked]>
Date: Tue, 21 Dec 2010 22:52:34 +0200

Andy, Hi

The origin of this requirement come from current limitations of communications system where not every components supports multiple m-lines with the same media type. So we have two modes of operation (REQ-10 and 11). There obvious drawbacks of REQ-10 however the question is do we want to apply such strong limitations on the implementations options (single vs multiple RS per CS).

I agree that it will create a mess with metadata reporting 

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Tuesday, December 21, 2010 7:24 PM
To: Leon Portman; Elwell, John; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: RE: [siprec] Consensus calls on requirements

Hi Leon,

Regards
Andy

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: 20 December 2010 16:50
To: Hutton, Andrew; Elwell, John; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: RE: [siprec] Consensus calls on requirements

Andy, Hi

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Monday, December 20, 2010 10:55 AM
To: Elwell, John; Ken Rehor (krehor); Leon Portman; Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Hi All,

A couple of commens.

----

[Leon] Agree
-----

Regards
Andy

-----Original Message-----
From: Elwell, John 
Sent: 20 December 2010 07:35
To: Ken Rehor (krehor); Leon Portman; Hutton, Andrew; Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Ken,

Thanks,

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Dec 2010 21:56:03 +0100

Leon,

If that is indeed the only motivation, I would suggest it be something to be considered during the protocol work, rather than a requirement. Would this mean we could delete REQ-010?

John (as individual)

> Sent: 21 December 2010 20:53
> The origin of this requirement come from current limitations 
> of communications system where not every components supports 
> multiple m-lines with the same media type. So we have two 
> modes of operation (REQ-10 and 11). There obvious drawbacks 
> of REQ-10 however the question is do we want to apply such 
> strong limitations on the implementations options (single vs 
> multiple RS per CS).
> 
> Regarding REQ-010 which states "The mechanism MUST support 
> the ability to deliver multiple media streams for a given 
> Communication Session over separate Recording Sessions to the SRS",
> 
> Does this really mean that we MUST define a mechanism to 
> allow a single SRC to create multiple RS's each containing 
> part of the media from the CS ?  If so can you give me an 
> example use case for this ?
> 
> I don't have a strong objection to the requirement although I 
> think it might make the metadata delivery more complex if the 
> metadata is delivered with the RS dialog of which due to this 
> requirement there might be multiple. However I am not sure 
> why it is needed.
> 
> Regards
> Andy
> 
>  
> 
> "Both the signaling and media for the SIPREC needs the 
> ability to be authenticated and protected from eavesdropping 
> and non-repudiation".
> 
> "REQ-010 The mechanism MUST support the ability to deliver 
> multiple media streams for a given Communication Session over 
> separate Recording Sessions to the SRS"
> 
> Does it really mean separate RS or is it meant to mean 
> separate media streams within a single RS?
> 
> Looks good. I would remove the sub-headings "SECURITY", 
> "AUTHENTICATION", "INTEGRITY" and "CONFIDENTIALITY" from the 
> list of requirements, since we don't have sub-headings for 
> all the earlier requirements. Also please attend to Leon's 
> comments, as qualified by my response to Leon.
> 
> I saw no objection to the consensus call, so please go ahead 
> and publish -06 today, having made the suggested changes.
> 
> Thanks,
> 
> John
> 
>  
>

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 21 Dec 2010 15:58:59 -0500

Looks good.

Please consider the environment before printing this email.

From: Ken Rehor (krehor) [mailto:[email-masked]]
Sent: Tuesday, December 21, 2010 3:43 PM
To: Hutton, Andrew; Leon Portman; Elwell, John; Jain, Rajnish
Cc: [email-masked]
Subject: siprec -- -06 draft (final?)

Before I post this, I'd like a final review,  particularly the change to the Contributors/Acknowldgements section.

Ken

________________________________
DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Leon Portman <[email-masked]>
Date: Tue, 21 Dec 2010 22:59:37 +0200

Looking good.

Leon

From: Ken Rehor (krehor) [mailto:[email-masked]]
Sent: Tuesday, December 21, 2010 10:43 PM
To: Hutton, Andrew; Leon Portman; Elwell, John; Jain, Rajnish
Cc: [email-masked]
Subject: siprec -- -06 draft (final?)

Ken

---

From: Leon Portman <[email-masked]>
Date: Tue, 21 Dec 2010 23:03:47 +0200

I tend to agree.

Ken, any comments? 

The main question is if we will not have such specific requirement (support for separate RS per participant), if it is still be possible to specify in the protocol and metadata drafts how to handle such configuration as well? Because a large percentage of current implementations are separate RSs today.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, December 21, 2010 10:56 PM
To: Leon Portman; Hutton, Andrew; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

Leon,

John (as individual)

---

From: "Dave Smith" <[email-masked]>
Date: Tue, 21 Dec 2010 13:36:12 -0800

I don't think we could remove REQ-010 (separate RS) and yet keep REQ-011
(single RS).  Probably we need both...i thought it guides the protocol
design.  

Notice that there are also the REQs for Mixed Streams.  

As I recall these req's were supporting the different needs we
identified.  

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Tuesday, December 21, 2010 1:04 PM
To: Elwell, John; Hutton, Andrew; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

I tend to agree.

Ken, any comments? 

The main question is if we will not have such specific requirement
(support for separate RS per participant), if it is still be possible to
specify in the protocol and metadata drafts how to handle such
configuration as well? Because a large percentage of current
implementations are separate RSs today.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Tuesday, December 21, 2010 10:56 PM
To: Leon Portman; Hutton, Andrew; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

Leon,

If that is indeed the only motivation, I would suggest it be something
to be considered during the protocol work, rather than a requirement.
Would this mean we could delete REQ-010?

John (as individual)

-------------------------------------------------------------------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Dec 2010 17:00:34 -0500

IIUC, regardless of *this* discussion, there is a requirement to support 
multiple SRCs in the same CS, each with an RS.

ISTM that what you are describing here is simply a degenerate case of 
that, where there is a single SRC with multiple RSs for the same CS.

	Thanks,
	Paul

---

From: "Dave Smith" <[email-masked]>
Date: Tue, 21 Dec 2010 14:38:21 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Tuesday, December 21, 2010 2:01 PM
To: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

IIUC[DS] ? It is UnClear ? , regardless of *this* discussion, there is a
requirement to support 

multiple SRCs in the same CS, each with an RS.[DS] Which REQ is that...i
don't see that...?      Or is this something new?  If so, not so sure we
need that...we already have a req't to "NOT prevent high availability
deployments."    

that, where there is a single SRC with multiple RSs for the same CS.
[DS] We are not specifying Single SRC or Multiple SRC in REQ-010.  We
didn't think we needed to do that.  

            Thanks,

            Paul

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John

>> I am not sure we should have a definition for "SIPREC" the

>> abbreviation is only used in one place.

>> In this context the word "SIPREC" could be replaced with

>> "Recording Session" or "RS".

>>> Updated -06 and change list. Can you review and let me know

>> if this is

>>>> If there are no objections, I will ask the editors to

>> produce req-06

>>>> also take the opportunity to renumber the requirements in

>> sequence.

siprec mailing list

[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Dec 2010 18:41:42 -0500

On 12/21/2010 5:38 PM, Dave Smith wrote:
> IIUC[DS] ? It is UnClear ? ,

IIIUC = If I Understood Correctly

  regardless of *this* discussion, there is a
> don't see that…? Or is this something new? If so, not so sure we need
> that…we already have a req’t to “NOT prevent high availability
> deployments.”

Well, it was my understanding that was an important use case.
Such as when two parties in the same call are both SRCs.
For instance this could happen when a supervisor joins a session between 
customer and agent if the agent and superviser both have their own SRC.

> didn’t think we needed to do that.

Having a *single* SRC set up multiple RSs for the same CS is new to me 
and seemed to be what led John to propose dropping this.

But if there is no need to support multiple RS contributing metadata to 
the same CS, CS group, etc. then it may make the mechanism much simpler.

	Thanks,
	Paul

>  > If that is indeed the only motivation, I would suggest it be
> something to be considered during the protocol work, rather than a
> requirement. Would this mean we could delete REQ-010?
>
>  >
>
>  > John (as individual)
>
>  >
>
>  >
>
> 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: "Dave Smith" <[email-masked]>
Date: Tue, 21 Dec 2010 16:26:26 -0800

Some further inputs ( [DS2] ) below.

Regards,
Dave

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, December 21, 2010 3:42 PM
To: Dave Smith
Cc: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

> From: [email-masked] [mailto:[email-masked]] On
Behalf

> don't see that...? Or is this something new? If so, not so sure we
need
> that...we already have a req't to "NOT prevent high availability
> deployments."

customer and agent if the agent and superviser both have their own
SRC.[DS2]  I believe that this use case could still be supported using
the existing REQ's (that is, no more REQ's are needed).  

Having a *single* SRC set up multiple RSs for the same CS is new to me 
and seemed to be what led John to propose dropping this.[DS2]  This is
certainly a valid case.  

But if there is no need to support multiple RS contributing metadata to 
the same CS, CS group, etc. then it may make the mechanism much
simpler.[DS2]  For Media, I don't think we need a specific REQ for that;
although it could be done/deployed that way.  For Metadata, I believe
delivery of metadata in RS was Leon's idea/concern/addition.  I don't
see any REQ's that capture that idea or Use Cases in the REQ
Doc...although they are really not needed there.  I vaguely remember
that this was part of the MetaData Doc discussion, so probably we need
Leon to comment on the need for this.      

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 22 Dec 2010 10:11:17 +0200

Dave, Hi

I want to comment regarding delivery of metadata in the RS. We used to have in previous iterations specific requirements regarding metadata delivery and configuration however it was agreed that it is more solution related and not requirements. From the solution point of view, it makes a sense to have both modes of  operation: metadata inside RS where possible in order to simplify the solution and outside RS as dedicated SUBSCRIBE session. Our first priority for the first phase is to focus on the first one. It is also applies for SRS initiated recording mode that was postponed for later phases.

I agree that REQ-10 is not related exactly to multiple SRC scenarios.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Smith
Sent: Wednesday, December 22, 2010 2:26 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

Regards,
Dave

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, December 21, 2010 3:42 PM
To: Dave Smith
Cc: [email-masked]
Subject: Re: [siprec] Consensus calls on requirements

Behalf

need

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 22 Dec 2010 10:29:57 +0100

>From the responses I have seen the reason for REQ-10 is that it is how many implementations work today and the reason they do that is because of the problem of specifying multiple m-lines for a single media type in SDP. 

I believe we intend to fix the problem of multiple m-lines for media recording in SIPREC so I don't see why we need REQ-10. 

Regards
Andy

-----Original Message-----
From: Dave Smith [mailto:[email-masked]] 
Sent: 21 December 2010 21:36
To: Leon Portman; Elwell, John; Hutton, Andrew; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: RE: [siprec] Consensus calls on requirements

Regards,
Dave

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

I tend to agree.

Ken, any comments? 

Leon

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

Leon,

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Wed, 22 Dec 2010 12:08:08 +0200

I believe it also some additional limitations on media side but let's give a chance for potential SRC vendors to response.
>From SRS point of view, we prefer single RS.

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2010 11:30 AM
To: Dave Smith; [email-masked]; Leon Portman; Elwell, John; Ken Rehor (krehor); Jain, Rajnish
Subject: RE: [siprec] Consensus calls on requirements

Regards
Andy

-----Original Message-----
From: Dave Smith [mailto:[email-masked]] 
Sent: 21 December 2010 21:36
To: Leon Portman; Elwell, John; Hutton, Andrew; Ken Rehor (krehor); Jain, Rajnish
Cc: [email-masked]
Subject: RE: [siprec] Consensus calls on requirements

Regards,
Dave

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

I tend to agree.

Ken, any comments? 

Leon

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

Leon,

John (as individual)