Subject: Re: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

From: "Henry Lum" <[email-masked]>
Date: Mon, 1 Feb 2010 09:33:57 -0800

Hi Leon,

Thanks for the quick response, I have a few more follow ups marked
[hlum] below.

Regards,

Henry 

From: Leon Portman [mailto:[email-masked]] 
Sent: Sunday, January 31, 2010 6:03 AM
To: Henry Lum; [email-masked]
Cc: Dave Smith; [email-masked]
Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-00

Hi, Henry.

I will try to answer some of the questions. Please see below.

Leon

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: [email-masked]
Cc: Dave Smith; [email-masked]
Subject: [dispatch] Comments on
draft-rehor-dispatch-session-recording-req-00

Hi Ken,

I have a bunch of questions and comments on the requirements for SRP
requirements.

-          Section 3 - Recording Client - If the SRP requirement does
not mandate to use SIP as the actual recording protocol, why does the
recording client have to be a SIP user agent or B2BUA?

[LeonP] Actually there is a difference between Recorded session (the
actual call to be recorded) that can be not SIP based and Recording
Session (part of SRP) that is used for triggering recording and it is
SIP based. So both RC and RS are SIP UA.

[[hlum]] I now understand that the recorded session does not have to be
SIP based, but the wording in the definition of SRP itself mentions that
it may be SIP; then why does RC and RS have to be a SIP UA if SRP does
not have to be SIP?

-          Section 3 - Recorded session - Is a recorded session has to
be a SIP session?

[LeonP] No, my comment above

-          Section 3 - Persistent Recording - does recorded session
exist in this context since it seems like the recording session is
persistent from the endpoint perspective.

[LeonP] No, recorded session are not required to be existing during
initiation of persistent session. Persistent recording session can be
initiated on agent logon for example.

-          Section 4 - use case 5 - if the recording can include
recording for an IVR application (ie. VoiceXML application), does that
mean the call metadata must include application contexts as well?

[LeonP] Yes, like specific script or input results

[[hlum]] I assume what kind of call metadata and how it is delivered is
outside of the scope of this document?

-          Section 4, use case 7 - the first sentence has a strange word
"&mdash". This use case somehow implies certain architectural design for
a PBX with regards to media forking. Is that necessary from a
requirement perspective?

[LeonP] XML convert mistake. We don't want assume any specific
configurations.

-          Section 4, use case 8 - shall we use a more general
terminology such as multi-party call? Depending on the situation, the
supervisor may be conferenced with the agent and customer so the
recording session needs to define how a multi-party session should be
recorded.

[LeonP] Yes, probably we want to use more generic term then Complex Call

-          Section 4, use case 11, does a recorder "must" support some
sort of media processing such as real-time analytics? This is more of a
business application on the recording server side, which is independent
of the session recording protocol itself.

[LeonP] The main point there was that Recording Protocol must support
real time streaming for real time analytics

-          Section 6:

o   REQ-001 - what does full-time Recording session mean?

[LeonP] Record all calls

o   REQ-003 - it's unclear what is the target of the recording session
here since this not directly related to a single recorded session
(perhaps many)

[LeonP] To minimize media clipping associated with recording initiation

[[hlum]] You actually answered my question above about what a persistent
recording mean and why it's useful, but what is unclear to me that is
whether there is something called a persistent recording session that
targets something like an agent device.

o   REQ-006 - I mentioned above that IVR sessions may contain additional
IVR application metadata; should this requirement clarify that the
mechanism should include application metadata?

[LeonP] Yes, we should

o   REQ-007 - this wording of the requirement to me is pointing towards
a specific implementation of high-availability or fault-tolerance of a
recording session.

o   REQ-009 - the wording here is a bit unclear here. Do you mean the
recorded session represents a multi-party session where there are
multiple media streams from multiple recorded sessions, and the media
streams may be mixed by a conference mixer?

[LeonP]  It is more for trading floor environments where multiple
concurrent calls on the same device (turret) recorded together. It is
not related to summation for conference participants at the same call.

[[hlum]] I'm not familiar with trading floor environments so I may not
understand the intent here. If you have multiple concurrent calls then
wouldn't you have multiple recording sessions to describe each call
individually? Does the endpoint device perform mixing function for
multiple calls so that's why you need to club them together in a single
recording session?

o   REQ-013 - this is only one way of notifying the customer that the
call is being recorded but there are others. I think this requires a bit
more explanation of why this is needed. To me this looks like a
duplicate of REQ-022

