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

From: Leon Portman <[email-masked]>
Date: Fri, 7 May 2010 09:32:16 +0300

Given that we have another requirements for supporting real time analytics for example, such information supposed to be available in real time to the SRS. By real time I mean as soon as available to SRC.

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave' <[email-masked]>; 'Paul Kyzivat' <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri May 07 09:28:24 2010
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

> -----Original Message-----
> From: Deepanshu Gautam [mailto:[email-masked]] 
> Sent: 07 May 2010 04:28
> To: Elwell, John; 'Peter Musgrave'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: 
> [siprec]FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
> 
> 
> 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"
[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
> --------------------------------------------------------------
> ---------------------
> RS related stuff
> 	REC-Time - RS initiation time
> 	REC-Len - RS length
[JRE] I would note that the latter parameter is not known until the end of the RS (see my comment above about timing).

> 	......
> CS related stuff (these are mentioned in ARC draft)
> 	CS-User - Identies of partticipating user
> 	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)

> 
> 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
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Peter Musgrave
> > Sent: 06 May 2010 16:51
> > To: Paul Kyzivat
> > Cc: [email-masked]
> > Subject: Re: [siprec]
> > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
> > 
> > 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. )
> [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)
> 
> 
> > 
> > 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:
> > >
> > >
> > > Peter Musgrave wrote:
> > >>
> > >> I guess based on the comments to this thread I'm off the
> > hook for call
> > >> 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
> > >
> > >> 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
> > >>
> > >> On Wed, May 5, 2010 at 5:42 PM, Paul Kyzivat
> > <[email-masked]> wrote:
> > >>>
> > >>> Peter Musgrave wrote:
> > >>>>
> > >>>> 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.
> > >>>
> > >>> 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
> > >>>
> > >>>> 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/>>
> > >>>>>
> > >>>>>      Thanks,
> > >>
> > >
> > _______________________________________________
> > 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: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 7 May 2010 12:33:32 +0530

CS-User may change in the course of the recording session, the metadata has to be passed in the real time. REC-Time & CS-User shall be used as a identifier between SRC and SRS in case NTP exists. 
 
In my opinion, Recording session (RS) start time/end-time has to be noted instead of CS start time/end time as it is more relevant. 
 
Regards
Partha

________________________________

From: [email-masked] on behalf of Leon Portman
Sent: Fri 5/7/2010 12:02 PM
To: [email-masked]'; [email-masked]'; [email-masked]'; Paul Kyzivat (pkyzivat)
Cc: [email-masked]'
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave' <[email-masked]>; 'Paul Kyzivat' <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri May 07 09:28:24 2010
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

>       CS-Didn't - Dialog identifier

[JRE] Agreed.

John (as individual)

> Sent: 2010?5?7? 3:32

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 07 May 2010 16:37:33 +0800

I don't see any requirement but a usecase for this. Do we need to add a
requirement?
Real-time transmission will also require modiying the data in real-time (in
case something gets changed). In contrast, we can just send the latest
metadata in the end, won't that be sufficient?

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: 2010年5月7日 14:32
To: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Re: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

Given that we have another requirements for supporting real time analytics
for example, such information supposed to be available in real time to the
SRS. By real time I mean as soon as available to SRC.

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'
<[email-masked]>; 'Paul Kyzivat' <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri May 07 09:28:24 2010
Subject: Re: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

> 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?

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

[JRE] Agreed.

John (as individual)

---

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

Regards
Partha

From: [email-masked] on behalf of Deepanshu Gautam
Sent: Fri 5/7/2010 2:07 PM
To: 'Leon Portman'; [email-masked]; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010?5?7? 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

[JRE] Agreed.

John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 7 May 2010 14:16:57 +0530

Deepanshu,

There will be cases where  CS parameters changes during the session. A simple example is participants change in the CS ( due to transfer, forward). metadata needs to be conveyed real time to support real time analytics. 

Ram

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: 2010年5月7日 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

[JRE] Agreed.

John (as individual)

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 07 May 2010 16:54:07 +0800

When you say "CS-User may change" do you mean SIP endpoint (participating in
a particular CS) may change?

  _____  

From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 2010年5月7日 16:41
To: Deepanshu Gautam; Leon Portman; [email-masked];
[email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

CS-User may change in the course of the recording session, the metadata has
to be passed in the real time. REC-Time & CS-User shall be used as a
identifier between SRC and SRS in case NTP exists. 
 
In my opinion, Recording session (RS) start time/end-time has to be noted
instead of CS start time/end time as it is more relevant. 
 
Regards
Partha

  _____  

From: [email-masked] on behalf of Deepanshu Gautam
Sent: Fri 5/7/2010 2:07 PM
To: 'Leon Portman'; [email-masked];
[email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010年5月7日 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

[JRE] Agreed.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 7 May 2010 14:30:13 +0530

Deepanshu,
 
In case of persistent recording (use case-4 of req doc), CS-User will keep changing and it has to be updated with time information. Like Ram mentioned, the supplementary service like call transfer with persistent recording will require the user change in the middle of the recording session.
 
Partha

From: Deepanshu Gautam [mailto:[email-masked]] 
Sent: Friday, May 07, 2010 2:24 PM
To: Parthasarathi R (partr); 'Leon Portman'; [email-masked]; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

When you say "CS-User may change" do you mean SIP endpoint (participating in a particular CS) may change?

From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 2010年5月7日 16:41
To: Deepanshu Gautam; Leon Portman; [email-masked]; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

 
Regards
Partha

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010年5月7日 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

[JRE] Agreed.

John (as individual)

---

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

Yes, the point is real-time analytics. For me that is not the integral part
of session recording implementations.

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年5月7日 16:47
To: Deepanshu Gautam; Leon Portman; [email-masked];

Deepanshu,

There will be cases where  CS parameters changes during the session. A
simple example is participants change in the CS ( due to transfer, forward).
metadata needs to be conveyed real time to support real time analytics. 

Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Deepanshu Gautam

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010年5月7日 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

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

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

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

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 07 May 2010 17:47:14 +0800

Partha,
 
In context of persistent recording, what difference its would make if SRC
notify about the change in CS-User as soon as the change happens or it
notify about all the involved CS-User(s), in particular RS, when the RS
ends. If it is for real-time analytics (as described in usecase 12) then i
personally think it is not something integral here.
 
I think reporting metadata in the end will simply things to some extent,
atleast that discussion about INVITE/reINVITE Vs Event Package will be taken
care of.
 
Regards
Deepanshu

  _____  

Sent: 2010年5月7日 17:00

Deepanshu,
 
In case of persistent recording (use case-4 of req doc), CS-User will keep
changing and it has to be updated with time information. Like Ram mentioned,
the supplementary service like call transfer with persistent recording will
require the user change in the middle of the recording session.
 
Partha

  _____  

From: Deepanshu Gautam [mailto:[email-masked]] 
Sent: Friday, May 07, 2010 2:24 PM
To: Parthasarathi R (partr); 'Leon Portman'; john.elwell@siemens-enterprise.
com; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

  _____  

 
 
Regards
Partha

  _____  

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010年5月7日 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

[JRE] Agreed.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 7 May 2010 16:44:02 +0530

Deepanshu,
 
As you mentioned, Usecase-12 requires CS-User informatation in real-time. I suppose that there will be no different mechanism for use-case12 alone. 
 
In use-case 4 also, CS-Users at the end may not suffice for all deployments. During retrieval of persistent recording, the recorder atleast should indicate who are the users are in the dialog at the given time.
 
Regards
Partha

From: Deepanshu Gautam [mailto:[email-masked]]
Sent: Fri 5/7/2010 3:17 PM
To: Parthasarathi R (partr); 'Leon Portman'; [email-masked]; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

Partha,
 
In context of persistent recording, what difference its would make if SRC notify about the change in CS-User as soon as the change happens or it notify about all the involved CS-User(s), in particular RS, when the RS ends. If it is for real-time analytics (as described in usecase 12) then i personally think it is not something integral here.
 
I think reporting metadata in the end will simply things to some extent, atleast that discussion about INVITE/reINVITE Vs Event Package will be taken care of.
 
Regards
Deepanshu

Sent: 2010?5?7? 17:00

Deepanshu,

Partha

Sent: 2010?5?7? 16:41

 
Regards
Partha

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 2010?5?7? 14:32
To: [email-masked]'; [email-masked]';

Leon

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'

[JRE] Agreed.

John (as individual)

---

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

Deepanshu Gautam wrote:
> Partha,
>  
> In context of persistent recording, what difference its would make 
> if SRC notify about the change in CS-User as soon as the change happens 
> or it notify about all the involved CS-User(s), in particular RS, when 
> the RS ends. If it is for real-time analytics (as described in usecase 
> 12) then i personally think it is not something integral here.

I'm no expert on this application, but ISTM that if the participants in
the CS change over time, then you will want to know which parts of the
captured media were contributed by each participant. While this could
potentially be provided after the fact, it would seem to be easier to
provide that at the same time the media source changes.

	Thanks,
	Paul

> atleast that discussion about INVITE/reINVITE Vs Event Package will be 
> taken care of.
>  
> Regards
> Deepanshu
> 
> ------------------------------------------------------------------------
> *From:* Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* 2010年5月7日 17:00
> *To:* Deepanshu Gautam; Leon Portman; 
> [email-masked]; [email-masked]; Paul 
> Kyzivat (pkyzivat)
> *Cc:* [email-masked]
> *Subject:* RE: [siprec] 
> In case of persistent recording (use case-4 of req doc), CS-User will 
> keep changing and it has to be updated with time information. Like Ram 
> mentioned, the supplementary service like call transfer with persistent 
> recording will require the user change in the middle of the recording 
> session.
>  
> Partha
> 
> ------------------------------------------------------------------------
> *From:* Deepanshu Gautam [mailto:[email-masked]]
> *Sent:* Friday, May 07, 2010 2:24 PM
> *To:* Parthasarathi R (partr); 'Leon Portman'; 
> [email-masked]; [email-masked]; Paul 
> Kyzivat (pkyzivat)
> *Cc:* [email-masked]
> *Subject:* RE: [siprec] 
> When you say "CS-User may change" do you mean SIP endpoint 
> (participating in a particular CS) may change?
> 
> ------------------------------------------------------------------------
> *From:* Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* 2010年5月7日 16:41
> *To:* Deepanshu Gautam; Leon Portman; 
> [email-masked]; [email-masked]; Paul 
> Kyzivat (pkyzivat)
> *Cc:* [email-masked]
> *Subject:* RE: [siprec] 
> CS-User may change in the course of the recording session, the metadata 
> has to be passed in the real time. REC-Time & CS-User shall be used as a 
> In my opinion, Recording session (RS) start time/end-time has to be 
> noted instead of CS start time/end time as it is more relevant.
>  
> Regards
> Partha
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Deepanshu Gautam
> *Sent:* Fri 5/7/2010 2:07 PM
> *To:* 'Leon Portman'; [email-masked]; 
> *Cc:* [email-masked]
> *Subject:* Re: [siprec]

---

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

I would say that in the event of call transfer a new Recording Session would be started, to reflect the new Communication Session.

John (as individual) 

> Sent: 07 May 2010 10:00
> To: Deepanshu Gautam; Leon Portman; Elwell, John; 
> In case of persistent recording (use case-4 of req doc), 
> CS-User will keep changing and it has to be updated with time 
> information. Like Ram mentioned, the supplementary service 
> like call transfer with persistent recording will require the 
> user change in the middle of the recording session.
>  
> Partha
> 
> To: Parthasarathi R (partr); 'Leon Portman'; 
> [email-masked]; 
> CS-User may change in the course of the recording session, 
> the metadata has to be passed in the real time. REC-Time & 
> CS-User shall be used as a identifier between SRC and SRS in 
> case NTP exists. 
>  
> In my opinion, Recording session (RS) start time/end-time has 
> to be noted instead of CS start time/end time as it is more relevant. 
>  
> Regards
> Partha
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 11 May 2010 15:36:17 +0530

John,

It depends upon SIP deployment. For example:

UA1-----B2BUA----------UA2
                |   |       
                |    ------------UA3
                ----------------SRS

In the above topology, B2BUA acts as SRC and the call transfer scenario is as follows:

1) Basic call is established between UA1 and UA2 through B2BUA         
2) B2BUA starts the recording with SRS using Recording session (RS1)
3) UA2 initiates the transfer towards UA3 through B2BUA and the resulting call is between UA1 and UA3 through B2BUA
4) B2BUA shall continue RS1 for the transferred call between UA1 and UA3

I'm considering this scenario falls under persistent recording (use-case 4). The recording architecture should not limit these sort of callflows.

Thanks
Partha
-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, May 07, 2010 7:20 PM
To: Parthasarathi R (partr); Deepanshu Gautam; Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt

John (as individual) 

> mentioned, the supplementary service like call transfer with 
> persistent recording will require the user change in the middle of the 
> recording session.
>  
> Partha
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 12:21:07 +0200

In an earlier message I queried the need for Persistent Recording. I don't see the benefit in a single Recording Session (RS) spanning multiple Communication Sessions (CS)  (although this does not preclude a solution that might involve a single SIP dialog supporting multiple RSs - but that is beyond the scope of the requirements document, which is what we are discussing in this thread, despite the title).

So if we disregard the Persistent Recording option for the time being, if call transfer is accomplished by REFER, resulting a new CS with a new SIP dialog, then clearly, this would result in a new RS. If call transfer is accomplished by 3PCC, I believe it still results in a new CS, even though it would reuse the same SIP dialog at UA1. Therefore it would still result in a new RS.

I think a lot of this discussion has been mixing up dialogs and sessions. Discussion of SIP dialogs should not be part of the requirements discussion.

John (as individual)

> Sent: 11 May 2010 11:06
> To: Elwell, John; Deepanshu Gautam; Leon Portman;
> 3) UA2 initiates the transfer towards UA3 through B2BUA and
> the resulting call is between UA1 and UA3 through B2BUA
> I'm considering this scenario falls under persistent
> recording (use-case 4). The recording architecture should not
> limit these sort of callflows.
>
> Thanks
> Partha
> To: Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;
> I would say that in the event of call transfer a new
> Recording Session would be started, to reflect the new
> Communication Session.
>
> John (as individual)
>
> CS-User will

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 May 2010 16:43:11 +0530

John,

I am not sure that I understand your points here. The case we are talking here is documented in Use Case 9 (Recording Complex calls) also in the Requirement document where in the call from a Customer can be  transferred to multiple Agents, Supervisor.

Assuming the Recording Client (RC) remains in the signaling path across these supplementary services, we can have the same Recording Session to indicate these changes (Transfer). In other words we can have just one Recording Session for the entire call.

The protocol should provide a mechanism to allow this kind of recording and there should not be a restriction in the requirement.

Thanks,
Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, May 11, 2010 3:51 PM
To: Parthasarathi R (partr); Deepanshu Gautam; Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
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: Tue, 11 May 2010 14:37:18 +0200

But each time call transfer takes place, the endpoints change and the media types and formats might change too. That is a new session, surely (i.e., a new CS)? As far as the RS is concerned, although the endpoints might remain the same, when call transfer takes place media types and formats might change, and metadata will change, so why not call it a new RS?

Of course, there might be a requirement to correlate different RSs under some circumstances, but we can formulate that as a separate requirement.

John  (as individual)

> Sent: 11 May 2010 12:13
> To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam;
> Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: Using the same RS when CS user changes (was RE:
> [siprec]
> FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )
>
> John,
>
> I am not sure that I understand your points here. The case we
> are talking here is documented in Use Case 9 (Recording
> Complex calls) also in the Requirement document where in the
> call from a Customer can be  transferred to multiple Agents,
> Supervisor.
>
> Assuming the Recording Client (RC) remains in the signaling
> path across these supplementary services, we can have the
> same Recording Session to indicate these changes (Transfer).
> In other words we can have just one Recording Session for the
> entire call.
>
> The protocol should provide a mechanism to allow this kind of
> recording and there should not be a restriction in the requirement.
>
> Thanks,
> Ram
>
> In an earlier message I queried the need for Persistent
> Recording. I don't see the benefit in a single Recording
> Session (RS) spanning multiple Communication Sessions (CS)
> (although this does not preclude a solution that might
> involve a single SIP dialog supporting multiple RSs - but
> that is beyond the scope of the requirements document, which
> is what we are discussing in this thread, despite the title).
>
> So if we disregard the Persistent Recording option for the
> time being, if call transfer is accomplished by REFER,
> resulting a new CS with a new SIP dialog, then clearly, this
> would result in a new RS. If call transfer is accomplished by
> 3PCC, I believe it still results in a new CS, even though it
> would reuse the same SIP dialog at UA1. Therefore it would
> still result in a new RS.
>
> I think a lot of this discussion has been mixing up dialogs
> and sessions. Discussion of SIP dialogs should not be part of
> the requirements discussion.
>
> John (as individual)
>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 May 2010 18:25:16 +0530

John,

Why do we need to think that it is a new RS when transfer takes place and media type and format changes at requirement level?
I do believe it should be left to the implementer on whether he wants the use the same RS or setup a different RS and this would depend on who the SRC is. If he is following the latter approach,  he has to have a mechanism to associate all the different RS's of the same call.
What I am saying is we need both these requirements. The protocol should not restrict saying that "we should always have different RS's".

I feel we need to add this as a separate requirement. 

Thanks,
Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 6:07 PM
To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

John  (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 15:20:35 +0200

Ram,

This is really just a terminology issue. If we do as you propose, and say that an RS can cover multiples CSs, then I believe we also need a name for the object (let's call it X for now) that represents that part of an RS that covers the recording of a single CS or part thereof. So the issue is:
- do we have an RS comprising (potentially) multiple Xs?
- or do we just have RSs, each covering a single CS (with perhaps a new object Y that represents a set of related RSs)?

My preference would be the latter, because I think for most purposes we would be talking about the recording of a single CS (or part thereof), and only occasionally would we need to talk about recording of a set of related CSs. This is because I see most RS-related attributes (e.g., media types and formats, security keys, metadata, as potentially having a lifetime of only a single CS, and changing from one CS to the next).

That is my personal preference, and if the majority prefer the first terminology option then I could live with it - although I believe we would need to find a term for X. The important thing is to have a complete and consistent set of defined terms.

John (as individual)

> Sent: 11 May 2010 13:55
> Subject: RE: Using the same RS when CS user changes (was RE:
> [siprec]
> Why do we need to think that it is a new RS when transfer
> takes place and media type and format changes at requirement level?
> I do believe it should be left to the implementer on whether
> he wants the use the same RS or setup a different RS and this
> would depend on who the SRC is. If he is following the latter
> approach,  he has to have a mechanism to associate all the
> different RS's of the same call.
> What I am saying is we need both these requirements. The
> protocol should not restrict saying that "we should always
> have different RS's".
>
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu
> Gautam; Leon Portman; [email-masked]; Paul
> Kyzivat (pkyzivat)
> Cc: [email-masked]
> Subject: RE: Using the same RS when CS user changes (was RE:
> [siprec]
> But each time call transfer takes place, the endpoints change
> and the media types and formats might change too. That is a
> new session, surely (i.e., a new CS)? As far as the RS is
> concerned, although the endpoints might remain the same, when
> call transfer takes place media types and formats might
> change, and metadata will change, so why not call it a new RS?
>
> Of course, there might be a requirement to correlate
> different RSs under some circumstances, but we can formulate
> that as a separate requirement.
>
> John  (as individual)
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 11 May 2010 19:16:45 +0530

John,

Till now, the architecture is open and there is no 1:1 relationship between RS and CS. From your description, it looks like that 1:1 dependency between RS and CS is created. The protocol should not restrict. In case RS has to be refined, we should discuss further and come with clear definition for RS. 

The extra correlation required to group the RS's of individual call shall be avoided by having the single RS with the provision to modify the CS User changes and its media properties. Even assuming CS media change should impact RS media may not correct. CS may use some set of media properties, RS may use some other media properties and SRC will do transcoding to make the sync and it will be become implementation specific.

The requirement shall be "Recording session (RS) mechanism should support CS-user changes, media changes in the mid-call" 

Thanks
Partha/Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 6:51 PM
To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

Ram,

John (as individual)

> To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam; Leon 
> Portman; [email-masked]; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Why do we need to think that it is a new RS when transfer takes place 
> and media type and format changes at requirement level?
> I do believe it should be left to the implementer on whether he wants 
> the use the same RS or setup a different RS and this would depend on 
> who the SRC is. If he is following the latter approach,  he has to 
> have a mechanism to associate all the different RS's of the same call.
> What I am saying is we need both these requirements. The protocol 
> should not restrict saying that "we should always have different 
> RS's".
>
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; 
> But each time call transfer takes place, the endpoints change and the 
> media types and formats might change too. That is a new session, 
> surely (i.e., a new CS)? As far as the RS is concerned, although the 
> endpoints might remain the same, when call transfer takes place media 
> types and formats might change, and metadata will change, so why not 
> call it a new RS?
>
> Of course, there might be a requirement to correlate different RSs 
> under some circumstances, but we can formulate that as a separate 
> requirement.
>
> John  (as individual)
>
> > To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam; Leon 
> > Portman; [email-masked]; Paul Kyzivat (pkyzivat)
> > Cc: [email-masked]
> > I am not sure that I understand your points here. The case we are 
> > talking here is documented in Use Case 9 (Recording Complex calls) 
> > also in the Requirement document where in the call from a Customer 
> > can be  transferred to multiple Agents, Supervisor.
> >
> > Assuming the Recording Client (RC) remains in the signaling path 
> > across these supplementary services, we can have the same Recording 
> > Session to indicate these changes (Transfer).
> > In other words we can have just one Recording Session for the entire 
> > call.
> >
> > In an earlier message I queried the need for Persistent Recording. I 
> > don't see the benefit in a single Recording Session (RS) spanning 
> > multiple Communication Sessions (CS) (although this does not 
> > preclude a solution that might involve a single SIP dialog 
> > supporting multiple RSs - but that is beyond the scope of the 
> > requirements document, which is what we are discussing in this 
> > thread, despite the title).
> >
> > So if we disregard the Persistent Recording option for the time 
> > being, if call transfer is accomplished by REFER, resulting a new CS 
> > with a new SIP dialog, then clearly, this would result in a new RS. 
> > If call transfer is accomplished by 3PCC, I believe it still results 
> > in a new CS, even though it would reuse the same SIP dialog at UA1. 
> > Therefore it would still result in a new RS.
> >
> > I think a lot of this discussion has been mixing up dialogs and 
> > sessions. Discussion of SIP dialogs should not be part of the 
> > requirements discussion.
> >
> > John (as individual)
> >
> >
> > > 3) UA2 initiates the transfer towards UA3 through B2BUA and the 
> > > resulting call is between UA1 and UA3 through B2BUA
> > > I'm considering this scenario falls under persistent recording 
> > > (use-case 4). The recording architecture should not limit these 
> > > sort of callflows.
> > >
> > > Thanks
> > > Partha
> > > I would say that in the event of call transfer a new Recording 
> > > Session would be started, to reflect the new Communication 
> > > Session.
> > >
> > > John (as individual)
> > >
> > > > CS-User may change in the course of the recording session, the 
> > > > metadata has to be passed in the real time. REC-Time & CS-User 
> > > > shall be used as a identifier between SRC and SRS in case NTP 
> > > > exists.
> > > >
> > > > In my opinion, Recording session (RS) start time/end-time has to 
> > > > be noted instead of CS start time/end time as it is more
> > > relevant.
> > > >
> > > > Regards
> > > > Partha
> > > >
> > > > I don't see any requirement but a usecase for this. Do we need 
> > > > to add a requirement?
> > > > Real-time transmission will also require modiying the data in 
> > > > real-time (in case something gets changed). In contrast, we can 
> > > > just send
> > > the latest
> > > > Given that we have another requirements for supporting real time 
> > > > analytics for example, such information supposed to be available 
> > > > in real time to the SRS. By real time I mean as soon as 
> > > > available to SRC.
> > > >
> > > > Leon
> > > >
> > > > 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?
> > > >
> > > > >
> > > > > the req draft. According to me (as previously) discussed, meta 
> > > > > data may describe a RS and its related CS or vice versa.
> > > > [JRE] I would note that the latter parameter is not known until 
> > > > the end of the RS (see my comment above about timing).
> > > >
> > > > >       ......
> > > > [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)..
> > > >
> > > >
> > > > > 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 
> > > > > 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)
> > > > >
> > > > >
> > > > > >
> > > > > > >>>  (Is one communication session participant asking  the 
> > > > > > >>> other? Is the RC asking one of the CS participants?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 10:31:38 -0400

John,

Maybe you are making a correlation between Communication Session and SIP
Session that others are not making. Or maybe we differ on the meaning of
SIP Session (because that isn't very clear either.)

I see no reason why a recording session cannot transcend a transfer.
Certainly there can be cases involving B2BUAs or gateways where there is
a transfer that the SRC isn't even aware of, and in those cases the RS
will transcend the transfer. Also, there can be changes of media type
and format within a single SIP Session/Communication Session without
there being a transfer.

So I'm in agreement with Partha and Ram here that the requirements ought
to permit an RS to transcend a transfer of the CS, among other things.
That of course can only happen if the same SRC continues to have access
to the media before and after the transfer. And of course it isn't a
requirement that transfers always be handled this way - only that they
*may* be handled this way.

	Thanks,
	Paul

Elwell, John wrote:
>>>>> real-time (in
>>>>> the SRS to
>>>>> identifier,

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 11 May 2010 20:19:39 +0530

John,

|This is really just a terminology issue. If we do as you propose, 
|and say that an RS can cover multiples CSs, then I believe we also
|need a name for the object (let's call it X for now) that represents
|that part of an RS that covers the recording of a single CS or part
|thereof.

The X could be something similar to the Session Identifier described in draft-kaplan-dispatch-session, though it is currently intended only for troubleshooting purpose.

|My preference would be the latter, because I think for most purposes
|we would be talking about the recording of a single CS (or part thereof),
|and only occasionally would we need to talk about recording of a set of
|related CSs.

For contact center environments I think it would mostly be the other way -- when a customer calls into a contact center and gets transferred to multiple agents, one might actually want to record all the CSs.

|This is because I see most RS-related attributes (e.g., media types 
|and formats, security keys, metadata, as potentially having a lifetime
|of only a single CS, and changing from one CS to the next).

The fact that the media type/format, keys etc change b/w CSs doesn't mean it needs to change for the RS as well. For e.g, while the CS is using g729 and SRTP over the WAN, the RS could be using g711 and RTP over the LAN, with the SRC performing transcoding and SRTP <-> RTP conversion.

The terminology/architecture should accommodate use-cases.

Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of
|Elwell, John
|Sent: Tuesday, May 11, 2010 6:51 PM
|To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; Leon
|Portman; [email-masked]; Paul Kyzivat (pkyzivat)
|Cc: [email-masked]
|Subject: Re: [siprec] Using the same RS when CS user changes (was RE: FW:I-
|DAction:draft-hutton-siprec-session-recording-arch-00.txt )
|
|Ram,
|
|This is really just a terminology issue. If we do as you propose, and say
|that an RS can cover multiples CSs, then I believe we also need a name for
|the object (let's call it X for now) that represents that part of an RS that
|covers the recording of a single CS or part thereof. So the issue is:
|- do we have an RS comprising (potentially) multiple Xs?
|- or do we just have RSs, each covering a single CS (with perhaps a new
|object Y that represents a set of related RSs)?
|
|My preference would be the latter, because I think for most purposes we
|would be talking about the recording of a single CS (or part thereof), and
|only occasionally would we need to talk about recording of a set of related
|CSs. This is because I see most RS-related attributes (e.g., media types and
|formats, security keys, metadata, as potentially having a lifetime of only a
|single CS, and changing from one CS to the next).
|
|That is my personal preference, and if the majority prefer the first
|terminology option then I could live with it - although I believe we would
|need to find a term for X. The important thing is to have a complete and
|consistent set of defined terms.
|
|John (as individual)
|
|> -----Original Message-----
|> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> Sent: 11 May 2010 13:55
|> To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam;
|> Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
|> Cc: [email-masked]
|> Subject: RE: Using the same RS when CS user changes (was RE:
|> [siprec]
|> FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )
|>
|> John,
|>
|> Why do we need to think that it is a new RS when transfer
|> takes place and media type and format changes at requirement level?
|> I do believe it should be left to the implementer on whether
|> he wants the use the same RS or setup a different RS and this
|> would depend on who the SRC is. If he is following the latter
|> approach,  he has to have a mechanism to associate all the
|> different RS's of the same call.
|> What I am saying is we need both these requirements. The
|> protocol should not restrict saying that "we should always
|> have different RS's".
|>
|> I feel we need to add this as a separate requirement.
|>
|> Thanks,
|> Ram
|>
|> -----Original Message-----
|> From: Elwell, John [mailto:[email-masked]]
|> Sent: Tuesday, May 11, 2010 6:07 PM
|> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu
|> Gautam; Leon Portman; [email-masked]; Paul
|> Kyzivat (pkyzivat)
|> Cc: [email-masked]
|> Subject: RE: Using the same RS when CS user changes (was RE:
|> [siprec]
|> FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )
|>
|> But each time call transfer takes place, the endpoints change
|> and the media types and formats might change too. That is a
|> new session, surely (i.e., a new CS)? As far as the RS is
|> concerned, although the endpoints might remain the same, when
|> call transfer takes place media types and formats might
|> change, and metadata will change, so why not call it a new RS?
|>
|> Of course, there might be a requirement to correlate
|> different RSs under some circumstances, but we can formulate
|> that as a separate requirement.
|>
|> John  (as individual)
|>
|> > -----Original Message-----
|> > From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
|> > Sent: 11 May 2010 12:13
|> > To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam;
|> > Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
|> > Cc: [email-masked]
|> > Subject: Using the same RS when CS user changes (was RE:
|> > [siprec]
|> > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )
|> >
|> > John,
|> >
|> > I am not sure that I understand your points here. The case we
|> > are talking here is documented in Use Case 9 (Recording
|> > Complex calls) also in the Requirement document where in the
|> > call from a Customer can be  transferred to multiple Agents,
|> > Supervisor.
|> >
|> > Assuming the Recording Client (RC) remains in the signaling
|> > path across these supplementary services, we can have the
|> > same Recording Session to indicate these changes (Transfer).
|> > In other words we can have just one Recording Session for the
|> > entire call.
|> >
|> > The protocol should provide a mechanism to allow this kind of
|> > recording and there should not be a restriction in the requirement.
|> >
|> > Thanks,
|> > Ram
|> >
|> > -----Original Message-----
|> > From: [email-masked]
|> > [mailto:[email-masked]] On Behalf Of Elwell, John
|> > Sent: Tuesday, May 11, 2010 3:51 PM
|> > To: Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;
|> > [email-masked]; Paul Kyzivat (pkyzivat)
|> > Cc: [email-masked]
|> > Subject: Re: [siprec]
|> > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> >
|> > In an earlier message I queried the need for Persistent
|> > Recording. I don't see the benefit in a single Recording
|> > Session (RS) spanning multiple Communication Sessions (CS)
|> > (although this does not preclude a solution that might
|> > involve a single SIP dialog supporting multiple RSs - but
|> > that is beyond the scope of the requirements document, which
|> > is what we are discussing in this thread, despite the title).
|> >
|> > So if we disregard the Persistent Recording option for the
|> > time being, if call transfer is accomplished by REFER,
|> > resulting a new CS with a new SIP dialog, then clearly, this
|> > would result in a new RS. If call transfer is accomplished by
|> > 3PCC, I believe it still results in a new CS, even though it
|> > would reuse the same SIP dialog at UA1. Therefore it would
|> > still result in a new RS.
|> >
|> > I think a lot of this discussion has been mixing up dialogs
|> > and sessions. Discussion of SIP dialogs should not be part of
|> > the requirements discussion.
|> >
|> > John (as individual)
|> >
|> >
|> > > -----Original Message-----
|> > > From: Parthasarathi R (partr) [mailto:[email-masked]]
|> > > Sent: 11 May 2010 11:06
|> > > To: Elwell, John; Deepanshu Gautam; Leon Portman;
|> > > [email-masked]; Paul Kyzivat (pkyzivat)
|> > > Cc: [email-masked]
|> > > Subject: RE: [siprec]
|> > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > >
|> > > John,
|> > >
|> > > It depends upon SIP deployment. For example:
|> > >
|> > > UA1-----B2BUA----------UA2
|> > >                 |   |
|> > >                 |    ------------UA3
|> > >                 ----------------SRS
|> > >
|> > > In the above topology, B2BUA acts as SRC and the call
|> > > transfer scenario is as follows:
|> > >
|> > > 1) Basic call is established between UA1 and UA2 through
|> > > B2BUA
|> > > 2) B2BUA starts the recording with SRS using Recording
|> session (RS1)
|> > > 3) UA2 initiates the transfer towards UA3 through B2BUA and
|> > > the resulting call is between UA1 and UA3 through B2BUA
|> > > 4) B2BUA shall continue RS1 for the transferred call between
|> > > UA1 and UA3
|> > >
|> > > I'm considering this scenario falls under persistent
|> > > recording (use-case 4). The recording architecture should not
|> > > limit these sort of callflows.
|> > >
|> > > Thanks
|> > > Partha
|> > > -----Original Message-----
|> > > From: Elwell, John [mailto:[email-masked]]
|> > > Sent: Friday, May 07, 2010 7:20 PM
|> > > To: Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;
|> > > [email-masked]; Paul Kyzivat (pkyzivat)
|> > > Cc: [email-masked]
|> > > Subject: RE: [siprec]
|> > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > >
|> > > I would say that in the event of call transfer a new
|> > > Recording Session would be started, to reflect the new
|> > > Communication Session.
|> > >
|> > > John (as individual)
|> > >
|> > > > -----Original Message-----
|> > > > From: Parthasarathi R (partr) [mailto:[email-masked]]
|> > > > Sent: 07 May 2010 10:00
|> > > > To: Deepanshu Gautam; Leon Portman; Elwell, John;
|> > > > [email-masked]; Paul Kyzivat (pkyzivat)
|> > > > Cc: [email-masked]
|> > > > Subject: RE: [siprec]
|> > > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > > Deepanshu,
|> > > >
|> > > > In case of persistent recording (use case-4 of req doc),
|> > > CS-User will
|> > > > keep changing and it has to be updated with time
|> > > information. Like Ram
|> > > > mentioned, the supplementary service like call transfer with
|> > > > persistent recording will require the user change in the
|> > > middle of the
|> > > > recording session.
|> > > >
|> > > > Partha
|> > > >
|> > > > ________________________________
|> > > >
|> > > > From: Deepanshu Gautam [mailto:[email-masked]]
|> > > > Sent: Friday, May 07, 2010 2:24 PM
|> > > > To: Parthasarathi R (partr); 'Leon Portman';
|> > > > [email-masked];
|> > > > [email-masked]; Paul Kyzivat (pkyzivat)
|> > > > Cc: [email-masked]
|> > > > Subject: RE: [siprec]
|> > > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > >
|> > > > When you say "CS-User may change" do you mean SIP endpoint
|> > > > (participating in a particular CS) may change?
|> > > >
|> > > > ________________________________
|> > > >
|> > > > From: Parthasarathi R (partr) [mailto:[email-masked]]
|> > > > Sent: 2010年5月7日 16:41
|> > > > To: Deepanshu Gautam; Leon Portman;
|> > > > [email-masked];
|> > > > [email-masked]; Paul Kyzivat (pkyzivat)
|> > > > Cc: [email-masked]
|> > > > Subject: RE: [siprec]
|> > > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > >
|> > > > CS-User may change in the course of the recording session,
|> > > > the metadata has to be passed in the real time. REC-Time &
|> > > > CS-User shall be used as a identifier between SRC and SRS in
|> > > > case NTP exists.
|> > > >
|> > > > In my opinion, Recording session (RS) start time/end-time has
|> > > > to be noted instead of CS start time/end time as it is more
|> > > relevant.
|> > > >
|> > > > Regards
|> > > > Partha
|> > > >
|> > > > ________________________________
|> > > >
|> > > > From: [email-masked] on behalf of Deepanshu Gautam
|> > > > Sent: Fri 5/7/2010 2:07 PM
|> > > > To: 'Leon Portman'; [email-masked];
|> > > > [email-masked]; Paul Kyzivat (pkyzivat)
|> > > > Cc: [email-masked]
|> > > > Subject: Re: [siprec]
|> > > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > >
|> > > >
|> > > >
|> > > > I don't see any requirement but a usecase for this. Do we
|> > > > need to add a
|> > > > requirement?
|> > > > Real-time transmission will also require modiying the data in
|> > > > real-time (in
|> > > > case something gets changed). In contrast, we can just send
|> > > the latest
|> > > > metadata in the end, won't that be sufficient?
|> > > >
|> > > >
|> > > >
|> > > > -----Original Message-----
|> > > > From: Leon Portman [mailto:[email-masked]]
|> > > > Sent: 2010年5月7日 14:32
|> > > > To: [email-masked]';
|> [email-masked]';
|> > > > [email-masked]'; [email-masked]'
|> > > > Cc: [email-masked]'
|> > > > Subject: Re: [siprec]
|> > > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > > Given that we have another requirements for supporting real
|> > > > time analytics
|> > > > for example, such information supposed to be available in
|> > > > real time to the
|> > > > SRS. By real time I mean as soon as available to SRC.
|> > > >
|> > > > Leon
|> > > >
|> > > > ----- Original Message -----
|> > > > From: [email-masked] <[email-masked]>
|> > > > To: Deepanshu Gautam <[email-masked]>; 'Peter Musgrave'
|> > > > <[email-masked]>; 'Paul Kyzivat'
|> > <[email-masked]>
|> > > > Cc: [email-masked] <[email-masked]>
|> > > > Sent: Fri May 07 09:28:24 2010
|> > > > Subject: Re: [siprec]
|> > > > FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > >
|> > > >
|> > > >
|> > > >
|> > > > > -----Original Message-----
|> > > > > From: Deepanshu Gautam [mailto:[email-masked]]
|> > > > > Sent: 07 May 2010 04:28
|> > > > > To: Elwell, John; 'Peter Musgrave'; 'Paul Kyzivat'
|> > > > > Cc: [email-masked]
|> > > > > Subject: RE:
|> > > > >
|> > > >
|> > >
|> >
|> [siprec]FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > > >
|> > > > >
|> > > > > 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"
|> > > > [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
|> > > > > --------------------------------------------------------------
|> > > > > ---------------------
|> > > > > RS related stuff
|> > > > >       REC-Time - RS initiation time
|> > > > >       REC-Len - RS length
|> > > > [JRE] I would note that the latter parameter is not known
|> > > > until the end of
|> > > > the RS (see my comment above about timing).
|> > > >
|> > > > >       ......
|> > > > > CS related stuff (these are mentioned in ARC draft)
|> > > > >       CS-User - Identies of partticipating user
|> > > > >       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)
|> > > >
|> > > >
|> > > > >
|> > > > > 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
|> > > > >
|> > > > >
|> > > > >
|> > > > > > -----Original Message-----
|> > > > > > From: [email-masked]
|> > > > > > [mailto:[email-masked]] On Behalf Of Peter Musgrave
|> > > > > > Sent: 06 May 2010 16:51
|> > > > > > To: Paul Kyzivat
|> > > > > > Cc: [email-masked]
|> > > > > > Subject: Re: [siprec]
|> > > > > >
|> FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
|> > > > > >
|> > > > > > 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. )
|> > > > > [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)
|> > > > >
|> > > > >
|> > > > > >
|> > > > > > 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:
|> > > > > > >
|> > > > > > >
|> > > > > > > Peter Musgrave wrote:
|> > > > > > >>
|> > > > > > >> I guess based on the comments to this thread I'm off the
|> > > > > > hook for call
|> > > > > > >> 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
|> > > > > > >
|> > > > > > >> 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
|> > > > > > >>
|> > > > > > >> On Wed, May 5, 2010 at 5:42 PM, Paul Kyzivat
|> > > > > > <[email-masked]> wrote:
|> > > > > > >>>
|> > > > > > >>> Peter Musgrave wrote:
|> > > > > > >>>>
|> > > > > > >>>> 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.
|> > > > > > >>>
|> > > > > > >>> 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
|> > > > > > >>>
|> > > > > > >>>> 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/>>
|> > > > > > >>>>>
|> > > > > > >>>>>      Thanks,
|> > > > > > >>
|> > > > > > >
|> > > > > > _______________________________________________
|> > > > > > 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
|> > > >
|> > > > _______________________________________________
|> > > > 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: Tue, 11 May 2010 11:07:44 -0400

> The X could be something similar to the Session Identifier described in draft-kaplan-dispatch-session, though it is currently intended only for troubleshooting purpose.

John, were you asking for a term to be used in *discussing* this? Or a
way of picking the pieces out of the metadata?

AFAIK there is intent to include "participants" as part of the metadata,
and a correlation between participant and media stream. And then
participants, and their streams may change over time within the RS.
Isn't that enough?

(E.g. An RS has Alice and Bob as participants from 10:00 till 10:15.
>From 10:15 to 10:16 Alice, Bob, and Charlie were all participants, and
from 10:16 to 10:30 Alice and Charlie were participants.)

This is needed in any case for recording multi-party conferences. A
transfer can be viewed as a special case of a conference.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 17:18:25 +0200

Paul,

I don't mind adopting the terminology that others are proposing, but I still think we might want a term for what I called "X".

John

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 11 May 2010 15:32
> To: Elwell, John
> Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu
> Gautam; Leon Portman; [email-masked]; [email-masked]
> Subject: Re: Using the same RS when CS user changes (was RE:
> [siprec]
> > This is really just a terminology issue. If we do as you
> propose, and say that an RS can cover multiples CSs, then I
> believe we also need a name for the object (let's call it X
> for now) that represents that part of an RS that covers the
> recording of a single CS or part thereof. So the issue is:
> > - or do we just have RSs, each covering a single CS (with
> perhaps a new object Y that represents a set of related RSs)?
> >
> > My preference would be the latter, because I think for most
> purposes we would be talking about the recording of a single
> CS (or part thereof), and only occasionally would we need to
> talk about recording of a set of related CSs. This is because
> I see most RS-related attributes (e.g., media types and
> formats, security keys, metadata, as potentially having a
> lifetime of only a single CS, and changing from one CS to the next).
> >
> > That is my personal preference, and if the majority prefer
> the first terminology option then I could live with it -
> although I believe we would need to find a term for X. The
> important thing is to have a complete and consistent set of
> defined terms.
> >
> > John (as individual)
> >

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 17:24:41 +0200

Paul,

I was looking for a term we could use in the requirements document. But I am willing to wait and see if we can get by without it.

John

> Sent: 11 May 2010 16:08
> To: Muthu ArulMozhi Perumal (mperumal)
> Cc: Elwell, John; Ram Mohan R (rmohanr); Parthasarathi R
> (partr); Deepanshu Gautam; Leon Portman;
> [email-masked]; [email-masked]
> Subject: Re: [siprec] Using the same RS when CS user changes
> (was RE:
> > The X could be something similar to the Session Identifier
> described in draft-kaplan-dispatch-session, though it is
> currently intended only for troubleshooting purpose.
>
> > For contact center environments I think it would mostly be
> the other way -- when a customer calls into a contact center
> and gets transferred to multiple agents, one might actually
> want to record all the CSs.
> >
> > The fact that the media type/format, keys etc change b/w
> CSs doesn't mean it needs to change for the RS as well. For
> e.g, while the CS is using g729 and SRTP over the WAN, the RS
> could be using g711 and RTP over the LAN, with the SRC
> performing transcoding and SRTP <-> RTP conversion.
> >
> > |From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> > |Elwell, John
> > |> > > From: Elwell, John
> [mailto:[email-masked]]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 May 2010 21:55:33 +0530

John,

I think we can use the same term [Recording Session RS] and just have the scope/requirement of RS extended to be able to have a single RS with changes in CS ( due to transfer e.t.c). Of course the assumption is the SRC is in the path always. 
 
Regarding your objects X and Y, I feel they should be part of metadata and should not the be confused with the scope for Recording Session (RS).

Regards,
Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 8:48 PM
To: Paul Kyzivat (pkyzivat)
Cc: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; Leon Portman; [email-masked]; [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

Paul,

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 12:43:02 -0400

> I don't mind adopting the terminology that others are proposing, but I still think we might want a term for what I called "X".

I have no objection to additional terms/concepts if they are helpful and
make sense. I just don't know precisely what X and Y are. One thing that
comes to mind is "call-leg". But I don't know if that is quite what you
are talking about. Also, that seems to connote the media going in both
directions to a particular participant, which gets entangled with the
mixing strategy, so it may not be right.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 11 May 2010 21:23:12 +0200

Let me try again. Suppose we have the so-called persistent recording session (RS). First there is a communication session (CS) using narrowband audio only, say. During that CS, the RS will need to have narrowband audio. Then there is a second CS (perhaps the first one finishes and a new one starts, or call transfer occurs) and the second CS has wideband audio + video. So the RS might now need to support wideband audio + video (assuming both are to be recorded). Is that a new RS or a modification of the old RS? I had been advocating that it be treated as a new RS, but opinion seems to be against me, with people preferring to call it the same RS. So clearly we have two phases to the RS, one with one set of media characteristics and one set of metadata, and the other with a different set of media characteristics and different metadata. Do we need a term to describe such a phase (this was my "X" object)?

John

> Sent: 11 May 2010 17:43
> > I don't mind adopting the terminology that others are
> proposing, but I still think we might want a term for what I
> called "X".
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 15:53:06 -0400

John,

I don't see much difference between your scenario and one in which:

"First there is a communication session (CS) using narrowband audio
only, say. During that CS, the RS will need to have narrowband audio.
Later there is a new o/a exchange within that CS, changing to wideband
audio + video. So the RS might now need to support wideband audio +
video (assuming both are to be recorded)."

I suppose it could happen that the SRC attempts to switch the media with
the SRS and discovers the SRS is incapable of doing so. Then it could
start a new RS with a different SRS that is capable of handling the new
media. But in general I imagine it would hope to have selected an SRS
from the beginning that could handle the entire session.

This could of course happen as a result of a transfer too. I don't think
that changes anything.

The brutal fact is that media handling requirements can happen
mid-session, regardless of the wishes of some to make decisions at the
beginning of a session.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 11 May 2010 15:56:08 -0400

Hi John,

I think a model where the primitive is the communication session
(which in my mind aligns with a SIP dialog) is ok. If the audio CODECs
change mid-dialog (reINVITE to change audio, add/remove video etc.)
then the CS would need to keep track of this.

If a persistent or compound RS is required then I would expect it
reference a series of constituent CS elements. (i.e. all calls for
that user or a RS which has the before and after transfer CS elements.

Would an approach in which an RS is a collection of one or more CS
elements be viable? I think an RS then might be just a container which
holds references to one of more CS.

This does imply that if the common case is a one-to-one map of RS<->CS
then we have added a layer of indirection which is not commonly used.
Is this an ok price to pay?

Peter Musgrave

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 12 May 2010 09:58:08 +0800

The use case 9 says "Each conversation is stored as a *separate* recording.
The Supervisor call must be associated with the original customer call."
Isn't this implying what John is saying.

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年5月11日 19:13
To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;
[email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Using the same RS when CS user changes (was RE: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

John,

I am not sure that I understand your points here. The case we are talking
here is documented in Use Case 9 (Recording Complex calls) also in the
Requirement document where in the call from a Customer can be  transferred
to multiple Agents, Supervisor.

Assuming the Recording Client (RC) remains in the signaling path across
these supplementary services, we can have the same Recording Session to
indicate these changes (Transfer). In other words we can have just one
Recording Session for the entire call.

The protocol should provide a mechanism to allow this kind of recording and
there should not be a restriction in the requirement.

Thanks,
Ram

-----Original Message-----
Elwell, John

In an earlier message I queried the need for Persistent Recording. I don't
see the benefit in a single Recording Session (RS) spanning multiple
Communication Sessions (CS)  (although this does not preclude a solution
that might involve a single SIP dialog supporting multiple RSs - but that is
beyond the scope of the requirements document, which is what we are
discussing in this thread, despite the title).

So if we disregard the Persistent Recording option for the time being, if
call transfer is accomplished by REFER, resulting a new CS with a new SIP
dialog, then clearly, this would result in a new RS. If call transfer is
accomplished by 3PCC, I believe it still results in a new CS, even though it
would reuse the same SIP dialog at UA1. Therefore it would still result in a
new RS.

I think a lot of this discussion has been mixing up dialogs and sessions.
Discussion of SIP dialogs should not be part of the requirements discussion.

John (as individual)

> (use-case 4). The recording architecture should not limit these sort 
> of callflows.
>
> Thanks
> Partha
> I would say that in the event of call transfer a new Recording Session 
> would be started, to reflect the new Communication Session.
>
> John (as individual)
>
> > metadata has to be passed in the real time. REC-Time & CS-User shall 
> > be used as a identifier between SRC and SRS in case NTP exists.
> >
> > I don't see any requirement but a usecase for this. Do we need to 
> > add a requirement?
> > real-time (in case something gets changed). In contrast, we can just 
> > send
> the latest
> > analytics for example, such information supposed to be available in 
> > real time to the SRS. By real time I mean as soon as available to 
> > SRC.
> >
> > Leon
> >
> > 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.
> > [JRE] I would note that the latter parameter is not known until the 
> > end of the RS (see my comment above about timing).
> >
> > >       ......
> > [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)
> >
> >
> > >
> > > Regards
> > > Deepanshu
> > >
> > >
> > >
> > > 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)
> > >
> > >
> > > >
> > > > >>>  If the query is after the CS is ended, then how is it  made 
> > > > >>> if there is no CS?)
> > > > >>>

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 12 May 2010 10:34:42 +0800

I think a general requirement saying "The mechanism SHALL support means to
relate RS(s) with CS(s)" would suffice. CS-User change, media change will be
some of the probable usecase for that requirement.

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 2010年5月11日 21:47
To: Elwell, John; Ram Mohan R (rmohanr); Deepanshu Gautam; Leon Portman;
[email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

John,

Till now, the architecture is open and there is no 1:1 relationship between
RS and CS. From your description, it looks like that 1:1 dependency between
RS and CS is created. The protocol should not restrict. In case RS has to be
refined, we should discuss further and come with clear definition for RS. 

The extra correlation required to group the RS's of individual call shall be
avoided by having the single RS with the provision to modify the CS User
changes and its media properties. Even assuming CS media change should
impact RS media may not correct. CS may use some set of media properties, RS
may use some other media properties and SRC will do transcoding to make the
sync and it will be become implementation specific.

The requirement shall be "Recording session (RS) mechanism should support
CS-user changes, media changes in the mid-call" 

Thanks
Partha/Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 6:51 PM
To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; Leon
Portman; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

Ram,

This is really just a terminology issue. If we do as you propose, and say
that an RS can cover multiples CSs, then I believe we also need a name for
the object (let's call it X for now) that represents that part of an RS that
covers the recording of a single CS or part thereof. So the issue is:
- do we have an RS comprising (potentially) multiple Xs?
- or do we just have RSs, each covering a single CS (with perhaps a new
object Y that represents a set of related RSs)?

My preference would be the latter, because I think for most purposes we
would be talking about the recording of a single CS (or part thereof), and
only occasionally would we need to talk about recording of a set of related
CSs. This is because I see most RS-related attributes (e.g., media types and
formats, security keys, metadata, as potentially having a lifetime of only a
single CS, and changing from one CS to the next).

That is my personal preference, and if the majority prefer the first
terminology option then I could live with it - although I believe we would
need to find a term for X. The important thing is to have a complete and
consistent set of defined terms.

John (as individual)

---

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

Deepanshu,

""Each conversation is stored as a *separate* recording" - This is what we have been debating in the last few e-mails.
I am of the opinion that the Requirement should not restrict the RS to be separate for each change in the CS.
The protocol should allow to have a single RS with changes in CS users, media properties e.t.c.

IMO it should be left to the implementers. Depending on the capabilities of SRC and SRS and whether SRC is in the media path before and after supplementary services one of the approach can be taken.

Regards,
Ram

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年5月11日 19:13
To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;

John,

Thanks,
Ram

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

John (as individual)

---

From: Deepanshu Gautam <[email-masked]>
Date: Wed, 12 May 2010 12:22:03 +0800

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年5月12日 10:54
To: Deepanshu Gautam; Elwell, John; Parthasarathi R (partr); Leon Portman;

Deepanshu,

""Each conversation is stored as a *separate* recording" - This is what we
have been debating in the last few e-mails.
I am of the opinion that the Requirement should not restrict the RS to be
separate for each change in the CS.
The protocol should allow to have a single RS with changes in CS users,
media properties e.t.c.

IMO it should be left to the implementers. Depending on the capabilities of
SRC and SRS and whether SRC is in the media path before and after
supplementary services one of the approach can be taken.
[DG] I agree with you. None of the two approchaes should have requirements
in the req. document, it is implementation specific. I was just trying to
point out the text in the draft (usecase 9) which is confusing and needs to
be change.

BTW, a general requirement about RS being assosited with CS (I gave an
example in a separate email in the thread) would be possible.

Regards,
Ram

-----Original Message-----
From: Deepanshu Gautam [mailto:[email-masked]]
Sent: Wednesday, May 12, 2010 7:28 AM
To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); 'Leon
Portman'; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec]
FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
Sent: 2010年5月11日 19:13
To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;

John,

Thanks,
Ram

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

John (as individual)

---

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

Please see inline <Ram>

-----Original Message-----
From: Deepanshu Gautam [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2010 9:52 AM
To: Ram Mohan R (rmohanr); 'Elwell, John'; Parthasarathi R (partr); 'Leon Portman'; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 2010年5月12日 10:54
To: Deepanshu Gautam; Elwell, John; Parthasarathi R (partr); Leon Portman;

Deepanshu,

IMO it should be left to the implementers. Depending on the capabilities of
SRC and SRS and whether SRC is in the media path before and after
supplementary services one of the approach can be taken.
[DG] I agree with you. None of the two approchaes should have requirements
in the req. document, it is implementation specific. I was just trying to
point out the text in the draft (usecase 9) which is confusing and needs to
be change.
<Ram> Yes the text for use case 9 needs to be changed to allow to have single RS with changes in CS.
I have raised a ticket for the same.
http://trac.tools.ietf.org/wg/siprec/trac/ticket/18

Thanks,
Ram

Regards,
Ram

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
Sent: 2010年5月11日 19:13
To: Elwell, John; Parthasarathi R (partr); Deepanshu Gautam; Leon Portman;

John,

Thanks,
Ram

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

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 12 May 2010 11:56:34 +0530

I'm fine with Deepanshu proposed requirement text

Thanks
Partha 
-----Original Message-----
From: Deepanshu Gautam [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2010 8:05 AM
To: Parthasarathi R (partr); 'Elwell, John'; Ram Mohan R (rmohanr); 'Leon Portman'; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

I think a general requirement saying "The mechanism SHALL support means to relate RS(s) with CS(s)" would suffice. CS-User change, media change will be some of the probable usecase for that requirement.

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: 2010年5月11日 21:47
To: Elwell, John; Ram Mohan R (rmohanr); Deepanshu Gautam; Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

John,

Thanks
Partha/Ram

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, May 11, 2010 6:51 PM
To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Deepanshu Gautam; Leon Portman; [email-masked]; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: Using the same RS when CS user changes (was RE: [siprec] FW:I-DAction:draft-hutton-siprec-session-recording-arch-00.txt )

Ram,

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 May 2010 08:27:11 +0200

Yes, I think the addition of such a requirement would solve the problem.

John (as individual)

> Sent: 12 May 2010 03:35
> To: 'Parthasarathi R (partr)'; Elwell, John; 'Ram Mohan R
> (rmohanr)'; 'Leon Portman'; [email-masked];
> 'Paul Kyzivat (pkyzivat)'
> Cc: [email-masked]
> Gautam; Leon
> propose, and say
> perhaps a new
> purposes we
> lifetime of only a
> takes place
> Recording. I