Subject: Re: [siprec] Limiting the scope - voice only?

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Apr 2010 08:19:20 +0200

Let me qualify this. We probably should not be excluding things like real-time text and video, for the benefit of the hearing-impaired. But we could probably limit to RTP-based media, which would still save a significant amount of specification work by leaving out IM.

John

> -----Original Message-----
> From: Elwell, John 
> Sent: 21 April 2010 07:27
> To: [email-masked]
> Subject: Limiting the scope - voice only?
> 
> One possible way in which we could limit the scope would be 
> by restricting initial deliverables to voice, whilst trying 
> not to do anything that would prevent the addition of support 
> for other media types later. Is voice the most pressing 
> requirement, and if so, could we restrict initial 
> deliverables to voice, and would this result in a significant 
> reduction in work?
> 
> John

---

From: Leon Portman <[email-masked]>
Date: Thu, 22 Apr 2010 09:27:11 +0300

One comment regarding video. Even if it is RTP based like audio media stream, from the recording point of view it bring additional issues because there are key frames and delta packets (each packet is not independent like for audio stream). So for Recording on Demand for example (mid call recording) there can be a relatively long time (10 seconds or even more) between recording request and actual recording thus requiring some kind of buffering mechanisms and negotiations between Recording Client and Recording Server. And obviously, we want to keep this complexity out of scope for now.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, April 22, 2010 9:19 AM
To: [email-masked]
Subject: Re: [siprec] Limiting the scope - voice only?

John

> deliverables to voice, and would this result in a significant 
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 22 Apr 2010 02:36:54 -0400

Leon,

Are you referring to issues on playback or recording?  It seems the
recording step is not so complicated.  It sounds like the playback is what
you're concerned with, but I don't see that as a reason not to record
whatever you send to the recording server.

Paul

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Thursday, April 22, 2010 2:27 AM
> To: Elwell, John; [email-masked]
> One comment regarding video. Even if it is RTP based like audio media
> stream, from the recording point of view it bring additional issues
> because there are key frames and delta packets (each packet is not
> independent like for audio stream). So for Recording on Demand for
> example (mid call recording) there can be a relatively long time (10
> seconds or even more) between recording request and actual recording
> thus requiring some kind of buffering mechanisms and negotiations
> between Recording Client and Recording Server. And obviously, we want
> to keep this complexity out of scope for now.
> 
> Leon
> 
> Let me qualify this. We probably should not be excluding things like
> real-time text and video, for the benefit of the hearing-impaired. But
> we could probably limit to RTP-based media, which would still save a
> significant amount of specification work by leaving out IM.
> 
> John
>

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 22 Apr 2010 08:40:23 -0400

I think Leon raises an interesting point about video recording.

If we start a recording mid-stream all the video stream contains is
deltas which reference a previously sent full image (I-frame) which
the recorder does not have. To start a recording the recorder would
need to trigger the request of a new I-frame (either by RTCP using fir
or pli) or potentially by a SIP INFO carrying a PFU request. I suspect
this will mean telling the current receiver to generate a request on
behalf of the recorder (depending on how the stream is being relayed
to the recorder).

I think this does add complexity - and while we should make sure the
architecture does not preclude it - working out the details might be
able to come later.

Peter Musgrave

On Thu, Apr 22, 2010 at 2:36 AM, Paul E. Jones <[email-masked]> wrote:
>> Behalf Of Elwell, John

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 22 Apr 2010 10:15:48 -0400

Peter,

Yes, that would if we want to guarantee recording starts immediately even
after the session started.  And what if packets are lost mid-call, we have
the same issue.  I guess my question is: does it really matter?  It does if
one wants an error-free (or nearly error-free) recording.

These enhancements to improve video recording could be done later, but it's
probably important to think about how that will work so as to avoid
introducing something undesirable later.

Paul

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 8:40 AM
> To: Paul E. Jones
> Cc: Leon Portman; Elwell, John; [email-masked]

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 22 Apr 2010 11:37:52 -0400

Agreed.

I am in the "it really matters" camp.

Peter

---

From: "Gabor Moczar" <[email-masked]>
Date: Fri, 23 Apr 2010 11:33:41 +0200

I agree with Peter and Paul.
It would be a major step back if we do not introduce video in the initial
phase.
Video call recording systems we developed were suffering from the drawbacks
of not having such kind of standard. 

Gabor

-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 5:38 PM
To: Paul E. Jones
Cc: Leon Portman; [email-masked]
Subject: Re: [siprec] Limiting the scope - voice only?

Agreed.

Peter

On Thu, Apr 22, 2010 at 10:15 AM, Paul E. Jones <[email-masked]>
wrote:
> Peter,
>
> Yes, that would if we want to guarantee recording starts immediately 
> even after the session started.  And what if packets are lost 
> mid-call, we have the same issue.  I guess my question is: does it 
> really matter?  It does if one wants an error-free (or nearly error-free)
recording.
>
> These enhancements to improve video recording could be done later, but 
> it's probably important to think about how that will work so as to 
> avoid introducing something undesirable later.
>
> Paul
>
>> need to trigger the request of a new I-frame (either by RTCP using 
>> fir or pli) or potentially by a SIP INFO carrying a PFU request. I 
>> suspect this will mean telling the current receiver to generate a 
>> request on behalf of the recorder (depending on how the stream is 
>> being relayed to the recorder).
>>
>> On Thu, Apr 22, 2010 at 2:36 AM, Paul E. Jones 
>> <[email-masked]>
>> wrote:
>> > Leon,
>> >
>> > recording step is not so complicated.  It sounds like the playback 
>> > is
>> what
>> > you're concerned with, but I don't see that as a reason not to 
>> > record whatever you send to the recording server.
>> >
>> > Paul
>> >
>> >> stream, from the recording point of view it bring additional 
>> >> issues because there are key frames and delta packets (each packet 
>> >> is not independent like for audio stream). So for Recording on 
>> >> Demand for example (mid call recording) there can be a relatively 
>> >> long time (10 seconds or even more) between recording request and 
>> >> actual recording thus requiring some kind of buffering mechanisms 
>> >> and negotiations between Recording Client and Recording Server. 
>> >> And obviously, we
>> want
>> >> Let me qualify this. We probably should not be excluding things 
>> >> like real-time text and video, for the benefit of the
hearing-impaired.
>> But
>> >> we could probably limit to RTP-based media, which would still save 
>> >> a significant amount of specification work by leaving out IM.
>> >>
>> >> John
>> >>
>> >> > One possible way in which we could limit the scope would be by 
>> >> > restricting initial deliverables to voice, whilst trying not to 
>> >> > do anything that would prevent the addition of support for other 
>> >> > media types later. Is voice the most pressing requirement, and 
>> >> > if so, could we restrict initial deliverables to voice, and 
>> >> > would this result in a significant reduction in work?
>> >> >
>> >> > John