Subject: [dispatch] Session recording in SIP

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 09 Jun 2009 16:01:38 -0500

Hi: I realize that the deadline for charter proposals
was yesterday, but I hope that it is not too late to submit
one more.

A few interested people (Hadriel Kaplan, Dan Wing, Rajnish Jain,
Leon Portman, Andrew Hutton and I) have been interested in
RTP session recording in SIP.  The requirement draft will
be released shortly.

We would like to request agenda time in dispatch to propose
the formation of a new working group to define protocol
extensions and an architecture for RTP recording.

Session recording in SIP
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

Session recording is a critical operational requirement in many
businesses, especially where voice is used as a medium for
commerce and customer support. A prime example where voice is used
for trade is the financial industry. The call recording requirements
in this industry are quite stringent. The recorded calls are used
for dispute resolution and regulatory compliance. Other businesses
such as customer support call centers typically employ call
recording for quality control or business analytics.

Depending on the country and its regulatory requirements, financial
trading floors typically must record all calls. The recorded media
content must be an exact copy of the actual conversation (i.e.
clipping and loss of media are unacceptable).  Some deployments
and regulations require that calls be aborted or rejected if
the recording device is unavailable.

This group will specify requirements for a SIP based protocol
interface between a communications system and a recorder. The
Communications System is responsible for establishing media sessions
where the actual business is conducted. The Recorder is the sink of
the recorded media.

The recorded sessions can be of any kind such as voice, video and
instant messaging. A recorded session is typically comprised of
actual media content and the call metadata. The call metadata allows
recording archives to be searched and filtered at a later time.
The conveyance of call metadata from the communications system
to the recorder is outside the scope of this document.

This group will only looks into active recording, where the recorded
system purposefully streams media to a recording device. Passive
recording, where a recording device detects media directly from
the network, is outside the scope of this document. In addition,
lawful intercept is outside the scope of the group.

Proposed deliverables:

1) Requirements document;
2) Solutions document, including reference architecture.

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2009 11:23:41 +0200

I believe that this is an important application, and I support doing
work in this direction. 

Three comments on the preliminary words: 

1. The requirement is for both signaling and media recording, right?
Probably good to say it. 
2. Security and regulations on how the information is accessed and
protected are of high importance. They would probably be reflected in
the requirements, but explicit wording in the future charter can help.
3. I suggest that we look at the IPFIX protocol as a possible technology
to re-use

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Wednesday, June 10, 2009 12:02 AM
> To: [email-masked]
> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan
> Subject: [dispatch] Session recording in SIP
> 
> Hi: I realize that the deadline for charter proposals was 
> yesterday, but I hope that it is not too late to submit one more.
> 
> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish 
> Jain, Leon Portman, Andrew Hutton and I) have been interested 
> in RTP session recording in SIP.  The requirement draft will 
> be released shortly.
> 
> Session recording is a critical operational requirement in 
> many businesses, especially where voice is used as a medium 
> for commerce and customer support. A prime example where 
> voice is used for trade is the financial industry. The call 
> recording requirements in this industry are quite stringent. 
> The recorded calls are used for dispute resolution and 
> regulatory compliance. Other businesses such as customer 
> support call centers typically employ call recording for 
> quality control or business analytics.
> 
> Depending on the country and its regulatory requirements, 
> financial trading floors typically must record all calls. The 
> recorded media content must be an exact copy of the actual 
> conversation (i.e.
> clipping and loss of media are unacceptable).  Some 
> deployments and regulations require that calls be aborted or 
> rejected if the recording device is unavailable.
> 
> Communications System is responsible for establishing media 
> sessions where the actual business is conducted. The Recorder 
> is the sink of the recorded media.
> 
> The recorded sessions can be of any kind such as voice, video 
> and instant messaging. A recorded session is typically 
> comprised of actual media content and the call metadata. The 
> call metadata allows recording archives to be searched and 
> filtered at a later time.
> The conveyance of call metadata from the communications 
> system to the recorder is outside the scope of this document.
> 
> This group will only looks into active recording, where the 
> recorded system purposefully streams media to a recording 
> device. Passive recording, where a recording device detects 
> media directly from the network, is outside the scope of this 
> document. In addition, lawful intercept is outside the scope 
> of the group.
> 
> Proposed deliverables:
> 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Leon Portman <[email-masked]>
Date: Wed, 10 Jun 2009 15:42:07 +0300

Dan, Hi

Thank you for the comments.

Please see below

Leon

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2009 12:24 PM
To: Vijay K. Gurbani; [email-masked]
Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan
Subject: RE: [dispatch] Session recording in SIP

1. The requirement is for both signaling and media recording, right?
Probably good to say it. 
[LeonP] Actually we want to separate into two separate documents: Media forking invocation (via SIP invite ) and SIP Event package for signaling reporting

[LeonP] Currently it was out of scope however we can discuss it
[LeonP] OK, we will

Dan

---

From: Alan Johnston <[email-masked]>
Date: Wed, 10 Jun 2009 08:42:26 -0500

This is important work to be done in RAI.  Key management for secure 
recording is an important component that needs to be addressed.

draft-wing-sipping-srtp-key-04 addresses many of these topics.

Thanks,
Alan

---

From: Roni Even <[email-masked]>
Date: Wed, 10 Jun 2009 19:18:20 +0300

Hi,
I agree that this is an important work but I am not sure about a WG. This
may be done in XCON and AVT.
Note that the recording is not only for point to point call but at least for
three parties like in call center scenarios

I also did not notice any mention of the playback part but it should also be
addressed

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alan Johnston
Sent: Wednesday, June 10, 2009 4:42 PM
To: Romascanu, Dan (Dan)
Cc: Leon Portman; [email-masked]; Jain, Rajnish; Hadriel Kaplan
Subject: Re: [dispatch] Session recording in SIP

Thanks,
Alan

---

From: Roni Even <[email-masked]>
Date: Thu, 11 Jun 2009 00:28:07 +0300

Hi,

Roni Even

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

Thanks,
Alan

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 Jun 2009 16:59:56 -0500

Hey

I agree with Roni about this probably being best suited for XCON, 
after all, any point to point recording is likely (merely) adding a 
3rd party (the recorder) to the session.

This brings up probably the most glaring whole (in my mind) that is 
not mentioned below - the ability to have a recorder without at least 
one side knowing it's there.  Not every time, and in fact probably 
most times, you don't want the other person knowing you are recording 
them. It's likely more of a case of not explicitly asking the called 
party "can I record this conversation", it just happens.

James

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 Jun 2009 17:48:29 -0500

