Re: [dispatch] Lossless Recording in SIPREC

Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 10 February 2014 20:04 UTC

Return-Path: <mary.ietf.barnes@gmail.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 922961A0870 for <dispatch@ietfa.amsl.com>; Mon, 10 Feb 2014 12:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 C8aEimBV2H57 for <dispatch@ietfa.amsl.com>; Mon, 10 Feb 2014 12:04:01 -0800 (PST)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE671A06D6 for <dispatch@ietf.org>; Mon, 10 Feb 2014 12:04:01 -0800 (PST)
Received: by mail-yk0-f174.google.com with SMTP id 20so8483318yks.5 for <dispatch@ietf.org>; Mon, 10 Feb 2014 12:04:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6YeqIzlxNgWq0u78GWqtwbbSsRbGS63MYDSlyidncts=; b=RT0ujxvKx1wkkPtvARXIjnR6nF6WF/AFG7TIMXKOZbc91gJeL2y4q2RzAesTEjLDbf 9E6WzFHlZI4xpRwf6m3DHkjrrtO4K9aavqlWjehp+W8SFYc8fOCf+VhwQ12k5kirIzhQ pBf+RV1VEEmyvUgzIndTq21Ek+C8IYwGzKYj61gEgpn/jQwBacjisc3yEs9KxVF61rR2 Qe0EKUYdoFjqOR3GrlR1ZGM+66zd95Thtxkc9/FUkZ5jzIk4sn2sXFjpnVNvWtRDJOTK aI7UTUx0h7cr9VTQgaVuZYrc2TyTpgpAYs9hdcaGNetok++sIFbCe8l3nLEbgXa2skCH 3N3Q==
MIME-Version: 1.0
X-Received: by 10.236.130.116 with SMTP id j80mr2283722yhi.140.1392062641213; Mon, 10 Feb 2014 12:04:01 -0800 (PST)
Received: by 10.170.150.2 with HTTP; Mon, 10 Feb 2014 12:04:01 -0800 (PST)
In-Reply-To: <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> <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Mon, 10 Feb 2014 14:04:01 -0600
Message-ID: <CAHBDyN59SWK0+mrjb-SzZh+OGXyaJCzbCWpFWugitb1PC+xURA@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="20cf3010e62b3c14ca04f212d72a"
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 20:04:07 -0000

Keith,

I'm not sure what your point is.  The DISPATCH WG chairs make
recommendations to the ADs based upon what they perceive as interest on the
DISPATCH WG mailing list.   If you concerns about an explicit action noted
below, please be specific.  It's not clear to me whether your concerned
about the decision for the discussion to move to SIPREC or the general
DISPATCH approach.

Mary.


On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (Keith) <
keith.drage@alcatel-lucent.com> wrote:

>  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>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] On Behalf Of Ram
>> > Mohan R (rmohanr)
>>  > Sent: 06 February 2014 16:20
>> > To: Gerben Stam
>> > Cc: dispatch@ietf.org
>> > Subject: Re: [dispatch] Lossless Recording in SIPREC
>> >
>> > Hi,
>> >
>> > Please see inline
>> >
>> > -----Original Message-----
>> > From: Gerben Stam <Gerben.Stam@nice.com>
>> > Date: Thursday, 6 February 2014 8:40 pm
>> > To: Cisco Employee <rmohanr@cisco.com>
>> > Cc: "dispatch@ietf.org" <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]
>> > >Sent: donderdag 6 februari 2014 15:45
>> > >To: Gerben Stam
>> > >Cc: 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>
>> > >Date:  Thursday, 6 February 2014 3:58 pm
>> > >To:  Gerben Stam <Gerben.Stam@nice.com>
>> > >Cc:  "dispatch@ietf.org" <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 OElossless¹ 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 OElossless¹ 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
>> > https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
>