Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06

From: "Elwell, John" <[email-masked]>
Date: Mon, 17 Jan 2011 09:22:40 +0100

Forwarded on behalf of Dave Smith.

> -----Original Message-----
> From: Dave Smith [mailto:[email-masked]] 
> Sent: 16 January 2011 16:08
> To: Elwell, John
> Subject: FW: Inputs to draft-ietf-siprec-req-06
> 
> Hi John,
> 
> Can you please send this email out to the "[email-masked]" email
> address for me. 
> Our Genesys email server is failing to send emails out to that address
> again (in the  mean time I will try to get it fixed through our
> HelpDesk).
> 
> Thanks,
> Dave
> 
> 
> -----Original Message-----
> From: Dave Smith 
> Sent: Saturday, January 15, 2011 10:59 PM
> To: Elwell, John; [email-masked]
> Subject: Inputs to draft-ietf-siprec-req-06
> 
> Here are my inputs to the latest draft-ietf-siprec-req-06.  
> 
> 
> 1.  Recommend to change this:
>   o REQ-005 The mechanism MUST support the ability to record a CS
>    without an intentional loss of media (for example, 
> clipping media at
>    the beginning of the CS) and without impacting the quality 
> or timing
>    of the CS (for example, delaying the start of the CS while
>    preparation for recording takes place).  See Use Case 4 in 
> Section 5.
> 
> To this:
>   o REQ-005 The mechanism MUST support the ability to record a CS
>    without an unintentional loss of media (for example, clipping media
> at
>    the beginning of the CS) and without impacting the quality 
> or timing
>    of the CS (for example, delaying the start of the CS while
>    preparation for recording takes place).  
> 
> The use case is not referenced correctly and I don't see any reason to
> refer to it (doesn't provide much additional info).  Also corrected
> "intentional" to "unintentional."
> 
> 
> 2.  Recommend to change this:
>    o REQ-018 The mechanism MUST provide a means of indicating to the
>    participants involved in a CS that their session is being recorded.
> 
>    Examples include: inject tones into the CS from the SRC, play a
>    message at the beginning of a session, a visual indicator on a
>    display, etc.
> 
> To this:
>    o REQ-018 The mechanism MUST provide a means of indicating to the
>    participants involved in a CS that their session is currently being
> recorded.
> 
>    Examples include: inject tones into the CS from the SRC, a visual
> indicator on a display
> 
> Added word "currently" because this is about providing an ongoing
> indicator during the call.  Removed the "play a message...." part
> because playing a message at the beginning of a session is 
> not a method
> that would require a siprec protocol solution, it's n/a, it's 
> not about
> " an ongoing indicator."  
> 
> 
> 3.  Recommend to change this:
>    o REQ-013 The mechanism MUST provide the SRS with the means to
>    correlate RS media with CS participant media described in metadata.
> 
> To this:
>    o REQ-013 The mechanism MUST provide the SRS with the means to
>    correlate RS media with CS participant media.
> 
> This is recommended because I don't see the need for the part 
> that read
> "described in metadata" and because it is not clear what it meant.  
> 
> 
> 4.  Recommend to delete this Requirement:
>    o REQ-021 The mechanism MUST support means to relate Recording
>    Session(s) with Communication Session(s).
> 
> It is not needed since we have REQ-012 and REQ-013.  
> 
> 
> 
> Regards,
> Dave
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Elwell, John
> Sent: Wednesday, January 12, 2011 4:12 AM
> To: [email-masked]
> Subject: [siprec] Agenda requests plus reminder
> 
> Please let me have your agenda requests for the dual interim on
> 25th/26th.
> 
> Also, a reminder that WGLC on siprec-req is into its second week and I
> have not seen any responses yet. Even if you are happy with 
> it as is, a
> note to the list would be helpful.
> 
> John
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> 
> 					
> --------------------------------------------------------------
> ----------
> -------------------------------------------
> 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.
> 					
> 
> 					
> --------------------------------------------------------------
> -----------------------------------------------------
> 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: Mon, 17 Jan 2011 09:37:40 +0100

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 17 January 2011 08:23
> To: [email-masked]
> Subject: [siprec] FW: Inputs to draft-ietf-siprec-req-06
> 
[JRE] The word "intentional" came from me a few months ago. Perhaps it was the wrong word - I was trying to convey the fact that some mechanism might frequently lead to clipping - the loss of media is kind of built into the mechanism, so in that sense it would be "intentional". I don't think changing to "unintentional" is correct - we can't avoid unintentional loss of media, e.g., through packet loss. I guess what we are really trying to achieve is something like this: "The mechanism MUST support the ability to record a CS without loss of media while preparation for recording takes place."

> > that would require a siprec protocol solution, it's n/a, it's 
[JRE] The word "currently" was there, in my opinion, because playing a message to indicate that recording might take place at some stage during the CS is what frequently happens and is sufficient for regulatory purposes in some jurisdictions. I agree it would not require a SIPREC protocol solution. Let's see what others say.

John (as individual)

> may contain

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 17 Jan 2011 14:38:54 +0530

Please read inline 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Monday, January 17, 2011 2:08 PM
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06

> >    without an intentional loss of media (for example, clipping media

> > at
> >    the beginning of the CS) and without impacting the quality or 
> > timing
> >    the beginning of the CS) and without impacting the quality or 
> > timing
[JRE] The word "intentional" came from me a few months ago. Perhaps it
was the wrong word - I was trying to convey the fact that some mechanism
might frequently lead to clipping - the loss of media is kind of built
into the mechanism, so in that sense it would be "intentional". I don't
think changing to "unintentional" is correct - we can't avoid
unintentional loss of media, e.g., through packet loss. I guess what we
are really trying to achieve is something like this: "The mechanism MUST
support the ability to record a CS without loss of media while
preparation for recording takes place."