James M. Polk wrote:
> I agree with Roni about this probably being best suited for XCON, after 
> all, any point to point recording is likely (merely) adding a 3rd party 
> (the recorder) to the session.

Could the dispatch chairs/RAI ADs please weigh in on where to
do this work?  This will help target the requirements
draft accordingly.

Yesterday, when we had a quick email exchange between
authors on where to submit it, sipcore and dispatch were
the candidates, and between them, dispatch was more appropriate.
And given that to get work going in dispatch required a "mini-
charter", we went ahead and submitted one.

Between xcon and avt, probably xcon will be more appropriate
since the bulk of this work revolves more around SIP than it
does on RTP-specific issues.  But then, this work does not
quite fit in the current xcon charter and deliverables (at least
as far as I can see it; I may be wrong, of course.)

Thanks,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Jun 2009 21:02:19 -0400

I think this would be interesting to look at, and I'd also support work 
in this direction.

I also think its pretty fertile ground. Though it seems simple at first 
blush, recording today is actually a really complicated space. Some of 
the issues:

  * where does the 'media forking' happen
  * interfaces from recording applications to find and request calls to 
record
  * storage of recordings
  * protocols for access to recordings
  * meta-data about recorded calls
  * multimedia recording - e.g., record the PPT share in conjunction 
with the audio

I think this is pretty chunky and could merit its own group.

I also don't think this is about conferencing. Conferencing and 
recording are not the same thing, though they both involve sending media 
streams to multiple places.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 10 Jun 2009 21:08:26 -0500

At this stage, DISPATCH is the appropriate place to be having these
discussions. Since this topic was just introduced to the WG yesterday,
it's a bit too early, and not obvious based on the various opinions
expressed thus far, to decide that it might belong elsewhere, need a new
WG/BoF, etc. So, let's continue the discussion on DISPATCH and refine
the problem space and solution scope. 

Thanks,
Mary.
DISPATCH WG co-chair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vijay K. Gurbani
Sent: Wednesday, June 10, 2009 5:48 PM
To: [email-masked]
Subject: Re: [dispatch] Session recording in SIP

> 3rd party (the recorder) to the session.

Could the dispatch chairs/RAI ADs please weigh in on where to do this
work?  This will help target the requirements draft accordingly.

Yesterday, when we had a quick email exchange between authors on where
to submit it, sipcore and dispatch were the candidates, and between
them, dispatch was more appropriate.
And given that to get work going in dispatch required a "mini- charter",
we went ahead and submitted one.

Between xcon and avt, probably xcon will be more appropriate since the
bulk of this work revolves more around SIP than it does on RTP-specific
issues.  But then, this work does not quite fit in the current xcon
charter and deliverables (at least as far as I can see it; I may be
wrong, of course.)

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/
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Roni Even <[email-masked]>
Date: Thu, 11 Jun 2009 08:07:34 +0300

Mary,
This brings another question about dispatch, what does it mean that dispatch
decides that this should be for example a specific WG work. (let's take XCON
for example) 

Does this qualify it as an XCON WG item
Does this make the topic a charter item for the XCON WG.

I assume that the answer is no for both questions.

If the assumption is correct, how do the chairs/Ads decide if to have a long
discussion in dispatch about the problem space and solution scope  or to
move it to a working group and finish this discussion there in order to
expedite the work and not repeat the discussion.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mary Barnes
Sent: Thursday, June 11, 2009 5:08 AM
To: Vijay K. Gurbani; [email-masked]
Subject: Re: [dispatch] Session recording in SIP

Thanks,
Mary.
DISPATCH WG co-chair

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

Thanks,

- vijay

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 11 Jun 2009 07:46:01 +0200

Hi,

A question on the use-case behind this:

Is the idea that users can record sessions, and then listen to them later? Ie it is some kind of "network based PVR for SIP sessions" :)

