Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

Henry, Hi

Please see below my comments

Leon

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

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.

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

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.

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

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.

[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)

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?

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

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.

[LeonP] Agree

Regards,

Henry

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

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf

Of Hutton, Andrew

Sent: Friday, June 18, 2010 10:03 PM

To: siprec@ietf.org

Subject: [siprec] FW:

I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

From: i-d-announce-bounces@ietf.org

[mailto:i-d-announce-bounces@ietf.org] On Behalf Of

Internet-Drafts@ietf.org

Sent: 18 June 2010 17:30

To: i-d-announce@ietf.org

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

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.

_______________________________________________

siprec mailing list

siprec@ietf.org

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.

_______________________________________________

siprec mailing list

siprec@ietf.org

https://www.ietf.org/mailman/listinfo/siprec