<Partha> IMO, without any loss of media may lead to inefficient system
in few deployment. For example, CS dialog is established whereas RS is
taking more time to establish due to network delay between SRC and SRS,
then it may be preferred in few deployment to loss some media instead of
delaying CS establishment and some other deployment may prefer to wait
for RS establishment. The current requirement wording indicates that CS
dialog establishment MUST be delayed for RS establishment. </Partha> 

> > because playing a message at the beginning of a session is not a 
> > method that would require a siprec protocol solution, it's n/a, it's

> > not about " an ongoing indicator."
[JRE] The word "currently" was there, in my opinion, because playing a
message to indicate that recording might take place at some stage during
the CS is what frequently happens and is sufficient for regulatory
purposes in some jurisdictions. I agree it would not require a SIPREC
protocol solution. Let's see what others say.
<Partha> I agree with John that playing a message meet some of the
Jurisdictions requirement. I like to hear from Dave whether any
jurisdiction mandates for "injection tone" or "visual display".
</Partha>

Thanks
Partha

John (as individual)

> > This is recommended because I don't see the need for the part that 
> > read "described in metadata" and because it is not clear what it 
> > meant.
> > 
> > 
> > have not seen any responses yet. Even if you are happy with it as 
> > is, a note to the list would be helpful.
> > 
> > John
> > 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.
> > 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: Mon, 17 Jan 2011 12:01:24 +0100

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 17 January 2011 09:09
> Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06
> 
> Please read inline 
> 
> clipping media
[JRE] No, I believe it was not intended to force the CS to be delayed. A mechanism that would meet this requirement without delaying CS establishment would be to keep an RS permanently established, even when there is no CS, so that it can immediately be used when a new CS starts. This was the persistent recording use case (4), which I believe some people felt was needed for some environments, and hence the desire to capture requirements that such environments have. Clearly we have failed to capture that requirements adequately - we need the right words.

John (as individual)

> information in

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 17 Jan 2011 20:04:43 +0530

John/David,

I'm fine with REQ-5 as long as the intention is to avoid initial
clipping in recording using persistent RS or similar SIPREC proposed
mechanism. Just, I'm trying to reword for this requirement:

 o REQ-005 The mechanism MUST support the ability to record a CS without
loss of media (for example, clipping media at the beginning of the CS)
due to RS recording preparation and also, without impacting the quality
or timing of the CS (for example, delaying the start of the CS while
preparation for recording session). See Use Case 4 in Section 4 for more
details. 

--- Removed: "intentional"
--- Added: "due to RS recording preparation and also"

Please let me know your opinion.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 4:31 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