OR, is the idea that sessions can be recorded, because there may be some authority which requires it? In that case, playback functionality etc may not be needed on the interface between the user and the recorder.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: 11. kesäkuuta 2009 8:08
> To: 'Mary Barnes'; 'Vijay K. Gurbani'; [email-masked]
> This brings another question about dispatch, what does it 
> mean that dispatch decides that this should be for example a 
> specific WG work. (let's take XCON for example) 
> 
> If the assumption is correct, how do the chairs/Ads decide if 
> to have a long discussion in dispatch about the problem space 
> and solution scope  or to move it to a working group and 
> finish this discussion there in order to expedite the work 
> and not repeat the discussion.
> 
> Roni Even
> 
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> At this stage, DISPATCH is the appropriate place to be having 
> these discussions. Since this topic was just introduced to 
> the WG yesterday, it's a bit too early, and not obvious based 
> on the various opinions expressed thus far, to decide that it 
> might belong elsewhere, need a new WG/BoF, etc. So, let's 
> continue the discussion on DISPATCH and refine the problem 
> space and solution scope. 
> 
> Thanks,
> Mary.
> DISPATCH WG co-chair
> 
> do this work?  This will help target the requirements draft 
> accordingly.
> 
> Yesterday, when we had a quick email exchange between authors 
> on where to submit it, sipcore and dispatch were the 
> candidates, and between them, dispatch was more appropriate.
> And given that to get work going in dispatch required a 
> "mini- charter", we went ahead and submitted one.
> 
> quite fit in the current xcon charter and deliverables (at 
> least as far as I can see it; I may be wrong, of course.)
> 
> Thanks,
> 
> - vijay
> --

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 11 Jun 2009 10:07:30 +0100

Hi,

I think that currently this discussion should continue to be in the
dispatch WG as the current status seems to fit exactly the Dispatch
charter.

In my opinion it does not belong in AVT as it does not require any
changes to media formats and I also don't think it belongs in XCON as it
really is not conferencing although I would agree it has some
similarity.

Regards
Andy

>Sent: 10 June 2009 22:28
>To: 'Alan Johnston'; 'Romascanu, Dan (Dan)'
>Cc: 'Leon Portman'; [email-masked]; 'Jain,Rajnish'; 'Hadriel Kaplan'
>[mailto:[email-masked]] On Behalf
>Of Alan Johnston

---

From: Roni Even <[email-masked]>
Date: Thu, 11 Jun 2009 13:47:34 +0300

Hi,
I looked at the suggested text and this is why I think it can be done in
XCON and that there are AVT aspects

The solution wants to record not only point to point calls since call center
scenarios include multipoint so it can be done in XCON instead of forming a
new WG . XCON is finishing its current charter and may get this as a new
charter.

As for the media, if you want to record multimedia RTP streams you need to
be able to synchronize between the separate streams (done in RTCP now), I
think Jonathan made this comment. You may also need to address the SRTP keys
if you want to keep the information secure. There is some drafts on the
topics currently in AVT. If not RTP is going to stored, you need to address
the storage format and require some transcoding capabilities on the record
server for audio and video unless you only want a G.711 solution. So if some
other packetization is needed maybe this is also AVT work

Roni Even

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Thursday, June 11, 2009 12:08 PM
To: Roni Even; Alan Johnston; Romascanu, Dan (Dan)
Cc: Leon Portman; [email-masked]; Jain,Rajnish; Hadriel Kaplan
Subject: RE: [dispatch] Session recording in SIP

Hi,

Regards
Andy

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 11 Jun 2009 08:05:05 -0500

Roni,

DISPATCH WG can tentatively agree that a work item is appropriate and
scoped for a particular WG. That's certainly non-binding as are any
decisions in any WG in terms of chartering new work items, until the ADs
approve. But, we can ask the ADs to move the work to the appropriate WG.

As far as how we decide how long to discuss a topic, that certainly
depends upon the topic. But, one of the reasons we set the early
deadlines for Stockholm was to get focused discussion on specific
topics, so that we could fairly quickly decide if and where work should
be done.  We do have the milestone of June 15th to finalize the topics
that are the focus for Stockholm and we are already in the process of
dispatching the items that were submitted on the appropriate deadlines.
We're doing those item by item so they're in the appropriate thread of
discussion and we'll provide a summary.  But, again, this topic has not
had enough discussion to make that decision yet. If the group comes to a
concensus on scope etc., then it may be possible to dispatch this item
prior to Stockholm or use f2f time if needed. 

Mary. 

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, June 11, 2009 12:08 AM
To: Barnes, Mary (RICH2:AR00); 'Vijay K. Gurbani'; [email-masked]
Subject: RE: [dispatch] Session recording in SIP

Mary,
This brings another question about dispatch, what does it mean that
dispatch decides that this should be for example a specific WG work.
(let's take XCON for example) 

If the assumption is correct, how do the chairs/Ads decide if to have a
long discussion in dispatch about the problem space and solution scope
or to move it to a working group and finish this discussion there in
order to expedite the work and not repeat the discussion.

Roni Even

-----Original Message-----
Behalf Of Mary Barnes

Thanks,
Mary.
DISPATCH WG co-chair

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

Thanks,

- vijay

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 11 Jun 2009 15:36:11 +0100

Hi,

I am sure that there are aspects of session recording that could require
work in AVT but I don't see that this is the focus of this proposed work
item which I think is to define the SIP requirements and possible SIP
protocol extensions that might be needed. 

I find it harder to see how this relates to XCON.

Regards
Andy

>Sent: 11 June 2009 11:48
>To: Hutton, Andrew; 'Alan Johnston'; 'Romascanu, Dan (Dan)'

---

From: Roni Even <[email-masked]>
Date: Thu, 11 Jun 2009 18:16:09 +0300

Andy,
You have a term called communication system in the proposal
Can you clarify what it is? Is this the end points in the call is this some
type of a proxy, application aware middle box?

There is also a recorder in the proposal, is this a SIP UA or is it just a
RTP terminating device like a "media server" in which case this is similar
to mediactrl WG work

Roni Even

-----Original Message-----
Of Hutton, Andrew
Sent: Thursday, June 11, 2009 5:36 PM

Hi,

Regards
Andy

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Jun 2009 14:42:45 -0400

> Sent: Thursday, June 11, 2009 11:16 AM
> 
> Andy,

Currently the proposed requirements would be to support a SIP UA be the communication system, i.e., the device which performs the replication from an active UA-to-UA call to a remote recording system may be either a phone, gateway, or a B2BUA-type middlebox.  Any SIP UA could logically perform that role.  I believe today some vendors do it in phones, others in middleboxes.
 
> RTP terminating device like a "media server" in which case this is similar

Well, one possible solution to address the requirements would be to make the recorder in fact a SIP UA. (for example there is a requirement to possibly be able to inject media back into the real UA-to-UA session)

I don't debate that it has obvious parallels with conferencing - I've even argued to others that it's almost like a 3-party conf call, but where one or two of the parties don't know it - but it has some other requirements/needs as well which really don't make it a traditional conference call scenario.

-hadriel

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 14:06:31 -0500

At 01:42 PM 6/11/2009, Hadriel Kaplan wrote:
>I don't debate that it has obvious parallels with conferencing - 
>I've even argued to others that it's almost like a 3-party conf 
>call, but where one or two of the parties don't know it -

Hadriel -- this is how I mostly see it also, at least as a foundation 
to work from.

>but it has some other requirements/needs as well which really don't 
>make it a traditional conference call scenario.
>
>-hadriel

---

From: Roni Even <[email-masked]>
Date: Thu, 11 Jun 2009 22:53:46 +0300

Hadriel,
I am still confused by the following text which was the reason for the
previous question

"This group will specify requirements for a SIP based protocol interface
between a communications system and a recorder. The Communications System is
responsible for establishing media sessions where the actual business is
conducted. The Recorder is the sink of the recorded media."

Can someone draw a figure showing the talking parties the Communication
system and the recorder and explain where is this interface. According to
your response I can think that there are at least two separate architectures
your are proposing one where the parties (or one of them) in the call know
the recorder and somehow forwards the media to it. The other architecture
has some B2BUA in the call path who is either forking the media to the
recorder and to the parties or the recorder is in the middle of the media
path.

My humble opinion is that a preferred solution will use a B2BUA in the call
path who will initiate the recording and this is why I was looking at XCON
or MEDIACTRL work in order to not develop a new protocol but leverage
existing ones.
Thanks
Roni 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, June 11, 2009 9:43 PM
To: Roni Even; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan (Dan)'
Cc: 'Leon Portman'; [email-masked]; 'Jain, Rajnish'
Subject: RE: [dispatch] Session recording in SIP

> type of a proxy, application aware middle box?

Currently the proposed requirements would be to support a SIP UA be the
communication system, i.e., the device which performs the replication from
an active UA-to-UA call to a remote recording system may be either a phone,
gateway, or a B2BUA-type middlebox.  Any SIP UA could logically perform that
role.  I believe today some vendors do it in phones, others in middleboxes.
 
> RTP terminating device like a "media server" in which case this is similar

Well, one possible solution to address the requirements would be to make the
recorder in fact a SIP UA. (for example there is a requirement to possibly
be able to inject media back into the real UA-to-UA session)

I don't debate that it has obvious parallels with conferencing - I've even
argued to others that it's almost like a 3-party conf call, but where one or
two of the parties don't know it - but it has some other requirements/needs
as well which really don't make it a traditional conference call scenario.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Jun 2009 18:51:28 -0400

Hey Roni,
Being a middlebox man myself, a B2BUA doing the media forking makes the most sense to me too, but some other folks don't do it/want-it that way.  So the proposed work is to cover both potential models.

The statement you cite reflects the belief that the solution to the requirements will be to use SIP between the UA doing the media forking, and the recorder doing the collection; and that the work of specification will be to define that.

So one diagram could be this, where "TBD" is the To-Be-Defined work:

   +-----+              +-----+
   |     |   Call       |     |
   |UA-A +<------------>+UA-B |
   |     |              |     |
   +-++--+              +-----+
      \\
       \\
    TBD \\
         \\+----------+
          \+          |
           + Recorder |
           |          |
           +----------+

Or this:

+-----+              +-----+              +-----+
|     |     Call     |     |   Call       |     |
|UA-A +<------------>+B2BUA+<------------>+UA-B |
|     |              |     |              |     |
+-----+              +-++--+              +-----+
                        \\
                         \\
                      TBD \\
                           \\+----------+
                            \+          |
                             + Recorder |
                             |          |
                             +----------+

-hadriel

> Sent: Thursday, June 11, 2009 3:54 PM
> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan
> (Dan)'

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jun 2009 19:11:26 -0400

> So one diagram could be this, where "TBD" is the To-Be-Defined work:

This model actually can make a lot of sense in *some* circumstances.
For instance, in a call center, where you may have control over what 
components are used throughout, it could make sense to do the media 
forking for recording and monitoring right at the agent phone.

But in those sorts of monitoring/recording we don't talk about in IETF, 
its essential that the recorded parties not be able to distinguish calls 
that are monitored from those that are not. Anything that requires 
cooperation by one of the endpoints is a no-go. Even something as simple 
as a middlebox replacing one media port with another in order to 
initiate monitoring might be enough to clue in the monitored parties. So 
  in those cases you had better have a way that looks exactly the same 
whether recording is happening or not, which generally requires 
something like your picture below.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 21:13:08 -0500

At 06:11 PM 6/11/2009, Paul Kyzivat wrote:

>Hadriel Kaplan wrote:
>>Hey Roni,
>>Being a middlebox man myself, a B2BUA doing the media forking makes 
>>the most sense to me too, but some other folks don't do it/want-it 
>>that way.  So the proposed work is to cover both potential models.
>>The statement you cite reflects the belief that the solution to the 
>>requirements will be to use SIP between the UA doing the media 
>>forking, and the recorder doing the collection; and that the work 
>>of specification will be to define that.

Paul - how is your call center example *not* better accomplished with 
the figure below instead of the figure above?

It seems to me that any enterprise based call center would have to 
have a SIP server of some form (i.e., the caller is not going to have 
a pt-to-pt SIP established session directly with a call center call 
taker). It seems much easier if that call center wants to record 
calls (even some of the calls, that to the caller, the B2BUA is the 
UAS, meaning the sRTP keys only have to be between the caller and the 
B2BUA, and not all the way to the call taker.  In this scenario, the 
B2BUA merely replicates the RTP stream out towards the recording 
device with RTCP in tact, an can allow the B2BUA provide any meta 
data about the specifics of the call signaling it wants to also store.

This scenario also means the caller is never aware the call is being 
recorded, creating anonymity wrt that facet of the solution.

I'm not advocating B2BUAs here, I just see this as a better solution 
for call center type recording than pt-to-pt between caller and call taker.

>But in those sorts of monitoring/recording we don't talk about in 
>IETF, its essential that the recorded parties not be able to 
>distinguish calls that are monitored from those that are not. 
>Anything that requires cooperation by one of the endpoints is a 
>no-go. Even something as simple as a middlebox replacing one media 
>port with another in order to initiate monitoring might be enough to 
>clue in the monitored parties. So  in those cases you had better 
>have a way that looks exactly the same whether recording is 
>happening or not, which generally requires something like your picture below.
>
>         Thanks,
>         Paul
>
>>Or this:
>>
>>+-----+              +-----+              +-----+
>>|     |     Call     |     |   Call       |     |

---

From: Alan Johnston <[email-masked]>
Date: Thu, 11 Jun 2009 22:39:14 -0500

These various models and modes of recording are described in

      http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-5

To summarize some of the arguments for forking the media in the middle 
as opposed to doing it in an endpoint:

1.  Requirements to use basic UAs without any extensions
2.  Not always having double the media bandwidth in endpoints, 
especially when they are remote
3.  The recording mode (always on, on demand, required, pause and 
resume) and policy is usually controlled centrally, and so another 
protocol would be needed to tell the UA to start and stop recording.

Thanks,
Alan

James M. Polk wrote:
>>> forking, and the recorder doing the collection; and that the work of 
>>> specification will be to define that.
> taker). It seems much easier if that call center wants to record calls 
> (even some of the calls, that to the caller, the B2BUA is the UAS, 
> meaning the sRTP keys only have to be between the caller and the 
> device with RTCP in tact, an can allow the B2BUA provide any meta data 
> about the specifics of the call signaling it wants to also store.
>
>> clue in the monitored parties. So  in those cases you had better have 
>> a way that looks exactly the same whether recording is happening or 
>> not, which generally requires something like your picture below.
>>
>>         Thanks,
>>         Paul
>>
>>> Or this:
>>>
>>> +-----+              +-----+              +-----+
>>> |     |     Call     |     |   Call       |     |
>>>> between a communications system and a recorder. The Communications 
>>>> System
>>>> is

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 11 Jun 2009 20:42:31 -0700

I agree with James.

There are *some* scenarios where the UA-initiated recording will work, but
they are very limited. They have the following disadvantages:
1- It makes the client "aware" that it is being recorded
2- It makes it very easy to avoid being recorded by interrupting the media
stream
3 - It makes it much easier to "dispute" (i.e., lawyers) the authenticity of
a recorded conversation if there is potential for significant differences in
the streams as seen by different ends
4 - It doubles the bandwidth requirements on the UA, which can be a problem
in some scenarios
5 - It doubles the processing power required in the client (think SRTP/key
negotiation & al). This can be a problem with many phones.
6 - They require phones that actually support this. Which means, you can't
use "normal" SIP phones. Which means,  if you get the $30 phone, you don't
get tapped into, but if you get the $300 phone, you don't.

But UA-initiated recording has very few advantages:
1 - Less work on servers. This is actually a big advantage because lots of
servers are so complex, it is difficult to do anything new on them.
2 - Looks much more abstract and cool in an IETF RFC :-)

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Jun 2009 23:54:26 -0400

Sure there are advantages/disadvantages to each model, but why bother arguing over it?  I think we probably all agree we need to support at least a B2BUA model, so once you have to standardize that doesn't the UA model come for virtually free?  (i.e., I would presume the details of a B2BUA model are either a superset or the same as a single UA model, not less)

-hadriel

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 12 Jun 2009 00:05:34 -0500

I'm not sure the UA model does "come for free", give there needs to 
be new code telling the UA to all of a sudden replicate the media 
stream (if it can) back out (which may or may not have the BW or the 
reachability to the sink device).  If the original media is sRTP, 
does this (or not) mean sRTP needs to be used to the media sink? That 
takes more negotiation (and time). Does the sink always trust what 
comes at it from any UA? It can be configured much more easily to 
trust certain (limited number of) servers that can send it media to record.

I could be wet behind the ears, but I don't believe the UA model is 
low hanging fruit if the server model is specified. I (think I) see 
each as completely separate solutions, requiring however much work to 
do regardless of whether the other is done too (other than having the 
recording sink specified/developed -- that part is free once it is 
done for either model).

This is an interesting problem space, and I think we should look into 
it. I think there will be more than we expect once we peel away the layers.

James

At 10:54 PM 6/11/2009, Hadriel Kaplan wrote:

>Sure there are advantages/disadvantages to each model, but why 
>bother arguing over it?  I think we probably all agree we need to 
>support at least a B2BUA model, so once you have to standardize that 
>doesn't the UA model come for virtually free?  (i.e., I would 
>presume the details of a B2BUA model are either a superset or the 
>same as a single UA model, not less)
>
>-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jun 2009 01:35:34 -0400

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, June 12, 2009 1:06 AM
> 

When I say "for free" I sure don't mean code-wise. :)
I meant from a protocol specification perspective.  Any protocol issue I can imagine of a UA would be likewise true of a B2BUA in any spec we define.  Can you think of any that aren't?

For example, in some recording applications, a B2BUA has to tear down the call (or not allow it to begin with) if it does not have sufficient bandwidth or reachability to the recorder.  Though I'm not sure the spec has to say much about that - seems more of a local policy decision not affecting interoperability.

Likewise any authentication of devices and protection of replicated media will undoubtedly need to be covered in any RFC we try to do, no matter the model, if nothing else than to get past the IESG. (and in practice I've been told there are some cases where the recorders are not in the same domain of the servers either, so having such measures is appropriate)  I have no doubt that in real-world practice many folks who deploy a server model would just skip most of that, but I doubt we'll be able to avoid it in an RFC.

-hadriel

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 12 Jun 2009 08:48:00 +0200

Hi, 

> If the original media is sRTP, does this (or not) mean sRTP 
> needs to be used to the media sink? That takes more 
> negotiation (and time). Does the sink always trust what comes 
> at it from any UA? It can be configured much more easily to 
That is one point we adressed in
http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#page-15 by
using a setup, were the call recording is done on the media way and the
client just discloses the session key. This saves an extra encryption
between the client and the recorder.

Steffen

> 
> I could be wet behind the ears, but I don't believe the UA 
> model is low hanging fruit if the server model is specified. 
> I (think I) see each as completely separate solutions, 
> requiring however much work to do regardless of whether the 
> other is done too (other than having the recording sink 
> specified/developed -- that part is free once it is done for 
> either model).
> 
> This is an interesting problem space, and I think we should 
> look into it. I think there will be more than we expect once 
> we peel away the layers.
> 
> James
> 
> >Sure there are advantages/disadvantages to each model, but 
> why bother 
> >arguing over it?  I think we probably all agree we need to 
> support at 
> >least a B2BUA model, so once you have to standardize that 
> doesn't the 
> >UA model come for virtually free?  (i.e., I would presume 
> the details 
> >of a B2BUA model are either a superset or the same as a single UA 
> >model, not less)
> >
> >-hadriel
>

---

From: Roni Even <[email-masked]>
Date: Fri, 12 Jun 2009 10:21:16 +0300

Hadriel,
I think that there may be a different protocol if you use the B2BUA
solution. In this case it will make more sense to use a "mediactrl"
direction where SIP is used to open a control channel to the recorder but
the recording protocol itself runs in the  control channel. This control
channel will be also used to deliver the meta data for the recording. So
maybe the sentence  " SIP based protocol interface between a communications
system and a recorder" is limiting the solution space.

Roni Even

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 8:36 AM
To: James M. Polk; Francois Audet; Paul Kyzivat
Cc: 'Leon Portman'; [email-masked]; 'Jain, Rajnish'; Roni Even
Subject: RE: [dispatch] Session recording in SIP

When I say "for free" I sure don't mean code-wise. :)
I meant from a protocol specification perspective.  Any protocol issue I can
imagine of a UA would be likewise true of a B2BUA in any spec we define.
Can you think of any that aren't?

For example, in some recording applications, a B2BUA has to tear down the
call (or not allow it to begin with) if it does not have sufficient
bandwidth or reachability to the recorder.  Though I'm not sure the spec has
to say much about that - seems more of a local policy decision not affecting
interoperability.

Likewise any authentication of devices and protection of replicated media
will undoubtedly need to be covered in any RFC we try to do, no matter the
model, if nothing else than to get past the IESG. (and in practice I've been
told there are some cases where the recorders are not in the same domain of
the servers either, so having such measures is appropriate)  I have no doubt
that in real-world practice many folks who deploy a server model would just
skip most of that, but I doubt we'll be able to avoid it in an RFC.

-hadriel

---

From: Roni Even <[email-masked]>
Date: Fri, 12 Jun 2009 10:27:16 +0300

James,
The B2BUA does not need to see the RTP/RTCP stream they can go directly from
the source to the recorder 

+-----+              +-----+              +-----+
|     |     Call     |     |   Call       |     |
    .                   \\                   .
      .                  \\ control          .
         .  RTP       TBD \\                 .RTP
             .             \\+----------+    .
                .           \+          |..... 
                      .      + Recorder |
                             |          |
                             +----------+

Roni

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Jun 2009 13:59:50 +0200

I have no response to any of the other points, but please note that for 1), in the scenarios of call centres, some jurisdictions do require the client to be informed that the call is being recorded. Normally this is done by a verbal announcement.

So in those use cases, 1) is a non-argument.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: Friday, June 12, 2009 4:43 AM
> To: James M. Polk; Paul Kyzivat; Hadriel Kaplan
> There are *some* scenarios where the UA-initiated recording 
> will work, but they are very limited. They have the following 
> disadvantages:
> 2- It makes it very easy to avoid being recorded by 
> interrupting the media stream
> 3 - It makes it much easier to "dispute" (i.e., lawyers) the 
> authenticity of a recorded conversation if there is potential 
> for significant differences in the streams as seen by different ends
> 4 - It doubles the bandwidth requirements on the UA, which 
> can be a problem in some scenarios
> 5 - It doubles the processing power required in the client 
> (think SRTP/key negotiation & al). This can be a problem with 
> many phones.
> 6 - They require phones that actually support this. Which 
> means, you can't use "normal" SIP phones. Which means,  if 
> you get the $30 phone, you don't get tapped into, but if you 
> get the $300 phone, you don't.
> 
> 
> 1 - Less work on servers. This is actually a big advantage 
> because lots of servers are so complex, it is difficult to do 
> anything new on them.
> >>>                              +----------+ -hadriel
> >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 
> 'Romascanu, 
> >>>> Dan (Dan)'
> >>>> I am still confused by the following text which was the 
> reason for 
> >>>> the previous question
> >>>> 
> >>>> "This group will specify requirements for a SIP based protocol 
> >>>> sessions where the actual business is conducted. The Recorder is 
> >>>> the sink of the recorded media."
> >>>> 
> >>>> 
> >>>> Can someone draw a figure showing the talking parties the 
> >>>> Communication system and the recorder and explain where is this 
> >>>> interface. According to your response I can think that 
> there are at 
> >>>> least two separate architectures your are proposing one 
> where the 
> >>>> parties (or one of them) in the call know the recorder 
> and somehow 
> >>>> forwards the media to it. The other architecture has 
> some B2BUA in 
> >>>> the call path who is either forking the media to the 
> recorder and 
> >>>> to the parties or the recorder is in the middle of the 
> media path.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jun 2009 09:12:04 -0400

