Subject: [siprec] FW: I-D Action:draft-hutton-siprec-session-recording-arch-01.txt

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 18 Jun 2010 18:33:15 +0200

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 18 June 2010 17:30
To: [email-masked]
Subject: I-D Action:draft-hutton-siprec-session-recording-arch-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : An Architecture for Media Recording using the Session Initiation Protocol
	Author(s)       : A. Hutton, et al.
	Filename        : draft-hutton-siprec-session-recording-arch-01.txt
	Pages           : 15
	Date            : 2010-06-18

Session recording is a critical requirement in many communications
environments such as call centers and financial trading.  In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons.  Recording of a session
is typically performed by sending a copy of a media stream to a
recording device.  This document describes architectures for
deploying session recording solutions in an environment which is
based on the Session Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hutton-siprec-session-recording-arch-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1odXR0b24tc2lwcmVjLXNlc3Npb24tcmVjb3JkaW5nLWFyY2gtMDEudHh0DQo=

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2010 14:42:09 -0400

This doc looks pretty good. I have a few small comments:

Section 3:

    to support the requirements for media recording.  The Replicated
    Media is required to be sent in real-time to the Session Recording
    Server and is not buffered by the Session Recording Client to allow
    for real-time analysis of the media by the Session Recording Server.

While I think I know what the above intends to say, I find the words 
ambiguous. Specifically, the referent of "to allow for real-time 
analysis..." could be misinterpreted. I suggest:

    to support the requirements for media recording.  To allow for
    real-time analysis of the media by the Session Recording Server,
    the Replicated Media is not buffered by the Session Recording Client;
    it is required to be sent in real-time to the Session Recording
    Server.

Section 4.2.2:

    o  If the Recording Session is to be started immediately then the
       Session Recording Client will include an SDP attribute of
       "a=recvonly" for each media line or "a=inactive" if it is not
       ready to receive the media

The above doesn't make sense to me. AFAIK the media sessions offered or 
answered by the SRC to the SRS are always either sendonly or inactive. 
(The SRC never expects to receive media from the SRS.)

Section 4.3.2

I think the reference to RFC 2976 should be omitted. It is superseded by 
  draft-ietf-sipcore-info-events. If INFO is to be used at all it should 
be via draft-ietf-sipcore-info-events.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 21 Jun 2010 19:11:49 +0530

The document looks pretty good.  I have a few minor comments

Section 4.2.2

I suppose you meant Session Recording Server and not client in the above
point. Please correct the same

Section 4.3.2
I think we should also consider  sending metadata in INVITE as MIME body
along with SDP. The architecture document should not have any
restrictions on delivery mechanisms for metadata.
The pros and cons of different delivery mechanisms may  be discussed
later.
Can you please add a note here "The metadata event XML documents may be
conveyed   from SRC to SRS in an INVITE with MIME body"

Section 4.4
   If the Session Recording Client is aware that the remote UA is a
   recording aware UA then it MUST notify the UA using a SIP based
   mechanism. 
Is the expectation that the recording aware UA has the capability to
play tone/announcements ?  I think that might not be the case always.
I think we should not restrict to using only NOTIFY in case the UA is
Recording aware UA.  We must allow both NOTIFY and in-band tone as
mechanisms by which SRC can notify a recording aware UA.

Regards,
Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hutton, Andrew
Sent: Friday, June 18, 2010 10:03 PM
To: [email-masked]
Subject: [siprec] FW:
I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 18 June 2010 17:30
To: [email-masked]
Subject: I-D Action:draft-hutton-siprec-session-recording-arch-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : An Architecture for Media Recording using the
Session Initiation Protocol
	Author(s)       : A. Hutton, et al.
	Filename        :
draft-hutton-siprec-session-recording-arch-01.txt
	Pages           : 15
	Date            : 2010-06-18

