Subject: [siprec] Persistent Recording Use Cases in draft-rehor-dispatch-session-recording-req-01

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Mar 2010 15:24:38 +0100

Hi,
 
I am having some difficulty understand Use Case 4 (Persistent Recording) and the implications of it.
 
The draft states

"The connection and attributes of media in the Recording Session are
   not dynamically signaled for each Communication Session before it can
   be recorded.  Call details and metadata will still be signaled, but
   can be post- correlated to the recorded media."

It seems that in this case the recording session can relate to many communication sessions and the communications sessions can occur in parallel (Fig. 7) or in sequence (Fig. 6). 

I think the text implies that there is a single offer/answer exchange for the RS. Is this correct ?

If so then this must assume that all the sessions contain the same media (e.g. audio, video) and this does not change and further more the codec does not change so the recording client will have to be able to transcode the media and not re-negotiate the codec with the recording server. Furthermore in the case of recording parallel communication sessions the client must be able to mix all the streams for each media type.  Are my assumptions correct and if so are these really the requirements we want to specify ?

The same use cases also states ?

"There will still need to be a means of correlating the recorded media connection/packets to
   the Communication Session, however this may be on a permanent filter-
   type basis, such as based on a SIP AoR of an agent that is always
   recorded, or based on identifiers in the recorded media itself".
 
Can someone explain this further and explain what is meant by "identifiers in the recorded media itself". 
 
Regards
Andy

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 19 Mar 2010 11:27:35 -0400

Hi Andy,

Pls. see inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hutton, Andrew
> Sent: Friday, March 19, 2010 10:25 AM
> To: [email-masked]
> Subject: [siprec] Persistent Recording Use Cases in draft-rehor-dispatch-
> session-recording-req-01
>
> Hi,
>
> It seems that in this case the recording session can relate to many
> communication sessions and the communications sessions can occur in parallel
> (Fig. 7) or in sequence (Fig. 6).

Correct.

> the RS. Is this correct ?

The recording session is a single RTP stream -- therefore a single offer/answer exchange. There may be mid-session RE-INVITE offer/answer exchanges for codec changes or for moving the RTP streams to handle failure scenarios.

> If so then this must assume that all the sessions contain the same media
> (e.g. audio, video) and this does not change and further more the codec does
> not change so the recording client will have to be able to transcode the
> media and not re-negotiate the codec with the recording server.

Codec re-negotiation is possible in a persistent recording session. I can see that the current draft language (the paragraph that you've quoted) may lead one to believe that there mid-session offer/answer exchanges aren't allowed in persistent recording sessions. We should improve the draft language.

Furthermore
> in the case of recording parallel communication sessions the client must be
> able to mix all the streams for each media type.  Are my assumptions correct
> and if so are these really the requirements we want to specify ?

I believe so. The issue is that when you're recording multiple CSs in a single RS, then the metadata must be able to communicate that.

> in the recorded media itself".

I'm not sure what that means either. I think that's a leftover statement from a previous revision of the draft.

Thanks,
Raj

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 19 Mar 2010 11:53:00 -0400

<as individual>
Why one stream per session?  If you have a typical audio+video SIP session
that you want to record, does it have to be two recording sessions, or can
it be one recording session with two RTP streams?

Brian

> The recording session is a single RTP stream -- therefore a single
> offer/answer exchange. There may be mid-session RE-INVITE offer/answer
> exchanges for codec changes or for moving the RTP streams to handle failure
> scenarios.
>

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 19 Mar 2010 12:01:20 -0400

> it be one recording session with two RTP streams?

Actually, there can be multiple RTP streams per recording session. Examples are audio+video, like you stated. Another scenario is two audio RTP streams per recording session - one which carries the CS's Tx audio and one which carries the CS's Rx audio.

Thanks,
Raj

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Mar 2010 18:42:49 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jain, Rajnish
> Sent: 19 March 2010 15:28
> To: Hutton, Andrew; [email-masked]
> Subject: Re: [siprec] Persistent Recording Use Cases in 
> draft-rehor-dispatch-session-recording-req-01
> 
> Hi Andy,
> 
> Pls. see inline:
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Hutton, Andrew
> > I am having some difficulty understand Use Case 4 
> (Persistent Recording) and
> > the implications of it.
> >
> > The draft states
> >
> > I think the text implies that there is a single 
> offer/answer exchange for
> > the RS. Is this correct ?
> 
> The recording session is a single RTP stream -- therefore a 
> single offer/answer exchange. There may be mid-session 
> RE-INVITE offer/answer exchanges for codec changes or for 
> moving the RTP streams to handle failure scenarios.
[JRE] Well, what about when the device handles two calls in parallel (I think >1 media per call has been addressed in other messages). I guess we assume that a user device capable of having >1 call in parallel would only have one active at a time, others would be held, in which case I guess we could re-negotiate the RS each time the user does hold retrieve. This may detract from the perceived clipping-avoidance benefits that a permanent RS might have, however.

Furthermore, what about the case where the RC is not a simple user device but an intermediary (an SBC, say)? There potentially could be a very large number of parallel calls, so how would the permanent RS apply then?

Having raised these questions, I don't want the requirements document to stray too far into architectural and mechanism details, but I would like to understand the requirement better.

> Codec re-negotiation is possible in a persistent recording 
> session. I can see that the current draft language (the 
> paragraph that you've quoted) may lead one to believe that 
> there mid-session offer/answer exchanges aren't allowed in 
> persistent recording sessions. We should improve the draft language.
> 
> Furthermore
> I believe so. The issue is that when you're recording 
> multiple CSs in a single RS, then the metadata must be able 
> to communicate that.
[JRE] An RC at an SBC, say, would certainly not want to mix media from different CSs.

John (as individual)

> > "There will still need to be a means of correlating the 
> recorded media
> > connection/packets to
> > Can someone explain this further and explain what is meant 
> by "identifiers
> > in the recorded media itself".
> 
> I'm not sure what that means either. I think that's a 
> leftover statement from a previous revision of the draft.
> 
> Thanks,
> Raj
> 
> DISCLAIMER: This e-mail may contain information that is 
> confidential, privileged or otherwise protected from 
> disclosure. If you are not an intended recipient of this 
> e-mail, do not duplicate or redistribute it by any means. 
> Please delete it and any attachments and notify the sender 
> that you have received it in error. Unintended recipients are 
> prohibited from taking action on the basis of information in 
> this e-mail.E-mail messages may contain computer viruses or 
> other defects, may not be accurately replicated on other 
> systems, or may be intercepted, deleted or interfered with 
> without the knowledge of the sender or the intended 
> recipient. If you are not comfortable with the risks 
> associated with e-mail messages, you may decide not to use 
> e-mail to communicate with IPC. IPC reserves the right, to 
> the extent and under circumstances permitted by applicable 
> law, to retain, monitor and intercept e-mail messages to and 
> from its systems.
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 19 Mar 2010 15:23:35 -0400

> [JRE] Well, what about when the device handles two calls in parallel (I
> think >1 media per call has been addressed in other messages). I guess we
> assume that a user device capable of having >1 call in parallel would only
> have one active at a time, others would be held, in which case I guess we
> could re-negotiate the RS each time the user does hold retrieve.

That may be the case. The other case is that the user has many active calls at the same time (e.g. multiple speakers on a trading phone).

This may
> detract from the perceived clipping-avoidance benefits that a permanent RS
> might have, however.
>
> Furthermore, what about the case where the RC is not a simple user device
> but an intermediary (an SBC, say)? There potentially could be a very large
> number of parallel calls, so how would the permanent RS apply then?

>From a definition perspective, the SBC would be a collection of RCs in that case. The RC-RS relationship doesn't change.

> Having raised these questions, I don't want the requirements document to
> stray too far into architectural and mechanism details, but I would like to
> understand the requirement better.

The main requirement here is media clipping.

> [JRE] An RC at an SBC, say, would certainly not want to mix media from

Possible. That's an RC (SBC) implementation issue.

Thanks,
Raj