James M. Polk wrote:
> It seems to me that any enterprise based call center would have to have 
> a SIP server of some form (i.e., the caller is not going to have a 
> pt-to-pt SIP established session directly with a call center call 
> meaning the sRTP keys only have to be between the caller and the B2BUA, 
> and not all the way to the call taker.  In this scenario, the B2BUA 
> merely replicates the RTP stream out towards the recording device with 
> RTCP in tact, an can allow the B2BUA provide any meta data about the 
> specifics of the call signaling it wants to also store.
> 
> I'm not advocating B2BUAs here, I just see this as a better solution for 
> call center type recording than pt-to-pt between caller and call taker.

There are pros and cons.
I agree that many implemenations *will* have a central server in any 
case. Routing *all* the media through a central server has resource 
costs, especially if you then require redundancy as well. Often forking 
media at the phone can be "free" in that it is well within the 
capabilities of even a cheap sip phone.

The point is that there are complex architectural tradeoffs here based 
on individual priorities, so it makes sense to consider both as viable.

>> distinguish calls that are monitored from those that are not. Anything 
>> that requires cooperation by one of the endpoints is a no-go. Even 
>> something as simple as a middlebox replacing one media port with 
>> another in order to initiate monitoring might be enough to clue in the 
>> monitored parties. So  in those cases you had better have a way that 
>> looks exactly the same whether recording is happening or not, which 
>> generally requires something like your picture below.
>>
>>         Thanks,
>>         Paul
>>
>>> Or this:
>>>
>>> +-----+              +-----+              +-----+
>>> |     |     Call     |     |   Call       |     |
>>>> interface

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 12 Jun 2009 15:22:06 +0200

Hi, 

>There are pros and cons.
>I agree that many implemenations *will* have a central server 
>in any case. Routing *all* the media through a central server 
>has resource costs, especially if you then require redundancy 
>as well. Often forking media at the phone can be "free" in 
>that it is well within the capabilities of even a cheap sip phone.

It may have impacts on battery- and/or CPU limited devices.

In addtion media forking at the phone may have resource cost on the
access network, if you have limited resources on your access network and
both the UA-to-UA and UA-to-recorder media has to be sent over that
access network.

Regards,

Christer

> 
> The point is that there are complex architectural tradeoffs 
> here based on individual priorities, so it makes sense to 
> consider both as viable.
> 
> >>>> Communication system and the recorder and explain where 
> is this interface.
> >>>> According to
> >>>> your response I can think that there are at least two separate 
> >>>> architectures your are proposing one where the parties 
> (or one of 
> >>>> them) in the call know the recorder and somehow forwards 
> the media 
> >>>> to it. The other architecture has some B2BUA in the call 
> path who 
> >>>> is either forking the media to the recorder and to the 
> parties or 
> >>>> the recorder is in the middle of the media path.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 12 Jun 2009 10:05:27 -0500

You are correct. 

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Friday, June 12, 2009 05:00
> To: Audet, Francois (SC100:3055); James M. Polk; Paul 
> Kyzivat; Hadriel Kaplan
> I have no response to any of the other points, but please 
> note that for 1), in the scenarios of call centres, some 
> jurisdictions do require the client to be informed that the 
> call is being recorded. Normally this is done by a verbal 
> announcement.
> 
> will work, 
> > but they are very limited. They have the following
> > disadvantages:
> > authenticity of a recorded conversation if there is potential for 
> > significant differences in the streams as seen by different ends
> > 4 - It doubles the bandwidth requirements on the UA, which can be a 
> > problem in some scenarios
> > 5 - It doubles the processing power required in the client (think 
> > SRTP/key negotiation & al). This can be a problem with many phones.
> means, you 
> > can't use "normal" SIP phones. Which means,  if you get the 
> $30 phone, 
> > you don't get tapped into, but if you get the $300 phone, you don't.
> > 
> > 
> > 1 - Less work on servers. This is actually a big advantage because 
> > lots of servers are so complex, it is difficult to do 
> anything new on 
> > them.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jun 2009 15:48:50 -0400

