Re: [dispatch] Updated PERC Charter proposal

"Hutton, Andrew" <andrew.hutton@unify.com> Wed, 03 June 2015 08:42 UTC

Return-Path: <andrew.hutton@unify.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 5A7261A88E0 for <dispatch@ietfa.amsl.com>; Wed, 3 Jun 2015 01:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 G-QRMs1VnYRn for <dispatch@ietfa.amsl.com>; Wed, 3 Jun 2015 01:42:35 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C41A88D7 for <dispatch@ietf.org>; Wed, 3 Jun 2015 01:42:35 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 42E8A23F045F; Wed, 3 Jun 2015 10:42:34 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.213]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Wed, 3 Jun 2015 10:42:33 +0200
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
Thread-Topic: [dispatch] Updated PERC Charter proposal
Thread-Index: AQHQnWNihHzG6QUxl02HeR+DxLSPGZ2Z+VaAgAB+W3Q=
Date: Wed, 03 Jun 2015 08:42:33 +0000
Message-ID: <A634ECAF-9D68-41B7-85C6-F521F5BC821B@MRS>
References: <CAHBDyN6BeyL-wh_=t7jN+tfhTTnZK0uTBra-F7MR11x9eFkGpg@mail.gmail.com> <D188F24E.14D48%goran.ap.eriksson@ericsson.com> <55683230.3020600@ericsson.com> <CAHBDyN68U=KiyM8aTzbmmFzN9cZJ_MgZs00VPCODyufMn=JpUA@mail.gmail.com> <556C2A44.8010805@ericsson.com> <D193CBFB.32759%rmohanr@cisco.com> <CABcZeBMGUG0A8ypCz2kF8hqfsKemXK4CX8ujLFOi2HjGWunJ9g@mail.gmail.com> <556DDC0C.3010107@andyet.net> <CABcZeBPtc-Wp=4WSc_NXCZM+SSY6o0eFDbnPE+zCLTB_LY7PvQ@mail.gmail.com> <556DF837.8050704@alum.mit.edu>,<D1946A1E.32827%rmohanr@cisco.com>
In-Reply-To: <D1946A1E.32827%rmohanr@cisco.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/5cvF6nW_AW6shO3ddiB8uj0ho34>
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Updated PERC Charter proposal
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: Wed, 03 Jun 2015 08:42:37 -0000

I agree there is some value in exploring the recording use case it is one of the first questions everybody asks when discussing PERC.

Hope we are allowed to consider this.

Andy 



> On 3 Jun 2015, at 04:10, Ram Mohan R (rmohanr) <rmohanr@cisco.com> wrote:
> 
> Hi Paul,
> 
> -----Original Message-----
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Date: Wednesday, 3 June 2015 12:08 am
> To: "dispatch@ietf.org" <dispatch@ietf.org>
> Subject: Re: [dispatch] Updated PERC Charter proposal
> 
>> At some level this would "work", but it might require rethinking the
>> whole approach to recording in an enterprise where recording is an
>> important part of the business.
>> 
>> IIUC, with PERC there is still likely to be a conference focus, for
>> signaling, much as without PERC. But the details of how the media is
>> handled will be different
> 
> Yes. The way PERC handles media would likely bring in differences on how
> recording needs to be done.
> IIUC PERC also brings in a model where in the conference cloud is less
> trusted and hence there needs
> to be some thinking on how recording needs to be handled in general.
> 
>> . Such a focus could automatically bring in a
>> recorder as a participant. That is already one of the models covered by
>> siprec. But PERC would prevent the focus and the PERC 'mixer" from
>> directly serving as the SRC.
> 
> Yes. That¹s exactly where I am coming from as well. The conference model
> where a mixer acts as SRC that SIPREC defines today will not work with
> PERC. 
> I am trying to see if there is an interest in looking at this problem.
> Given that recording is critical in many business I believe there
> is some value in looking at it.
> 
> Regards,
> Ram
>> 
>>    Thanks,
>>    Paul
>> 
>> As long as PERC conferences are
>> 
>>> On 6/2/15 12:40 PM, Eric Rescorla wrote:
>>> 
>>> 
>>> On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet
>>> <peter@andyet.net <mailto:peter@andyet.net>> wrote:
>>> 
>>>    On 6/2/15 10:21 AM, Eric Rescorla wrote:
>>> 
>>>        The way you record PERC sessions is by bringing them into the
>>>        call at
>>>        the signaling level. There's no PERC-level accommodation needed.
>>> 
>>> 
>>>    Who is "them"? Do you mean "recording resources" of some kind would
>>>    be added as participants to the call? Just trying to clarify the
>>>    model...
>>> 
>>> 
>>> Yes.
>>> 
>>> -Ekr
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch