Re: [dispatch] Lossless Recording in SIPREC

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 10 February 2014 19:42 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6FA1A01A8 for <dispatch@ietfa.amsl.com>; Mon, 10 Feb 2014 11:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMhRW6zUsEAq for <dispatch@ietfa.amsl.com>; Mon, 10 Feb 2014 11:42:06 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD51A03C9 for <dispatch@ietf.org>; Mon, 10 Feb 2014 11:42:06 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1AJg3Uh018593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 13:42:05 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AJg25F004558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 20:42:02 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 20:42:02 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>, "Hutton, Andrew" <andrew.hutton@unify.com>
Thread-Topic: [dispatch] Lossless Recording in SIPREC
Thread-Index: AQHPJoOSx59IE/b4SkKjD7FE2seEVZqu4vvw
Date: Mon, 10 Feb 2014 19:42:02 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <CF199D4B.7A6E4%rmohanr@cisco.com> <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <CF19B110.7A78A%rmohanr@cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> <CAHBDyN4PfGJZsh1djzgNsB6PCiHQOgKAZ7JLOCm6gMWLJTGD0w@mail.gmail.com>
In-Reply-To: <CAHBDyN4PfGJZsh1djzgNsB6PCiHQOgKAZ7JLOCm6gMWLJTGD0w@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12F844FR712WXCHMBA11zeu_"
MIME-Version: 1.0
Cc: Gerben Stam <Gerben.Stam@nice.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Lossless Recording in SIPREC
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 19:42:10 -0000

According to the charter:

The Dispatch working group is chartered to consider proposals for
new work in the RAI area and identify, or help create, an appropriate
venue for the work.

I would read this as a working group decision rather than a WG chairs decision.

Keith



________________________________
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 10 February 2014 16:39
To: Hutton, Andrew
Cc: Gerben Stam; dispatch@ietf.org
Subject: Re: [dispatch] Lossless Recording in SIPREC

Yes, that is the appropriate action.  The ADs just met with the DISPATCH WG chairs in preparation for IETF-89. We discussed this topic and agree that discussion should move to SIPREC WG mailing list. But, it's important to note that this dispatchment in no way implies that the community agrees that work is needed. It's up to the SIPREC WG to make that decision.

Regards,
Mary
DISPATCH WG co-chair.


On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew <andrew.hutton@unify.com<mailto:andrew.hutton@unify.com>> wrote:
Hi Gerben,

Looking back at our off-list discussion I did actually say that you "should start a discussion on the SIPREC list".

Sorry if there was confusion.

Andy

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org<mailto:dispatch-bounces@ietf.org>] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: 06 February 2014 16:20
> To: Gerben Stam
> Cc: dispatch@ietf.org<mailto:dispatch@ietf.org>
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.Stam@nice.com<mailto:Gerben.Stam@nice.com>>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@cisco.com<mailto:rmohanr@cisco.com>>
> Cc: "dispatch@ietf.org<mailto:dispatch@ietf.org>" <dispatch@ietf.org<mailto:dispatch@ietf.org>>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a good
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispatch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com<mailto:rmohanr@cisco.com>]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatch@ietf.org<mailto:dispatch@ietf.org>
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch and
> >not in SIPREC WG which is meant to discuss the issues around SIP
> >recording ?
> >If you don¹t have any specific reason to do it here you may want to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com<mailto:Gerben.Stam@nice.com>>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <Gerben.Stam@nice.com<mailto:Gerben.Stam@nice.com>>
> >Cc:  "dispatch@ietf.org<mailto:dispatch@ietf.org>" <dispatch@ietf.org<mailto:dispatch@ietf.org>>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >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.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >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.
>
> There may be other approaches well. For example an SRC may buffer for a
> small duration to take care of the loss. Two parallel receivers still
> does
> not guarantee that recording is loseless as you can have UDP packet
> loss
> on both paths.
>
> >
> >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.
>
>
> Current SIPREC does not have any such constraints. Depending on your
> implementation model you can have the same CS recorded by multiple SRC
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > 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
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org<mailto:dispatch@ietf.org>
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org<mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch