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

From: Leon Portman <[email-masked]>
Date: Sun, 2 May 2010 13:00:09 +0300

Peter, H

Usually we are trying not to put recorder in the middle of the communication session in order not to make it a critical element in the call setup.
What you are suggesting in item 2 is possible and can be done either by EP or by PBX itself, where actual Recording Server became B2BUA. However then it will be just specific case of B2BUA recording use case where B2BUA (like media server or conference server) and RS are the same element.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Musgrave
Sent: Thursday, April 29, 2010 11:59 PM
To: Hutton, Andrew
Cc: [email-masked]
Subject: Re: [siprec] FW: I-D Action:draft-hutton-siprec-session-recording-arch-00.txt

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

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 2 May 2010 08:50:58 -0400

Hi Leon,

I agree that making the recorder non-critical in call setup is a good
idea. In the B2B architecture in 4.1.1 I view the B2B as an essential
a part of the recording function.  i.e. I think the RS box really
includes the B2B. If I do not normally want to call through a B2B this
architecture requires me to do so for every call which I might want to
record and I might not know this in advance - so that means I am
forced onto the B2B for every call and need to fail over to direct
calling if it is not present.

I still think a RS which can insert itself into only the media path
via 3PCC after call establishment could be a useful architecture. I
agree it then becomes a critical element - much as the B2B is in 4.1.1
(since it has inserted itself into the media path in order to tap a
stream for the RS).

There may be valid reasons this architecture does not suit some
situations - but I still see it as a viable choice and consistent with
a lot of the 3PCC media server stuff routinely done in SIP.

Regards,

Peter Musgrave

---

From: Leon Portman <[email-masked]>
Date: Sun, 2 May 2010 15:54:24 +0300

Peter, Hi

I agree that it is a valid option. I was just raising the point that it probably a special case of the first configuration from the draft: 
"4.1.1.  B2BUA acts as a Recording Client" where RS and RC the same entity.

Leon

-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: Sunday, May 02, 2010 3:51 PM
To: Leon Portman
Cc: Hutton, Andrew; [email-masked]
Subject: Re: [siprec] FW: I-D Action:draft-hutton-siprec-session-recording-arch-00.txt

Hi Leon,

Regards,

Peter Musgrave

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 2 May 2010 10:08:34 -0400

Hi Leon,

I see it as distinct since the media path is relayed and the
signalling is direct. I tend to view B2B as something that has a
signalling relay in the path, callId changes etc. Since a B2B is not
required and 4.1.1 is "B2B acts as recording client", I think it might
be clearer as a separate case.

In any event I'm glad we agree it's viable.

Peter

---

From: Leon Portman <[email-masked]>
Date: Mon, 3 May 2010 16:16:41 +0300

I agree with the roles definitions. In general we have three layers of roles:
1. SIP level - initiation of the recording session
2. Media level - actual media forking/cloning 
3. Recording initiation level - optional flow between external entity like Agent desktop application or button on the phone and RC/RS (currently out of scope)
However I don’t think that we should classify recording session as a conference, it is only specific use case where recording is done by creating a conference call with RS as a participant.

Leon

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, May 03, 2010 4:10 PM
To: Peter Musgrave; Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] FW: I-D Action:draft-hutton-siprec-session-recording-arch-00.txt

<as individual>
Let's make sure we separate the element that is cloning media from the
element that is arranging SIP sessions.  They sometimes interact.  Some of
the possibilities I think occur are
A) There is a B2BUA in the path of all calls, it handles the SIP session and
either it is or it controls the element that clones media
B) One end is recording aware, it clones media itself or arranges
connections to include the media cloner.
C) All calls are answered at a bridge, and the recorder is invited to the
conference either automatically by the bridge or at the invitation of one
end

Is the "3PCC" case one of those?

Brian

On 5/2/10 8:50 AM, "Peter Musgrave" <[email-masked]> wrote:

>> Usually we are trying not to put recorder in the middle of the communication
>> session in order not to make it a critical element in the call setup.
>> What you are suggesting in item 2 is possible and can be done either by EP or
>> by PBX itself, where actual Recording Server became B2BUA. However then it
>> will be just specific case of B2BUA recording use case where B2BUA (like
>> media server or conference server) and RS are the same element.
>> 
>> Leon
>> 
>> Subject: Re: [siprec] FW: I-D
>> Action:draft-hutton-siprec-session-recording-arch-00.txt
>> 
>> Hi Andrew,
>> 
>>> 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.
>>>

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 3 May 2010 10:34:49 -0400

HI Brian,

I think your 'taxonomy' is a good idea.

The 3PCC case would fit into B) it "arranges the connections to
include the media cloner"

Peter Musgrave

---

From: Brian Rosen <[email-masked]>
Date: Mon, 03 May 2010 09:10:01 -0400

<as individual>

Brian

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 4 May 2010 20:24:07 +0530

Hi Andrew,

I have a comment with respect to the Mechanisms for delivery of Metadata
to Recording Server. I see from Section 4.3.2 that there are two
mechanisms mentioned
Using a new event package 
INFO package

Can we add another requirement here saying metadata could be carried in
a INVITE also ? I do believe we need to look at carrying metadata in
INVITE also along with the above mentioned delivery mechanisms.

Regards,
Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hutton, Andrew
Sent: Thursday, April 29, 2010 11:04 PM
To: [email-masked]
Subject: [siprec] FW:
I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

-----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-recordin
g-arch-00.txt

---

From: Brian Rosen <[email-masked]>
Date: Tue, 04 May 2010 11:21:49 -0400

<as individual>
Hmmmm

An event package is easy, the data is carried in the event subscription
and/or NOTIFY.

INVITE is a bit trickier - you carry it in the body of the message, and what
we need is a new MIME type.  Not too bad, and if it's available then, why
send more messages?

You would use INFO if the metadata came after the session is established.
On the other hand, if you defined it for INVITE, then reINVITE could be
after the session was established.

Generally, I'm not an INFO fan, but with INFO packages, it's less yucky.

So I guess the question is when does the data become available?  Are we
thinking the event package is JUST for the metadata, or is metadata tagging
along with something else?

I assumed it was available right from the beginning, in which case carrying
it in the INVITE may be all you need, with the possibility of a reINVITE if
you needed to change it mid stream.

Brian

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 5 May 2010 09:53:29 +0200

I am not sure that using INVITE is a good idea for a number of reasons.

It is going to need the INVITE to use a multipart body which I am not so keen on. I prefer to keep the INVITE/reINVITE for creating the session and use a different mechanism for metadata delivery.

The metadata may not be available when the recording session is established and it may change during the life of the recording session without any need to renegotiate SDP so I guess we would have to start talking about UPDATE as well. It seems cleaner to me to use an event package be it INFO events or NOTIFY events.

Regards
Andy

> Sent: 04 May 2010 16:22
> To: Ram Mohan R (rmohanr); Hutton, Andrew; [email-masked]
> Subject: Re: [siprec] FW: 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Hutton, Andrew
> > Subject: I-D

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 May 2010 14:23:45 +0530

Hi Andy,

The metadata shall be added in the SIP header/SDP of recording session
(INVITE based dialog). For e.g REC-Time of metadata can be derived from
"Date" header of SIP. Any updation in the metadata can be notified by
UPDATE or RE-INVITE. I feel there is no need to create the new (NOTIFY)
mechanism just to pass the metadata.  
 
We can use the same dialog (Recording Session) to indicate pause/resume,
stop/ re-start recording with metadata embedded in the message.
If we are using out of band mechanism like NOTFIY, we need another
mechanism to relate the Recording Session with Metadata.

Ram

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 1:23 PM
To: Brian Rosen; Ram Mohan R (rmohanr); [email-masked]
Subject: RE: [siprec] FW:

It is going to need the INVITE to use a multipart body which I am not so
keen on. I prefer to keep the INVITE/reINVITE for creating the session
and use a different mechanism for metadata delivery.

The metadata may not be available when the recording session is
established and it may change during the life of the recording session
without any need to renegotiate SDP so I guess we would have to start
talking about UPDATE as well. It seems cleaner to me to use an event
package be it INFO events or NOTIFY events.

Regards
Andy

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 5 May 2010 11:56:49 +0200

An issue here is the relationship between recording session (RS) and communication session (CS). If there is a 1:1 relationship (an RS is established for each CS), conveying metadata in an INVITE request might suffice. For the case where a RS is retained long term and used to support a multiplicity of CSs, it clearly won't work. That is one reason why I think it is important to see if we can trim down the options in this area.

John 

> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: 04 May 2010 16:22

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 May 2010 17:46:48 +0530

Hi John,

I am not clear how using INVITE session can cause problems for cases
where we have single RS for multiple Communication Sessions. Please note
the Recording Session (RS) is a separate Dialog and is independent of
Communication Session (CS).

Even though the Communication Sessions may change the RS can still
remain persistent. The Recording Client which is a logical function [
having components like Call Control Agent ] can setup the Recording
Session (RS) with Recorder. It can send RE-INVITE with hold/resume to
stop /start recording. It can update the metadata as each new
communication session starts/ends.

With NOTIFY mechanism, there is always one way communication. Only the
RC can NOTIFY RS assuming RS has SUBSCRIBED. But RS will not be able to
request any data from RC.

So I believe we still need to consider the mechanism of delivering
metadata with INVITE.

Am I missing something ?

Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 3:27 PM
To: Brian Rosen; Ram Mohan R (rmohanr); Hutton, Andrew; [email-masked]
Subject: RE: [siprec] FW:

An issue here is the relationship between recording session (RS) and
communication session (CS). If there is a 1:1 relationship (an RS is
established for each CS), conveying metadata in an INVITE request might
suffice. For the case where a RS is retained long term and used to
support a multiplicity of CSs, it clearly won't work. That is one reason
why I think it is important to see if we can trim down the options in
this area.

John

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 5 May 2010 08:24:46 -0400

