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

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 29 Apr 2010 19:33:51 +0200

FYI - Just updated the name of the working group and made a minor modification to the diagram to align with what was presented at IETF77. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 29 April 2010 18:30
To: [email-masked]
Subject: I-D Action:draft-hutton-siprec-session-recording-arch-00.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-00.txt
	Pages           : 13
	Date            : 2010-04-29

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).  This is an initial
draft which explores possible architectural solutions and has many
open issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hutton-siprec-session-recording-arch-00.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
cy9kcmFmdC1odXR0b24tc2lwcmVjLXNlc3Npb24tcmVjb3JkaW5nLWFyY2gtMDAudHh0DQo=

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 29 Apr 2010 16:58:33 -0400

Hi Andrew,

I had two other architectural ideas. Not sure if they have been/are
worth discussing:

1) A variation on the endpoint model. If both endpoints support
recording then have each device individually stream a copy of it's
media to the RS.

2) Have an endpoint use reINVITEs to redirect the media it is
receiving to a RS which acts as a 'man-in-the-middle' RTP relay [This
would require some mechanism to get relay ports allocated by the RS.
Could be modelled on the semantics of TURN or could be more like the
3PCC flows which insert music-on-hold]. This relieves the EP from the
responsibility of dual-streaming media without the need for the
signalling to go through a B2BUA.

Peter Musgrave

On Thu, Apr 29, 2010 at 1:33 PM, Hutton, Andrew
<[email-masked]> wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>
>