Session recording is a critical requirement in many communications
environments such as call centers and financial trading.  In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons.  Recording of a session is
typically performed by sending a copy of a media stream to a recording
device.  This document describes architectures for deploying session
recording solutions in an environment which is based on the Session
Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hutton-siprec-session-recordin
g-arch-01.txt

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 21 Jun 2010 13:57:56 -0400

Hi Andrew,

I agree with the sentiment that the doc is in good shape.

My only question is whether the two architectural choices (B2B or
endpoint) are enough. Do we see any need for looking at an
architecture which would allow a stateful proxy to ensure recording
occurs on calls? If this is viewed as a logical sub-case of the B2B
man-in-middle mode then perhaps that could be explicitly stated?

Regards,

Peter Musgrave

On Fri, Jun 18, 2010 at 12:33 PM, Hutton, Andrew
<[email-masked]> wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>
>

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 21 Jun 2010 14:27:04 -0700

I have a few comments and questions:

Section 4.1.1 - in figure 1, when B2BUA is used, are there two
communication sessions as drawn in the diagram or just one communication
session? From the definition in the requirements document, it looks like
there are two communication sessions since a communication session
refers to one SIP session. 

Section 4.1.3 - in figure 3, should the media server be drawn within the
border of the SRS? This looks to me that this is a different
architecture than the one introduced in figure 2.

Section 4.2.2 - an open issue for me is when the SRC is a SIP B2BUA as
described in section 4.1.1. If the SRS uses a mechanism like Join header
to identify a particular session to be recorded, then the SRS is only
recording the call from the viewpoint of one of the endpoint. For
example, if SRS asks for recording on the communication session on UA-A
(as in figure 1), then will the recording follow UA-A even when UA-A may
not be talking to UA-B anymore? I see that there are two types of
mechanism for SRS-initiated recording, one for 1pcc and the other for
3pcc.

Section 4.2.5 - the wording here sounds like whenever there is a
mismatch in codecs the SRC is responsible for performing the
transcoding. Is that the intention to use a transcoder (RFC5369) first
before doing transcoding on the SRC? 

Section 4.3.1 - 4.3.2 mentions the use of XML schema for the metadata
content. This section should make it clear that an XML schema for the
metadata content should be used.

Section 4.5 - A recording aware UA should be able to indicate the
recording preference in the INVITE response (ie. 200 OK) as well when it
is acting as the UAS receiving a call.

Regards,
Henry

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

-------------------------------------------------------------------------------------------------------------------
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: Leon Portman <[email-masked]>
Date: Tue, 22 Jun 2010 09:41:36 +0300

Henry, Hi

Please see below my comments

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: Tuesday, June 22, 2010 12:27 AM
To: [email-masked]
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

[LeonP] Actually it is an open item that I mention for multi-party recording via conference server,

where we are recording one communication session that actually represented by multiple SIP sessions.

[LeonP] Yes, media server is part of SRS. There is also another configuration, where MedaCTRL and media server are used for SRC implementation.

3pcc.

[LeonP] I agree that we need to use some universal call-id parameter for communication session identification.

So we need to have ability to identify specific participant (like record UA-A) or specific communication session (record call-id)

[LeonP] I think, the preference should be transcoding on SRC side

[LeonP] Agree

Regards,

Henry

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

Of Hutton, Andrew

To: [email-masked]

Subject: [siprec] FW:

[email-masked]

Sent: 18 June 2010 17:30

directories.

      Filename        :

      Pages           : 15

      Date            : 2010-06-18

g-arch-01.txt

Internet-Draft.

siprec mailing list

[email-masked]

siprec mailing list

[email-masked]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 22 Jun 2010 09:40:00 +0200

Hi Paul,

Thanks for your comments see responses below.

Regards
Andy 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 18 June 2010 19:42
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] FW: I-D 
> Action:draft-hutton-siprec-session-recording-arch-01.txt
> 

[Andy H] - Yes I agree your text is better I will use it in the next update.

> (The SRC never expects to receive media from the SRS.)

[Andy H] - You are correct this is a mistake I will correct it in the next update.