> Of Elwell, John
> suffice. For the case where a RS is retained long term and used to support
> a multiplicity of CSs, it clearly won't work. That is one reason why I
> think it is important to see if we can trim down the options in this area.

Unfortunately, there isn't a 1:1 relationship between CS and RS. Metadata is not what we usually consider signaling (SIP, SS7 etc.). I recommend we keep it that way.

--
Raj Jain

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: "Elwell, John" <[email-masked]>
Date: Wed, 5 May 2010 14:29:45 +0200

True you can send it in a re-INVITE, but then if you can have multiple recording sessions on a single communication session, how do you determine for which communication session the metadata in the re-INVITE applies?

John

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 05 May 2010 13:17
> To: Elwell, John; Brian Rosen; Hutton, Andrew; [email-masked]
> Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken 
> Rehor (krehor)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 May 2010 18:10:05 +0530

I am trying to break this question in to two parts

Multiple Recording Sessions for a single communication session -
This will not have any issues if we carry metadata in INVITE as each RS
is a independent dialog

Multiple Communication Sessions and a single Recording Session -
For this case the metadata has to have a content that will distinguish
each CS. This will still be needed if we use NOTIFY as it is a single
dialog.
But still NOTIFY has the issue of one way communication.

I don't see any real advantage NOTIFY provides over INVITE.

Thanks,
Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 6:00 PM
To: Ram Mohan R (rmohanr); Brian Rosen; Hutton, Andrew; [email-masked]
Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor (krehor)
Subject: RE: [siprec] FW:

True you can send it in a re-INVITE, but then if you can have multiple
recording sessions on a single communication session, how do you
determine for which communication session the metadata in the re-INVITE
applies?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 May 2010 09:13:00 -0400

If you are going to be doing control of the recording session, such as 
pause/resume, then I think you should seriously be considering use of 
RTSP or mediactl. Otherwise you are reinventing the wheel.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 05 May 2010 09:37:00 -0400

<as individual>
Handling metadata is new code in the UA.  If it needs to add multipart
support, that shouldn't be a problem.  We are increasing the number of
mechanisms that require multipart support, cf Geolocation, which will have
to be implemented in any device that supports emergency calling.

I would be adamantly opposed to using INFO if INVITE with multipart will
suffice.  If metadata really changes frequently mid call, and reINVITE just
to change metadata strikes people as unreasonable, then INFO may be
appropriate.  On the other hand, if the best mechanism is SUB/NOT, I am fine
with that.

I agree than minimizing the number of mechanisms is important.

Brian

On 5/5/10 3:53 AM, "Hutton, Andrew" <[email-masked]>
wrote:

> It is going to need the INVITE to use a multipart body which I am not so keen
> on. I prefer to keep the INVITE/reINVITE for creating the session and use a
> different mechanism for metadata delivery.
> 
> The metadata may not be available when the recording session is established
> and it may change during the life of the recording session without any need to
> renegotiate SDP so I guess we would have to start talking about UPDATE as
> well. It seems cleaner to me to use an event package be it INFO events or
> NOTIFY events.
> 
> Regards
> Andy
>  
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 5 May 2010 15:37:58 +0200

> Sent: 05 May 2010 13:40
[JRE] Earlier in the thread for issue #10 I proposed for the definition of metadata "...describing the Communication Session and how it relates to the Recording Session", but this was shot down because people didn't agree with "how it relates to the Recording Session". But here you seem to be proposing something similar.

> But still NOTIFY has the issue of one way communication.
[JRE] Surely metadata is one way - CS to RS? 

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 5 May 2010 19:41:10 +0530

In case you wish to use SUB/NOT for recording session, how media
negotiation happens between RS and RC. I'm seeing this proposal as
metadata dialog(SUB/NOT), recording session and communication session.
The metadata dialog for passing metadata only. The recording session
(RS-RC) is used for media communication (RTP/RTSP) between Recording
server and Recording client. Please correct me where I'm going wrong. 

In case of the persistent recording session, Participants info has to be
part of metadata or not? In case not, how RS will detect/distinguish the
related participant during retrieval.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 7:08 PM
To: Ram Mohan R (rmohanr); Brian Rosen; Hutton, Andrew; [email-masked]
Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor (krehor)
Subject: RE: [siprec] FW:

> Multiple Recording Sessions for a single communication session - This 
> will not have any issues if we carry metadata in INVITE as each RS is 
> a independent dialog
> 
> Multiple Communication Sessions and a single Recording Session - For 
> this case the metadata has to have a content that will distinguish 
[JRE] Earlier in the thread for issue #10 I proposed for the definition
of metadata "...describing the Communication Session and how it relates
to the Recording Session", but this was shot down because people didn't
agree with "how it relates to the Recording Session". But here you seem
to be proposing something similar.

John

> determine for which communication session the metadata in the 
> re-INVITE applies?
> 
> John
>  
> 

> > RC can NOTIFY RS assuming RS has SUBSCRIBED. But RS will not be able

> > to request any data from RC.
> > 

> > established for each CS), conveying metadata in an INVITE request 
> > might suffice. For the case where a RS is retained long term and 
> > used to support a multiplicity of CSs, it clearly won't work. That 
> > is one reason why I think it is important to see if we can trim down

> > the
> options in
> > > An event package is easy, the data is carried in the event 
> > > subscription and/or NOTIFY.
> > > 
> > > INVITE is a bit trickier - you carry it in the body of the 
> > > message, and what we need is a new MIME type.  Not too bad, and if

> > > it's available then, why send more messages?
> > > 
> > > On the other hand, if you defined it for INVITE, then reINVITE 
> > > could be after the session was established.
> > > 
> > > So I guess the question is when does the data become available?  
> > > Are we thinking the event package is JUST for the metadata, or is 
> > > metadata tagging along with something else?
> > > 
> > > I assumed it was available right from the beginning, in which case

> > > carrying it in the INVITE may be all you need, with the 
> > > possibility of a reINVITE if you needed to change it mid stream.
> > > 
> > > Brian
> > > 
> > >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 May 2010 22:02:41 +0530

John
Please see Inline <Ram>

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, May 05, 2010 7:08 PM
To: Ram Mohan R (rmohanr); Brian Rosen; Hutton, Andrew; [email-masked]
Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor (krehor)
Subject: RE: [siprec] FW:

[JRE] Earlier in the thread for issue #10 I proposed for the definition
of metadata "...describing the Communication Session and how it relates
to the Recording Session", but this was shot down because people didn't
agree with "how it relates to the Recording Session". But here you seem
to be proposing something similar.
<Ram> I am not proposing anything here. I was just trying to interpret
the question you had asked below where in you intend to say that INVITE
will not work for multiple CS case. I see that INVITE with metadata
could handle all the cases that NOTIFY/SUB can handle. Further INVITE +
metadata has advantages like two way communication.

Thanks,
Ram

John

> re-INVITE
> > > message, and what

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 5 May 2010 23:38:11 +0530

One of the cases where using SUBSCRIBE/NOTIFY would be better than
INVITE/re-INVITE is, if the metadata is lot of information and we want
to spit it into multiple sets/packages, so that notifications can be
sent for only what was subscribed to.

Of course, both RC and RS can subscribe to each one another and get
notified, so it also 2-way.