o   REQ-015 - what does non-repudiation mean in this context? Isn't this
the same as REQ-017?

[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP
Session

o   REQ-021 - what happens with SRTP if recording client simply forks
the media? The recording server would not be able to decrypt the media
unless it gets the private keys from the recorded session.

[LeonP] It is out of scope of this document. 

o   REQ-028 - the wording redirected looks out of context here; the
requirement only applies when recording client initiates a recording
session to an available recorder server?

[LeonP] We want to support both directions

[[hlum]] Okay, then I think we should re-word to mention something about
availability in general.  (eg. "A request for a new recording session
must reach an available recording client or server").

o   REQ-029/030 - They look very generic and I don't think these should
be requirements for SRP, but rather a product requirement on how OA&M
works for the recording client/server.

Thanks

Henry

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: "Jain, Rajnish" <[email-masked]>
Date: Mon, 1 Feb 2010 18:28:23 -0500

Henry,

Thanks for your comments. Inline:

-        Section 3 - Recording Client - If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user agent or B2BUA?
[LeonP] Actually there is a difference between Recorded session (the actual call to be recorded) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP based. So both RC and RS are SIP UA.
[[hlum]] I now understand that the recorded session does not have to be SIP based, but the wording in the definition of SRP itself mentions that it may be SIP; then why does RC and RS have to be a SIP UA if SRP does not have to be SIP?

[rj] The SRP, which manages how the recording media gets delivered to the recorders, is based on SIP (SRP is a set of extensions to the SIP core protocol). The sessions that SRP manages are called "Recording Sessions" and they are SIP sessions. Therefore, RC and RS are, by definition, SIP UAs. The sessions that get actually recorded (e.g. communication between a call center agent and an external caller) may or may not be SIP (this depends on the kind of the PBX phone the agent).

-        Section 4 - use case 5 - if the recording can include recording for an IVR application (ie. VoiceXML application), does that mean the call metadata must include application contexts as well?
[LeonP] Yes, like specific script or input results
[[hlum]] I assume what kind of call metadata and how it is delivered is outside of the scope of this document?

[rj] Correct.

o   REQ-003 - it's unclear what is the target of the recording session here since this not directly related to a single recorded session (perhaps many)
[LeonP] To minimize media clipping associated with recording initiation
[[hlum]] You actually answered my question above about what a persistent recording mean and why it's useful, but what is unclear to me that is whether there is something called a persistent recording session that targets something like an agent device.

[rj] I guess, Persistent Recording is a bit confusing term (we've received other feedback on this as well). If I can use the term always-on recording from the wing-srtp draft then these sessions get established when the agent logs on and torn off when the agent logs off. Codecs such as G.729 and G.711 with VAD are used to ensure that silence is not recorded (for instance, when the agent isn't on a call).

o   REQ-009 - the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer?
[LeonP]  It is more for trading floor environments where multiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call.
[[hlum]] I'm not familiar with trading floor environments so I may not understand the intent here. If you have multiple concurrent calls then wouldn't you have multiple recording sessions to describe each call individually? Does the endpoint device perform mixing function for multiple calls so that's why you need to club them together in a single recording session?

[rj] Due to bandwidth and other cost burdens, the customer demand is that you mix multiple _recorded sessions_ in a single _recording session_.

o   REQ-028 - the wording redirected looks out of context here; the requirement only applies when recording client initiates a recording session to an available recorder server?
[LeonP] We want to support both directions
[[hlum]] Okay, then I think we should re-word to mention something about availability in general.  (eg. "A request for a new recording session must reach an available recording client or server").

[rj] The example test you quoted doesn't reflect the actual intent here. The reason for supporting both directions is dependent on where the policy to record or not resides - RC or RS. The INVITE always comes from either of these two places.

Thanks,
Raj Jain

________________________________
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, 2 Feb 2010 09:40:33 +0200

Dave, Hi

Thank you very much for the comments.

Please see below.

We can also discuss it on our call today.

Leon
From: Dave Smith [mailto:[email-masked]]
Sent: Tuesday, February 02, 2010 7:03 AM
To: [email-masked]
Cc: [email-masked]; Leon Portman; Henry Lum
Subject: RE: Comments on draft-rehor-dispatch-session-recording-req-00

Hi Leon, Henry,
I put together some inputs on top of yours for consideration as well....pls see my inputs below.

Regards,
Dave

Sent: Sunday, January 31, 2010 3:03 AM

Hi, Henry.

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Sunday, January 31, 2010 6:11 AM
To: [email-masked]
Cc: Dave Smith; [email-masked]
Subject: [dispatch] Comments on draft-rehor-dispatch-session-recording-req-00

Hi Ken,

I have a bunch of questions and comments on the requirements for SRP requirements.

-          Section 3 - Recording Client - If the SRP requirement does not mandate to use SIP as the actual recording protocol, why does the recording client have to be a SIP user agent or B2BUA?
[LeonP] Actually there is a difference between Recorded session (the actual call to be recorded[DS]  Is this just the voice - the RTP stream (the replicated voice stream that is sent to a Logger)?  ) that can be not SIP based and Recording Session (part of SRP) that is used for triggering recording and it is SIP based[DS] Is this the control messaging...for starting/stopping/pause/resume...the messaging (SIP) for set up of the replicated voice stream/RTP transfer? . So both RC and RS are SIP UA.
[LeonP] Yes, SRP is the control session for replicated media stream (any RTP type of media)

-          Section 3 - Recorded session - Is a recorded session has to be a SIP session?
[LeonP] No, my comment above[DS] I recommend better Terms and/or better definitions of the Terms "Recorded Session" and "Recording Session"in the Draft - is it possible to change one or both terms since they sound so similar.  That is, the IETF Draft definitions are not clear to me...and the difference between these is not clear (for example, do not use the terms themselves in the definitions...provide examples.  Recommend also to differentiate these from the Metadata messaging (if they are or could be different), and to define that as well (as rec'd by Martin).
[LeonP] Let's talk about it

-          Section 3 - Persistent Recording - does recorded session exist in this context since it seems like the recording session is persistent from the endpoint perspective.
[LeonP] No, recorded session are not required to be existing during initiation of persistent session. Persistent recording session can be initiated on agent logon for example.

-          Section 4, use case 7 - the first sentence has a strange word "&mdash". This use case somehow implies certain architectural design for a PBX with regards to media forking. Is that necessary from a requirement perspective?
[LeonP] XML convert mistake. We don't want assume any specific configurations.

-          Section 4, use case 8 - shall we use a more general terminology such as multi-party call? Depending on the situation, the supervisor may be conferenced with the agent and customer so the recording session needs to define how a multi-party session should be recorded.
[LeonP] Yes, probably we want to use more generic term then Complex Call[DS] The term "Multi-Party Call" seems to imply a call/interaction with more than two users...that is, a conference.  Recommend to keep "Complex Calls" terminology but define several different cases/examples - for example, Conferences (Henry's example), Consults (as in use case 8), also could include a Whisper Agent/Coaching example, Barge-In example, other...  Alternatively, change Use Case 8 to "Consult Call" and add additional use cases for these other complex call examples.

-          Section 4, use case 11, does a recorder "must" support some sort of media processing such as real-time analytics? This is more of a business application on the recording server side, which is independent of the session recording protocol itself.
[LeonP] The main point there was that Recording Protocol must support real time streaming for real time analytics[DS]  This Use Case reads like a requirement and should read more like an example of how it is used.
Is the ability to support "real-time" analytics dependent on the recording protocol?  Is there also a need separate streams for the two channels (what the agent said, what the agent heard) - And do we already have a req't for that.....i.e., req't 10 and/or req't 11?

-          Section 6:

o   REQ-001 - what does full-time Recording session mean?
[LeonP] Record all calls[DS] Recommend we explain that in the req't; also, is that by DN, or by Agent, or by Customer, other, or all of the above...?
[LeonP] Yes, the requirement is to initiate recording session not by call id but by some fixed identifier as above

o   REQ-006 - I mentioned above that IVR sessions may contain additional IVR application metadata; should this requirement clarify that the mechanism should include application metadata?
[LeonP] Yes, we should

o   REQ-007 - this wording of the requirement to me is pointing towards a specific implementation of high-availability or fault-tolerance of a recording session.

o   REQ-009 - the wording here is a bit unclear here. Do you mean the recorded session represents a multi-party session where there are multiple media streams from multiple recorded sessions, and the media streams may be mixed by a conference mixer?
[LeonP]  It is more for trading floor environments where multiple concurrent calls on the same device (turret) recorded together. It is not related to summation for conference participants at the same call.     [DS] Recommend to state this info in the req'ts and provide this example.

o   REQ-013 - this is only one way of notifying the customer that the call is being recorded but there are others. I think this requires a bit more explanation of why this is needed. To me this looks like a duplicate of REQ-022    [DS] Recommend to change this req't from "Must" to "May"

o   REQ-015 - what does non-repudiation mean in this context? Isn't this the same as REQ-017?
[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP Session [DS] Recommend to define "non-repudiation" and/or provide an example to avoid any confusion.

o   REQ-017 - [DS]  Why is non-repudiation of both the SRP and the Media needed?

o   Req - 022  - [DS]  Recommend to add "This MAY be performed by injecting tones into the Recorded Session either from the RS or from the RC."  (but could also be done by informing via speech script upon first answering call)

o   REQ-021 - what happens with SRTP if recording client simply forks the media? The recording server would not be able to decrypt the media unless it gets the private keys from the recorded session.
[LeonP] It is out of scope of this document.

o   REQ-029/030 - They look very generic and I don't think these should be requirements for SRP, but rather a product requirement on how OA&M works for the recording client/server.

Thanks
Henry

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 1 Feb 2010 21:02:42 -0800

Hi Leon, Henry,

I put together some inputs on top of yours for consideration as
well....pls see my inputs below.

Regards,

Dave

Hi, Henry.

Leon

Hi Ken,

[LeonP] Actually there is a difference between Recorded session (the
actual call to be recorded[DS]  Is this just the voice - the RTP stream
(the replicated voice stream that is sent to a Logger)?  ) that can be
not SIP based and Recording Session (part of SRP) that is used for
triggering recording and it is SIP based[DS] Is this the control
messaging...for starting/stopping/pause/resume...the messaging (SIP) for
set up of the replicated voice stream/RTP transfer? . So both RC and RS
are SIP UA.  

[LeonP] No, my comment above[DS] I recommend better Terms and/or better
definitions of the Terms "Recorded Session" and "Recording Session"in
the Draft - is it possible to change one or both terms since they sound
so similar.  That is, the IETF Draft definitions are not clear to
me...and the difference between these is not clear (for example, do not
use the terms themselves in the definitions...provide examples.
Recommend also to differentiate these from the Metadata messaging (if
they are or could be different), and to define that as well (as rec'd by
Martin).  

[LeonP] Yes, probably we want to use more generic term then Complex
Call[DS] The term "Multi-Party Call" seems to imply a call/interaction
with more than two users...that is, a conference.  Recommend to keep
"Complex Calls" terminology but define several different cases/examples
- for example, Conferences (Henry's example), Consults (as in use case
8), also could include a Whisper Agent/Coaching example, Barge-In
example, other...  Alternatively, change Use Case 8 to "Consult Call"
and add additional use cases for these other complex call examples.  

[LeonP] The main point there was that Recording Protocol must support
real time streaming for real time analytics[DS]  This Use Case reads
like a requirement and should read more like an example of how it is
used.  

Is the ability to support "real-time" analytics dependent on the
recording protocol?  Is there also a need separate streams for the two
channels (what the agent said, what the agent heard) - And do we already
have a req't for that.....i.e., req't 10 and/or req't 11?

-          Section 6:

[LeonP] Record all calls[DS] Recommend we explain that in the req't;
also, is that by DN, or by Agent, or by Customer, other, or all of the
above...?   

[LeonP] Yes, we should

[LeonP]  It is more for trading floor environments where multiple
concurrent calls on the same device (turret) recorded together. It is
not related to summation for conference participants at the same call.
[DS] Recommend to state this info in the req'ts and provide this
example.

o   REQ-013 - this is only one way of notifying the customer that the
call is being recorded but there are others. I think this requires a bit
more explanation of why this is needed. To me this looks like a
duplicate of REQ-022    [DS] Recommend to change this req't from "Must"
to "May"    

[LeonP] REQ-015 talk regarding media and REQ-017 regarding SRP SIP
Session [DS] Recommend to define "non-repudiation" and/or provide an
example to avoid any confusion.  

o   REQ-017 - [DS]  Why is non-repudiation of both the SRP and the Media
needed?

o   Req - 022  - [DS]  Recommend to add "This MAY be performed by
injecting tones into the Recorded Session either from the RS or from the
RC."  (but could also be done by informing via speech script upon first
answering call)  

Thanks

Henry

---

From: "Dave Smith" <[email-masked]>
Date: Tue, 2 Feb 2010 14:33:07 -0800

Raj,

Regarding this input:

[rj] The SRP, which manages how the recording media gets delivered to
the recorders, is based on SIP (SRP is a set of extensions to the SIP
core protocol). The sessions that SRP manages are called "Recording
Sessions" and they are SIP sessions. Therefore, RC and RS are, by
definition, SIP UAs. The sessions that get actually recorded (e.g.
communication between a call center agent and an external caller) may or
may not be SIP (this depends on the kind of the PBX phone the agent). 

Can you please provide a few examples of the different types of
protocols that might be possible/practical for the sessions that get
actually recorded (which are dependent on the kind of PBX phone used)?

Regards,

Dave

From: Jain, Rajnish [mailto:[email-masked]] 
Sent: Monday, February 01, 2010 3:28 PM
To: Henry Lum; Leon Portman; [email-masked]
Cc: Dave Smith; [email-masked]
Subject: RE: [dispatch] Comments
ondraft-rehor-dispatch-session-recording-req-00

Henry,

[rj] The SRP, which manages how the recording media gets delivered to
the recorders, is based on SIP (SRP is a set of extensions to the SIP
core protocol). The sessions that SRP manages are called "Recording
Sessions" and they are SIP sessions. Therefore, RC and RS are, by
definition, SIP UAs. The sessions that get actually recorded (e.g.
communication between a call center agent and an external caller) may or
may not be SIP (this depends on the kind of the PBX phone the agent). 

[rj] Correct.

[rj] I guess, Persistent Recording is a bit confusing term (we've
received other feedback on this as well). If I can use the term
always-on recording from the wing-srtp draft then these sessions get
established when the agent logs on and torn off when the agent logs off.
Codecs such as G.729 and G.711 with VAD are used to ensure that silence
is not recorded (for instance, when the agent isn't on a call).

[rj] Due to bandwidth and other cost burdens, the customer demand is
that you mix multiple _recorded sessions_ in a single _recording
session_.

[rj] The example test you quoted doesn't reflect the actual intent here.
The reason for supporting both directions is dependent on where the
policy to record or not resides - RC or RS. The INVITE always comes from
either of these two places.

Thanks,

Raj Jain

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: "Jain, Rajnish" <[email-masked]>
Date: Tue, 2 Feb 2010 18:42:55 -0500

Dave,

Inline:

From: Dave Smith [mailto:[email-masked]]
Sent: Tuesday, February 02, 2010 5:33 PM
To: Jain, Rajnish; Henry Lum; Leon Portman; [email-masked]
Cc: [email-masked]
Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

Raj,
Regarding this input:

Can you please provide a few examples of the different types of protocols that might be possible/practical for the sessions that get actually recorded (which are dependent on the kind of PBX phone used)?

[rj] This can range anywhere from proprietary VoIP media and signaling protocols to things such as SCCP, UNISTIM, H.323, TDM and analog phones. Most such phones are not SIP UAs. Some other entity (such as a SIP-enabled mixer) may provide the RC media forking point functionality in these cases.

Thanks,
Raj

Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

Henry,

[rj] Correct.

Thanks,
Raj Jain

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 4 Feb 2010 11:12:11 +0100

I can see that the recorded session could in theory be something other than a SIP session however I think that for the purposes of this draft and the working group which we hope will be formed shortly that we should assume that the recorded session is a SIP session.

We have requirements and proposed charter text that impact the recorded session and will require protocol to be defined.

Of course the recording client can be a SIP gateway which provides interworking with other protocols but this is outside the scope so I think we should state that the recorded session is a SIP session.

Regards
Andy

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jain, Rajnish
Sent: 02 February 2010 23:43
To: Dave Smith; Henry Lum; Leon Portman; [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

Dave,

Inline:

Raj,
Regarding this input:

Thanks,
Raj

Henry,

[rj] Correct.

Thanks,
Raj Jain

---

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 4 Feb 2010 08:50:37 -0500

I agree with this proposal in the interest of moving this work forward.

Regards,
Raj

From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Thursday, February 04, 2010 5:12 AM
To: Jain, Rajnish; Dave Smith; Henry Lum; Leon Portman; [email-masked]
Cc: [email-masked]
Subject: RE: [dispatch] Comments ondraft-rehor-dispatch-session-recording-req-00

 
 
Regards
Andy

________________________________________

Inline:

Raj,
Regarding this input:

Thanks,
Raj

Henry,

[rj] Correct.

Thanks,
Raj Jain

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