I agree that assuming SIP is the protocol between the recordee and the recorder is probably premature, but I still don't see it as making us have to choose whether to support a UA vs. a B2BUA.  

I mean even from a logical perspective, a UA could just pretend to be an integrated B2BUA to itself and who would know?  I.e., this:

            UA-A
   +----------------------+
   | +-----+      +-----+ |            +-----+
   | |     |      |     | | Call       |     |
   | | UA  +<---->+B2BUA+<+----------->+UA-B |
   | |     |      |     | |            |     |
   | +-----+      +-++--+ |            +-----+
   +-----------------\\---+
                      \\
                   TBD \\
                        \\+----------+
                         \+          |
                          + Recorder |
                          |          |
                          +----------+

-hadriel

> Behalf Of Roni Even
> Sent: Friday, June 12, 2009 3:21 AM
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Jun 2009 15:50:34 -0400

I'll add - from a dispatch perspective - that the liveliness of this 
discussion, and the breadth of opinions/options on architecture - show 
pretty clearly that this is big enough to warrant its own group, rather 
than just another thing to do in AVT or XCON.

-Jonathan R.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jun 2009 16:08:04 -0400

Huh, interesting idea.  I don't see how that could easily work though.  The recorder needs to be able to associate specific audio streams with specific calls, and from which called/calling party they came.  Unless there's a control channel between each UA and the recorder, you'd have to somehow get the B2BUA to know what IP:port each UA can send the forked media from, and provide each UA with the addr:port of the Recorder to send the forked media to.  Not to mention if we decide to allow a different codec to be used on the forked-media connection vs. the in-call side (which I personally don't like the idea of but others do).  At the end of the day, I'd bet you'd have one complicated protocol for all that to occur, with a bunch of re-INVITEs/UPDATEs and all kinds of whacked corner-cases with pre-conditions, and IPv4/v6, and god-knows-what else.  :)

-hadriel

> Sent: Friday, June 12, 2009 3:27 AM
> 
> James,

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 12 Jun 2009 17:04:13 -0400

> than just another thing to do in AVT or XCON.

I certainly support getting some clarity around how to do this cleanly.

I'm not crazy about some of the ideas thrown around so far, but the need
is clear.  I also agree with previous posters that while this overlaps
with XCON and some other things, it's really a distinct problem and
would probably be solvable more quickly in a more focused setting.  One
of the major ideas behind our recent reorg was that smaller, more
time-limited WGs will work better than the perpetual ones we've been
using.

---

From: Roni Even <[email-masked]>
Date: Sat, 13 Jun 2009 00:07:17 +0300

Hadriel,
This is what mediactrl is about. Look in http://tools.ietf.org/html/rfc5567 

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Friday, June 12, 2009 11:08 PM
To: Roni Even; 'James M. Polk'; 'Paul Kyzivat'
Cc: 'Leon Portman'; [email-masked]; 'Jain, Rajnish'
Subject: Re: [dispatch] Session recording in SIP

Huh, interesting idea.  I don't see how that could easily work though.  The
recorder needs to be able to associate specific audio streams with specific
calls, and from which called/calling party they came.  Unless there's a
control channel between each UA and the recorder, you'd have to somehow get
the B2BUA to know what IP:port each UA can send the forked media from, and
provide each UA with the addr:port of the Recorder to send the forked media
to.  Not to mention if we decide to allow a different codec to be used on
the forked-media connection vs. the in-call side (which I personally don't
like the idea of but others do).  At the end of the day, I'd bet you'd have
one complicated protocol for all that to occur, with a bunch of
re-INVITEs/UPDATEs and all kinds of whacked corner-cases with
pre-conditions, and IPv4/v6, and god-knows-what else.  :)

-hadriel

---

From: Roni Even <[email-masked]>
Date: Sat, 13 Jun 2009 00:14:53 +0300

Hi,
I think that RAI have two wgs working on different aspects of a central
server. One is XCON and the other is Mediactrl. I think that once an
architecture for the recorder is specified it may be just another
application (recording application) that can be based on one of these two
WGs work. 
Recording is just another application for a central server or media server
like conferencing, IVR, and others. Recording was even discussed in
mediactrl but there were no requirement at the time.

Roni Even 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Scott Lawrence
Sent: Saturday, June 13, 2009 12:04 AM
To: [email-masked]
Subject: Re: [dispatch] Session recording in SIP

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Jun 2009 17:54:19 -0400

I was about to write a long-winded reply on how your example was not the same as mediactrl, but I just realized your drawing was subtly different from what I had thought it implied. :)  The example you're describing is one where the recorder is not being sent forked/replicated media content by the UA's, but is just put in the media path itself for the real media, so the original media itself is going from UA to recorder to UA. 
Right?

If so, good point - I assume that's one possible deployment model to use.  I don't think it's how some (most?) people do it, because they can't or don't want to move the media path from where it began, especially for the UA side that's outside their domain.  (though I dunno much about why they do what they do)  But it is one interesting solution.

-hadriel

> Sent: Friday, June 12, 2009 5:07 PM
> To: Hadriel Kaplan; 'James M. Polk'; 'Paul Kyzivat'
> Behalf

---

From: Roni Even <[email-masked]>
Date: Sun, 14 Jun 2009 09:47:44 +0300

Hi,
This is a good observation but in the conferencing case you can have the
media coming not from the UAs but from the media mixer or have the mixer
functionality as part of the recorder. 

I understand the UA forking scenario for the call center application where
the UAs in the call center will be required to support this functionality.
Note that in this case if you have a multipoint video call you are recording
just what the UA receives (you record the view point of the recording UA)
and not the whole conference. If the handling UA is recording you may also
miss in the call center scenario any side discussion between the customer
and a supervisor if the handling UA is excluded from this part, in some
cases he will not even know about being kept out of some side call.
 
The general case is where you want to record a call but do not have the
media forking and recording application on your UA. In this case my view is
that you will need a recording application server in the network. It will
need to record both point to point and multipoint calls. It can be like
suggested by Hadriel where the RTP streams are forked by the Application
Server (note that I am not calling it a general B2BUA) or using a decomposed
Application Server like the mediactrl architecture.  

Roni Even

-----Original Message-----
From: Jain, Rajnish [mailto:[email-masked]] 
Sent: Sunday, June 14, 2009 4:54 AM
To: Hadriel Kaplan; Roni Even; 'James M. Polk'; 'Paul Kyzivat'
Cc: 'Leon Portman'; [email-masked]
Subject: RE: [dispatch] Session recording in SIP

I think the UA-UA RTP line was missing in the diagram. Otherwise, the
recorder is being expected to do conferencing (assuming more than 2 recordee
UAs) and transcoding. That's really not the purpose of the recorders.

--
Raj Jain

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, June 12, 2009 5:54 PM
To: Roni Even; 'James M. Polk'; 'Paul Kyzivat'
Cc: 'Leon Portman'; [email-masked]; Jain, Rajnish
Subject: RE: [dispatch] Session recording in SIP