However, we may want to take a use-case based approach here, and first
address simple use-cases that can perhaps be handled using
INVITE/re-INVITE and then extend it to metadata packages to solve more
complex uses-cases using event notification.

Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of
|Ram Mohan R (rmohanr)
|Sent: Wednesday, May 05, 2010 10:03 PM
|To: Elwell, John; Brian Rosen; Hutton, Andrew; [email-masked]
|Subject: Re: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-
|arch-00.txt
|
|John
|Please see Inline <Ram>
|
|-----Original Message-----
|From: Elwell, John [mailto:[email-masked]]
|Sent: Wednesday, May 05, 2010 7:08 PM
|To: Ram Mohan R (rmohanr); Brian Rosen; Hutton, Andrew; [email-masked]
|Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor
(krehor)
|Subject: RE: [siprec] FW:
|I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|
|
|
|> -----Original Message-----
|> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> Sent: 05 May 2010 13:40
|> To: Elwell, John; Brian Rosen; Hutton, Andrew; [email-masked]
|> Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken
|> Rehor (krehor)
|> Subject: RE: [siprec] FW:
|> I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|>
|> I am trying to break this question in to two parts
|>
|> Multiple Recording Sessions for a single communication session -
|> This will not have any issues if we carry metadata in INVITE
|> as each RS
|> is a independent dialog
|>
|> Multiple Communication Sessions and a single Recording Session -
|> For this case the metadata has to have a content that will
distinguish
|> each CS. This will still be needed if we use NOTIFY as it is a single
|> dialog.
|[JRE] Earlier in the thread for issue #10 I proposed for the definition
|of metadata "...describing the Communication Session and how it relates
|to the Recording Session", but this was shot down because people didn't
|agree with "how it relates to the Recording Session". But here you seem
|to be proposing something similar.
|<Ram> I am not proposing anything here. I was just trying to interpret
|the question you had asked below where in you intend to say that INVITE
|will not work for multiple CS case. I see that INVITE with metadata
|could handle all the cases that NOTIFY/SUB can handle. Further INVITE +
|metadata has advantages like two way communication.
|
|Thanks,
|Ram
|
|> But still NOTIFY has the issue of one way communication.
|[JRE] Surely metadata is one way - CS to RS?
|
|John
|
|>
|> I don't see any real advantage NOTIFY provides over INVITE.
|>
|> Thanks,
|> Ram
|>
|> -----Original Message-----
|> From: Elwell, John [mailto:[email-masked]]
|> Sent: Wednesday, May 05, 2010 6:00 PM
|> To: Ram Mohan R (rmohanr); Brian Rosen; Hutton, Andrew;
|> [email-masked]
|> Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken
|> Rehor (krehor)
|> Subject: RE: [siprec] FW:
|> I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|>
|> True you can send it in a re-INVITE, but then if you can have
multiple
|> recording sessions on a single communication session, how do you
|> determine for which communication session the metadata in the
|> re-INVITE
|> applies?
|>
|> John
|>
|>
|> > -----Original Message-----
|> > From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> > Sent: 05 May 2010 13:17
|> > To: Elwell, John; Brian Rosen; Hutton, Andrew; [email-masked]
|> > Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken
|> > Rehor (krehor)
|> > Subject: RE: [siprec] FW:
|> > I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> >
|> > Hi John,
|> >
|> > I am not clear how using INVITE session can cause problems for
cases
|> > where we have single RS for multiple Communication Sessions.
|> > Please note
|> > the Recording Session (RS) is a separate Dialog and is
|> independent of
|> > Communication Session (CS).
|> >
|> > Even though the Communication Sessions may change the RS can still
|> > remain persistent. The Recording Client which is a logical
|> function [
|> > having components like Call Control Agent ] can setup the Recording
|> > Session (RS) with Recorder. It can send RE-INVITE with
|> hold/resume to
|> > stop /start recording. It can update the metadata as each new
|> > communication session starts/ends.
|> >
|> > With NOTIFY mechanism, there is always one way
|> communication. Only the
|> > RC can NOTIFY RS assuming RS has SUBSCRIBED. But RS will not
|> > be able to
|> > request any data from RC.
|> >
|> > So I believe we still need to consider the mechanism of delivering
|> > metadata with INVITE.
|> >
|> > Am I missing something ?
|> >
|> > Ram
|> >
|> > -----Original Message-----
|> > From: Elwell, John [mailto:[email-masked]]
|> > Sent: Wednesday, May 05, 2010 3:27 PM
|> > To: Brian Rosen; Ram Mohan R (rmohanr); Hutton, Andrew;
|> > [email-masked]
|> > Subject: RE: [siprec] FW:
|> > I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> >
|> > An issue here is the relationship between recording session (RS)
and
|> > communication session (CS). If there is a 1:1 relationship (an RS
is
|> > established for each CS), conveying metadata in an INVITE
|> > request might
|> > suffice. For the case where a RS is retained long term and used to
|> > support a multiplicity of CSs, it clearly won't work. That is
|> > one reason
|> > why I think it is important to see if we can trim down the
|> options in
|> > this area.
|> >
|> > John
|> >
|> > > -----Original Message-----
|> > > From: [email-masked]
|> > > [mailto:[email-masked]] On Behalf Of Brian Rosen
|> > > Sent: 04 May 2010 16:22
|> > > To: Ram Mohan R (rmohanr); Hutton, Andrew; [email-masked]
|> > > Subject: Re: [siprec] FW:
|> > > I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > >
|> > > <as individual>
|> > > Hmmmm
|> > >
|> > > An event package is easy, the data is carried in the event
|> > > subscription
|> > > and/or NOTIFY.
|> > >
|> > > INVITE is a bit trickier - you carry it in the body of the
|> > > message, and what
|> > > we need is a new MIME type.  Not too bad, and if it's
|> > > available then, why
|> > > send more messages?
|> > >
|> > > You would use INFO if the metadata came after the session is
|> > > established.
|> > > On the other hand, if you defined it for INVITE, then
|> > > reINVITE could be
|> > > after the session was established.
|> > >
|> > > Generally, I'm not an INFO fan, but with INFO packages, it's
|> > > less yucky.
|> > >
|> > > So I guess the question is when does the data become
|> > > available?  Are we
|> > > thinking the event package is JUST for the metadata, or is
|> > > metadata tagging
|> > > along with something else?
|> > >
|> > > I assumed it was available right from the beginning, in which
|> > > case carrying
|> > > it in the INVITE may be all you need, with the possibility of
|> > > a reINVITE if
|> > > you needed to change it mid stream.
|> > >
|> > > Brian
|> > >
|> > >
|> > > On 5/4/10 10:54 AM, "Ram Mohan R (rmohanr)"
|> > <[email-masked]> wrote:
|> > >
|> > > > Hi Andrew,
|> > > >
|> > > > I have a comment with respect to the Mechanisms for
|> > > delivery of Metadata
|> > > > to Recording Server. I see from Section 4.3.2 that there are
two
|> > > > mechanisms mentioned
|> > > > Using a new event package
|> > > > INFO package
|> > > >
|> > > > Can we add another requirement here saying metadata could
|> > > be carried in
|> > > > a INVITE also ? I do believe we need to look at carrying
|> > metadata in
|> > > > INVITE also along with the above mentioned delivery mechanisms.
|> > > >
|> > > > Regards,
|> > > > Ram
|> > > >
|> > > > -----Original Message-----
|> > > > From: [email-masked]
|> > > [mailto:[email-masked]] On Behalf
|> > > > Of Hutton, Andrew
|> > > > Sent: Thursday, April 29, 2010 11:04 PM
|> > > > To: [email-masked]
|> > > > Subject: [siprec] FW:
|> > > > I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > >
|> > > > 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-sessio
|> > > n-recordin
|> > > > g-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.
|> > > > _______________________________________________
|> > > > siprec mailing list
|> > > > [email-masked]
|> > > > https://www.ietf.org/mailman/listinfo/siprec
|> > >
|> > >
|> > > _______________________________________________
|> > > siprec mailing list
|> > > [email-masked]
|> > > https://www.ietf.org/mailman/listinfo/siprec
|> > >
|> >
|>
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 May 2010 14:28:40 -0400

I'm sorry, but I'm not getting the concept here for use of NOTIFY.
Is somebody subscribing to the RS to obtain metadata about the recording 
session? Or is the RS subscribing to somebody (the RC?) to obtain the 
metadata?

If the former, is retrieving the metadata from the RS in scope???

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 5 May 2010 22:04:30 +0200

I guess one of the problems we have is that we have not so far try to define the metadata.

However personally I think that using the recording session to convey the metadata is going to limit what we can do and does not seem right to me. Using a SUBSCRIBE/NOTIFY event package outside of the recording session dialog seems better architecturally as it allows the recording metadata to be requested by a different entity (I.e. the functions of the RS can be split between different logical/physical entities). 

It is also likely that metadata will need to be delivered after the recording session has been terminated or even before it is created and we don't want to maintain the media session longer then necessary.

In fact it might be possibly to satisfy some of the requirements for recording metadata using the existing dialog event package possibly with some extension for recording specific stuff.

I seem to be moving towards the SUBSCRIBE/NOTIFY camp.

Regards
Andy

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]] 
> Sent: 05 May 2010 19:08
> To: Ram Mohan R (rmohanr); Elwell, John; Brian Rosen; Hutton, 
> Andrew; [email-masked]
> Subject: RE: [siprec] 
> FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 5 May 2010 22:24:07 +0200

See below. 

> Sent: 05 May 2010 09:54
> To: Hutton, Andrew; Brian Rosen; [email-masked]; Ken Rehor (krehor)
> Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat)
[Andy Hutton] - SDP would definitely not be suitable for conveying recording metadata and I don't think using SIP headers would be feasible either. I think we need to use an XML based body for conveying this similar for example to the dialog event package.

> mechanism to relate the Recording Session with Metadata.
[Andy Hutton] - I think we can use dialog identifiers in the metadata to tie everything togethor this has already been done for other services which use dialog events.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 5 May 2010 22:47:45 +0200

See below. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 05 May 2010 19:29
> To: Muthu ArulMozhi Perumal (mperumal)
> Cc: Ram Mohan R (rmohanr); Elwell, John; Brian Rosen; Hutton, 
> Andrew; [email-masked]
> Subject: Re: [siprec] 
[Andy Hutton] - RS is subscribing to the RC for recording metadata.

> If the former, is retrieving the metadata from the RS in scope???
[Andy Hutton] - I think that anything that happens to the metadata once it has been received by the RS is out of scope.

> http://www.ietf.org/internet-drafts/draft-hutton-siprec-sessio
> > |> > > n-recordin
> > |> > > > g-arch-00.txt
> > |> > > >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 May 2010 17:04:00 -0400

Do you envision any circumstances under which the subscription for 
metadata would be to anything other than the RC?

If not, then this seems like the first good example I have seen where 
info packages would be a better solution.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 5 May 2010 17:17:05 -0400

Hi all,

I guess I favour SUB/NOT and not INFO.

The scenario I have in mind is a feature where after the recording we
ask the initiator whether they want to retain the recording (and where
a secure link can be emailed to) or if it should be discarded.

This is done after the dialog has ended - so SUB/NOT works and INFO
(in dialog) cannot - since the dialog end was the signal used to
terminate the recording.

Peter Musgrave

On Wed, May 5, 2010 at 5:04 PM, Paul Kyzivat <[email-masked]> wrote:
> Do you envision any circumstances under which the subscription for metadata
> would be to anything other than the RC?
>
> If not, then this seems like the first good example I have seen where info
> packages would be a better solution.
<deleted rest/>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 May 2010 17:42:58 -0400

> (in dialog) cannot - since the dialog end was the signal used to

Can you show a call flow for this? I don't quite get it.

- Who is asking who, and when?
   (Is one communication session participant asking
   the other? Is the RC asking one of the CS participants?
   If the query is after the CS is ended, then how is it
   made if there is no CS?)

- When does the subscription get established?

- How is the subscription correlated with a recording session?

- When is the subscription terminated?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 6 May 2010 08:15:30 +0200

Ram,

OK, I understand. Let's focus on requirements around metadata for now, before we start diving too deeply into solutions.

John 

> Sent: 05 May 2010 17:33
> > > > n-recordin

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 6 May 2010 12:08:20 +0530

Hi John,

Yes I agree with you. We need to first focus on the details of the
metadata before diving in to the mechanisms to deliver metadata.
My point is we should keep the INVITE based mechanism to deliver
metadata open and add it to Architecture document.
Once we have the finer details of metadata, we can close in on one of
the approaches to deliver metadata.

