Subject: [dispatch] Summary on Session Recording in SIP

From: Vijay Gurbani <[email-masked]>
Date: Sun, 21 Jun 2009 23:09:26 -0500

All: Here is the summary of the Session Recording thread from June 9
to June 19, 2009.  If I misrepresented anything, please let me know.

There was a fair amount of discussion on where to conduct this
work.  In the end, it was decided to continue discussions on
dispatch, further decisions what to do -- new working group or
put this work in an existing working group -- will be decided
later.  Regardless of where the work is done, opinions were
expressed that the work is important that it should commence
in the IETF.

Need to be crisp about the purpose of this work: is it that users
record sessions to hear later, or sessions need to be recorded
because of some business needs?  Or both?  Is SRTP covered or
only RTP?

Solutions should cover:
  Always on recording
  Recording on demand
  Required recording
  Pause and resume recording
  Playback facilities and how they interact with recording
  Recording formats and protocols for controlling the stored recording.

A lot of discussion ensued on the specific architecture or
architectures that would be possible.  No decision was reached on
which specific architecture is good or bad, although various opinions
were expressed in support for each.

There are essentially four architectures to realize recording
services: two that discuss where the media stream is forked
out to the recorder -- at the UA or in a middlebox of some
sort are outlined here:
   http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html

The third architecture has both UAs sending media to a
recorder.  See:
     http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html

A fourth architecture that is a superset of the third one is at:
     http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://ect.bell-labs.com/who/vkg

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Jun 2009 14:36:08 -0400

A real simple question about intended scope:

Does this include a direct session between a UAC and a UAS whose purpose 
is recording, such as for a VM system? (A VM system does seem to be a 
special case of "recording on demand", and also often includes playback 
facilities.)

I had the impression that this work was more scoped toward cases where 
there is an interactive session between two or more parties, and that 
recording is intended to be supplemental to that.

	Thanks,
	Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Jun 2009 14:55:53 -0400

I am having trouble understanding why playback is part of this at all.
There appear to be two cases:
1) Playback after the call has ended.  That is clearly a distinct 
application.  Whether it is delivered by SIP, HTTP, or some other 
applicaiton protocol does not matter.

2) Playback during a call.  That would seem to be a combination of (1) 
plus the general problem of inserting media from another application 
into an ongoing call.  Again not part of the recording problem.

There do seem to be ligitmate items that need work in the SIP area on 
enabling several different kinds of call recording.  So I think there is 
work to be done.  I am just confused by the inclusion of this dimension 
(other than "because someone asked for it.")

Yours,
Joel

Paul Kyzivat wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Jun 2009 14:14:40 -0500

> recording is intended to be supplemental to that.

Paul: When we (i.e., the author team) had initially started
this work, the latter was more of what we had in mind.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Jun 2009 17:13:44 -0500

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 22, 2009 1:55 PM
Subject: Re: [dispatch] Summary on Session Recording in SIP

>I am having trouble understanding why playback is part of this at all.

As am I, FWIW...

> (other than "because someone asked for it.")

What Joel said.

Thanks,

Spencer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 23 Jun 2009 10:35:52 +0100

Hi,

I would support dropping playback from the requirements,

Regards
Andy 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Spencer Dawkins
>Sent: 22 June 2009 23:14
>To: Joel M. Halpern; [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Jun 2009 08:55:55 +0100

> [mailto:[email-masked]] On Behalf Of Vijay Gurbani
> Sent: 22 June 2009 05:09
> To: [email-masked]
> Subject: [dispatch] Summary on Session Recording in SIP
> 
[JRE] Whatever architecture(s) we adopt, must allow SRTP to be used on
the original call. We can then discuss various options on the recorded
leg, e.g., SRTP using the same keys as the original call (i.e., without
decryption and re-encryption), SRTP with separate keys, or RTP.

John