> dialog establishment MUST be delayed for RS establishment. </Partha> 
[JRE] No, I believe it was not intended to force the CS to be delayed. A
mechanism that would meet this requirement without delaying CS
establishment would be to keep an RS permanently established, even when
there is no CS, so that it can immediately be used when a new CS starts.
This was the persistent recording use case (4), which I believe some
people felt was needed for some environments, and hence the desire to
capture requirements that such environments have. Clearly we have failed
to capture that requirements adequately - we need the right words.

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Tue, 18 Jan 2011 09:13:12 +0200

Looking good

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Monday, January 17, 2011 4:35 PM
To: Elwell, John; [email-masked]
Cc: Dave Smith
Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06

John/David,

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 4:31 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

John (as individual)

---

From: "Dave Smith" <[email-masked]>
Date: Fri, 21 Jan 2011 10:00:41 -0800

My follow-on inputs inline below ( [DS] ).

Regards,
Dave

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 11:13 PM
To: Parthasarathi R (partr); Elwell, John; [email-masked]
Cc: Dave Smith
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

Looking good

Leon

-----Original Message-----
Of Parthasarathi R (partr)

John/David,

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 4:31 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

John (as individual)

[DS]  
I agree with John's new wording, and that for this document we should
simplify and state:   o REQ-005 "The mechanism MUST support the ability
to record a CS without loss of RS media while preparation for recording
takes place."
Although in a future version we might want to consider this area
further.  
[DS]

> jurisdiction mandates for "injection tone" or "visual display".
[DS]  I believe that informing ahead of time (that is, to indicate that
recording might take place at some stage during the CS) has nothing to
do with SIPREC.  If that is a suitable solution for this req't then I
believe we should drop the req't entirely.  
However, I see two reasons for functionality indicating that recording
is "currently" going on.  And although I do not know of any regulations
requiring this functionality, I believe it is important.  The reasons
are:  In order to inform (1) agents, and/or (2) customers that a call is
"currently" being recorded.  
For many Customers, I believe that playing a message up-front via an IVR
(for example) to "inform" them that "a call may be recorded..." may not
be enough and that it would be desirable to also provide an ongoing
indicator if recording is actually occurring "currently."    Also, there
are many examples where companies/environments want to be able to inform
their Agents when a call is "currently being recorded".  [DS]  

> > > read "described in metadata" and because it is not clear what it 
 
[DS]  I recommend to drop the wording "described in metadata" in
REQ-013.   [DS]

> > > [DS]  I recommend to delete REQ-021.   [DS]
> > > 
> > > 
> > > Regards,
> > > Dave
> > > 

-------------------------------------------------------------------------------------------------------------------
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: Mon, 24 Jan 2011 08:57:51 +0100

OK with me.

John (as individual)

> From: Dave Smith [mailto:[email-masked]]
> Sent: 21 January 2011 18:01
> To: Leon Portman; Parthasarathi R (partr); Elwell, John;
> [email-masked]

---

From: Leon Portman <[email-masked]>
Date: Mon, 24 Jan 2011 12:27:10 +0200

Ok,

Thank you

Leon

-----Original Message-----
From: Dave Smith [mailto:[email-masked]] 
Sent: Friday, January 21, 2011 8:01 PM
To: Leon Portman; Parthasarathi R (partr); Elwell, John; [email-masked]
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

Regards,
Dave

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: Monday, January 17, 2011 11:13 PM
To: Parthasarathi R (partr); Elwell, John; [email-masked]
Cc: Dave Smith
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

Looking good

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Monday, January 17, 2011 4:35 PM
To: Elwell, John; [email-masked]
Cc: Dave Smith
Subject: Re: [siprec] Inputs to draft-ietf-siprec-req-06

John/David,

I'm fine with REQ-5 as long as the intention is to avoid initial clipping in recording using persistent RS or similar SIPREC proposed mechanism. Just, I'm trying to reword for this requirement:

 o REQ-005 The mechanism MUST support the ability to record a CS without loss of media (for example, clipping media at the beginning of the CS) due to RS recording preparation and also, without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparation for recording session). See Use Case 4 in Section 4 for more details. 

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Monday, January 17, 2011 4:31 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