Hi Hutton / Ken,
Could you please add the INVITE based mechanism to deliver metadata to
the Architecture document as one of the mechanisms ?

Regards,
Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, May 06, 2010 11:46 AM
To: Ram Mohan R (rmohanr); Brian Rosen; Hutton, Andrew; [email-masked]
Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor (krehor)
Subject: RE: [siprec] FW:

Ram,

OK, I understand. Let's focus on requirements around metadata for now,
before we start diving too deeply into solutions.

John

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 6 May 2010 10:39:40 +0200

See below

Regards
Andy

> Sent: 05 May 2010 22:04
> Cc: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R
> (rmohanr); Elwell, John; Brian Rosen; [email-masked]
> Subject: Re: [siprec]

[Andy Hutton] - Probably not although I think some people would argue that what we are calling the RC could be decomposed in some way.

> info packages would be a better solution.
[Andy Hutton] - The major disadvantage of info events is that they can only be generated within the Invite dialog which I think will be a limiting factor and I would not be in favour of defining multiple mechanisms for conveying metadat. I am not sure what example you are refering to.

> > [Andy Hutton] - I think that anything that happens to the
> metadata once it has been received by the RS is out of scope.
> >
> >>    Thanks,
> >>    Paul
> >>
> >>> |> > From: Elwell, John
> [mailto:[email-masked]]

---

From: Leon Portman <[email-masked]>
Date: Thu, 6 May 2010 11:48:31 +0300

Regarding potential clients of metadata reporting. Today such metadata is provided via CTI/CDR interfaces and there are multiple clients for that:
call logging and billing, reporting systems, workforce management systems, agent applications (Popup for example).
Almost for all of these cases, webservice(WSDL) based interface is more appropriate (these clients are not SIP UAs).
The main question is if we want to have the same XML schema or not for these use cases and recording.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Thursday, May 06, 2010 11:40 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

See below

Regards
Andy

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 6 May 2010 11:15:36 +0200

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 05 May 2010 22:43
> To: Peter Musgrave
> Cc: [email-masked]
> Subject: Re: [siprec] 
[JRE] This further highlights the problem that we don't yet have clear requirements concerning metadata.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 6 May 2010 11:21:37 +0200

I am not sure pause/resume is the correct terminology. With pause/resume, I would expect to resume at the point where I paused, i.e., with no loss of data. This implies buffering at the client for an arbitrary period of time, in anticipation of an eventual resume. I think what is needed is just the ability to start/stop the recording (with loss of data while stopped). Pause/resume (and other "trick-play" capabilities like fast forward/reverse) are features of playback, which is out of scope.

John (as individual) 

> Sent: 05 May 2010 14:13
> To: Ram Mohan R (rmohanr)
> Cc: [email-masked]

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 6 May 2010 02:27:02 -0700

There's Pause/Resume for Recording, which as you point out is different
from Pause/Resume for Playback.

Recording Pause/Resume means media is not captured between Pause and
Resume. But unlike Start/Stop, Pause means the recording is (assumed to)
going to resume. Stop implies the session is ending (and possibly the
file is closed).

Playback Pause/Resume (along with all playback features) is out of
scope.

Ken

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Thursday, May 06, 2010 2:22 AM
> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Subject: Re: [siprec]FW: I-DAction:draft-hutton-siprec-session-
> recording-arch-00.txt
> 
> I am not sure pause/resume is the correct terminology. With
> pause/resume, I would expect to resume at the point where I paused,
> i.e., with no loss of data. This implies buffering at the client for
an
> arbitrary period of time, in anticipation of an eventual resume. I
> think what is needed is just the ability to start/stop the recording
> (with loss of data while stopped). Pause/resume (and other
"trick-play"
> capabilities like fast forward/reverse) are features of playback,
which
> is out of scope.

---

From: Deepanshu Gautam <[email-masked]>
Date: Thu, 06 May 2010 17:34:11 +0800

I would advocate to use XML based mechanism for sure, and I see no
difference in using INVITE (new MIME type for body) or Event Package from
that prespective. 
Using SIP header/SDP for exchanging metadata looks messy to me.

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Leon Portman
Sent: 2010年5月6日 16:49
To: Hutton, Andrew; Paul Kyzivat
Cc: [email-masked]
Subject: Re:
[siprec]FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

Regarding potential clients of metadata reporting. Today such metadata is
provided via CTI/CDR interfaces and there are multiple clients for that:
call logging and billing, reporting systems, workforce management systems,
agent applications (Popup for example).
Almost for all of these cases, webservice(WSDL) based interface is more
appropriate (these clients are not SIP UAs).
The main question is if we want to have the same XML schema or not for these
use cases and recording.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hutton, Andrew
Sent: Thursday, May 06, 2010 11:40 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

See below

Regards
Andy

> Cc: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Elwell, 
> John; Brian Rosen; [email-masked]
> Subject: Re: [siprec]

[Andy Hutton] - Probably not although I think some people would argue that
what we are calling the RC could be decomposed in some way.

> info packages would be a better solution.
[Andy Hutton] - The major disadvantage of info events is that they can only
be generated within the Invite dialog which I think will be a limiting
factor and I would not be in favour of defining multiple mechanisms for
conveying metadat. I am not sure what example you are refering to.

> >> Is somebody subscribing to the RS to obtain metadata about the 
> >> recording session? Or is the RS subscribing to somebody (the RC?) 
> >> to
> obtain the
> >> metadata?
> >>
> >>> |> Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor 
> >>> |> (krehor)
> >>> |> This will not have any issues if we carry metadata in INVITE as 
> >>> |> each RS is a independent dialog
> >>> |>
> >>> |> Cc: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Ken Rehor 
> >>> |> (krehor)
> >>> |> re-INVITE applies?
> >>> |> > be able to request any data from RC.
> >>> |> >
> >>> |> > request might suffice. For the case where a RS is retained 
> >>> |> > long term
> >> and used to
> >>> |> > one reason why I think it is important to see if we can trim 
> >>> |> > down the
> >>> |> options in
> >>> |> > this area.
> >>> |> >
> >>> |> > John
> >>> |> >
> >>> |> > > subscription and/or NOTIFY.
> >>> |> > >
> >>> |> > > message, and what we need is a new MIME type.  Not too bad, 
> >>> |> > > and if it's available then, why send more messages?
> >>> |> > >
> >>> |> > > reINVITE could be after the session was established.
> >>> |> > >
> >>> |> > > available?  Are we thinking the event package is JUST for 
> >>> |> > > the metadata, or is metadata tagging along with something 
> >>> |> > > else?
> >>> |> > >
> >>> |> > > > Using a new event package INFO package
> >>> |> > > >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 6 May 2010 11:44:36 +0200

Ken,

Yes, thanks for clarifying - I don't know if we can find different terms, to avoid confusion.

John 

> From: Ken Rehor (krehor) [mailto:[email-masked]] 
> Sent: 06 May 2010 10:27
> To: Elwell, John; Paul Kyzivat (pkyzivat); Ram Mohan R 
> (rmohanr); [email-masked]
> Subject: RE: [siprec]FW: 
> > > > From: Hutton, Andrew 
> [mailto:[email-masked]]

---

From: Leon Portman <[email-masked]>
Date: Thu, 6 May 2010 12:45:28 +0300

Mute/unmute?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, May 06, 2010 12:45 PM
To: Ken Rehor (krehor); Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] FW: I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

Ken,

John

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 6 May 2010 02:51:17 -0700

Mute/Unmute is time preserving -- that is, the amplitude of the signal
is essentially "turned down" but recording continues. This is
particularly useful for cases where (for example) one 'track' of a
'multi-track' recording must not be recorded for a period of time.
Instead of 'muting' a tone may be recorded in place of the incoming
signal. I've seen that referred to as mask/unmask.  

I'll write up a set of definitions for all these variations that we can
throw darts at.

> From: Leon Portman [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 2:45 AM
> To: Elwell, John; Ken Rehor (krehor); Paul Kyzivat (pkyzivat); Ram
> Mohan R (rmohanr); [email-masked]
> Subject: RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-
> recording-arch-00.txt
> 
> Mute/unmute?

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 6 May 2010 06:30:27 -0400

I guess based on the comments to this thread I'm off the hook for call
flows (at least for now).

I agree focusing on requirements makes sense.

Is the requirement here that we need to allow exchange of recording
meta-data and potential control information after the media session
for the call has stopped? This leaves open the implementation choices
of some in-dialog scheme (after the media has been stopped with
reINVITEs), some sidebar SIP mechanism or something completely
out-of-band.

Peter Musgrave

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 May 2010 09:17:22 -0400

I wasn't focusing on the detailed semantics of pause/resume.
I'm just observing that the interface between the RC and the RS seems to 
be getting more "chatty" the longer it is discussed. Some of this is 
"control" and some of it is informative (metadata transfer).

ISTM that there is enough of this that the mediactrl approach ought to 
be *investigated* as a possible direction. That doesn't mean it will be 
selected.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 May 2010 09:20:06 -0400

> Mute/unmute?

Or HOLD/RESUME. We already have signaling that works for that, and which 
would work as well here, as best I can tell.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 May 2010 09:23:41 -0400

> flows (at least for now).

Maybe :-)

