Subject: [dispatch] Lossless Recording in SIPREC

From: Gerben Stam <[email-masked]>
Date: Thu, 6 Feb 2014 10:28:00 +0000

Dear DISPATCH group,

SIPREC is a great initiative to standardize the interface for capturing Communication Sessions.
Session Recording is becoming more and more critical due to Compliance and regulatory changes over the last years.

The compliance market is requesting more than capture only these days
Confirmation is needed to acknowledge the entire Communication Session was captured correctly.
RTCP Reports (rfc3611) will help to confirm complete handover of RTP content.

New requirement is 'lossless' Session Capturing.
Lossless indicating handover of content (RTP) is acknowledged by the receiver AND in case of receiving issues, the sender will resend.
Reasons for loss may be UDP packet loss or receiver failing(over) and temporary not able to accept content.
Current approach to address this 'lossless' requirement is using 2 independent parallel receivers.
This requires the sender to send 2 individual streams, in fact 2 independent SIPREC sessions.
Not sure if this is covered currently as supported SIPREC deployment. We do see implementations based on SIPREC supporting it.
Alternative is quick failover at receiver in case of failure but as sender will send only once, this may lead to loss during failover.

I am not aware of any rfc covering lossless content handover, but there may be standards covering this already.

Looking forward to discussion on the mailing list. I may be at the London event.

Regards,

Gerben Stam,
NICE Systems

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 10:33:08 -0500

On 2/6/14 5:28 AM, Gerben Stam wrote:
> Session Recording is becoming more and more critical due to Compliance
> and regulatory changes over the last years.
>
> New requirement is ‘lossless’ Session Capturing.
>
> Lossless indicating handover of content (RTP) is acknowledged by the
> receiver AND in case of receiving issues, the sender will resend.

I am a novice at this subject, but ISTM that trying to invent something 
new to achieve reliability here is a bad idea. There are already RTP 
mechanisms that increase reliability of delivery. (E.g., FEC) And if 
that isn't good enough, then it is possible to use a reliable transport. 
But a reliable transport ceases to be real-time. That is presumably ok 
for recording, but in turn it means the SRC would need to buffer - 
potentially an arbitrary amount of buffering.

> Current approach to address this ‘lossless’ requirement is using 2
> independent parallel receivers.
> Not sure if this is covered currently as supported SIPREC deployment. We
> do see implementations based on SIPREC supporting it.

It is certainly acceptable for an SRC to establish sessions with 
multiple SRSs. We don't need any specific language to permit that.

And if you prefer, and can arrange it, you can have two different SRCs 
in the same CS, each recording to the same, or different, SRSs.

	Thanks,
	Paul

> Alternative is quick failover at receiver in case of failure but as
> sender will send only once, this may lead to loss during failover.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>