> was the wrong word - I was trying to convey the fact that some 
> mechanism might frequently lead to clipping - the loss of media is 
> kind of built into the mechanism, so in that sense it would be 
> "intentional". I don't think changing to "unintentional" is correct - 
> we can't avoid unintentional loss of media, e.g., through packet loss. 
> I guess what we are really trying to achieve is something like this: 
> "The mechanism MUST support the ability to record a CS without loss of 
> media while preparation for recording takes place."
> 
> taking more time to establish due to network delay between SRC and 
> SRS, then it may be preferred in few deployment to loss some media 
> instead of delaying CS establishment and some other deployment may 
> prefer to wait for RS establishment. The current requirement wording 
> indicates that CS dialog establishment MUST be delayed for RS 
> establishment. </Partha>
[JRE] No, I believe it was not intended to force the CS to be delayed. A mechanism that would meet this requirement without delaying CS establishment would be to keep an RS permanently established, even when there is no CS, so that it can immediately be used when a new CS starts.
This was the persistent recording use case (4), which I believe some people felt was needed for some environments, and hence the desire to capture requirements that such environments have. Clearly we have failed to capture that requirements adequately - we need the right words.

John (as individual)

[DS]
I agree with John's new wording, and that for this document we should
simplify and state:   o REQ-005 "The mechanism MUST support the ability
to record a CS without loss of RS media while preparation for recording takes place."
Although in a future version we might want to consider this area further.  
[DS]

> message to indicate that recording might take place at some stage 
> during the CS is what frequently happens and is sufficient for 
> regulatory purposes in some jurisdictions. I agree it would not 
> require a SIPREC protocol solution. Let's see what others say.
[DS]  I believe that informing ahead of time (that is, to indicate that recording might take place at some stage during the CS) has nothing to do with SIPREC.  If that is a suitable solution for this req't then I believe we should drop the req't entirely.  
However, I see two reasons for functionality indicating that recording is "currently" going on.  And although I do not know of any regulations requiring this functionality, I believe it is important.  The reasons
are:  In order to inform (1) agents, and/or (2) customers that a call is "currently" being recorded.  
For many Customers, I believe that playing a message up-front via an IVR (for example) to "inform" them that "a call may be recorded..." may not be enough and that it would be desirable to also provide an ongoing
indicator if recording is actually occurring "currently."    Also, there
are many examples where companies/environments want to be able to inform their Agents when a call is "currently being recorded".  [DS]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 25 Jan 2011 11:22:16 +0530

+1 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, January 24, 2011 1:28 PM
To: Dave Smith; Leon Portman; Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Inputs to draft-ietf-siprec-req-06

OK with me.

John (as individual)

> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> without loss of media (for example, clipping media at the beginning of

> the CS) due to RS recording preparation and also, without impacting 
> the quality or timing of the CS (for example, delaying the start of 
> the CS while preparation for recording session). See Use Case 4 in 
> Section
> 4 for more
> details.
>
> kind of built
> > into the mechanism, so in that sense it would be "intentional". I 
> > don't think changing to "unintentional" is correct - we can't avoid 
> > unintentional loss of media, e.g., through packet loss. I guess what

> > we are really trying to achieve is something like this: "The 
> > mechanism MUST support the ability to record a CS without loss of 
> prefer to wait
> > for RS establishment. The current requirement wording indicates that

> > CS dialog establishment MUST be delayed for RS establishment.
> </Partha>
> [JRE] No, I believe it was not intended to force the CS to be delayed.

> A mechanism that would meet this requirement without delaying CS 
> establishment would be to keep an RS permanently established, even 
> when there is no CS, so that it can immediately be used when a new CS 
> starts.
> capture requirements that such environments have. Clearly we have 
> failed to capture that requirements adequately - we need the right 
> words.
>
> John (as individual)
>
> [DS]
> require a SIPREC
> [DS]  I believe that informing ahead of time (that is, to indicate 
> that recording might take place at some stage during the CS) has 
> nothing to do with SIPREC.  If that is a suitable solution for this 
> req't then I believe we should drop the req't entirely.

> is "currently" going on.  And although I do not know of any 
> regulations requiring this functionality, I believe it is important.  
> The reasons
> For many Customers, I believe that playing a message up-front via an 
> IVR (for example) to "inform" them that "a call may be recorded..." 
> may not be enough and that it would be desirable to also provide an 
> ongoing indicator if recording is actually occurring "currently."
> Also, there
> are many examples where companies/environments want to be able to 
> inform their Agents when a call is "currently being recorded".  [DS]
>
>
> > Thanks
> > Partha
> >
> > John (as individual)
> >
> > > >
> > > >

> 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.