If you are the advocate for NOTIFY, then I'd still be interested in the 
call flows simply as a way to actually understand what it is you have in 
mind. (I'm pretty sure you must have something different in mind than 
anything I'm imagining.)

	Thanks,
	Paul

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 6 May 2010 16:05:36 +0200

Hi Paul. This is exactly what I dared to
suggest at the last IETF meeting. I keep on thinking that the scope of  
siprec might be much less narrow rhan it currently is, if we tried and  
avoid the not invented here syndrome.

Simon

Il giorno 06/mag/2010, alle ore 15.17, Paul Kyzivat  
<[email-masked]> ha scritto:

> I'm just observing that the interface between the RC and the RS  
> seems to be getting more "chatty" the longer it is discussed. Some  
> of this is "control" and some of it is informative (metadata  
> transfer).
>
> ISTM that there is enough of this that the mediactrl approach ought  
> to be *investigated* as a possible direction. That doesn't mean it  
> will be selected.
>
>    Thanks,
>    Paul
>

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 6 May 2010 11:51:15 -0400

I'm not THE advocate for notify. I may be an advocate but I'm really
not sure anymore.

The specific use case I had in mind was that after the media session
to the RS terminates I want to be told by the RS some information
about the recording (participants, duration and web link to retrieve
it etc. )

It seemed to me if I had subscribed to the RS then it could send me a
NOTIFY with this stuff.

I agree that looking into mediactrl makes sense. That's on my (way too
long) ietf related todo list.

Cheers,

Peter Musgrave

On Thu, May 6, 2010 at 9:23 AM, Paul Kyzivat <[email-masked]> wrote:
> If you are the advocate for NOTIFY, then I'd still be interested in the call
> flows simply as a way to actually understand what it is you have in mind.
> (I'm pretty sure you must have something different in mind than anything I'm
> imagining.)
>
>        Thanks,
>        Paul
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 6 May 2010 21:31:56 +0200

> [mailto:[email-masked]] On Behalf Of Peter Musgrave
> Sent: 06 May 2010 16:51
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [siprec] 
[JRE] This seems to suggest you see a requirement for a third party to receive metadata from the Recording Server - correct? I had been asking whether the requirement was for the Recording Server to receive metadata from the Recording Client. Clearly those would be two different requirements (in fact the first requirement would also require that the second requirement be met, I think). This just illustrates that we are not clear on what the requirement is. Who or what needs to receive metadata, what does the metadata comprise, and at what point in time?

John (as individual)

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 07 May 2010 11:27:45 +0800

Very good points, I would like to share my opinion on them

Although there is no explicit *requirement* on who or what needs to receive the metada, the draft in many section kinda implying that **RS receives metadata from RC**. To make it clear, we may add a requirement in the requirement section. An example would be "The mechanism MUST support the ability to deliver metadata from SRC to SRS"

What metadata comprise of is not at all mentioned anywhere in the req draft. According to me (as previously) discussed, meta data may describe a RS and its related CS or vice versa. An example of metadata would be
-----------------------------------------------------------------------------------
RS related stuff
	REC-Time - RS initiation time
	REC-Len - RS length
	......
CS related stuff (these are mentioned in ARC draft)
	CS-User - Identies of partticipating user
	CS-Didn’t - Dialog identifier
	......
CS related stuff
	......
	......
-----------------------------------------------------------------------------------
	
At what point of time metadata is exchanged, is purly depend on what kind of specific usecase we have. A usecase in req draft would help.

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 2010年5月7日 3:32
To: Peter Musgrave; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec]FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 7 May 2010 11:34:04 +0530

I agree with Deepanshu for coming with well defined metadata requirement. In my opinion, the cs-callid should not be included in metadata as callid may not be the appropriate key in case B2BUA(SBC) exists between RC and RS. The metadata shall include
 
1) Recording mechanism whether mixed or separated audio stream in case both mechanism is supported by WG.
2) Indicating the relationship between the user participants and recording stream in case of recording the media separately.
 
Regards
Partha
________________________________

From: [email-masked] on behalf of Deepanshu Gautam
Sent: Fri 5/7/2010 8:57 AM
To: 'Elwell, John'; 'Peter Musgrave'; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

        CS-Didn't - Dialog identifier

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 2010?5?7? 3:32
To: Peter Musgrave; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec]FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 08:28:24 +0200

> From: Deepanshu Gautam [mailto:[email-masked]] 
> Sent: 07 May 2010 04:28
> To: Elwell, John; 'Peter Musgrave'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: 
> Although there is no explicit *requirement* on who or what 
> needs to receive the metada, the draft in many section kinda 
> implying that **RS receives metadata from RC**. To make it 
> clear, we may add a requirement in the requirement section. 
> An example would be "The mechanism MUST support the ability 
> to deliver metadata from SRC to SRS"
[JRE] Yes, this is the sort of statement I was looking for. We might reformulate it as "The mechanism MUST support the ability for the SRS to obtain metadata". This would no longer constrain the solution to delivery directly from the SRC to the SRS, but allow the SRC to deliver some sort of identifier to allow the SRS to retrieve the metadata.

It might also be good to have some sort of statement on timing. For example, is it sufficient that the SRS be able to obtain the information after the Recording Session is finished, or is some/all information needed earlier?

> 
> What metadata comprise of is not at all mentioned anywhere in 
> the req draft. According to me (as previously) discussed, 
> meta data may describe a RS and its related CS or vice versa. 
> An example of metadata would be
[JRE] I would note that the latter parameter is not known until the end of the RS (see my comment above about timing).

> 	CS-Didn’t - Dialog identifier
[JRE] Dialog identifiers are not necessarily the best form of identifier, given the fact that B2BUAs often change them.

> CS related stuff
[JRE] I would expect the CS start time and duration might also be relevant, for cases where the RS is not for the entire duration of the CS. We might also want information on media, including times of addition or removal of media, unless this is obvious from the RS itself (i.e., if we assume media will stop/start in the RS in synch. With the stopping and starting of media in the CS)..

> At what point of time metadata is exchanged, is purly depend 
> on what kind of specific usecase we have. A usecase in req 
> draft would help.
[JRE] Agreed.

John (as individual)

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 2010年5月7日 3:32
> [JRE] This seems to suggest you see a requirement for a third 
> party to receive metadata from the Recording Server - 
> correct? I had been asking whether the requirement was for 
> the Recording Server to receive metadata from the Recording 
> Client. Clearly those would be two different requirements (in 
> fact the first requirement would also require that the second 
> requirement be met, I think). This just illustrates that we 
> are not clear on what the requirement is. Who or what needs 
> to receive metadata, what does the metadata comprise, and at 
> what point in time?
> 
> John (as individual)
> 
> 
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 09:23:33 -0400

John,

> [JRE] Yes, this is the sort of statement I was looking for. We might reformulate it as "The mechanism MUST support the ability for the SRS to obtain metadata". This would no longer constrain the so…

That seems awfully vague.
ISTM that if the metadata includes properties of the SRS, then those
would be provided by the SRS itself. Beyond that, I can't envision that
the SRS would have a clue how to proactively "obtain" metadata. (Pull
model.) Rather I would expect that this metadata would be "pushed" to
it. One obvious source that would do this pushing is the SRC. Are there
other sources? Or is it up to the SRC to "pull" from other sources and
then "push" to the SRS?

Note that if metadata is to be pushed from any source other than the
SRS, or by the SRS after the recording session has ended, then the
pusher needs a way to identify the recording session unambiguously. At
the moment no way of doing so has been identified. Nor has any way of
reaching the RS to do that push.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 10:05:15 -0400

Elwell, John wrote:
>> Sent: 07 May 2010 14:24
>> To: Elwell, John
>> Cc: Deepanshu Gautam; 'Peter Musgrave'; [email-masked]
>> Subject: Re: 
>>> [JRE] Yes, this is the sort of statement I was looking for. 
>> We might reformulate it as "The mechanism MUST support the 
>> ability for the SRS to obtain metadata". This would no longer 
>> constrain the solution to delivery directly from the SRC to 
>> the SRS, but allow the SRC to deliver some sort of identifier 
>> to allow the SRS to retrieve the metadata.
>>
> [JRE] I was trying to leave the door open to passing the metadata by reference, rather than necessarily by value. In other words, I was trying not to pre-judge the mechanism. If my words are too vague, I would welcome other attempts at expressing this.

I hadn't thought of pass  by ref, but I can see how that might have some 
role. If so, the reference would be pushed, and then I guess it would be 
deref'ed by the RS as some point. Or else the reference itself would 
become part of the metadata. So for pass by reference there would need 
to be some clarity about how long the reference needs to remain valid 
and who is expected to do the deref.

I would take a stab at some new words, but I'm still trying to 
understand what the requirement should be. I think the metadata (or a 
ref to it) needs to be pushed. But I'm not certain if anything but the 
SRC needs to do the pushing.

Perhaps could start by making a requirement for that, and then add 
others for other "pushers" if needed.

I'll take a stab at that later.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 15:53:05 +0200

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 16:35:52 +0200

Paul,

I agree that the information comes from SRC initially, and needs to become available to the SRS, and that there must be some element of 'push' there. I am just trying to find some solution-neutral words to express the need. Perhaps the original words proposed by Deepanshu would suffice: "The mechanism MUST support the ability to deliver metadata from SRC to SRS", since a by-reference mechanism would still meet this needed.

John

> Sent: 07 May 2010 15:05
> > [JRE] I was trying to leave the door open to passing the 
> metadata by reference, rather than necessarily by value. In 
> other words, I was trying not to pre-judge the mechanism. If 
> my words are too vague, I would welcome other attempts at 
> expressing this.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 May 2010 13:32:02 -0400

Elwell, John wrote:
> Paul,
> 
> I agree that the information comes from SRC initially, and needs to become available to the SRS, and that there must be some element of 'push' there. I am just trying to find some solution-neutral words to express the need. 
 >
> Perhaps the original words proposed by Deepanshu would suffice: 
 >
> "The mechanism MUST support the ability to deliver metadata from SRC to SRS", 
 >
> since a by-reference mechanism would still meet this needed.
> 

Those words seem reasonable. How about the following fine tuning:

   "The mechanism MUST support the ability for the SRC to deliver
    metadata to the SRS at the time of RS initiation.

    The mechanism MUST support the ability for the SRC to deliver
    metadata updates to the SRS while the recording session is active."

That excludes mechanisms that only support one-time sending of the 
metadata, either at initiation or termination.

It intentionally does not cover:
- pushing metadata from any other source
- pulling metadata
- pushing metadata after the session has ended