> be via draft-ietf-sipcore-info-events.

[Andy H] I agree.

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 23 Jun 2010 15:42:20 +0800

I have a question about the new section called "Media Transcoding". The
section states "......it may be limit the media formats in the offer to the
SRS depending on what media is negotiated on the CS or may limit what it
includes in the offer on the CS.......". I can undersatnd the first part of
it where SRC limit the media format in its offer to SRS (it *may* know the
CS negotiations from metadata) but for the second part (...may limit what it
includes in the offer on the CS...), are we assuming that SRC will always be
induldge in CS negotiation/establishment? or SRC can change the previously
negotiated media for CS? There may be scenarios where SRC will not come it
picture untill the CS is established/negotiated and went on for some time.
For e.g consider a supervisor terminal (SRC) in a call center which randomly
picks a communication session between one of his/her subordinate and
customer, to record, for purpose of agent performance check. This perhaps,
can be done by SRC joining the pre-established CS, making it a conference
and start sending replicated media to SRS.  In this case, SRC will not be
among the communicating parties of CS, I mean it may join the CS later but
was not there when it was negotiated/established and neither it wants to
change the negotiated media for CS (perhaps for privacy resons).

Having said this, I'm not sure what is the motivation behind  "...may limit
what it includes in the offer on the CS...". Further, we may think of a
additioanl ARC model where SRC can be a SIP entity which does not
participate in CS negotiation/establishment and has no idea about the media
format negotiated for CS. I'm not sure if we can consider this aspect being
covered by B2BUA model.

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hutton, Andrew
Sent: 2010年6月19日 0:33
To: [email-masked]
Subject: [siprec] FW:
I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: 18 June 2010 17:30
To: [email-masked]
Subject: I-D Action:draft-hutton-siprec-session-recording-arch-01.txt 

Session recording is a critical requirement in many communications
environments such as call centers and financial trading.  In some of these
environments, all calls must be recorded for regulatory, compliance, and
consumer protection reasons.  Recording of a session is typically performed
by sending a copy of a media stream to a recording device.  This document
describes architectures for deploying session recording solutions in an
environment which is based on the Session Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hutton-siprec-session-recording-ar
ch-01.txt

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jun 2010 10:26:04 -0400

Deepanshu,

I guess there are cases where the SRC is influential in the
establishment of the CS, and other cases where it is not.

When it is, it could potentially limit the formats it offers or accepts
to those it knows to be supported by the SRS.

When its just a bystander to the CS establishment then it can't do that,
and so must hope the SRS can handle what is negotiated, or must find a
transcoder to help, or must forgo recording in that case, or must block
the CS in that case.

	Thanks,
	Paul

---

From: Deepanshu Gautam <[email-masked]>
Date: Thu, 24 Jun 2010 10:24:57 +0800

Paul,

I agree. So, now I think its OK to keep the statement "...or may limit what
it includes in the offer on the CS...." in the section provided it is with
*may*.

But, do we need another architecture (another location for SRC) to
accommodate the case when SRC is just a bystander to the CS establishment?

Regards
Deepanshu

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2010年6月23日 22:26
To: Deepanshu Gautam
Cc: 'Hutton, Andrew'; [email-masked]
Subject: Re: [siprec] FW:

Deepanshu,

I guess there are cases where the SRC is influential in the establishment of
the CS, and other cases where it is not.

When it is, it could potentially limit the formats it offers or accepts to
those it knows to be supported by the SRS.

When its just a bystander to the CS establishment then it can't do that, and
so must hope the SRS can handle what is negotiated, or must find a
transcoder to help, or must forgo recording in that case, or must block the
CS in that case.

	Thanks,
	Paul

Deepanshu Gautam wrote:
> I have a question about the new section called "Media Transcoding". 
> The section states "......it may be limit the media formats in the 
> offer to the SRS depending on what media is negotiated on the CS or 
> may limit what it includes in the offer on the CS.......". I can 
> undersatnd the first part of it where SRC limit the media format in 
> its offer to SRS (it *may* know the CS negotiations from metadata) but 
> for the second part (...may limit what it includes in the offer on the 
> CS...), are we assuming that SRC will always be induldge in CS 
> negotiation/establishment? or SRC can change the previously negotiated 
> media for CS? There may be scenarios where SRC will not come it picture
untill the CS is established/negotiated and went on for some time.
> For e.g consider a supervisor terminal (SRC) in a call center which 
> randomly picks a communication session between one of his/her 
> subordinate and customer, to record, for purpose of agent performance 
> check. This perhaps, can be done by SRC joining the pre-established 
> CS, making it a conference and start sending replicated media to SRS.  
> In this case, SRC will not be among the communicating parties of CS, I 
> mean it may join the CS later but was not there when it was 
> negotiated/established and neither it wants to change the negotiated media
for CS (perhaps for privacy resons).
> 
> Having said this, I'm not sure what is the motivation behind  "...may 
> limit what it includes in the offer on the CS...". Further, we may 
> think of a additioanl ARC model where SRC can be a SIP entity which 
> does not participate in CS negotiation/establishment and has no idea 
> about the media format negotiated for CS. I'm not sure if we can 
> consider this aspect being covered by B2BUA model.
> 
> Regards
> Deepanshu
> 
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hutton, Andrew
> Sent: 2010年6月19日 0:33
> To: [email-masked]
> Subject: [siprec] FW:
> [mailto:[email-masked]]
> recording device.  This document describes architectures for deploying 
> session recording solutions in an environment which is based on the
Session Initiation Protocol (SIP).

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Jun 2010 13:14:17 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Deepanshu Gautam
> Sent: 24 June 2010 03:25
> To: 'Paul Kyzivat'
> Cc: [email-masked]
[JRE] This sounds like physical separation between the SRC and the SIP UA. Could this left out of scope, possibly to be covered by MEDIACTRL?

John

> > Subject: I-D

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jun 2010 10:28:46 -0400

> [JRE] This sounds like physical separation between the SRC and the SIP UA. Could this left out of scope, possibly to be covered by MEDIACTRL?

I don't think anything needs to be said.
Its a fact of life in this situation.
The SRC can use any of the sip bag of tricks to deal with it.

	Thanks,
	Paul

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 25 Jun 2010 10:05:04 +0800

Well, the arch document tends to specify the location of SRC, I understand
it may not be exhaustive, but, *if* in the process of ARC development we
came across a possible different (not covered) scenario then I don't think
it hurts to spell it out and possibly pointing out that *bag* of SIP which
could be used to satisfy that.

Regards
Deepanshu

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2010年6月24日 22:29
To: Elwell, John
Cc: Deepanshu Gautam; [email-masked]
Subject: Re: [siprec] FW:

Elwell, John wrote:
>> I agree. So, now I think its OK to keep the statement "...or may 
>> limit what it includes in the offer on the CS...." in the section 
>> provided it is with *may*.
>>
> [JRE] This sounds like physical separation between the SRC and the SIP UA.
Could this left out of scope, possibly to be covered by MEDIACTRL?

	Thanks,
	Paul

>> When it is, it could potentially limit the formats it offers or 
>> accepts to those it knows to be supported by the SRS.
>>
>> When its just a bystander to the CS establishment then it can't do 
>> that, and so must hope the SRS can handle what is negotiated, or must 
>> find a transcoder to help, or must forgo recording in that case, or 
>> must block the CS in that case.
>>
>> 	Thanks,
>> 	Paul
>>
>> Deepanshu Gautam wrote:
>> http://www.ietf.org/internet-drafts/draft-hutton-siprec-session-recor
>> d
>>> ing-ar
>>> ch-01.txt
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jun 2010 08:59:51 -0400

> could be used to satisfy that.

I think its fine to document *examples* of all sorts of things.
Exactly what document they end up in can be resolved later.

	Thanks,
	Paul