I was about to write a long-winded reply on how your example was not the
same as mediactrl, but I just realized your drawing was subtly different
from what I had thought it implied. :)  The example you're describing is one
where the recorder is not being sent forked/replicated media content by the
UA's, but is just put in the media path itself for the real media, so the
original media itself is going from UA to recorder to UA.
Right?

If so, good point - I assume that's one possible deployment model to use.  I
don't think it's how some (most?) people do it, because they can't or don't
want to move the media path from where it began, especially for the UA side
that's outside their domain.  (though I dunno much about why they do what
they do)  But it is one interesting solution.

-hadriel

> > the source to the recorder

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: Sat, 13 Jun 2009 21:54:25 -0400

I think the UA-UA RTP line was missing in the diagram. Otherwise, the recorder is being expected to do conferencing (assuming more than 2 recordee UAs) and transcoding. That's really not the purpose of the recorders.

--
Raj Jain

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, June 12, 2009 5:54 PM
To: Roni Even; 'James M. Polk'; 'Paul Kyzivat'
Cc: 'Leon Portman'; [email-masked]; Jain, Rajnish
Subject: RE: [dispatch] Session recording in SIP

-hadriel

> > the source to the recorder

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: Sun, 14 Jun 2009 21:42:31 -0400

Hi,

Inline:

> Sent: Sunday, June 14, 2009 2:48 AM
> To: Jain, Rajnish; 'Hadriel Kaplan'; 'James M. Polk'; 'Paul Kyzivat'

I think it'll help to model the mixer and the recorder as separate logical entities. The mixer can feed the recorder if a conference call needs to be recorded. Or the mixer can be used as a tapping device in case of non-forking UAs. Below is how I'd draw it (control path from app server to recorder not shown for brevity):

           SIP   +------------+ SIP
      /----------| App Server |--------
     /           +------------+        \
    /                   |SIP            \
   /                    |                \
+-----+              +-----+              +-----+
|     |     RTP      |     |   RTP        |     |
|UA-A +<------------>+Mixer+<------------>+UA-B |
|     |              |     |              |     |
+-----+              +-++--+              +-----+
                      |   |
           RTP UA-A   |   | RTP UA-B (Rx+Tx)
           (Rx+Tx)    V   V
                   +----------+
                   |          |
                   | Recorder |
                   |          |
                   +----------+

> cases he will not even know about being kept out of some side call.

Yes, you typically record the view point of the recording UA. But, there may be requirement to record a conference call as opposed to individual participants to save disk space.

> Application Server like the mediactrl architecture.

Yes. I agree that an application server will compensate for non-forking UAs, but I think the RTP streams will be forked by the media server and not the application server. The application server will dictate the media server to do so. The diagram above reflects this arrangement.

--
Raj Jain

---

From: "Doken, Serhad" <[email-masked]>
Date: Thu, 18 Jun 2009 01:04:15 -0700

> Behalf Of James M. Polk
> Sent: Wednesday, June 10, 2009 3:00 PM
> To: Roni Even; 'Alan Johnston'; 'Romascanu, Dan (Dan)'
> Cc: 'Leon Portman'; [email-masked]; 'Jain, Rajnish'; 'Hadriel
> Kaplan'

As someone who have implemented SIP based recording which has been shipping for several years, this thread caught my eye though I haven't read the whole lively set of e-mails yet. 

In most enterprise contact center environments(say 1-800-2CALLME), caller(let's call him customer) will get an announcement of some sort like "This call may/will be monitored/recorded for quality purposes" at the beginning of the call. For limited cases, customer has a chance to accept/reject that or if refuses he/she can hang up. Called party(Agent) as an employee is almost always aware that call may be recorded since contact center businesses collect quality and business analytic data based on those recordings. Moreover, in some deployments, periodic recording tones are played towards customer and agent phones to alert/remind them that call is being recorded. It could be the case that sometimes all calls are recorded or sometimes calls to a particular set of agent phones are recorded.

On the other hand, a supervisor monitoring a conversation between a customer and agent may decide to record that conversation, at any random point, simply triggering it via a CTI application that is running on his desktop for the whole call duration or may wish to stop that recording at any random point.

Serhad

---

From: "Doken, Serhad" <[email-masked]>
Date: Thu, 18 Jun 2009 10:24:21 -0700

Comment on (6) : 

Once people pay for an expensive SIP Phone with fair Dsp power, they expect that endpoint trigger the recording/fork the stream towards the recorder(s) as well. For those cases, it's hard to convince folks/justify the need to increase the resources on the server/B2BUA/gateway to do recording for many endpoints when an endpoint itself is capable of doing so.

Moreover, forking a stream is not all that expensive(cpu intensive). A phone, even a basic one, that can do 3-way conferencing can easily make a copy of a stream and send somewhere else. 

Serhad

> Behalf Of Francois Audet
> Sent: Thursday, June 11, 2009 8:43 PM
> authenticity of
> problem
> SRTP/key
> Communication
> >>>> architectures

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Jun 2009 11:58:19 -0700

Scott and Mary nicely expressed what I was thinking about where to run  
this discussion.

On Jun 12, 2009, at 14:04 , Scott Lawrence wrote:

>  I also agree with previous posters that while this overlaps

> the problem space and solution scope.

Lets focus the conversation on what is the problem to solve, what's  
the big picture, what needs to be standardized then we can send the  
right parts off to an existing group or form a new WG and do the  
technical work of developing the standard.

Cullen <RAI AD>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Jun 2009 12:05:42 -0700

I look forward to reading the requirements draft when that comes out  
as it may answer this but ...

>>> A prime example where

So in the case where a customer is talking to an agent, my  
understanding is that some of the deployments (often legal compliance  
type situations) require an accurate recording of what the agent heard  
while other sorts of deployments may (perhaps a post call statistical  
analysis) only care about  an best effort approximation of the call.  
So in the first case, if the call could not be recorded, the call  
would not be set up but in the second case, the call would go ahead  
regardless.

I'm assuming the scope of the work would cover both case. Does that  
sound about right to others?

Cullen <with my individual contributor hat on>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 18 Jun 2009 16:26:33 -0500

> sound about right to others?

Yes - we need to cover the various modes.  We described four in our 
draft (http://tools.ietf.org/html/draft-wing-sipping-srtp-key):

1. Always On Recording
2. Recording On Demand
3. Required Recording
4. Pause and Resume Recording

There may be others as well, but these cover all the ones we support in 
our systems today.  Some are different by policy, others are different 
in actual call flows.

Thanks,
Alan