I don't object to those as requirements. But if they are, they can be 
distinct requirements.

	Thanks,
	Paul

---

From: Deepanshu Gautam <[email-masked]>
Date: Mon, 10 May 2010 10:33:01 +0800

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2010年5月8日 1:32
To: Elwell, John
Cc: Deepanshu Gautam; 'Peter Musgrave'; [email-masked]
Subject: Re:

Elwell, John wrote:
> Paul,
> 
> I agree that the information comes from SRC initially, and needs to become
available to the SRS, and that there must be some element of 'push' there. I
am just trying to find some solution-neutral words to express the need. 

That excludes mechanisms that only support one-time sending of the metadata,
either at initiation or termination.

I don't object to those as requirements. But if they are, they can be
distinct requirements.
[DG] If we want to add distinct requirement for each possible poin-of-time
at which the metadata can be exchanged, then I would add the following
requirement in addition to the two mentioned above

"The mechanism MUST support the ability for the SRC to deliver metadata to
the SRS at the time of RS termination."
	As discussed before metadata may contain information (REC-Len) which
may not be avaliable untill RS finishes That why, the delivery of metadata
is required at RS termination.
	
"The mechanism MUST support the ability for the SRC to deliver metadata to
the SRS at the time of CS initiation."
	In persistent recording (as described in the darft) CS initiates
after RS, so requirement for "RS initiation" won't apply bcz mata data won't
be avaliable untill CS initiates.

Or we can have one requirement covering all these four requirements as

"The mechanism MUST support the ability to deliver metadata and its updates
from SRC to SRS"
	I'm bit tilted towards having 1 but will live with 4 too.

Regards
Deepanshu

As discussed before metadata may contain information (REC-Len) which may not
be avaliable untill RS finishes That why, the delivery of metadata is
required at RS termination. But, I may not push it to be a requirement
because then we may have to put distinct requirement for each possible
point-of-time at which the metadata can be delivered. e.g at RS initiation,
during RS, RS termination, CS initiation (in persistent recording, CS
initiates after RS), during CS, CS termination.

	Thanks,
	Paul

>>>>>> Although there is no explicit *requirement* on who or what needs 
>>>>>> to receive the metada, the draft in many section kinda implying 
>>>>>> that **RS receives metadata from RC**. To make it clear, we may 
>>>>>> add a requirement in the requirement section.
>>>>>> An example would be "The mechanism MUST support the ability to 
>>>>>> deliver metadata from SRC to SRS"
>>>> We might reformulate it as "The mechanism MUST support the ability 
>>>> for the SRS to obtain metadata". This would no longer constrain the 
>>>> solution to delivery directly from the SRC to the SRS, but allow 
>>>> the SRC to deliver some sort of identifier to allow the SRS to 
>>>> retrieve the metadata.
>>>>
>>>> would be provided by the SRS itself. Beyond that, I can't envision 
>>>> that the SRS would have a clue how to proactively "obtain"
>> metadata. (Pull
>> metadata by reference, rather than necessarily by value. In other 
>> words, I was trying not to pre-judge the mechanism. If my words are 
>> too vague, I would welcome other attempts at expressing this.
>>
>> I hadn't thought of pass  by ref, but I can see how that might have 
>> some role. If so, the reference would be pushed, and then I guess it 
>> would be deref'ed by the RS as some point. Or else the reference 
>> itself would become part of the metadata. So for pass by reference 
>> there would need to be some clarity about how long the reference 
>> needs to remain valid and who is expected to do the deref.
>>
>> ref to it) needs to be pushed. But I'm not certain if anything but 
>> the SRC needs to do the pushing.
>>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 10 May 2010 17:14:57 +0200

Hi Simon,

I changed the subject because I am having a hard time following all the threads.

The SIPREC WG is currently capturing requirements and exploring possible architectures and nothing has been ruled out so I don't think we can be suffering from a "not invented here syndrome" already.

Personally I would like to understand more about how you think mediactrl might be applicable to SIPREC. 

During early discussions on requirements we discussed mediactrl and it is of course easy to see how it is applicable internally within the RC when it is an application server (B2BUA) or when the RS itself is an application server controlling a media server. However these are internal issues within the RC and RS and not within the scope of SIPREC so I am not sure how you think mediactrl relates to SIPREC.

Regards
Andy

> [mailto:[email-masked]] On Behalf Of Simon Pietro Romano
> Sent: 06 May 2010 15:06
> To: Paul Kyzivat
> Cc: [email-masked]
> >>>> pause/resume, then I think you should seriously be 
> considering use
> >> of

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 14:46:19 -0400

Andrew,

My thought here was that mediactrl provides a framework by which a sip 
session (in this case the SRC-SRS session) is established including both 
media streams and a special "control" stream.

In this case, the control stream would be used to send metadata, 
possibly retrieve metadata (if that is useful), potentially change how 
the recording is being done, etc.

Maybe this is overkill. But there seems to be a lot of confusion about 
exactly how much metadata needs to be transferred, and this might 
provide a vehicle for transmitting a lot of stuff.

It might also be attractive if the servers used for siprec are also 
servers for other things the mediactrl covers.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 16:28:35 -0400

> requirement in addition to the two mentioned above

Well, I wasn't defining requirements for "each possible point of time".
I was defining an interval, with a beginning and an end, during which it
can be transmitted.

In any case I think there must be some beginning and some end.

> the SRS at the time of RS termination."

Well, I thought the two bullets I proposed should cover that.
Presumably the RS is dependent on the CS (or perhaps multiple CS.)
And presumably the RS needs to be torn down, probably by the SRC.

If it has some metadata to send at that point, it can do so before
terminating the RS. The fact that media may have ceased to flow at that
point doesn't really matter, does it?

> is required at RS termination.

I guess I don't understand that.
I can understand how there might be info that isn't available until the
CS terminates. So as I just noted, the SRC might need to send some info
about the termination of the CS to the SRS before tearing down the RS.

But info about the RS itself that isn't available until the RS has
ended, such as the amount of data recorded, would AFAIK be known to the
SRS without being told by the SRC.
 	
> be avaliable untill CS initiates.

The *ability* to deliver metadata at RS initiation doesn't imply a
*requirement* to do so. In case the RS starts before the CS, then when
the CS begins, the SRC can send metadata about it as an "update".

> 	I'm bit tilted towards having 1 but will live with 4 too.

The real question is whether there is a need for the SRC to deliver
metadata to the SRS *before* the RS is established, or *after* the RS is
terminated. I haven't heard any requirement for that. And that is what I
was trying to pin down.

Transmission of metadata via a mechanism that is linked to the RS itself
(e.g. in the sip signaling, or in a control "media" stream established
as part of the RS) would be adequate for the requirements I proposed. If
you extend to other times or other senders, then it won't be.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 10 May 2010 22:30:29 +0200

Hi Paul,

So far I had not envisaged that any mediactrl type control channel was needed and I don't think that metadata is not about "control" of the media. My understanding of the requirements is that metadata simply provides information to the RS relating to the communication session that is being recorded so has no impact on the recording session. However I guess we could use a similar mechanism for conveying metadata.

My thinking so far is that metadata delivery is very much like the dialog event package (RFC 4235) with the RS subscribing to the RC for this information.

However lets see how the requirements discussion goes and keep our options open for now.

Regards
Andy

> Sent: 10 May 2010 19:46
> Cc: Simon Pietro Romano; [email-masked]
> Subject: Re: SIPREC and Mediactrl
> 
> Andrew,
> 
> > The SIPREC WG is currently capturing requirements and 
> exploring possible architectures and nothing has been ruled 
> out so I don't think we can be suffering from a "not invented 
> here syndrome" already.
> > 
> > Personally I would like to understand more about how you 
> think mediactrl might be applicable to SIPREC. 
> > 
> > During early discussions on requirements we discussed 
> mediactrl and it is of course easy to see how it is 
> applicable internally within the RC when it is an application 
> server (B2BUA) or when the RS itself is an application server 
> controlling a media server. However these are internal issues 
> within the RC and RS and not within the scope of SIPREC so I 
> am not sure how you think mediactrl relates to SIPREC.
> > 
> > Regards
> > Andy
> > 
> > 
> > 
> > 
> > 
> >>>>>>>>> implementation to automatically retrieve the ASCII 
> version of
> >>>> the
> >>>>>>>>> Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 16:42:09 -0400

> My thinking so far is that metadata delivery is very much like the dialog event package (RFC 4235) with the RS subscribing to the RC for this information.

Note that using sub/not from SRS to SRC is probably going to require 
both to support GRUU, because its unlikely you can get anything approved 
that does a subscription reusing the INVITE dialog.

Whether that is a problem is debatable.

Using an INFO package would sidestep that.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 10 May 2010 22:47:02 +0200

> that does a subscription reusing the INVITE dialog.
[Andy Hutton] - understood.

> Using an INFO package would sidestep that.
[Andy Hutton] - understood.

> >>>>>>>>> talking about UPDATE as well. It seems cleaner to
> me to use an
> >>>>>>> event
> >>>>>>>>>> You would use INFO if the metadata came after the
> session is
> >>>>>>>>>> established.
> >>>>>>>>>> Generally, I'm not an INFO fan, but with INFO
> packages, it's
> >>>>>>>>>> less yucky.
> >>>>>>>>>>
> >>>>>>>>>> I assumed it was available right from the
> beginning, in which
> >>>>>>>>>> case carrying
> >>>>>>>>>> it in the INVITE may be all you need, with the
> possibility of
> >>>>>>>>>> a reINVITE if
> >>>>>>>>>>> FYI - Just updated the name of the working group
> and made a
> >>>>>> minor
> >>>>>>>>>>> A New Internet-Draft is available from the
> on-line Internet-
> >>>>>>> Drafts
> >>>>>>>>>>> directories.
> >>>>>>>>>>>

---

From: Deepanshu Gautam <[email-masked]>
Date: Tue, 11 May 2010 16:44:17 +0800

Paul,

Thanks for the clarification.
Perhaps, two requirements proposed by you would be fine.

Regards
Deepanshu

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 2010年5月11日 4:29
To: Deepanshu Gautam
Cc: 'Elwell, John'; 'Peter Musgrave'; [email-masked]
Subject: Re:

Deepanshu Gautam wrote:
> available to the SRS, and that there must be some element of 'push' 
> there. I am just trying to find some solution-neutral words to express the
need.
> [DG] If we want to add distinct requirement for each possible 
> poin-of-time at which the metadata can be exchanged, then I would add 
> the following requirement in addition to the two mentioned above

Well, I wasn't defining requirements for "each possible point of time".
I was defining an interval, with a beginning and an end, during which it can
be transmitted.

> metadata to the SRS at the time of RS termination."

Well, I thought the two bullets I proposed should cover that.
Presumably the RS is dependent on the CS (or perhaps multiple CS.) And
presumably the RS needs to be torn down, probably by the SRC.

> may not be avaliable untill RS finishes That why, the delivery of 
> metadata is required at RS termination.

I guess I don't understand that.
I can understand how there might be info that isn't available until the CS
terminates. So as I just noted, the SRC might need to send some info about
the termination of the CS to the SRS before tearing down the RS.

But info about the RS itself that isn't available until the RS has ended,
such as the amount of data recorded, would AFAIK be known to the SRS without
being told by the SRC.
 	
> metadata to the SRS at the time of CS initiation."
> after RS, so requirement for "RS initiation" won't apply bcz mata data 
> won't be avaliable untill CS initiates.

The *ability* to deliver metadata at RS initiation doesn't imply a
*requirement* to do so. In case the RS starts before the CS, then when the
CS begins, the SRC can send metadata about it as an "update".

> "The mechanism MUST support the ability to deliver metadata and its 
> updates from SRC to SRS"

The real question is whether there is a need for the SRC to deliver metadata
to the SRS *before* the RS is established, or *after* the RS is terminated.
I haven't heard any requirement for that. And that is what I was trying to
pin down.

Transmission of metadata via a mechanism that is linked to the RS itself (e.
g. in the sip signaling, or in a control "media" stream established as part
of the RS) would be adequate for the requirements I proposed. If you extend
to other times or other senders, then it won't be.

	Thanks,
	Paul

---

From: [email-masked]
Date: Wed, 12 May 2010 14:56:04 +0200

Hi Andy,

I'll try to answer your question by extracting some relevant piece of  
text from our draft (draft-romano-dcon-recording-01). I'm sorry about  
the terminology, which might not be aligned 100% with the terms you  
are currently adopting in your documents. The following piece is about  
audio and video.

**************************************************************************
 From an high level topology point of view, this is how a recorder for
audio and video streams could be envisaged:

               SIP   +------------+ SIP
          /----------|   XCON AS  |--------
         /           +------------+        \
        /                   |MEDIACTRL      \
       /                    |                \
    +-----+              +-----+              +-----+
    |     |     RTP      |     |   RTP        |     |
    |UA-A +<------------>+Mixer+<------------>+UA-B |
    |     |              |     |              |     |
    +-----+              +-++--+              +-----+
                          |   |
               RTP UA-A   |   | RTP UA-B (Rx+Tx)
               (Rx+Tx)    V   V
                       +----------+
                       |          |
                       | Recorder |
                       |          |
                       +----------+

       This is a slightly modified version of the
       topology proposed on the DISPATCH mailing list,
       http://www.ietf.org/mail-archive/web/dispatch/current/
       msg00256.html
       where the Application Server has been specialized in an XCON-aware
       AS, and the AS<->Mixer protocol is the Media Control Channel
       Framework protocol (CFW) specified in
       [I-D.ietf-mediactrl-sip-control-framework].]

    Actually, recording audio and video streams in a conference
    may be accomplished in several ways.  Two different approaches might
    be highlighted:

    1.  recording each contribution from/to each participant in a
        separate file:

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v
   +-------+  A (RTP)           +----------+           B (RTP)  +-------+
   | UAC-A |===================>| Recorder |<===================| UAC-B |
   +-------+                    +----------+                    +-------+
                                     *
                                     *
                                     *
                                     ****> A.gsm, A.h263
                                     ****> B.g711, B.h264
                                     ****> C.amr

    2.  recording the overall mix (one for audio and one from video, or
        more if several mixes for the same media type are available) in a
        dedicated file:

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v
   +-------+  A (RTP)           +----------+           B (RTP)  +-------+
   | UAC-A |===================>| Recorder |<===================| UAC-B |
   +-------+                    +----------+                    +-------+
                                     *
                                     *
                                     *
                                     ****> (A+B+C).wav, (A+B+C).h263

    Of the two, the second is probably more feasable.  In fact, the first
    would require a potentially vast amount of separate recordings which
    would need to be subsequently muxed and correlated to each other.
    Besides, within the context of a multimedia conference, most of the
    times the streams are already mixed for all the participants, and so
    recording the mix directly would be a clear advantage.  Such an
    approach, of course, assumes that all the streams pass through a
    central point where the mixing occurs: it is the case depicted in
    the first figure.  The recording would take place in that point.  Such
    central point, the mixer (which in this case would also act as the
    recorder, or a frontend to it), might be a MEDIACTRL-based [RFC5567]
    Media Server.  Considering the similar nature of audio and video
    (both being RTP based and mixed by probably the same entity) they are
    analysed in the same section of this document.  The same applies to
    tagging and playout as well.  It is important to note that in case
    any policy is involved (e.g. moderation by means of the BFCP
    [RFC4582]) the mixer would take it into account when recording.  In
    fact, the same policies applied to the actual conference with respect
    to the delivery of audio and video to the participants need to be
    enforced for the recording as well.

    In a more general way, if the mixer does not support a direct
    recording of the mixes it prepares, recording a mix can be achieved
    by attaching the recorder entity (whatever it is) as a passive
    participant to the conference.  This would allow the recorder to
    receive all the involved audio and video streams already properly
    mixed, with policies already taken into consideration:

                                 +-------+
                                 |  UAC  |
                                 |   C   |
                                 +-------+
                                    " ^
                            C (RTP) " "
                                    " "
                                    " " A+B (RTP)
                                    v "
    +-------+  A (RTP)           +--------+  A+C (RTP)         +-------+
    |  UAC  |===================>| Media  |===================>|  UAC  |
    |   A   |<===================| Server |<===================|   B   |
    +-------+         B+C (RTP)  +--------+           B (RTP)  +-------+
                                     "
                                     "
                                     " A+B+C (RTP)
                                     "
                                     v
                               +----------+
                               | Recorder |
                               +----------+
                                     *
                                     ****> (A+B+C).wav, (A+B+C).h263

    Whether or not the mixer is MEDIACTRL-based, it's quite likely that
    the AS handling the multimedia conference business logic has some
    control on the mixing involved.  This means it can request the
    recording of each available audio and/or video mix in a conference,
    if only by adding the passive participant as mentioned above.
    Besides, events occurring at the media level or business logic in the
    AS itself allow the AS to take note of timing information for each of
    the recorded media.  For instance, the AS may take note of when the
    video mixing started, in order to properly tag the video recording in
    the tagging phase.  Both the recordings and the timing events list
    would subsequently be used in order to prepare the metadata
    information of the audio and video in the overall session recording
    description.

    In a MEDIACTRL Media Server, such a functionality might be
    accomplished by means of the Mixer Control Package
    [I-D.ietf-mediactrl-mixer-control-package].  At the end of the
    conference, URLs to the actual recordings would be made available for
    the AS to use.  The AS might then subsequently access those
    recordings according to its business logic, e.g. to store them
    somewhere else (the MS storage might be temporary) or to implement an
    offline transcoding and/or mixing of all the recordings in order to
    obtain a single file representative of the whole audio/video
    participation in the conference.  Practical examples of these
    scenarios are presented in [I-D.ietf-mediactrl-call-flows].

    Of course, if the recording of a mix is not possible or desired, one
    could still fallback to the first approach, that is individually
    recording all the incoming contributions.  It is the case, for
    instance, of conferencing systems which don't implement video mixing,
    but just rely instead on a switching/forwarding of the potentially
    several video streams to each participant.  This functionality can
    also be achieved by means of the same control package previously
    introduced, since it allows for the recording of both mixes and
    individual connections.  Once the conference ends, the AS can then
    decide what to do with the recordings, e.g. mixing them all together
    offline (thus obtaining an overall mix) or leave them as they are.
    The tagging process would the subsequently take the decision into
    account, and address the resulting media accordingly.

The above should give you an idea of what we have in mind when we  
think of re-using mediactrl in the framewrok of siprec. We are already  
doing session recording in this way and would also be glad to present  
a demo in a 10 minutes slot at the upcoming IETF, if needed.

Cheers,

Simon

Quoting "Hutton, Andrew" <[email-masked]>:

> The SIPREC WG is currently capturing requirements and exploring   
> possible architectures and nothing has been ruled out so I don't   
> think we can be suffering from a "not invented here syndrome" already.
>
> During early discussions on requirements we discussed mediactrl and   
> it is of course easy to see how it is applicable internally within   
> the RC when it is an application server (B2BUA) or when the RS   
> itself is an application server controlling a media server. However   
> these are internal issues within the RC and RS and not within the   
> scope of SIPREC so I am not sure how you think mediactrl relates to   
> SIPREC.
>
> Regards
> Andy
>
>
>
>
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 13 May 2010 12:27:37 +0200

Hi Simon,

I need to spend more time on this but here is an initial response.

I think the type of architecture you describe using MEDIACTRL is not incompatible with what SIPREC is trying to achieve but would not meet all of the requirements of SIPREC. I could imagine a deployment like what I have shown below (Figure 1) in which all the recording is controlled within a centralised AS and the only thing we would need SIPREC for is to provide the SIP endpoints with notifications and some control over the recording service this is what I called a "Recording Aware UA" in the siprec arch draft. However in this architecture if the Recorder is a separate entity how would it request and receive recording related metadata (i.e. information about the session being recorded etc)?

                       +--------------------+
         SIP + SIPREC  |  +------------+    |     SIP + SIPREC
         ,-------------+--|   XCON AS  |----+--------------.
        /              |  +------------+    |               \
       /               |         |MEDIACTRL |                \
      ,'               |         |          |                 \
   +--'--+             |      +-----+       |               +--`--+
   |       RTP(Rx+Tx)  |      |     |       |  RTP(Rx+Tx)   |     |
   |UA-A +<------------+----->+Mixer+<------+-------------->+UA-B |
   |     |             |      |     |       |               |     |
   +-----+             |      +-++--+       |               +-----+
     UA-A is a SIPREC  |       |   |        |        UA-B is a SIPREC
 Recording Aware Client|       |   |        |    Recording Aware Client
                       |       V   V        |
                       |    +----------+    |
                       |    |          |    |
                       |    | Recorder |    |
                       |    |          |    |
                       |    +----------+    |
                       |                    |
                       | Combined AS/B2BUA  |
                       |  and SIPREC RS     |
                       +--------------------+

                         Figure 1.

However the SIPREC charter states "The Session Recording Protocol (SIPREC) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder". The idea behind this I believe is to allow the recording server to be a SIP UA, which actually is already common practice, and to standardise the interface between it and recording clients which are also SIP UA's and which are already using SIP to interface to a RS. SIPREC therefore will provide an architecture which allows SIP UA's to directly interface with the RS without the need for a centralised recording aware AS or for an AS to use the same SIPREC interface to control the RS.

So we can have

       (Recording Session) +-----------+
      +----------SIP------>|           |
      |  +-------RTP------>| Recording |
      |  |                 |  Server   |
      |  |                 +   (RS)    |
      |  | +-- Metadata -->|           |
      |  | |               |           |
      |  | |               +-----------+
      |  | |
      |  | |
      |  | |
      |  | |
      V  | |  (Communication Session)
   +--+------+                     +---------+
   |         |<-------SIP--------->|         |
   |  UA-A   |                     |  UA-B   |
   |         |<-------RTP--------->|         |
   +---------+                     +---------+

Or

                                           +-----------+
                       (Recording Session) |           |
                          +----SIP-------->| Recording |
                          |                |  Server   |
                          |   +----RTP---->|   (RS)    |
                          |   |            +-----------+
                          V   |                   ^
                     +-------------+              |
                     |             |              |
                     |             |--- MetaData -+
                     |             |
                     |    B2BUA    |
                     |             |
                     |  Recording  |
  +--------+         |   Client    |         +---------+
  |        |<- SIP ->|             |<- SIP ->|         |
  |  UA-A  |         |             |         |  UA-B   |
  |        |<- RTP ->|             |<- RTP ->|         |
  +--------+         |             |         +---------+
                     +-------------+
   (Communication Session)        (Communication Session)

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 May 2010 13:56
To: Hutton, Andrew
Cc: [email-masked]; Paul Kyzivat
Subject: Re: SIPREC and Mediactrl

Hi Andy,

               SIP   +------------+ SIP

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v

                                 +-------+
                                 |  UAC  |
                                 |   C   |
                                 +-------+
                                    " ^
                            C (RTP) " "
                                    " "
                                    " " A+B (RTP)
                                    v "

Cheers,

Simon

---

From: Leon Portman <[email-masked]>
Date: Thu, 13 May 2010 15:15:07 +0300

Simon, Hi

I have follow-up question. In the XCON  diagrams below, do you have a SIP session between Mixer, UAC or Media Server and recorder or they just fork the RTP based on MEDIACTRL based request?

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Thursday, May 13, 2010 1:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [siprec] SIPREC and Mediactrl

Hi Simon,

                       +--------------------+

                         Figure 1.

So we can have

Or

                                           +-----------+
                       (Recording Session) |           |

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12 May 2010 13:56
To: Hutton, Andrew
Cc: [email-masked]; Paul Kyzivat
Subject: Re: SIPREC and Mediactrl

Hi Andy,

               SIP   +------------+ SIP

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v

                                 +-------+
                                 |  UAC  |
                                 |   C   |
                                 +-------+
                                    " ^
                            C (RTP) " "
                                    " "
                                    " " A+B (RTP)
                                    v "

Cheers,

Simon

---

From: [email-masked]
Date: Fri, 14 May 2010 11:55:38 +0200

Hi Andy,

my point is that all the things you mark in the figures with a "SIP +  
SIPREC" tag might be equally marked with a "SIP + MEDIACTRL" tag.  
Indeed, the currently available mediactrl packages (specifically, IVR  
and mixing) can do exactly the job you need in SIPREC. You might want  
to have a look at our mediactrl call flows draft, section 6.2.3.  
(Recording a conversation) to have an idea of the actual flow of  
messages involved. In any case, even in the presence of requirements  
which are not covered by mediactrl as yet, you might easily define a  
brand new control package to address the specific issues you have to  
face in SIPREC and re-use the entire mediactrl control framework. Keep  
in mind that the client-side behavior of the framework is a very  
lightweight one (typical text-based protocol with some xml exchanging).

Hope this helps clarify the issue in the subject.

Cheers,

Simon

Quoting "Hutton, Andrew" <[email-masked]>:

> I think the type of architecture you describe using MEDIACTRL is not  
>  incompatible with what SIPREC is trying to achieve but would not   
> meet all of the requirements of SIPREC. I could imagine a deployment  
>  like what I have shown below (Figure 1) in which all the recording   
> is controlled within a centralised AS and the only thing we would   
> need SIPREC for is to provide the SIP endpoints with notifications   
> and some control over the recording service this is what I called a   
> "Recording Aware UA" in the siprec arch draft. However in this   
> architecture if the Recorder is a separate entity how would it   
> request and receive recording related metadata (i.e. information   
> about the session being recorded etc)?
>
>
>
>                        +--------------------+
> However the SIPREC charter states "The Session Recording Protocol   
> (SIPREC) working group is chartered to define a SIP-based protocol   
> for controlling a session (media) recorder". The idea behind this I   
> believe is to allow the recording server to be a SIP UA, which   
> actually is already common practice, and to standardise the   
> interface between it and recording clients which are also SIP UA's   
> and which are already using SIP to interface to a RS. SIPREC   
> therefore will provide an architecture which allows SIP UA's to   
> directly interface with the RS without the need for a centralised   
> recording aware AS or for an AS to use the same SIPREC interface to   
> control the RS.
>
> So we can have
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 14 May 2010 15:22:02 +0200

Hi Simon,

See below.

Regards
Andy

> Sent: 14 May 2010 10:56
> Cc: [email-masked]; Paul Kyzivat; [email-masked]
> Subject: RE: SIPREC and Mediactrl
>
> Hi Andy,
>

[Andy H] - I don't believe that can be the case. The SIP+SIPREC Session in the figure 1 (below) is the actual communication session that is being recorded and is therefore just a straight forward SIP Session with some extensions to allow the UA to be notified that recording is taking place and express some preferences regarding whether the session can/should be recorded or not. It therefore has nothing to do with controlling the recording server so MEDIACTRL is in my mind not relevant for this session if it was then we would have to establish a control channel for each and every SIP session ever established.

> messages involved.

[Andy H] - I have seen this draft and other mediactrl specs and so far I don't see the overlap with SIPREC. If it is determined that the SIPREC Recording Client (RC) needs some type of control over the Recording Server (RS) other than simply establishing the session with SIP/SDP then possibly MEDIACTRL would be a candidate for this but so far the need for this has not been determined. I think it has also been said that MEDIACTRL could be the framework for delivering the recording metadata to the RS from the RC but since this has nothing to do with controlling the media part of the RS I think it is a bit of a stretch to think that mediactrl should be used for this.

> In any case, even in the presence of requirements
> face in SIPREC and re-use the entire mediactrl control
> framework.

[Andy H] - What services would this new control package provide to meet requirements of the SIPREC requirements draft ?

> Keep
[Andy H] - Understood.

> >>> >>>>>>> implementation to automatically retrieve the
> ASCII version of
> >>> >> the
> >>> >>>>>>> Internet-Draft.

---

From: [email-masked]
Date: Fri, 14 May 2010 16:16:53 +0200

No problem. I'm afraid we'll never converge on this point...so I won't  
keep on bothering you with my personal view ;-).

Cheers,

Simon

Quoting "Hutton, Andrew" <[email-masked]>:

> [Andy H] - I don't believe that can be the case. The SIP+SIPREC   
> Session in the figure 1 (below) is the actual communication session   
> that is being recorded and is therefore just a straight forward SIP   
> Session with some extensions to allow the UA to be notified that   
> recording is taking place and express some preferences regarding   
> whether the session can/should be recorded or not. It therefore has   
> nothing to do with controlling the recording server so MEDIACTRL is   
> in my mind not relevant for this session if it was then we would   
> have to establish a control channel for each and every SIP session   
> ever established.
>
> [Andy H] - I have seen this draft and other mediactrl specs and so   
> far I don't see the overlap with SIPREC. If it is determined that   
> the SIPREC Recording Client (RC) needs some type of control over the  
>  Recording Server (RS) other than simply establishing the session   
> with SIP/SDP then possibly MEDIACTRL would be a candidate for this   
> but so far the need for this has not been determined. I think it has  
>  also been said that MEDIACTRL could be the framework for delivering  
>  the recording metadata to the RS from the RC but since this has   
> nothing to do with controlling the media part of the RS I think it   
> is a bit of a stretch to think that mediactrl should be used for this.
>
> [Andy H] - What services would this new control package provide to   
> meet requirements of the SIPREC requirements draft ?
>
>
>> Keep