We would like to start a working group last call of = http://tools.ietf.org/html/draft-ietf-siprec-protocol-10

Please send comments by the end of the day on September 22^nd (Two week= s).

The deadline for requesting a meeting during IETF88 (Vancouver) is Sep= t 23^rd and whether or not there are WGLC comments on this draft may determine= whether we need a SIPREC meeting in Vancouver.

Regards

Andy (SIPREC Co-Chair).

&nbs= p;

--_000_9F33F40F6F2CD847824537F3C4E37DDF17BBABB6MCHP04MSXglobal_-- From andrew.hutton@siemens-enterprise.com Mon Sep 9 01:24:33 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA45021E80A3 for ; Mon, 9 Sep 2013 01:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoWyW0lM73mt for ; Mon, 9 Sep 2013 01:24:21 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E5C6411E8189 for ; Mon, 9 Sep 2013 01:24:19 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0A87123F053C; Mon, 9 Sep 2013 10:24:17 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Mon, 9 Sep 2013 10:24:14 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Meeting (or NOT) at IETF88 Thread-Index: Ac6tNfhvv0219Z/aQ0ickoQEXSOimQ== Date: Mon, 9 Sep 2013 08:24:16 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BBABC3@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SIPREC Meeting (or NOT) at IETF88 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 08:24:33 -0000 Hi, You might feel that you have just got home from Berlin but the deadline for= requesting meeting time at IETF88 (Vancouver) is fast approaching (23rd of= Sept). My current feeling is that there is no need for a SIPREC meeting at this ti= me unless there is new material to consider or we receive substantial WGLC = comments on draft-ietf-siprec-protocol-10 Please let me know if you have a view on this. Regards Andy From pkyzivat@alum.mit.edu Mon Sep 9 13:13:38 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9D211E813F for ; Mon, 9 Sep 2013 13:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1T0FQL28uaD for ; Mon, 9 Sep 2013 13:13:26 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D11BE21F9BFF for ; Mon, 9 Sep 2013 13:13:25 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id Nzp51m0021YDfWL538DNEB; Mon, 09 Sep 2013 20:13:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id P8DM1m01z3ZTu2S3g8DNEk; Mon, 09 Sep 2013 20:13:22 +0000 Message-ID: <522E2BE1.2070801@alum.mit.edu> Date: Mon, 09 Sep 2013 16:13:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF17BBABC3@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BBABC3@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378757602; bh=xhPPPvwsifKHPYantv3H9Xap0CIbqUJuzivp8FAqj3E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CnvRHp149V4vha9QzEYfz8JR4qMlxdyeLtjG/4kCi7LrW7TwoHf+CSmxacGHyCQ6B +uPL6vzyhJ4vhORCwYU8L2df9HO5BlWXJMYOUV8fvYgG/0/vjRmuzgoEiBrr2MaJvx GPo6A3cCmWIMmPHx6Ko531dy6w0zJdw14le2N/7jZ0Dkh1/zefg65ENUhnRGpESs5S rETE4yoFTnpniQ7Jgr6pdi9eLKPMv5CPFPvL6nsook8z5svVZZnnK2HMEnrpYcK6E2 5L1/F75jqS4P3vBEK6sgfa7RLcgSIO0k5ybbDrxZTLLVSzgGCgawi5QzFDeRhVbwvi MIzFwilzMSwxA== Subject: Re: [siprec] SIPREC Meeting (or NOT) at IETF88 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:13:38 -0000 Andy, We were hoping to use the siprec session to talk more about conferencing extensions. We are working on a refined proposal, within the boundaries discussed at the last meeting. How about a session with a focus on "the future of SIPREC"? Thanks, Paul On 9/9/13 4:24 AM, Hutton, Andrew wrote: > Hi, > > You might feel that you have just got home from Berlin but the deadline for requesting meeting time at IETF88 (Vancouver) is fast approaching (23rd of Sept). > > My current feeling is that there is no need for a SIPREC meeting at this time unless there is new material to consider or we receive substantial WGLC comments on draft-ietf-siprec-protocol-10 > > Please let me know if you have a view on this. > > Regards > Andy > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From mary.ietf.barnes@gmail.com Mon Sep 9 13:16:54 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A362211E81C8 for ; Mon, 9 Sep 2013 13:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.933 X-Spam-Level: X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMpW0ObudD6 for ; Mon, 9 Sep 2013 13:16:53 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEEA11E81B6 for ; Mon, 9 Sep 2013 13:16:53 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so483948qab.1 for ; Mon, 09 Sep 2013 13:16:51 -0700 (PDT) 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=l2BQ1PJHlh8TDWJh3L6GG4H50cpN1GBHkQA518Ufzww=; b=NaTTHmnxIRnTHxvzT2lUblrVRMqDNfb6END6tk2gZrmXZ4qePJsQsPQfNu3rPnETE6 U2Wz/qVr2fcmZ7GF8iI7A9gpSMoMQ3p0BDsFQ9QBfVTno2mVp7DIylxIuSP6kKnxZSeg LdcvZqf25iAocE1LCmObrsWoKhx7cDC3NB1xpd5nb1F/RcerU8gKs5MNI0zqmkYtEgek hXWD92bctEdWaA08E7AtuMMy4o2I4X6r+J0xL1E+utDKFEtoFckajQsJAEKp5eFp0Wcg 17jBaJbXS3IDzkpREaxbS1i9Wquo44TvZUsSgk1n3iI1zTJxL2ZjtG8MeBcOxfF/t9Ov 5rpw== MIME-Version: 1.0 X-Received: by 10.224.96.197 with SMTP id i5mr3775580qan.63.1378757811902; Mon, 09 Sep 2013 13:16:51 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Mon, 9 Sep 2013 13:16:51 -0700 (PDT) In-Reply-To: <522E2BE1.2070801@alum.mit.edu> References: <9F33F40F6F2CD847824537F3C4E37DDF17BBABC3@MCHP04MSX.global-ad.net> <522E2BE1.2070801@alum.mit.edu> Date: Mon, 9 Sep 2013 15:16:51 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1132ebc69c20b404e5f91141 Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Meeting (or NOT) at IETF88 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:16:54 -0000 --001a1132ebc69c20b404e5f91141 Content-Type: text/plain; charset=ISO-8859-1 To me the question is whether this should take up a full WG slot or whether we should have more of an adhoc with the interested parties to agree what we think is a good scope? OR, we should start that discussion now so a meeting in Vancouver can be very focused rather than open ended. Mary. On Mon, Sep 9, 2013 at 3:13 PM, Paul Kyzivat wrote: > Andy, > > We were hoping to use the siprec session to talk more about conferencing > extensions. We are working on a refined proposal, within the boundaries > discussed at the last meeting. > > How about a session with a focus on "the future of SIPREC"? > > Thanks, > Paul > > > On 9/9/13 4:24 AM, Hutton, Andrew wrote: > >> Hi, >> >> You might feel that you have just got home from Berlin but the deadline >> for requesting meeting time at IETF88 (Vancouver) is fast approaching (23rd >> of Sept). >> >> My current feeling is that there is no need for a SIPREC meeting at this >> time unless there is new material to consider or we receive substantial >> WGLC comments on draft-ietf-siprec-protocol-10 >> >> Please let me know if you have a view on this. >> >> Regards >> Andy >> ______________________________**_________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/**listinfo/siprec >> >> > ______________________________**_________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/**listinfo/siprec > --001a1132ebc69c20b404e5f91141 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

To me the question is whether this should take up a full W= G slot or whether we should have more of an adhoc with the interested parti= es to agree what we think is a good scope? =A0OR, we should start that disc= ussion now so a meeting in Vancouver can be very focused rather than open e= nded.

Mary.=A0

On Mon, Sep 9, 2013 at 3:13 PM, Paul Kyzivat <pk= yzivat@alum.mit.edu> wrote:

Andy,

We were hoping to use the siprec session to talk more about conferencing ex= tensions. We are working on a refined proposal, within the boundaries discu= ssed at the last meeting.

How about a session with a focus on "the future of SIPREC"?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

On 9/9/13 4:24 AM, Hutton, Andrew wrote:

Hi,

You might feel that you have just got home from Berlin but the deadline for= requesting meeting time at IETF88 (Vancouver) is fast approaching (23rd of= Sept).

My current feeling is that there is no need for a SIPREC meeting at this ti= me unless there is new material to consider or we receive substantial WGLC = comments on draft-ietf-siprec-protocol-10

Please let me know if you have a view on this.

Regards
Andy
_______________________________________________
siprec mailing list
siprec@ietf.org = https://www.ietf.org/mailman/listinfo/siprec

_______________________________________________
siprec mailing list
siprec@ietf.org = https://www.ietf.org/mailman/listinfo/siprec

--001a1132ebc69c20b404e5f91141-- From pkyzivat@alum.mit.edu Mon Sep 9 15:19:35 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5011E8158 for ; Mon, 9 Sep 2013 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+hDCx0fdmJO for ; Mon, 9 Sep 2013 15:19:31 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id BD94311E8136 for ; Mon, 9 Sep 2013 15:19:30 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Nzwp1m00127AodY5BAKWQM; Mon, 09 Sep 2013 22:19:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id PAKV1m01D3ZTu2S3fAKVER; Mon, 09 Sep 2013 22:19:30 +0000 Message-ID: <522E4971.9020302@alum.mit.edu> Date: Mon, 09 Sep 2013 18:19:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <9F33F40F6F2CD847824537F3C4E37DDF17BBABC3@MCHP04MSX.global-ad.net> <522E2BE1.2070801@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378765170; bh=iucDQT5v7DDYgMKYJ7UaKQmEtC3mc4YJSiHBiziEIcI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gEh8P0CkU+PeKwVMpQisK9fGYK3mZSlDNLrl+ns1t9MkzPlYu4OIsOC/RLYH7au9Z hjp4Pq2lvcgYTroutRcdczvDPQ9T0+y4xT6LH15zX6xE63Y5PTn4u1DWYMt4+VYyR8 lV7n/cL8JLoQPIW0vBdwCmKt4M5WfvYHfIzWfco5rlPPM3x/crwFnnMZMFqbJdFb1A 7pO8ws2+D9ubYhHy0pziBDD3jfx8hKV4iUtIbhZOvmdVPC9VeA3tAgGeacgc1Dd+Ok RQbti0gBDKZALuSrqHTqc1t/hxjNDKIPxHNmHXuiFvDoMDP5m+4wwphUfpi5dqfFqe /EnL8G9vkC5CQ== Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Meeting (or NOT) at IETF88 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 22:19:35 -0000 On 9/9/13 4:16 PM, Mary Barnes wrote: > To me the question is whether this should take up a full WG slot or > whether we should have more of an adhoc with the interested parties to > agree what we think is a good scope? OR, we should start that > discussion now so a meeting in Vancouver can be very focused rather than > open ended. We can start the discussion soon. We are updating the materials. Thanks, Paul > Mary. > > > On Mon, Sep 9, 2013 at 3:13 PM, Paul Kyzivat > wrote: > > Andy, > > We were hoping to use the siprec session to talk more about > conferencing extensions. We are working on a refined proposal, > within the boundaries discussed at the last meeting. > > How about a session with a focus on "the future of SIPREC"? > > Thanks, > Paul > > > On 9/9/13 4:24 AM, Hutton, Andrew wrote: > > Hi, > > You might feel that you have just got home from Berlin but the > deadline for requesting meeting time at IETF88 (Vancouver) is > fast approaching (23rd of Sept). > > My current feeling is that there is no need for a SIPREC meeting > at this time unless there is new material to consider or we > receive substantial WGLC comments on draft-ietf-siprec-protocol-10 > > Please let me know if you have a view on this. > > Regards > Andy > _________________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/__listinfo/siprec > > > > _________________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/__listinfo/siprec > > > From pkyzivat@alum.mit.edu Tue Sep 10 14:57:58 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480DC21F9A59 for ; Tue, 10 Sep 2013 14:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wfUK+zD2vRL for ; Tue, 10 Sep 2013 14:57:53 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7921F99F4 for ; Tue, 10 Sep 2013 14:57:49 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id PR7i1m0010xGWP854ZxoFT; Tue, 10 Sep 2013 21:57:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id PZxo1m01G3ZTu2S3YZxoYt; Tue, 10 Sep 2013 21:57:48 +0000 Message-ID: <522F95DC.3030904@alum.mit.edu> Date: Tue, 10 Sep 2013 17:57:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF17BBABB6@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BBABB6@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378850268; bh=jGl+AYr+oQHKXcNGNooJFjYQbiSlO860ySNShQtiq/8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ePynE4rtcu2qVpR6iAEBB16i5q6pLcEFCvVKR0OV4L2FUiM18yrlY/DYsBhCn4Rtk K+7gOGb96xr75ZUxvXzJhdWOwLxWfwxFpjwMBbw+Gc6FW4hl/gpPhGv7fa1PWaQTfs LxAS4RAdlQauxQ8U9imSlgxOMFb+fU4tAiMprXbRvk92iGnPZN2jCvNNX76jd5qukN 1NTG0HyQtVCBdi/mnxZY5WUP0YE70Yxd/8qtZZ6/l7bFFYmHjhbYE5F4rdzkE3ij7C 9HiPOh061OmQVYzgxcznwu/1WJ9LrAZrE33H/2PIH8rpAg6fFw5lTgsnR3en4pSMP0 NBx1kjZXXYMbQ== Subject: Re: [siprec] WGLC on draft-ietf-siprec-protocol-10 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:57:58 -0000 I hadn't read this all the way through for a long time. (I've just been looking at the diffs.) It is instructive to read it all. I found a lot of relatively minor stuff, and one thing that is going to require more thought and discussion. Many places containing ABNF: The operator "/=" is being used, but the correct operator is "=/". This suggests that a syntax verification of the ABNF is called for. There is a tool for that. But to do it right requires extracting all the ABNF, merging with the referenced ABNF, and then running the tool. The remaining comments follow the order of text in the document. Section 5: Section 6 describes SIP the handling in a recording session between a SRC and a SRS, and the procedures for recording-aware user agents participating in a CS. I can't parse the beginning of this sentence. I think you might mean: Section 6 describes the SIP handling in a recording session between a SRC and a SRS, ... Section 6.1.1.1: In addition, when an SRC sends a REGISTER request to a registrar, the SRC MUST include the '+sip.src' feature tag to indicate the that it is a SRC. This could be misinterpreted. And I'm not sure it should always be true. Consider an ordinary UA that sometimes or always acts as an SRC to record its own calls. Why would it want to indicate this to a registrar. That might be a good thing, if a caller wants to use callerprefs to select a callee UA that can record calls. But that is an odd thing to do. It could be a good thing if there is a pool of B2BUAs that are registered to a common AOR. It would allow recruiting one by sending an INVITE to it. But this is also very obscure usage. Normally B2BUAs are selected more overtly, and not by the UAC. Its especially bad if this is taken literally by a box that is don't registrations of contact URIs other than its own. For instance, a PBX B2BUA box that is an SRC, but that also registers contact URIs on behalf of its endpoints. It would not want to do this on behalf of those endpoints. So can someone refresh my memory about why this is a good thing? If this is to be kept, then it would be better if it is worded as: When the URI of an SRC is included in a REGISTER request to a registrar, then the '+sip.src' feature tag SHOULD be included in the contact URI for the SRC. Section 6.2: Similar issue to the one above for section 6.1.1.1. In addition, when an SRS sends a REGISTER request to a registrar, the SRS MUST include the '+sip.srs' feature tag to indicate that it is a SRS. At least it is more likely that an SRC might be sending an INVITE to an AOR in order to reach an SRS, so this might have some utility. (But would an AOR used to describe SRSs have any registrations for non-SRSs? And some of the problem cases I mentioned re SRCs are less likely for SRSs. But I still recommend the analogous text change here: When the URI of an SRS is included in a REGISTER request to a registrar, then the '+sip.srs' feature tag SHOULD be included in the contact URI for the SRS. Section 6.3: A recording-aware UA MUST be prepared to provide recording indication to the end user through an appropriate user interface an indication whether recording is on, off, or paused for each medium. I can't parse this sentence. How about: A recording-aware UA MUST be prepared to provide a recording indication to the end user through an appropriate user interface, indicating whether recording is on, off, or paused for each medium. Section 7.1.1.1: The following is slightly ambiguous: Note that a CS itself may change the media stream direction by updating the SDP, for example, by setting a=inactive for SDP hold. Media stream direction changes in CS are conveyed in the metadata by the SRC. The SRC MUST NOT modify the media stream with a=inactive for SDP hold on the CS since this operation is reserved for pausing the RS media, however, an SRC can have a local policy to pause the RS media when the CS is placed on hold. In the last sentence above, it isn't clear which media stream is being referenced in "The SRC MUST NOT modify the media stream". So I suggest changing this to: The SRC MUST NOT modify the RS media stream with a=inactive for SDP hold on the CS since this operation is reserved for pausing the RS media, ... Section 7.1.3: When the SRC receives the a=recordpref SDP in an SDP offer or answer, the SRC chooses to honor the preference to record based on local policy at the SRC. Whether or not the SRC honors the recording preference, the SRC MUST update the a=record attribute to indicate the current state of the recording (on/off/paused). Its unclear to me what the MUST means. The following are some things that might be done: - if the a=recordpref is received in an offer, put the resulting a=record setting in the answer. - if the a=recordpref is received in an offer or answer, send a new offer *soon* to all CS legs with the resulting a=record. - same as above. Unconditionally send to leg that changed a=recordpref, but don't send again to other legs if recording state remains as it was. Also, ISTM that once a UA has put a=recordpref in its SDP, it will probably leave it there, unchanged, through subsequent O/A cycles. That means, for the above, every time it sends an offer or answer, it will be sending a=recordpref again. It would be unfortunate if that forced the SRC to send *another* offer. (It could lead to an infinite o/a loop.) I *don't* think it is a good idea to treat this as a one-time request. So I suggest that both a=recordpref and a=record should be viewed as *state* that is announced in every offer or answer. As long as the state remains unchanged, it is just put into each offer or answer when they are required for other purposes. When one of them changes state, then an offer or answer must be sent asap to announce the change. Section 7.3: (THE BIG ISSUE IS HERE) This section brings up the situation where there are multiple SRCs in the CS. That presents some other issues that I don't think we have considered. Suppose we have: UA1 ----- SRC1 ---- B2BUA ---- SRC2 ----- UA2 (UA1, B2BUA, and UA2 all indicate they are recording aware.) Now suppose SRC1 is recording, and SRC2 is not recording. What sort of recording indications do we have in the CS signaling? Initially - SRC1 would send a=recording:on to UA1 and B2BUA - SRC2 would send a=recording:off to UA2 and B2BUA - B2BUA would propagate a=recording:on to SRC2 and propagate a=recording:off to SRC1 ??? Then, what do SRC1 and SRC2 do when they receive these values from the B2BUA? This is actually quite a mess. I think *somebody* needs to keep a count of recordings. Either we put the count into the attributes, or we make some of the components keep the count. The latter might be easier. I think only recording aware B2BUAs and conference foci (including those that are SRCs) would need to do this. They would need to keep a count over all their legs. (And an SRC B2BUA would include its own recording in this count.) When the count is zero the recording state is off, else it is on. (Need more analysis for what to do with pause.) Some similar treatment is probably required for recordpref. My head hurts now, so I'm not doing it here. I think we need some list discussion on this! Note that the solution to this will probably invalidate the suggestion I made for 7.1.3. Section 8.1.5.1: Do we want to reference the new mechanism for chooseing CNAME that has been proposed by EKR? (I forget the draft name, or if it has become and RFC.) Section 8.2: First paragraph: There are numerous ways in which an SRC may do this is, including but not limited to, appearing as a UA within a CS, or as a B2BUA between UAs within a CS. s/do this is/do this/ Section 8.3: An SRC may choose to use one or more of the RTP session usages within a single RS. For the purpose of base interoperability between SRC and SRS, an SRC MUST support separate m-lines in SDP, one per CS media direction. I find the above confusing. (But maybe just because I don't understand enough about RTP.) Isn't the SRC the one that is deciding what usage to employ? If so, and if it must support separate m-lines, then under what circumstance would it employ anything else? Is the intended to be determined by configuration during deployment? Or my multiple o/a attempts? Or by CAPNEG? Or what? Section 8.3.1: Additionally, the SRC SHOULD map each unique combination of CNAME/SSRC within the CSs to a unique CNAME/ SSRC within the RS. Isn't it ok to map both CNAME1/SSRC1 and CNAME1/SSRC2 in the CS to CNAMEn/SSRCn in the RS? The above statement seems to suggest not. Section 8.4: IIUC, normal draft style is to indent notes relative to the surrounding text. Section 9.1: When the SRC sends a full metadata snapshot, the SRC MUST send an INVITE or an UPDATE request ... A partial update sent by the SRC can be an INVITE request or response with an SDP offer, or an INVITE/UPDATE request or response containing a "recording-session" disposition, or an INVITE request containing both an SDP offer and the "recording-session" disposition. I find the above confusing. For one thing, disposition is associated with a body part, not a request. A request can have multiple body parts, each with its own disposition. Offers and answers are carried in body parts with disposition "session". (Its the default, so you don't often see it written.) There could also be other body parts. We don't care about those so we ignore them. In principle a given body part with a particular disposition might be valid with any of a variety of content types. But in practice, session always contains application/sdp and recording-session always contains application/rs-metadata or application/rs-metadata-request. So we can simply talk about the possibilities in terms of the content types it contains. In the case of SDP, it may be either an offer or answer. That is only determined by context - you cant tell by looking at a single message. AFAIK we have the following valid sip signaling possibilities on the RS: - INVITE by SRC: offer-sdp, metadata response by SRS: answer-sdp - INVITE by SRC: offer-sdp response by SRS: answer-sdp - INVITE by SRS: response by SRC: offer-sdp, metadata - INVITE by SRS: response by SRC: offer-sdp - UPDATE by SRC: offer-sdp, metadata response by SRC: answer-sdp - UPDATE by SRC: offer-sdp response by SRS: answer-sdp - UPDATE by SRS: response by SRC: - UPDATE by SRS: offer-sdp response by SRC: answer-sdp - UPDATE by SRS: metadata-request response by SRC: Of those, only three carry metadata: - INVITE by SRC: offer-sdp, metadata - INVITE by SRS: response by SRC: offer-sdp, metadata - UPDATE by SRC: offer-sdp, metadata That is independent of whether the metadata is a snapshot or a partial. The special case for a snapshot request is: - UPDATE by SRS: metadata-request response by SRC: and followed by one of the two above initiated by the SRC: - INVITE by SRC: offer-sdp, metadata - UPDATE by SRC: offer-sdp, metadata So how to say all that in a comprehensible way? How about replacing that entire paragraph with the following: "Metadata sent by the SRC can be categorized as either a full metadata snapshot or partial update. A full metadata snapshot describes all the recorded streams and all metadata associated with the recording session. The SRC MAY send a full metadata snapshot at any time. The SRC MAY send a partial update if a full metadata snapshot has previously been sent. If the SRC receives a snapshot request from the SRS, then it MUST immediately send a full metadata snapshot. The SRC MAY send metadata (either a full metadata shapshot or a partial update) in either an INVITE request, an UPDATE request, or in the final (200) response to an offerless INVITE from the SRS. If any of the metadata being sent contains a reference to any SDP labels, then the request containing the metadata MUST also contain an SDP offer that defines those labels. When an INVITE or UPDATE request contains both an SDP offer and metadata, then the request body has content type multipart/mixed, with one subordinate body part containing the SDP offer and another containing the metadata. When an INVITE contains only an SDP offer or metadata, then the multipart/mixed container is optional." Figure 11: (A nit) there is no need for "application/rs-metadata" in the Accept. (This only describes what can be *received*, and the SRC will never receive this.) Section 9.2: When the SRS explicitly requests for a full metadata snapshot, the SRS MUST send an UPDATE request without an SDP offer. A metadata snapshot request contains a content with the content disposition type "recording-session". ... The above is at least awkward. How about: The SRS MAY explicitly request a full metadata snapshot by sending an UPDATE request. This request MUST contain a body with a content disposition type "recording-session", and MUST NOT contain an SDP body part. ... Then further into this section: When the SRC receives the request for a metadata snapshot, the SRC MUST provide a full metadata snapshot in a separate INVITE or UPDATE transaction, along with an SDP offer. All subsequent metadata updates sent by the SRC MUST be based on the new metadata snapshot. Most of the time SDP will be required. But its possible that there are currently no media streams, and hence no references to SDP. In that case the SDP isn't needed. (To avoid the SDP, the metadata would need to be sent in an UPDATE.) I covered the cases where SDP must be sent in my proposed changes above, so it doesn't really need to be mentioned here. Also, subsequent partial updates could depend on future full snapshots, not just this one. So how about changing the above to: When the SRC receives a request for a metadata snapshot, it MUST immediately provide a full metadata snapshot in a separate INVITE or UPDATE transaction. Any subsequent partial updates will not be dependent on any metadata sent prior to this full metadata snapshot. Section 9.2.1: The ABNF references TEXT-UTF8-TRIM, but doesn't specify where this is defined. (It comes from 3261.) Section 11.5.1, 11.5.2: These list Leon with his Nice email address. This should probably be changed. Section 12: Have we had a security review yet? Section 12.2: Authors Addresses: Lean is still shown at Nice. That's all. Thanks, Paul On 9/9/13 4:23 AM, Hutton, Andrew wrote: > We would like to start a working group last call of > _http://tools.ietf.org/html/draft-ietf-siprec-protocol-10_ > Please send comments by the end of the day on September 22^nd (Two weeks). > The deadline for requesting a meeting during IETF88 (Vancouver) is Sept > 23^rd and whether or not there are WGLC comments on this draft may > determine whether we need a SIPREC meeting in Vancouver. > Regards > Andy (SIPREC Co-Chair). > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Fri Sep 13 07:24:49 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C521E8098 for ; Fri, 13 Sep 2013 07:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFt1ZDHewy6L for ; Fri, 13 Sep 2013 07:24:38 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id D628621E8055 for ; Fri, 13 Sep 2013 07:24:37 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id Qbgu1m0010SCNGk5AeQct7; Fri, 13 Sep 2013 14:24:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id QeQc1m00Z3ZTu2S3VeQcdg; Fri, 13 Sep 2013 14:24:36 +0000 Message-ID: <52332023.5070006@alum.mit.edu> Date: Fri, 13 Sep 2013 10:24:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: multipart/mixed; boundary="------------050504060706070902000506" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379082276; bh=g0U990FfGhKFSHZsxiJmnk9AbyMalVkyIpPimznvbN4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mXHDw/p+PJidegmUry/A70dDQ2Powwcs7xXjOY4rh+H5nvR6Y1152MSPswk7Luwr9 D7z0QZHoN6SfvW2wFErKyT8QrxOpqHJviZNbT8j2YyOe6u6BhU/IzbHOTC6HOnDlIy VJpvwVJUere0zjBxaUltFxY/8k9e6DEkEnCJ6L9+vumjAG0acumRzT9sLOwML+fV4h CNs2WDMbEIL3IVNKMz3XWSswWkFUbRC9eIz6vigoi3M3UWqKswWiqAaWhAUjsfvzG0 Xu9KnAqxNZYpWaKW6PqsWDwqkhooLqbQUAZO5ovRovr3gHCvB3dk7m3SRNTihScWiQ +5ABrZUO2oHNw== Subject: [siprec] Proposal: new SIPREC work on conference recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:24:49 -0000 This is a multi-part message in MIME format. --------------050504060706070902000506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In Berlin I spoke about a proposal to extend the siprec charter to more fully address conference recording. There was good feedback during that meeting about where to focus, and significant interest in going forward with this. Since then Simon Romano, my associate Michael Yan, and I have refined a use case and requirements draft about that, which was just posted. The announcement of that draft is attached. I request that all you SIPRECers please review and comment on this draft. I'd appreciate feedback to make it better. In conjunction with that, below are are specific siprec charter change proposals, to extend our scope to cover this work. I'm also soliciting comments on these. After some list discussion on the draft and the charter changes, I hope we can have a session at ietf88 to progress this. Thanks, Paul --------------------------------------------------------------------- PROPOSED SIPREC CHARTER REVISION (as deltas to current charter): --------------------------------------------------------------------- > The Session Recording Protocol (SIPREC) working group is chartered to > define a SIP-based protocol for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such as call centers and financial trading > floors. [Replace above sentence with:] Session recording is a critical requirement in many business communications environments such as call centers, financial trading floors, and multimedia conferences. > In some of these environments, all calls must be recorded for > regulatory and compliance reasons. In others, calls may be recorded for > quality control, business analytics, or consumer protection. Recording > is typically done by sending a copy of the media to the recording > devices. The working group will determine requirements and produce a > specification for a protocol that will manage delivery of media [Insert:] (including audio, video, MSRP instant message sessions, and real-time sharing of documents, applications, and computer screens) > from an > end-point that originates media, or that has access to it, to a > recording device. PBX and recording vendors today implement proprietary, > incompatible mechanisms to facilitate recording. A standard protocol > will reduce the complexity and cost of providing such recording > services. > > The Session Recording problem presents certain unique requirements that > are not addressed in the current SIP protocol specification. These > include requirements such as the need for a distinction between the > session that is being recorded versus the session that has been > established for recording. > > Privacy and security of conversations are significant concerns. The > working group will make sure that any protocol specified addresses these > concerns and includes mechanisms to alert users to the fact that a > session they are participating in is being recorded. > > The working group must take care that the session recording requirements > and protocol does not conflict with the IETF statement on wiretapping > contained in RFC 2804. > > The SIPREC Working Group will thoroughly identify use cases, provide > example system architectures and deployment scenarios, and define > requirements. > > The scope of the activity includes: > > * Recorder Control > > * Session metadata content and format > > * Security mechanisms, including transport and media encryption > > * Privacy concerns, including end-user notification > > * Negotiation of recording media streams > > The group will define these issues and rationalize with IETF standards > and practices. This includes encryption, NAT traversal, operations and > manageability, SIP-enabled firewalls, authorization, and security. > > The group will produce: > > * Updated Requirements, Use Cases, Architecture draft > > * Specification for Session Recording Protocol [Insert:] and Metadata > > Milestones > Done Use Cases and Requirements to IESG as Informational RFC > Jan 2013 Submit Architecture to IESG as Informational RFC > Apr 2013 Submit protocol draft to IESG as Proposed Standard RFC > Aug 2013 Submit Metadata model and format to IESG as Proposed > Standard RFC > Aug 2013 Submit SIPREC Call Flows draft to IESG as an > informational RFC. [additional milestones - optimistic dates:] Apr 2014 Conference Recording Use Cases and Requirements to IESG as Informational RFC Aug 2014 Conference Recording Architecture to IESG as Informational RFC Aug 2014 Protocol and metadata for MSRP recording to IESG as Proposed Standard RFC Dec 2014 Protocol and metadata for recording of document & application sharing to IESG as Proposed Standard RFC --------------050504060706070902000506 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: srs0=z8ty=sz=ietf.org=internet-drafts@alum.mit.edu Received: from imta37.westchester.pa.mail.comcast.net (LHLO imta37.westchester.pa.mail.comcast.net) (76.96.62.97) by sz0055.wc.mail.comcast.net with LMTP; Fri, 13 Sep 2013 05:56:05 +0000 (UTC) Received: from alum-mailsec-relay-9.mit.edu ([18.7.68.29]) by imta37.westchester.pa.mail.comcast.net with comcast id QVw41m01D0dt8C20cVw45g; Fri, 13 Sep 2013 05:56:05 +0000 X-CAA-SPAM: 00000 X-Authority-Analysis: v=2.1 cv=e4I/F8Z/ c=1 sm=1 tr=0 a=MRj2BPNAhLswQ1TjTjGTrQ==:117 a=GU4rwa5YvsQnE15YQEkOQw==:17 a=C_IRinGWAAAA:8 a=lS0MHldHvS4A:10 a=DoyLNiy-LgAA:10 a=LSVET5z0puwA:10 a=Y8pcNLQseH4A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=T4iP7njNTVoA:10 a=zzPzetCxK8GqC5mrGfoA:9 a=8NNSE5sbPybOGbzR:21 a=xKt_Q0fzxkLi1MIo:21 a=QEXdDO2ut3YA:10 Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by alum-mailsec-relay-9.mit.edu (8.14.7/8.12.8) with ESMTP id r8D5tkbt011309 for ; Fri, 13 Sep 2013 01:56:04 -0400 X-AuditID: 1207440c-b7fdf6d000001b94-be-5232a8f31d45 Authentication-Results: symauth.service.identifier Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 54.1D.07060.3F8A2325; Fri, 13 Sep 2013 01:56:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED8911E8164; Thu, 12 Sep 2013 22:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5VEr6BMNNaJ; Thu, 12 Sep 2013 22:56:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6893A11E80FB; Thu, 12 Sep 2013 22:56:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: "Paul H. Kyzivat" , Simon Pietro Romano , Michael Yan , Paul Kyzivat , Simon Romano Subject: New Version Notification for draft-kyzivat-siprec-conference-use-cases-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913055602.10539.20347.idtracker@ietfa.amsl.com> Date: Thu, 12 Sep 2013 22:56:02 -0700 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRWlGSWpSXmKPExsXCI2Ylp/t5hVGQwe1fihYrNhxgdWD0+Pv+ A1MAYxSXTUpqTmZZapG+XQJXxv+m++wFT7kr9t5/xdLA2MjZxcjJISFgItG/+jo7iM0oYCSx +9wrVoi4mMSFe+vZuhi5OIQEjjBK3NrynwXCmcQoMXHvF2aIKg2JGSsvMEIktjFKdO29zArh TGOUuPvuNgtIFa+AoMTJmU+AbA4OZgFNifW79EHCzALaEssWvgYbxCYgJ7H61TSwQSICJxgl Di/8xAiSEBaIkPh+9AcbxDYRiXdXH0JtlpRYMeMFK8TdchI/jj1mArEFBAQk/k26ALXXUeLF nBVgcRYBVYnp886xTGAUmYXkpFkIJ81CctICRuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbqG ermZJXqpKaWbGIGBL8TuwrOD8ds6mUOMAhyMSjy8HTFGQUKsiWXFlbmHGCU5mJREeVMWAoX4 kvJTKjMSizPii0pzUosPMUpwMCuJ8AotAsrxpiRWVqUW5cOkpDlYlMR5VZeo+wkJpCeWpGan phakFsFkmTjYDzHKcHAoSfD+Xg7ULViUmp5akZaZU4KshhNEcIGs4QFa0w5SyFtckJhbnJkO UXSKUVFKnFcdmG6EBEASGaV5cANgyeoSo6yUMC8jAwODEA/QBUCPo8o/YhTkeMkuxMbFlJon oCvFkpefl/qKURwYEMK8oiCTeTLzSuA2vgI6hgnomO+++iDHlCQipKQaGPNmTZ7qxP0n17xe jKMvabbiS0Otw/Z3Ow15j15+/fr7qx2rFxisLvfr9mr45+4RYNcTohLP82B9/p3uq0WPC2J6 ln8u82rZwRJa93eHorCP5LWpjbxGyTpnpbvcHPz+8N7KVco35qhssp37q9VTaVf0b6nPphXN 363n3LSpuSnmez46oOCWEktxRqKhFnNRcSIAkjU/wmUDAAA= A new version of I-D, draft-kyzivat-siprec-conference-use-cases-00.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-siprec-conference-use-cases Revision: 00 Title: Multimedia Conference Recording Use Cases and Requirements Creation date: 2013-09-13 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-c= onference-use-cases-00.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-siprec-confe= rence-use-cases Htmlized: http://tools.ietf.org/html/draft-kyzivat-siprec-conference= -use-cases-00 Abstract: The current work of SIPREC will soon finish. As conferences are the key requirement for some environments, it is worth to explore several extensions and additional functionalities to support multimedia conference recording. SIPREC is not sufficient to record all the conference sessions via certain interactive media channels, like multi-user chat or screen sharing. This draft tries to show the use cases for multimedia conference recording and the requirements for how to work well under SIPREC mechanism. = = Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------050504060706070902000506-- From simon.farrow@stancilcorp.com Fri Sep 13 12:00:36 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3639F11E81B6 for ; Fri, 13 Sep 2013 12:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xojEhDQxUG27 for ; Fri, 13 Sep 2013 12:00:28 -0700 (PDT) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7A211E81B3 for ; Fri, 13 Sep 2013 11:59:57 -0700 (PDT) Received: from mymail.myregisteredsite.com (wmailnode1f.webmail.web.com [209.237.134.171]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with SMTP id r8DIxujR012236 for ; Fri, 13 Sep 2013 14:59:56 -0400 Received: (qmail 13126 invoked by uid 80); 13 Sep 2013 18:59:55 -0000 Received: from unknown (HELO simonlaptop) (simon.farrow@stancilcorp.com@12.52.78.250) by wmailnode1f.mymail.myregisteredsite.com with ESMTPA; 13 Sep 2013 18:59:55 -0000 From: "Simon Farrow" To: "'Paul Kyzivat'" , References: <52332023.5070006@alum.mit.edu> In-Reply-To: <52332023.5070006@alum.mit.edu> Date: Fri, 13 Sep 2013 11:59:53 -0700 Message-ID: <008301ceb0b3$7085e220$5191a660$@stancilcorp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01CEB078.C42BC510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF+0Q5BL6W4OR7lH/I/5y5/5E8KsJpjwpSQ Content-Language: en-us Subject: Re: [siprec] Proposal: new SIPREC work on conference recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 19:00:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0084_01CEB078.C42BC510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul I suggest adding the Public Safety (as shown below) to the text. SIPREC has been adopted by the NG-911 as the way to record public safety media. In early November some of the leading vendors in this industry are getting together for inter-operability testing. One of the key topics is SIPREC recording between many SRCs and SRSs. > The Session Recording Protocol (SIPREC) working group is chartered to > define a SIP-based protocol for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such as call centers and financial trading > floors. [Replace above sentence with:] Session recording is a critical requirement in many business communications environments such as call centers, Public Safety ,financial trading floors, and multimedia conferences. Simon Farrow Director of Engineering Stancil Corporation 2644 South Croddy Way Santa Ana CA 92704 Tel: 1-714-546-2002 ext 4311 http://www.stancilcorp.com simon.farrow@stancilcorp.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, September 13, 2013 7:25 AM To: siprec@ietf.org Subject: [siprec] Proposal: new SIPREC work on conference recording In Berlin I spoke about a proposal to extend the siprec charter to more fully address conference recording. There was good feedback during that meeting about where to focus, and significant interest in going forward with this. Since then Simon Romano, my associate Michael Yan, and I have refined a use case and requirements draft about that, which was just posted. The announcement of that draft is attached. I request that all you SIPRECers please review and comment on this draft. I'd appreciate feedback to make it better. In conjunction with that, below are are specific siprec charter change proposals, to extend our scope to cover this work. I'm also soliciting comments on these. After some list discussion on the draft and the charter changes, I hope we can have a session at ietf88 to progress this. Thanks, Paul --------------------------------------------------------------------- PROPOSED SIPREC CHARTER REVISION (as deltas to current charter): --------------------------------------------------------------------- > The Session Recording Protocol (SIPREC) working group is chartered to > define a SIP-based protocol for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such as call centers and financial trading > floors. [Replace above sentence with:] Session recording is a critical requirement in many business communications environments such as call centers, financial trading floors, and multimedia conferences. > In some of these environments, all calls must be recorded for > regulatory and compliance reasons. In others, calls may be recorded > for quality control, business analytics, or consumer protection. > Recording is typically done by sending a copy of the media to the > recording devices. The working group will determine requirements and > produce a specification for a protocol that will manage delivery of > media [Insert:] (including audio, video, MSRP instant message sessions, and real-time sharing of documents, applications, and computer screens) > from an > end-point that originates media, or that has access to it, to a > recording device. PBX and recording vendors today implement > proprietary, incompatible mechanisms to facilitate recording. A > standard protocol will reduce the complexity and cost of providing > such recording services. > > The Session Recording problem presents certain unique requirements > that are not addressed in the current SIP protocol specification. > These include requirements such as the need for a distinction between > the session that is being recorded versus the session that has been > established for recording. > > Privacy and security of conversations are significant concerns. The > working group will make sure that any protocol specified addresses > these concerns and includes mechanisms to alert users to the fact that > a session they are participating in is being recorded. > > The working group must take care that the session recording > requirements and protocol does not conflict with the IETF statement on > wiretapping contained in RFC 2804. > > The SIPREC Working Group will thoroughly identify use cases, provide > example system architectures and deployment scenarios, and define > requirements. > > The scope of the activity includes: > > * Recorder Control > > * Session metadata content and format > > * Security mechanisms, including transport and media encryption > > * Privacy concerns, including end-user notification > > * Negotiation of recording media streams > > The group will define these issues and rationalize with IETF standards > and practices. This includes encryption, NAT traversal, operations and > manageability, SIP-enabled firewalls, authorization, and security. > > The group will produce: > > * Updated Requirements, Use Cases, Architecture draft > > * Specification for Session Recording Protocol [Insert:] and Metadata > > Milestones > Done Use Cases and Requirements to IESG as Informational RFC > Jan 2013 Submit Architecture to IESG as Informational RFC Apr 2013 > Submit protocol draft to IESG as Proposed Standard RFC Aug 2013 > Submit Metadata model and format to IESG as Proposed > Standard RFC > Aug 2013 Submit SIPREC Call Flows draft to IESG as an > informational RFC. [additional milestones - optimistic dates:] Apr 2014 Conference Recording Use Cases and Requirements to IESG as Informational RFC Aug 2014 Conference Recording Architecture to IESG as Informational RFC Aug 2014 Protocol and metadata for MSRP recording to IESG as Proposed Standard RFC Dec 2014 Protocol and metadata for recording of document & application sharing to IESG as Proposed Standard RFC ------=_NextPart_000_0084_01CEB078.C42BC510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul

I = suggest adding the Public Safety (as shown below) to the text. SIPREC = has been adopted by the NG-911 as the way to record public safety media. = In early November some of the leading vendors in this industry are = getting together for inter-operability testing. One of the key topics is = SIPREC recording between many SRCs and SRSs.

> = The Session Recording Protocol (SIPREC) working group is chartered to =

> define a SIP-based protocol = for controlling a session (media) recorder.

> Session recording is a critical requirement in = many business

> communications = environments such as call centers and financial trading =

> floors.

[Replace above sentence with:]

Session recording is a critical requirement in many = business communications environments such as call centers, Public Safety ,financial trading floors, and = multimedia conferences.

Simon = Farrow

Director of = Engineering

Stancil = Corporation

2644 South Croddy = Way

Santa Ana

CA 92704

Tel: = 1-714-546-2002 ext 4311

http://www.stancilcorp.com<= /o:p>

simon.farrow@stancilcorp.com=

-----Original Message-----
From: = siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Paul Kyzivat
Sent: Friday, September 13, 2013 7:25 AM
To: = siprec@ietf.org
Subject: [siprec] Proposal: new SIPREC work on = conference recording

In Berlin I spoke about a proposal to extend the = siprec charter to more fully address conference recording. There was = good feedback during that meeting about where to focus, and significant = interest in going forward with this.

Since = then Simon Romano, my associate Michael Yan, and I have refined a use = case and requirements draft about that, which was just posted. The = announcement of that draft is attached.

I = request that all you SIPRECers please review and comment on this draft. = I'd appreciate feedback to make it better.

In = conjunction with that, below are are specific siprec charter change = proposals, to extend our scope to cover this work. I'm also soliciting = comments on these.

After = some list discussion on the draft and the charter changes, I hope we can = have a session at ietf88 to progress this.

&nbs= p; Thanks,

&nbs= p; Paul

----------------------------------------------------= -----------------

PROPOSED SIPREC = CHARTER REVISION (as deltas to current charter):

----------------------------------------------------= -----------------

> = The Session Recording Protocol (SIPREC) working group is chartered to =

> define a SIP-based protocol = for controlling a session (media) recorder.

> Session recording is a critical requirement in = many business

> communications = environments such as call centers and financial trading =

> floors.

[Replace above sentence with:]

Session recording is a critical requirement in many = business communications environments such as call centers, financial = trading floors, and multimedia conferences.

> = In some of these environments, all calls must be recorded for =

> regulatory and compliance = reasons. In others, calls may be recorded

> for quality control, business analytics, or = consumer protection.

> = Recording is typically done by sending a copy of the media to the =

> recording devices. The = working group will determine requirements and

> produce a specification for a protocol that = will manage delivery of

> = media

[Insert:]

(including audio, video, MSRP instant message = sessions, and real-time sharing of documents, applications, and computer = screens)

> from an

> end-point that originates media, or that has = access to it, to a

> recording = device. PBX and recording vendors today implement

> proprietary, incompatible mechanisms to = facilitate recording. A

> = standard protocol will reduce the complexity and cost of providing =

> such recording = services.

> The Session Recording problem presents certain = unique requirements

> that are = not addressed in the current SIP protocol specification. =

> These include requirements = such as the need for a distinction between

> the session that is being recorded versus the = session that has been

> = established for recording.

> Privacy and security of conversations are = significant concerns. The

> = working group will make sure that any protocol specified addresses =

> these concerns and includes = mechanisms to alert users to the fact that

> a session they are participating in is being = recorded.

> The working group must take care that the = session recording

> = requirements and protocol does not conflict with the IETF statement on =

> wiretapping contained in RFC = 2804.

> The SIPREC Working Group will thoroughly = identify use cases, provide

> = example system architectures and deployment scenarios, and define =

> = requirements.

> The scope of the activity = includes:

> * Recorder Control

> * Session metadata content and = format

> * Security mechanisms, including transport and = media encryption

> * Privacy concerns, including end-user = notification

> * Negotiation of recording media = streams

> The group will define these issues and = rationalize with IETF standards

> and practices. This includes encryption, NAT = traversal, operations and

> = manageability, SIP-enabled firewalls, authorization, and = security.

> The group will produce:

> * Updated Requirements, Use Cases, = Architecture draft

> * Specification for Session Recording = Protocol

[Insert:]

and = Metadata

> Milestones

> Done Use Cases = and Requirements to IESG as Informational RFC

> Jan 2013 Submit Architecture to IESG as = Informational RFC Apr 2013

> Submit protocol draft to IESG as Proposed = Standard RFC Aug 2013

> = Submit Metadata model and format to IESG as Proposed

> = Standard RFC

> Aug = 2013 Submit SIPREC Call Flows draft to IESG as an

> = informational RFC.

[additional milestones - optimistic = dates:]

Apr 2014 Conference Recording Use Cases and = Requirements to IESG

&nbs= p; as Informational RFC

Aug = 2014 Conference Recording Architecture to IESG as

&nbs= p; Informational RFC

Aug = 2014 Protocol and metadata for MSRP recording to IESG = as

&nbs= p; Proposed Standard RFC

Dec = 2014 Protocol and metadata for recording of document = &

= application sharing to IESG as Proposed = Standard RFC

------=_NextPart_000_0084_01CEB078.C42BC510-- From michael.yan@huawei.com Fri Sep 13 18:31:10 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE311E8125 for ; Fri, 13 Sep 2013 18:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5pN91PbKGbg for ; Fri, 13 Sep 2013 18:31:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF37611E80E7 for ; Fri, 13 Sep 2013 18:31:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ73819; Sat, 14 Sep 2013 01:31:00 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 02:30:41 +0100 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 02:30:58 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.162]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.007; Sat, 14 Sep 2013 09:30:50 +0800 From: "Yanqiang (Michael)" To: Simon Farrow , "'Paul Kyzivat'" , "siprec@ietf.org" Thread-Topic: [siprec] Proposal: new SIPREC work on conference recording Thread-Index: AQHOsI0IDQsTAWihE0C71Atf00dg6JnDf6WAgADxrBA= Date: Sat, 14 Sep 2013 01:30:49 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B313B643E@szxeml561-mbx.china.huawei.com> References: <52332023.5070006@alum.mit.edu> <008301ceb0b3$7085e220$5191a660$@stancilcorp.com> In-Reply-To: <008301ceb0b3$7085e220$5191a660$@stancilcorp.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.146] Content-Type: multipart/alternative; boundary="_000_21794EB0EE82B0458A524942A141542B313B643Eszxeml561mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [siprec] Proposal: new SIPREC work on conference recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 01:31:10 -0000 --_000_21794EB0EE82B0458A524942A141542B313B643Eszxeml561mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUuIE1heWJlIHdlIGNvdWxkIGFsc28gdXNlIOKAmGVtZXJnZW5jeSAoZmlyc3QtcmVzcG9u ZGVyKSBzZXJ2aWNlIGJ1cmVhdXPigJkgdGhhdCB1c2VkIGluIFJGQzYzNDEuDQoNClRoYW5rcywN Ck1pY2hhZWwNCg0KRnJvbTogc2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXByZWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNpbW9uIEZhcnJvdw0KU2VudDogU2F0dXJk YXksIFNlcHRlbWJlciAxNCwgMjAxMyAzOjAwIEFNDQpUbzogJ1BhdWwgS3l6aXZhdCc7IHNpcHJl Y0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXByZWNdIFByb3Bvc2FsOiBuZXcgU0lQUkVDIHdv cmsgb24gY29uZmVyZW5jZSByZWNvcmRpbmcNCg0KDQpQYXVsDQoNCg0KDQpJIHN1Z2dlc3QgYWRk aW5nIHRoZSBQdWJsaWMgU2FmZXR5IChhcyBzaG93biBiZWxvdykgdG8gdGhlIHRleHQuIFNJUFJF QyBoYXMgYmVlbiBhZG9wdGVkIGJ5IHRoZSBORy05MTEgYXMgdGhlIHdheSB0byByZWNvcmQgcHVi bGljIHNhZmV0eSBtZWRpYS4gSW4gZWFybHkgTm92ZW1iZXIgc29tZSBvZiB0aGUgbGVhZGluZyB2 ZW5kb3JzIGluIHRoaXMgaW5kdXN0cnkgYXJlIGdldHRpbmcgdG9nZXRoZXIgZm9yIGludGVyLW9w ZXJhYmlsaXR5IHRlc3RpbmcuIE9uZSBvZiB0aGUga2V5IHRvcGljcyBpcyBTSVBSRUMgcmVjb3Jk aW5nIGJldHdlZW4gbWFueSBTUkNzIGFuZCBTUlNzLg0KDQoNCg0KPiBUaGUgU2Vzc2lvbiBSZWNv cmRpbmcgUHJvdG9jb2wgKFNJUFJFQykgd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8NCg0K PiBkZWZpbmUgYSBTSVAtYmFzZWQgcHJvdG9jb2wgZm9yIGNvbnRyb2xsaW5nIGEgc2Vzc2lvbiAo bWVkaWEpIHJlY29yZGVyLg0KDQo+DQoNCj4gU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNh bCByZXF1aXJlbWVudCBpbiBtYW55IGJ1c2luZXNzDQoNCj4gY29tbXVuaWNhdGlvbnMgZW52aXJv bm1lbnRzIHN1Y2ggYXMgY2FsbCBjZW50ZXJzIGFuZCBmaW5hbmNpYWwgdHJhZGluZw0KDQo+IGZs b29ycy4NCg0KDQoNCltSZXBsYWNlIGFib3ZlIHNlbnRlbmNlIHdpdGg6XQ0KDQoNCg0KU2Vzc2lv biByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBpbiBtYW55IGJ1c2luZXNzIGNv bW11bmljYXRpb25zIGVudmlyb25tZW50cyBzdWNoIGFzIGNhbGwgY2VudGVycywgUHVibGljIFNh ZmV0eSAsZmluYW5jaWFsIHRyYWRpbmcgZmxvb3JzLCBhbmQgbXVsdGltZWRpYSBjb25mZXJlbmNl cy4NCg0KDQoNClNpbW9uIEZhcnJvdw0KRGlyZWN0b3Igb2YgRW5naW5lZXJpbmcNClN0YW5jaWwg Q29ycG9yYXRpb24NCjI2NDQgU291dGggQ3JvZGR5IFdheQ0KU2FudGEgQW5hDQpDQSA5MjcwNA0K VGVsOiAxLTcxNC01NDYtMjAwMiBleHQgNDMxMQ0KaHR0cDovL3d3dy5zdGFuY2lsY29ycC5jb208 aHR0cDovL3d3dy5zdGFuY2lsY29ycC5jb20vPg0KDQpzaW1vbi5mYXJyb3dAc3RhbmNpbGNvcnAu Y29tPG1haWx0bzpzaW1vbi5mYXJyb3dAc3RhbmNpbGNvcnAuY29tPg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNClNlbnQ6 IEZyaWRheSwgU2VwdGVtYmVyIDEzLCAyMDEzIDc6MjUgQU0NClRvOiBzaXByZWNAaWV0Zi5vcmcN ClN1YmplY3Q6IFtzaXByZWNdIFByb3Bvc2FsOiBuZXcgU0lQUkVDIHdvcmsgb24gY29uZmVyZW5j ZSByZWNvcmRpbmcNCg0KDQoNCkluIEJlcmxpbiBJIHNwb2tlIGFib3V0IGEgcHJvcG9zYWwgdG8g ZXh0ZW5kIHRoZSBzaXByZWMgY2hhcnRlciB0byBtb3JlIGZ1bGx5IGFkZHJlc3MgY29uZmVyZW5j ZSByZWNvcmRpbmcuIFRoZXJlIHdhcyBnb29kIGZlZWRiYWNrIGR1cmluZyB0aGF0IG1lZXRpbmcg YWJvdXQgd2hlcmUgdG8gZm9jdXMsIGFuZCBzaWduaWZpY2FudCBpbnRlcmVzdCBpbiBnb2luZyBm b3J3YXJkIHdpdGggdGhpcy4NCg0KDQoNClNpbmNlIHRoZW4gU2ltb24gUm9tYW5vLCBteSBhc3Nv Y2lhdGUgTWljaGFlbCBZYW4sIGFuZCBJIGhhdmUgcmVmaW5lZCBhIHVzZSBjYXNlIGFuZCByZXF1 aXJlbWVudHMgZHJhZnQgYWJvdXQgdGhhdCwgd2hpY2ggd2FzIGp1c3QgcG9zdGVkLiBUaGUgYW5u b3VuY2VtZW50IG9mIHRoYXQgZHJhZnQgaXMgYXR0YWNoZWQuDQoNCg0KDQpJIHJlcXVlc3QgdGhh dCBhbGwgeW91IFNJUFJFQ2VycyBwbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50IG9uIHRoaXMgZHJh ZnQuIEknZCBhcHByZWNpYXRlIGZlZWRiYWNrIHRvIG1ha2UgaXQgYmV0dGVyLg0KDQoNCg0KSW4g Y29uanVuY3Rpb24gd2l0aCB0aGF0LCBiZWxvdyBhcmUgYXJlIHNwZWNpZmljIHNpcHJlYyBjaGFy dGVyIGNoYW5nZSBwcm9wb3NhbHMsIHRvIGV4dGVuZCBvdXIgc2NvcGUgdG8gY292ZXIgdGhpcyB3 b3JrLiBJJ20gYWxzbyBzb2xpY2l0aW5nIGNvbW1lbnRzIG9uIHRoZXNlLg0KDQoNCg0KQWZ0ZXIg c29tZSBsaXN0IGRpc2N1c3Npb24gb24gdGhlIGRyYWZ0IGFuZCB0aGUgY2hhcnRlciBjaGFuZ2Vz LCBJIGhvcGUgd2UgY2FuIGhhdmUgYSBzZXNzaW9uIGF0IGlldGY4OCB0byBwcm9ncmVzcyB0aGlz Lg0KDQoNCg0KICAgICAgICAgICAgICAgIFRoYW5rcywNCg0KICAgICAgICAgICAgICAgIFBhdWwN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpQUk9QT1NFRCBTSVBSRUMgQ0hBUlRFUiBSRVZJU0lPTiAo YXMgZGVsdGFzIHRvIGN1cnJlbnQgY2hhcnRlcik6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KPiBU aGUgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2wgKFNJUFJFQykgd29ya2luZyBncm91cCBpcyBj aGFydGVyZWQgdG8NCg0KPiBkZWZpbmUgYSBTSVAtYmFzZWQgcHJvdG9jb2wgZm9yIGNvbnRyb2xs aW5nIGEgc2Vzc2lvbiAobWVkaWEpIHJlY29yZGVyLg0KDQo+DQoNCj4gU2Vzc2lvbiByZWNvcmRp bmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBpbiBtYW55IGJ1c2luZXNzDQoNCj4gY29tbXVu aWNhdGlvbnMgZW52aXJvbm1lbnRzIHN1Y2ggYXMgY2FsbCBjZW50ZXJzIGFuZCBmaW5hbmNpYWwg dHJhZGluZw0KDQo+IGZsb29ycy4NCg0KDQoNCltSZXBsYWNlIGFib3ZlIHNlbnRlbmNlIHdpdGg6 XQ0KDQoNCg0KU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBpbiBt YW55IGJ1c2luZXNzIGNvbW11bmljYXRpb25zIGVudmlyb25tZW50cyBzdWNoIGFzIGNhbGwgY2Vu dGVycywgZmluYW5jaWFsIHRyYWRpbmcgZmxvb3JzLCBhbmQgbXVsdGltZWRpYSBjb25mZXJlbmNl cy4NCg0KDQoNCj4gSW4gc29tZSBvZiB0aGVzZSBlbnZpcm9ubWVudHMsIGFsbCBjYWxscyBtdXN0 IGJlIHJlY29yZGVkIGZvcg0KDQo+IHJlZ3VsYXRvcnkgYW5kIGNvbXBsaWFuY2UgcmVhc29ucy4g SW4gb3RoZXJzLCBjYWxscyBtYXkgYmUgcmVjb3JkZWQNCg0KPiBmb3IgcXVhbGl0eSBjb250cm9s LCBidXNpbmVzcyBhbmFseXRpY3MsIG9yIGNvbnN1bWVyIHByb3RlY3Rpb24uDQoNCj4gUmVjb3Jk aW5nIGlzIHR5cGljYWxseSBkb25lIGJ5IHNlbmRpbmcgYSBjb3B5IG9mIHRoZSBtZWRpYSB0byB0 aGUNCg0KPiByZWNvcmRpbmcgZGV2aWNlcy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXRlcm1p bmUgcmVxdWlyZW1lbnRzIGFuZA0KDQo+IHByb2R1Y2UgYSBzcGVjaWZpY2F0aW9uIGZvciBhIHBy b3RvY29sIHRoYXQgd2lsbCBtYW5hZ2UgZGVsaXZlcnkgb2YNCg0KPiBtZWRpYQ0KDQoNCg0KW0lu c2VydDpdDQoNCg0KDQooaW5jbHVkaW5nIGF1ZGlvLCB2aWRlbywgTVNSUCBpbnN0YW50IG1lc3Nh Z2Ugc2Vzc2lvbnMsIGFuZCByZWFsLXRpbWUgc2hhcmluZyBvZiBkb2N1bWVudHMsIGFwcGxpY2F0 aW9ucywgYW5kIGNvbXB1dGVyIHNjcmVlbnMpDQoNCg0KDQo+IGZyb20gYW4NCg0KPiBlbmQtcG9p bnQgdGhhdCBvcmlnaW5hdGVzIG1lZGlhLCBvciB0aGF0IGhhcyBhY2Nlc3MgdG8gaXQsIHRvIGEN Cg0KPiByZWNvcmRpbmcgZGV2aWNlLiBQQlggYW5kIHJlY29yZGluZyB2ZW5kb3JzIHRvZGF5IGlt cGxlbWVudA0KDQo+IHByb3ByaWV0YXJ5LCBpbmNvbXBhdGlibGUgbWVjaGFuaXNtcyB0byBmYWNp bGl0YXRlIHJlY29yZGluZy4gQQ0KDQo+IHN0YW5kYXJkIHByb3RvY29sIHdpbGwgcmVkdWNlIHRo ZSBjb21wbGV4aXR5IGFuZCBjb3N0IG9mIHByb3ZpZGluZw0KDQo+IHN1Y2ggcmVjb3JkaW5nIHNl cnZpY2VzLg0KDQo+DQoNCj4gVGhlIFNlc3Npb24gUmVjb3JkaW5nIHByb2JsZW0gcHJlc2VudHMg Y2VydGFpbiB1bmlxdWUgcmVxdWlyZW1lbnRzDQoNCj4gdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBp biB0aGUgY3VycmVudCBTSVAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4NCg0KPiBUaGVzZSBpbmNs dWRlIHJlcXVpcmVtZW50cyBzdWNoIGFzIHRoZSBuZWVkIGZvciBhIGRpc3RpbmN0aW9uIGJldHdl ZW4NCg0KPiB0aGUgc2Vzc2lvbiB0aGF0IGlzIGJlaW5nIHJlY29yZGVkIHZlcnN1cyB0aGUgc2Vz c2lvbiB0aGF0IGhhcyBiZWVuDQoNCj4gZXN0YWJsaXNoZWQgZm9yIHJlY29yZGluZy4NCg0KPg0K DQo+IFByaXZhY3kgYW5kIHNlY3VyaXR5IG9mIGNvbnZlcnNhdGlvbnMgYXJlIHNpZ25pZmljYW50 IGNvbmNlcm5zLiBUaGUNCg0KPiB3b3JraW5nIGdyb3VwIHdpbGwgbWFrZSBzdXJlIHRoYXQgYW55 IHByb3RvY29sIHNwZWNpZmllZCBhZGRyZXNzZXMNCg0KPiB0aGVzZSBjb25jZXJucyBhbmQgaW5j bHVkZXMgbWVjaGFuaXNtcyB0byBhbGVydCB1c2VycyB0byB0aGUgZmFjdCB0aGF0DQoNCj4gYSBz ZXNzaW9uIHRoZXkgYXJlIHBhcnRpY2lwYXRpbmcgaW4gaXMgYmVpbmcgcmVjb3JkZWQuDQoNCj4N Cg0KPiBUaGUgd29ya2luZyBncm91cCBtdXN0IHRha2UgY2FyZSB0aGF0IHRoZSBzZXNzaW9uIHJl Y29yZGluZw0KDQo+IHJlcXVpcmVtZW50cyBhbmQgcHJvdG9jb2wgZG9lcyBub3QgY29uZmxpY3Qg d2l0aCB0aGUgSUVURiBzdGF0ZW1lbnQgb24NCg0KPiB3aXJldGFwcGluZyBjb250YWluZWQgaW4g UkZDIDI4MDQuDQoNCj4NCg0KPiBUaGUgU0lQUkVDIFdvcmtpbmcgR3JvdXAgd2lsbCB0aG9yb3Vn aGx5IGlkZW50aWZ5IHVzZSBjYXNlcywgcHJvdmlkZQ0KDQo+IGV4YW1wbGUgc3lzdGVtIGFyY2hp dGVjdHVyZXMgYW5kIGRlcGxveW1lbnQgc2NlbmFyaW9zLCBhbmQgZGVmaW5lDQoNCj4gcmVxdWly ZW1lbnRzLg0KDQo+DQoNCj4gVGhlIHNjb3BlIG9mIHRoZSBhY3Rpdml0eSBpbmNsdWRlczoNCg0K Pg0KDQo+ICogUmVjb3JkZXIgQ29udHJvbA0KDQo+DQoNCj4gKiBTZXNzaW9uIG1ldGFkYXRhIGNv bnRlbnQgYW5kIGZvcm1hdA0KDQo+DQoNCj4gKiBTZWN1cml0eSBtZWNoYW5pc21zLCBpbmNsdWRp bmcgdHJhbnNwb3J0IGFuZCBtZWRpYSBlbmNyeXB0aW9uDQoNCj4NCg0KPiAqIFByaXZhY3kgY29u Y2VybnMsIGluY2x1ZGluZyBlbmQtdXNlciBub3RpZmljYXRpb24NCg0KPg0KDQo+ICogTmVnb3Rp YXRpb24gb2YgcmVjb3JkaW5nIG1lZGlhIHN0cmVhbXMNCg0KPg0KDQo+IFRoZSBncm91cCB3aWxs IGRlZmluZSB0aGVzZSBpc3N1ZXMgYW5kIHJhdGlvbmFsaXplIHdpdGggSUVURiBzdGFuZGFyZHMN Cg0KPiBhbmQgcHJhY3RpY2VzLiBUaGlzIGluY2x1ZGVzIGVuY3J5cHRpb24sIE5BVCB0cmF2ZXJz YWwsIG9wZXJhdGlvbnMgYW5kDQoNCj4gbWFuYWdlYWJpbGl0eSwgU0lQLWVuYWJsZWQgZmlyZXdh bGxzLCBhdXRob3JpemF0aW9uLCBhbmQgc2VjdXJpdHkuDQoNCj4NCg0KPiBUaGUgZ3JvdXAgd2ls bCBwcm9kdWNlOg0KDQo+DQoNCj4gKiBVcGRhdGVkIFJlcXVpcmVtZW50cywgVXNlIENhc2VzLCBB cmNoaXRlY3R1cmUgZHJhZnQNCg0KPg0KDQo+ICogU3BlY2lmaWNhdGlvbiBmb3IgU2Vzc2lvbiBS ZWNvcmRpbmcgUHJvdG9jb2wNCg0KDQoNCltJbnNlcnQ6XQ0KDQoNCg0KYW5kIE1ldGFkYXRhDQoN Cg0KDQo+DQoNCj4gTWlsZXN0b25lcw0KDQo+IERvbmUgICAgICBVc2UgQ2FzZXMgYW5kIFJlcXVp cmVtZW50cyB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwgUkZDDQoNCj4gSmFuIDIwMTMgIFN1Ym1p dCBBcmNoaXRlY3R1cmUgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQyBBcHIgMjAxMw0KDQo+ IFN1Ym1pdCBwcm90b2NvbCBkcmFmdCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIFJGQyBB dWcgMjAxMw0KDQo+IFN1Ym1pdCBNZXRhZGF0YSBtb2RlbCBhbmQgZm9ybWF0IHRvIElFU0cgYXMg UHJvcG9zZWQNCg0KPiAgICAgICAgICAgU3RhbmRhcmQgUkZDDQoNCj4gQXVnIDIwMTMgIFN1Ym1p dCBTSVBSRUMgQ2FsbCBGbG93cyBkcmFmdCB0byBJRVNHIGFzIGFuDQoNCj4gICAgICAgICAgIGlu Zm9ybWF0aW9uYWwgUkZDLg0KDQoNCg0KW2FkZGl0aW9uYWwgbWlsZXN0b25lcyAtIG9wdGltaXN0 aWMgZGF0ZXM6XQ0KDQoNCg0KQXByIDIwMTQgIENvbmZlcmVuY2UgUmVjb3JkaW5nIFVzZSBDYXNl cyBhbmQgUmVxdWlyZW1lbnRzIHRvIElFU0cNCg0KICAgICAgICAgICBhcyBJbmZvcm1hdGlvbmFs IFJGQw0KDQoNCg0KQXVnIDIwMTQgIENvbmZlcmVuY2UgUmVjb3JkaW5nIEFyY2hpdGVjdHVyZSB0 byBJRVNHIGFzDQoNCiAgICAgICAgICAgSW5mb3JtYXRpb25hbCBSRkMNCg0KDQoNCkF1ZyAyMDE0 ICBQcm90b2NvbCBhbmQgbWV0YWRhdGEgZm9yIE1TUlAgcmVjb3JkaW5nIHRvIElFU0cgYXMNCg0K ICAgICAgICAgICBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCg0KDQoNCkRlYyAyMDE0ICBQcm90b2Nv bCBhbmQgbWV0YWRhdGEgZm9yIHJlY29yZGluZyBvZiBkb2N1bWVudCAmDQoNCiAgICAgICAgICAg YXBwbGljYXRpb24gc2hhcmluZyB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KDQoN Cg== --_000_21794EB0EE82B0458A524942A141542B313B643Eszxeml561mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1z b1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6 r+aWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0KcC5QbGFpblRleHQsIGxpLlBsYWluVGV4dCwgZGl2LlBsYWluVGV4dA0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+ QWdyZWUuIE1heWJlIHdlIGNvdWxkIGFsc28gdXNlIOKAmGVtZXJnZW5jeSAoZmlyc3QtcmVzcG9u ZGVyKSBzZXJ2aWNlIGJ1cmVhdXPigJkgdGhhdCB1c2VkIGluIFJGQzYzNDEuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpzaXByZWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2lt b24gRmFycm93PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTQsIDIwMTMg MzowMCBBTTxicj4NCjxiPlRvOjwvYj4gJ1BhdWwgS3l6aXZhdCc7IHNpcHJlY0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcHJlY10gUHJvcG9zYWw6IG5ldyBTSVBSRUMgd29y ayBvbiBjb25mZXJlbmNlIHJlY29yZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgc3VnZ2VzdCBhZGRpbmcgdGhl IFB1YmxpYyBTYWZldHkgKGFzIHNob3duIGJlbG93KSB0byB0aGUgdGV4dC4gU0lQUkVDIGhhcyBi ZWVuIGFkb3B0ZWQgYnkgdGhlIE5HLTkxMSBhcyB0aGUgd2F5IHRvIHJlY29yZCBwdWJsaWMgc2Fm ZXR5IG1lZGlhLiBJbiBlYXJseSBOb3ZlbWJlciBzb21lIG9mIHRoZSBsZWFkaW5nIHZlbmRvcnMg aW4gdGhpcyBpbmR1c3RyeSBhcmUgZ2V0dGluZw0KIHRvZ2V0aGVyIGZvciBpbnRlci1vcGVyYWJp bGl0eSB0ZXN0aW5nLiBPbmUgb2YgdGhlIGtleSB0b3BpY3MgaXMgU0lQUkVDIHJlY29yZGluZyBi ZXR3ZWVuIG1hbnkgU1JDcyBhbmQgU1JTcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg VGhlIFNlc3Npb24gUmVjb3JkaW5nIFByb3RvY29sIChTSVBSRUMpIHdvcmtpbmcgZ3JvdXAgaXMg Y2hhcnRlcmVkIHRvDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBkZWZpbmUgYSBTSVAtYmFzZWQgcHJvdG9jb2wg Zm9yIGNvbnRyb2xsaW5nIGEgc2Vzc2lvbiAobWVkaWEpIHJlY29yZGVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsgU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1 aXJlbWVudCBpbiBtYW55IGJ1c2luZXNzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBjb21tdW5pY2F0aW9ucyBl bnZpcm9ubWVudHMgc3VjaCBhcyBjYWxsIGNlbnRlcnMgYW5kIGZpbmFuY2lhbCB0cmFkaW5nDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0OyBmbG9vcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5bUmVwbGFjZSBh Ym92ZSBzZW50ZW5jZSB3aXRoOl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlc3Npb24gcmVj b3JkaW5nIGlzIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQgaW4gbWFueSBidXNpbmVzcyBjb21tdW5p Y2F0aW9ucyBlbnZpcm9ubWVudHMgc3VjaCBhcyBjYWxsIGNlbnRlcnMsDQo8c3BhbiBzdHlsZT0i Y29sb3I6cmVkIj5QdWJsaWMgU2FmZXR5IDwvc3Bhbj4sZmluYW5jaWFsIHRyYWRpbmcgZmxvb3Jz LCBhbmQgbXVsdGltZWRpYSBjb25mZXJlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5TaW1vbiBGYXJyb3c8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5EaXJlY3RvciBvZiBFbmdpbmVlcmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3RhbmNpbCBDb3Jwb3JhdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4yNjQ0IFNvdXRoIENyb2RkeSBXYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2FudGEgQW5hPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNBIDky NzA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRlbDogMS03MTQtNTQ2LTIwMDIgZXh0IDQzMTE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cDovL3d3dy5zdGFuY2lsY29ycC5jb20vIj5odHRwOi8vd3d3LnN0YW5jaWxjb3JwLmNvbTwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOnNpbW9uLmZhcnJvd0BzdGFuY2lsY29ycC5jb20iPnNp bW9uLmZhcnJvd0BzdGFuY2lsY29ycC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5 eml2YXQ8YnI+DQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxMywgMjAxMyA3OjI1IEFNPGJyPg0K VG86IHNpcHJlY0BpZXRmLm9yZzxicj4NClN1YmplY3Q6IFtzaXByZWNdIFByb3Bvc2FsOiBuZXcg U0lQUkVDIHdvcmsgb24gY29uZmVyZW5jZSByZWNvcmRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPkluIEJlcmxpbiBJIHNwb2tlIGFib3V0IGEgcHJvcG9zYWwgdG8gZXh0ZW5kIHRoZSBzaXBy ZWMgY2hhcnRlciB0byBtb3JlIGZ1bGx5IGFkZHJlc3MgY29uZmVyZW5jZSByZWNvcmRpbmcuIFRo ZXJlIHdhcyBnb29kIGZlZWRiYWNrIGR1cmluZyB0aGF0IG1lZXRpbmcgYWJvdXQgd2hlcmUgdG8g Zm9jdXMsIGFuZCBzaWduaWZpY2FudCBpbnRlcmVzdCBpbiBnb2luZyBmb3J3YXJkDQogd2l0aCB0 aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U2luY2UgdGhlbiBTaW1vbiBSb21hbm8sIG15 IGFzc29jaWF0ZSBNaWNoYWVsIFlhbiwgYW5kIEkgaGF2ZSByZWZpbmVkIGEgdXNlIGNhc2UgYW5k IHJlcXVpcmVtZW50cyBkcmFmdCBhYm91dCB0aGF0LCB3aGljaCB3YXMganVzdCBwb3N0ZWQuIFRo ZSBhbm5vdW5jZW1lbnQgb2YgdGhhdCBkcmFmdCBpcyBhdHRhY2hlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgcmVxdWVzdCB0aGF0IGFsbCB5b3UgU0lQUkVDZXJzIHBsZWFzZSByZXZpZXcg YW5kIGNvbW1lbnQgb24gdGhpcyBkcmFmdC4gSSdkIGFwcHJlY2lhdGUgZmVlZGJhY2sgdG8gbWFr ZSBpdCBiZXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBjb25qdW5jdGlvbiB3aXRo IHRoYXQsIGJlbG93IGFyZSBhcmUgc3BlY2lmaWMgc2lwcmVjIGNoYXJ0ZXIgY2hhbmdlIHByb3Bv c2FscywgdG8gZXh0ZW5kIG91ciBzY29wZSB0byBjb3ZlciB0aGlzIHdvcmsuIEknbSBhbHNvIHNv bGljaXRpbmcgY29tbWVudHMgb24gdGhlc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BZnRl ciBzb21lIGxpc3QgZGlzY3Vzc2lvbiBvbiB0aGUgZHJhZnQgYW5kIHRoZSBjaGFydGVyIGNoYW5n ZXMsIEkgaG9wZSB3ZSBjYW4gaGF2ZSBhIHNlc3Npb24gYXQgaWV0Zjg4IHRvIHByb2dyZXNzIHRo aXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBST1BP U0VEIFNJUFJFQyBDSEFSVEVSIFJFVklTSU9OIChhcyBkZWx0YXMgdG8gY3VycmVudCBjaGFydGVy KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRo ZSBTZXNzaW9uIFJlY29yZGluZyBQcm90b2NvbCAoU0lQUkVDKSB3b3JraW5nIGdyb3VwIGlzIGNo YXJ0ZXJlZCB0bw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZGVmaW5lIGEgU0lQLWJhc2VkIHByb3RvY29sIGZv ciBjb250cm9sbGluZyBhIHNlc3Npb24gKG1lZGlhKSByZWNvcmRlci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IFNlc3Npb24gcmVjb3JkaW5nIGlzIGEgY3JpdGljYWwgcmVxdWly ZW1lbnQgaW4gbWFueSBidXNpbmVzcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgY29tbXVuaWNhdGlvbnMgZW52 aXJvbm1lbnRzIHN1Y2ggYXMgY2FsbCBjZW50ZXJzIGFuZCBmaW5hbmNpYWwgdHJhZGluZw0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgZmxvb3JzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+W1JlcGxhY2UgYWJv dmUgc2VudGVuY2Ugd2l0aDpdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZXNzaW9uIHJlY29y ZGluZyBpcyBhIGNyaXRpY2FsIHJlcXVpcmVtZW50IGluIG1hbnkgYnVzaW5lc3MgY29tbXVuaWNh dGlvbnMgZW52aXJvbm1lbnRzIHN1Y2ggYXMgY2FsbCBjZW50ZXJzLCBmaW5hbmNpYWwgdHJhZGlu ZyBmbG9vcnMsIGFuZCBtdWx0aW1lZGlhIGNvbmZlcmVuY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OyBJbiBzb21lIG9mIHRoZXNlIGVudmlyb25tZW50cywgYWxsIGNhbGxzIG11c3Qg YmUgcmVjb3JkZWQgZm9yDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyByZWd1bGF0b3J5IGFuZCBjb21wbGlhbmNl IHJlYXNvbnMuIEluIG90aGVycywgY2FsbHMgbWF5IGJlIHJlY29yZGVkDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyBmb3IgcXVhbGl0eSBjb250cm9sLCBidXNpbmVzcyBhbmFseXRpY3MsIG9yIGNvbnN1bWVyIHBy b3RlY3Rpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBSZWNvcmRpbmcgaXMgdHlwaWNhbGx5IGRvbmUgYnkg c2VuZGluZyBhIGNvcHkgb2YgdGhlIG1lZGlhIHRvIHRoZQ0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVjb3Jk aW5nIGRldmljZXMuIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGV0ZXJtaW5lIHJlcXVpcmVtZW50 cyBhbmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHByb2R1Y2UgYSBzcGVjaWZpY2F0aW9uIGZvciBhIHByb3Rv Y29sIHRoYXQgd2lsbCBtYW5hZ2UgZGVsaXZlcnkgb2YNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IG1lZGlhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5bSW5zZXJ0Ol08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PihpbmNsdWRpbmcgYXVkaW8sIHZpZGVvLCBNU1JQIGluc3RhbnQgbWVzc2FnZSBzZXNzaW9ucywg YW5kIHJlYWwtdGltZSBzaGFyaW5nIG9mIGRvY3VtZW50cywgYXBwbGljYXRpb25zLCBhbmQgY29t cHV0ZXIgc2NyZWVucyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZnJvbSBhbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7IGVuZC1wb2ludCB0aGF0IG9yaWdpbmF0ZXMgbWVkaWEsIG9yIHRoYXQgaGFzIGFj Y2VzcyB0byBpdCwgdG8gYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVjb3JkaW5nIGRldmljZS4gUEJYIGFu ZCByZWNvcmRpbmcgdmVuZG9ycyB0b2RheSBpbXBsZW1lbnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHByb3By aWV0YXJ5LCBpbmNvbXBhdGlibGUgbWVjaGFuaXNtcyB0byBmYWNpbGl0YXRlIHJlY29yZGluZy4g QQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsgc3RhbmRhcmQgcHJvdG9jb2wgd2lsbCByZWR1Y2UgdGhlIGNvbXBs ZXhpdHkgYW5kIGNvc3Qgb2YgcHJvdmlkaW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBzdWNoIHJlY29yZGlu ZyBzZXJ2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRoZSBTZXNzaW9u IFJlY29yZGluZyBwcm9ibGVtIHByZXNlbnRzIGNlcnRhaW4gdW5pcXVlIHJlcXVpcmVtZW50cw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiB0aGUgY3VycmVudCBTSVAg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRoZXNlIGluY2x1ZGUgcmVx dWlyZW1lbnRzIHN1Y2ggYXMgdGhlIG5lZWQgZm9yIGEgZGlzdGluY3Rpb24gYmV0d2Vlbg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgdGhlIHNlc3Npb24gdGhhdCBpcyBiZWluZyByZWNvcmRlZCB2ZXJzdXMgdGhl IHNlc3Npb24gdGhhdCBoYXMgYmVlbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZXN0YWJsaXNoZWQgZm9yIHJl Y29yZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFByaXZhY3kgYW5kIHNl Y3VyaXR5IG9mIGNvbnZlcnNhdGlvbnMgYXJlIHNpZ25pZmljYW50IGNvbmNlcm5zLiBUaGUNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IHdvcmtpbmcgZ3JvdXAgd2lsbCBtYWtlIHN1cmUgdGhhdCBhbnkgcHJvdG9j b2wgc3BlY2lmaWVkIGFkZHJlc3Nlcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdGhlc2UgY29uY2VybnMgYW5k IGluY2x1ZGVzIG1lY2hhbmlzbXMgdG8gYWxlcnQgdXNlcnMgdG8gdGhlIGZhY3QgdGhhdA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDsgYSBzZXNzaW9uIHRoZXkgYXJlIHBhcnRpY2lwYXRpbmcgaW4gaXMgYmVpbmcg cmVjb3JkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUgd29ya2luZyBn cm91cCBtdXN0IHRha2UgY2FyZSB0aGF0IHRoZSBzZXNzaW9uIHJlY29yZGluZw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgcmVxdWlyZW1lbnRzIGFuZCBwcm90b2NvbCBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRo ZSBJRVRGIHN0YXRlbWVudCBvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgd2lyZXRhcHBpbmcgY29udGFpbmVk IGluIFJGQyAyODA0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVGhlIFNJUFJF QyBXb3JraW5nIEdyb3VwIHdpbGwgdGhvcm91Z2hseSBpZGVudGlmeSB1c2UgY2FzZXMsIHByb3Zp ZGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IGV4YW1wbGUgc3lzdGVtIGFyY2hpdGVjdHVyZXMgYW5kIGRlcGxv eW1lbnQgc2NlbmFyaW9zLCBhbmQgZGVmaW5lDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyByZXF1aXJlbWVudHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUgc2NvcGUgb2YgdGhlIGFjdGl2 aXR5IGluY2x1ZGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgKiBSZWNvcmRl ciBDb250cm9sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAqIFNlc3Npb24gbWV0 YWRhdGEgY29udGVudCBhbmQgZm9ybWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyAqIFNlY3VyaXR5IG1lY2hhbmlzbXMsIGluY2x1ZGluZyB0cmFuc3BvcnQgYW5kIG1lZGlhIGVu Y3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICogUHJpdmFjeSBjb25j ZXJucywgaW5jbHVkaW5nIGVuZC11c2VyIG5vdGlmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDsgKiBOZWdvdGlhdGlvbiBvZiByZWNvcmRpbmcgbWVkaWEgc3RyZWFtczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVGhlIGdyb3VwIHdpbGwgZGVmaW5lIHRo ZXNlIGlzc3VlcyBhbmQgcmF0aW9uYWxpemUgd2l0aCBJRVRGIHN0YW5kYXJkcw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgYW5kIHByYWN0aWNlcy4gVGhpcyBpbmNsdWRlcyBlbmNyeXB0aW9uLCBOQVQgdHJhdmVy c2FsLCBvcGVyYXRpb25zIGFuZA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbWFuYWdlYWJpbGl0eSwgU0lQLWVu YWJsZWQgZmlyZXdhbGxzLCBhdXRob3JpemF0aW9uLCBhbmQgc2VjdXJpdHkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgKiBVcGRhdGVkIFJlcXVpcmVtZW50cywgVXNlIENhc2Vz LCBBcmNoaXRlY3R1cmUgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7ICog U3BlY2lmaWNhdGlvbiBmb3IgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9jb2w8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPltJbnNlcnQ6XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+YW5kIE1ldGFk YXRhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgTWls ZXN0b25lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IERvbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IEphbiAyMDEzJm5ic3A7IFN1Ym1pdCBBcmNoaXRlY3R1cmUgdG8gSUVTRyBh cyBJbmZvcm1hdGlvbmFsIFJGQyBBcHIgMjAxMyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgU3VibWl0 IHByb3RvY29sIGRyYWZ0IHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQgUkZDIEF1ZyAyMDEz Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTdWJtaXQgTWV0YWRhdGEgbW9kZWwgYW5kIGZvcm1hdCB0 byBJRVNHIGFzIFByb3Bvc2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RhbmRhcmQgUkZDPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsgQXVnIDIwMTMmbmJzcDsgU3VibWl0IFNJUFJFQyBDYWxsIEZsb3dzIGRyYWZ0IHRvIElF U0cgYXMgYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbmFsIFJGQy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlthZGRpdGlvbmFsIG1pbGVzdG9uZXMgLSBvcHRpbWlzdGljIGRhdGVzOl08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFwciAyMDE0Jm5ic3A7IENvbmZlcmVuY2UgUmVjb3Jk aW5nIFVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRzIHRvIElFU0c8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIElu Zm9ybWF0aW9uYWwgUkZDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BdWcgMjAxNCZuYnNwOyBD b25mZXJlbmNlIFJlY29yZGluZyBBcmNoaXRlY3R1cmUgdG8gSUVTRyBhczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SW5mb3JtYXRpb25hbCBSRkM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkF1ZyAyMDE0Jm5ic3A7 IFByb3RvY29sIGFuZCBtZXRhZGF0YSBmb3IgTVNSUCByZWNvcmRpbmcgdG8gSUVTRyBhczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUHJvcG9zZWQgU3RhbmRhcmQgUkZDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5E ZWMgMjAxNCZuYnNwOyBQcm90b2NvbCBhbmQgbWV0YWRhdGEgZm9yIHJlY29yZGluZyBvZiBkb2N1 bWVudCAmYW1wOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXBwbGljYXRpb24gc2hhcmluZyB0byBJRVNHIGFzIFBy b3Bvc2VkIFN0YW5kYXJkIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_21794EB0EE82B0458A524942A141542B313B643Eszxeml561mbxchi_-- From michael.yan@huawei.com Fri Sep 13 19:36:25 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012E211E80FD for ; Fri, 13 Sep 2013 19:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jfvPeJj+96K for ; Fri, 13 Sep 2013 19:36:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D713E11E80F5 for ; Fri, 13 Sep 2013 19:36:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ76261; Sat, 14 Sep 2013 02:36:17 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 03:35:56 +0100 Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 03:36:13 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.162]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.01.0323.007; Sat, 14 Sep 2013 10:36:07 +0800 From: "Yanqiang (Michael)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Proposal: new SIPREC work on conference recording Thread-Index: AQHOsI0IDQsTAWihE0C71Atf00dg6JnEfSnA Date: Sat, 14 Sep 2013 02:36:07 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B313B64A8@szxeml561-mbx.china.huawei.com> References: <52332023.5070006@alum.mit.edu> In-Reply-To: <52332023.5070006@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [siprec] Proposal: new SIPREC work on conference recording X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 02:36:25 -0000 SGkgQWxsLA0KDQoJV2hpbGUgcmV2aXNpbmcgdGhlIGRvY3VtZW50LCB0aGVyZSB3ZXJlIHNvbWUg cXVlc3Rpb25zIGNhbWUgdG8gdXM6DQoNCjEuIFRob3VnaCBCRkNQIHdhcyBub3RpY2VkIGluIGlu dHJvZHVjdGlvbiwgd2UgZG9uJ3QgaGF2ZSBhbnkgaWRlYSBhYm91dCB0aGUgKmNhc2VzKiB3aXRo IEJGQ1Agd2hlbiByZWNvcmRpbmcgYSBjb25mZXJlbmNlLiBTbyBob3BlIHNvbWVvbmUgd291bGQg dGVsbCB1cy4NCg0KMi4gQXMgbG9va2luZyBiYWNrIHRoZSBoaXN0b3J5IGluIFJBSSwgZXNwZWNp YWxseSBmb3IgdGhlIE1NVVNJQyBhbmQgQVZUIFdHLCB0aGVyZSB1c2VkIHRvIGJlIHNldmVyYWwg YXR0ZW1wdHMgdG8gc3RhbmRhcmRpemUgdGhlIGRhdGEgc2hhcmluZyBvciBjb250ZW50IGNvbGxh Ym9yYXRpb24uIFNvIHdlIHRhbGtlZCBzb21lIG1lY2hpbmFzbSB0aGF0IGhvdyBkYXRhIHNoYXJp bmcgd29ya3MgaW4gQ1MsIGJ1dCB0YWtlIG1vcmUgYXR0ZW50aW9uIGF0IHRoZSBtZWRpYSB0eXBl IGl0IHdvdWxkIGNob29zZSBpbiBSUy4gQW5kIGNvbmNlbnRyYXRpbmcgb24gbWVkaWEocnRwKSBm bG93IGlzIHRoZSBmZWVkYmFjayBvZiA4N3RoIG1lZXRpbmcuDQpUaGUgaGlzdG9yaWFsIGF0dGVt cHRzIGFzIGJlbG93Og0KZHJhZnQtc2NodWx6cmlubmUtbW11c2ljLXNoYXJpbmctMDAoMjAwNCkN CmRyYWZ0LWdhcmNpYS1tbXVzaWMtc2RwLWNvbGxhYm9yYXRpb24tMDAoMjAwOCkNCmRyYWZ0LWxl bm5veC1hdnQtYXBwLXNoYXJpbmctMDAoMjAwNSkNCmRyYWZ0LWJveWFjaS1hdnQtYXBwLXNoYXJp bmctMDAoMjAwOCkNCg0KMy4gV2Ugc3BsaXQgdGhlIGRhdGEgc2hhcmluZyBpbnRvIHRocmVlIGNh c2VzLCBzY3JlZW4gc2hhcmluZywgYXBwbGljYXRpb24gc2hhcmluZyBhbmQgZG9jdW1lbnQgc2hh cmluZy4gQnV0IHdlIHRyaWVkIHRvIGZvY3VzIG9uIHRoZSBzY3JlZW4gc2hhcmluZyBvciBhcHBs aWNhdGlvbiBzaGFyaW5nLCBhbmQgdHJlYXQgdGhlIGRvY3VtZW50IHNoYXJpbmcgYXMgYSBzcGVj aWFsIGNhc2Ugb2YgdGhlbS4gVGhpcyBjYW4gbWFrZSB0aGUgbmV3IG1lY2hhbmlzbSB0byBiZSBz aW1wbGUgYW5kIGVhc3kuIFRoYXQncyB3aHkgd2UgYXZvaWQgdG8gdGFsayBhYm91dCB0aGUgZG9j dW1lbnQgY29sbGFib3JhdGlvbiB3aGljaCBoYXZlIGFjdGlvbnMgbGlrZSBhbm5vdGF0aW5nIG9y IHBhZ2UgdHVybmluZy4NCg0KNC4gU29ycnkgdG8gbWlzdXNlIHRoZSBSRkMgMzI0OCBmb3IgUkZD IDM0MjgNCg0KCVdlJ2QgYXBwcmVjaWF0ZSBhbnkgZmVlZGJhY2sgZnJvbSB5b3UuIDotKQ0KDQpU aGFua3MsDQpNaWNoYWVsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXByZWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+IFBhdWwgS3l6aXZhdA0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAx MywgMjAxMyAxMDoyNSBQTQ0KPiBUbzogc2lwcmVjQGlldGYub3JnDQo+IFN1YmplY3Q6IFtzaXBy ZWNdIFByb3Bvc2FsOiBuZXcgU0lQUkVDIHdvcmsgb24gY29uZmVyZW5jZSByZWNvcmRpbmcNCj4g DQo+IEluIEJlcmxpbiBJIHNwb2tlIGFib3V0IGEgcHJvcG9zYWwgdG8gZXh0ZW5kIHRoZSBzaXBy ZWMgY2hhcnRlciB0byBtb3JlIGZ1bGx5DQo+IGFkZHJlc3MgY29uZmVyZW5jZSByZWNvcmRpbmcu IFRoZXJlIHdhcyBnb29kIGZlZWRiYWNrIGR1cmluZyB0aGF0IG1lZXRpbmcNCj4gYWJvdXQgd2hl cmUgdG8gZm9jdXMsIGFuZCBzaWduaWZpY2FudCBpbnRlcmVzdCBpbiBnb2luZyBmb3J3YXJkIHdp dGggdGhpcy4NCj4gDQo+IFNpbmNlIHRoZW4gU2ltb24gUm9tYW5vLCBteSBhc3NvY2lhdGUgTWlj aGFlbCBZYW4sIGFuZCBJIGhhdmUgcmVmaW5lZCBhIHVzZQ0KPiBjYXNlIGFuZCByZXF1aXJlbWVu dHMgZHJhZnQgYWJvdXQgdGhhdCwgd2hpY2ggd2FzIGp1c3QgcG9zdGVkLiBUaGUNCj4gYW5ub3Vu Y2VtZW50IG9mIHRoYXQgZHJhZnQgaXMgYXR0YWNoZWQuDQo+IA0KPiBJIHJlcXVlc3QgdGhhdCBh bGwgeW91IFNJUFJFQ2VycyBwbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50IG9uIHRoaXMgZHJhZnQu IEknZA0KPiBhcHByZWNpYXRlIGZlZWRiYWNrIHRvIG1ha2UgaXQgYmV0dGVyLg0KPiANCj4gSW4g Y29uanVuY3Rpb24gd2l0aCB0aGF0LCBiZWxvdyBhcmUgYXJlIHNwZWNpZmljIHNpcHJlYyBjaGFy dGVyIGNoYW5nZSBwcm9wb3NhbHMsDQo+IHRvIGV4dGVuZCBvdXIgc2NvcGUgdG8gY292ZXIgdGhp cyB3b3JrLiBJJ20gYWxzbyBzb2xpY2l0aW5nIGNvbW1lbnRzIG9uIHRoZXNlLg0KPiANCj4gQWZ0 ZXIgc29tZSBsaXN0IGRpc2N1c3Npb24gb24gdGhlIGRyYWZ0IGFuZCB0aGUgY2hhcnRlciBjaGFu Z2VzLCBJIGhvcGUgd2UgY2FuDQo+IGhhdmUgYSBzZXNzaW9uIGF0IGlldGY4OCB0byBwcm9ncmVz cyB0aGlzLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBQ Uk9QT1NFRCBTSVBSRUMgQ0hBUlRFUiBSRVZJU0lPTiAoYXMgZGVsdGFzIHRvIGN1cnJlbnQgY2hh cnRlcik6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gPiBUaGUgU2Vzc2lvbiBSZWNvcmRpbmcgUHJv dG9jb2wgKFNJUFJFQykgd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8NCj4gPiBkZWZpbmUg YSBTSVAtYmFzZWQgcHJvdG9jb2wgZm9yIGNvbnRyb2xsaW5nIGEgc2Vzc2lvbiAobWVkaWEpIHJl Y29yZGVyLg0KPiA+DQo+ID4gU2Vzc2lvbiByZWNvcmRpbmcgaXMgYSBjcml0aWNhbCByZXF1aXJl bWVudCBpbiBtYW55IGJ1c2luZXNzDQo+ID4gY29tbXVuaWNhdGlvbnMgZW52aXJvbm1lbnRzIHN1 Y2ggYXMgY2FsbCBjZW50ZXJzIGFuZCBmaW5hbmNpYWwgdHJhZGluZw0KPiA+IGZsb29ycy4NCj4g DQo+IFtSZXBsYWNlIGFib3ZlIHNlbnRlbmNlIHdpdGg6XQ0KPiANCj4gU2Vzc2lvbiByZWNvcmRp bmcgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudCBpbiBtYW55IGJ1c2luZXNzIGNvbW11bmljYXRp b25zDQo+IGVudmlyb25tZW50cyBzdWNoIGFzIGNhbGwgY2VudGVycywgZmluYW5jaWFsIHRyYWRp bmcgZmxvb3JzLCBhbmQgbXVsdGltZWRpYQ0KPiBjb25mZXJlbmNlcy4NCj4gDQo+ID4gSW4gc29t ZSBvZiB0aGVzZSBlbnZpcm9ubWVudHMsIGFsbCBjYWxscyBtdXN0IGJlIHJlY29yZGVkIGZvcg0K PiA+IHJlZ3VsYXRvcnkgYW5kIGNvbXBsaWFuY2UgcmVhc29ucy4gSW4gb3RoZXJzLCBjYWxscyBt YXkgYmUgcmVjb3JkZWQNCj4gPiBmb3IgcXVhbGl0eSBjb250cm9sLCBidXNpbmVzcyBhbmFseXRp Y3MsIG9yIGNvbnN1bWVyIHByb3RlY3Rpb24uDQo+ID4gUmVjb3JkaW5nIGlzIHR5cGljYWxseSBk b25lIGJ5IHNlbmRpbmcgYSBjb3B5IG9mIHRoZSBtZWRpYSB0byB0aGUNCj4gPiByZWNvcmRpbmcg ZGV2aWNlcy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXRlcm1pbmUgcmVxdWlyZW1lbnRzIGFu ZA0KPiA+IHByb2R1Y2UgYSBzcGVjaWZpY2F0aW9uIGZvciBhIHByb3RvY29sIHRoYXQgd2lsbCBt YW5hZ2UgZGVsaXZlcnkgb2YNCj4gPiBtZWRpYQ0KPiANCj4gW0luc2VydDpdDQo+IA0KPiAoaW5j bHVkaW5nIGF1ZGlvLCB2aWRlbywgTVNSUCBpbnN0YW50IG1lc3NhZ2Ugc2Vzc2lvbnMsIGFuZCBy ZWFsLXRpbWUgc2hhcmluZw0KPiBvZiBkb2N1bWVudHMsIGFwcGxpY2F0aW9ucywgYW5kIGNvbXB1 dGVyIHNjcmVlbnMpDQo+IA0KPiA+IGZyb20gYW4NCj4gPiBlbmQtcG9pbnQgdGhhdCBvcmlnaW5h dGVzIG1lZGlhLCBvciB0aGF0IGhhcyBhY2Nlc3MgdG8gaXQsIHRvIGENCj4gPiByZWNvcmRpbmcg ZGV2aWNlLiBQQlggYW5kIHJlY29yZGluZyB2ZW5kb3JzIHRvZGF5IGltcGxlbWVudA0KPiA+IHBy b3ByaWV0YXJ5LCBpbmNvbXBhdGlibGUgbWVjaGFuaXNtcyB0byBmYWNpbGl0YXRlIHJlY29yZGlu Zy4gQQ0KPiA+IHN0YW5kYXJkIHByb3RvY29sIHdpbGwgcmVkdWNlIHRoZSBjb21wbGV4aXR5IGFu ZCBjb3N0IG9mIHByb3ZpZGluZw0KPiA+IHN1Y2ggcmVjb3JkaW5nIHNlcnZpY2VzLg0KPiA+DQo+ ID4gVGhlIFNlc3Npb24gUmVjb3JkaW5nIHByb2JsZW0gcHJlc2VudHMgY2VydGFpbiB1bmlxdWUg cmVxdWlyZW1lbnRzDQo+ID4gdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiB0aGUgY3VycmVudCBT SVAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4NCj4gPiBUaGVzZSBpbmNsdWRlIHJlcXVpcmVtZW50 cyBzdWNoIGFzIHRoZSBuZWVkIGZvciBhIGRpc3RpbmN0aW9uIGJldHdlZW4NCj4gPiB0aGUgc2Vz c2lvbiB0aGF0IGlzIGJlaW5nIHJlY29yZGVkIHZlcnN1cyB0aGUgc2Vzc2lvbiB0aGF0IGhhcyBi ZWVuDQo+ID4gZXN0YWJsaXNoZWQgZm9yIHJlY29yZGluZy4NCj4gPg0KPiA+IFByaXZhY3kgYW5k IHNlY3VyaXR5IG9mIGNvbnZlcnNhdGlvbnMgYXJlIHNpZ25pZmljYW50IGNvbmNlcm5zLiBUaGUN Cj4gPiB3b3JraW5nIGdyb3VwIHdpbGwgbWFrZSBzdXJlIHRoYXQgYW55IHByb3RvY29sIHNwZWNp ZmllZCBhZGRyZXNzZXMNCj4gPiB0aGVzZSBjb25jZXJucyBhbmQgaW5jbHVkZXMgbWVjaGFuaXNt cyB0byBhbGVydCB1c2VycyB0byB0aGUgZmFjdCB0aGF0DQo+ID4gYSBzZXNzaW9uIHRoZXkgYXJl IHBhcnRpY2lwYXRpbmcgaW4gaXMgYmVpbmcgcmVjb3JkZWQuDQo+ID4NCj4gPiBUaGUgd29ya2lu ZyBncm91cCBtdXN0IHRha2UgY2FyZSB0aGF0IHRoZSBzZXNzaW9uIHJlY29yZGluZw0KPiA+IHJl cXVpcmVtZW50cyBhbmQgcHJvdG9jb2wgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgSUVURiBz dGF0ZW1lbnQgb24NCj4gPiB3aXJldGFwcGluZyBjb250YWluZWQgaW4gUkZDIDI4MDQuDQo+ID4N Cj4gPiBUaGUgU0lQUkVDIFdvcmtpbmcgR3JvdXAgd2lsbCB0aG9yb3VnaGx5IGlkZW50aWZ5IHVz ZSBjYXNlcywgcHJvdmlkZQ0KPiA+IGV4YW1wbGUgc3lzdGVtIGFyY2hpdGVjdHVyZXMgYW5kIGRl cGxveW1lbnQgc2NlbmFyaW9zLCBhbmQgZGVmaW5lDQo+ID4gcmVxdWlyZW1lbnRzLg0KPiA+DQo+ ID4gVGhlIHNjb3BlIG9mIHRoZSBhY3Rpdml0eSBpbmNsdWRlczoNCj4gPg0KPiA+ICogUmVjb3Jk ZXIgQ29udHJvbA0KPiA+DQo+ID4gKiBTZXNzaW9uIG1ldGFkYXRhIGNvbnRlbnQgYW5kIGZvcm1h dA0KPiA+DQo+ID4gKiBTZWN1cml0eSBtZWNoYW5pc21zLCBpbmNsdWRpbmcgdHJhbnNwb3J0IGFu ZCBtZWRpYSBlbmNyeXB0aW9uDQo+ID4NCj4gPiAqIFByaXZhY3kgY29uY2VybnMsIGluY2x1ZGlu ZyBlbmQtdXNlciBub3RpZmljYXRpb24NCj4gPg0KPiA+ICogTmVnb3RpYXRpb24gb2YgcmVjb3Jk aW5nIG1lZGlhIHN0cmVhbXMNCj4gPg0KPiA+IFRoZSBncm91cCB3aWxsIGRlZmluZSB0aGVzZSBp c3N1ZXMgYW5kIHJhdGlvbmFsaXplIHdpdGggSUVURiBzdGFuZGFyZHMNCj4gPiBhbmQgcHJhY3Rp Y2VzLiBUaGlzIGluY2x1ZGVzIGVuY3J5cHRpb24sIE5BVCB0cmF2ZXJzYWwsIG9wZXJhdGlvbnMg YW5kDQo+ID4gbWFuYWdlYWJpbGl0eSwgU0lQLWVuYWJsZWQgZmlyZXdhbGxzLCBhdXRob3JpemF0 aW9uLCBhbmQgc2VjdXJpdHkuDQo+ID4NCj4gPiBUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlOg0KPiA+ DQo+ID4gKiBVcGRhdGVkIFJlcXVpcmVtZW50cywgVXNlIENhc2VzLCBBcmNoaXRlY3R1cmUgZHJh ZnQNCj4gPg0KPiA+ICogU3BlY2lmaWNhdGlvbiBmb3IgU2Vzc2lvbiBSZWNvcmRpbmcgUHJvdG9j b2wNCj4gDQo+IFtJbnNlcnQ6XQ0KPiANCj4gYW5kIE1ldGFkYXRhDQo+IA0KPiA+DQo+ID4gTWls ZXN0b25lcw0KPiA+IERvbmUgICAgICBVc2UgQ2FzZXMgYW5kIFJlcXVpcmVtZW50cyB0byBJRVNH IGFzIEluZm9ybWF0aW9uYWwgUkZDDQo+ID4gSmFuIDIwMTMgIFN1Ym1pdCBBcmNoaXRlY3R1cmUg dG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQyBBcHIgMjAxMw0KPiA+IFN1Ym1pdCBwcm90b2Nv bCBkcmFmdCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIFJGQyBBdWcgMjAxMw0KPiA+IFN1 Ym1pdCBNZXRhZGF0YSBtb2RlbCBhbmQgZm9ybWF0IHRvIElFU0cgYXMgUHJvcG9zZWQNCj4gPiAg ICAgICAgICAgU3RhbmRhcmQgUkZDDQo+ID4gQXVnIDIwMTMgIFN1Ym1pdCBTSVBSRUMgQ2FsbCBG bG93cyBkcmFmdCB0byBJRVNHIGFzIGFuDQo+ID4gICAgICAgICAgIGluZm9ybWF0aW9uYWwgUkZD Lg0KPiANCj4gW2FkZGl0aW9uYWwgbWlsZXN0b25lcyAtIG9wdGltaXN0aWMgZGF0ZXM6XQ0KPiAN Cj4gQXByIDIwMTQgIENvbmZlcmVuY2UgUmVjb3JkaW5nIFVzZSBDYXNlcyBhbmQgUmVxdWlyZW1l bnRzIHRvIElFU0cNCj4gICAgICAgICAgICBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KPiANCj4gQXVn IDIwMTQgIENvbmZlcmVuY2UgUmVjb3JkaW5nIEFyY2hpdGVjdHVyZSB0byBJRVNHIGFzDQo+ICAg ICAgICAgICAgSW5mb3JtYXRpb25hbCBSRkMNCj4gDQo+IEF1ZyAyMDE0ICBQcm90b2NvbCBhbmQg bWV0YWRhdGEgZm9yIE1TUlAgcmVjb3JkaW5nIHRvIElFU0cgYXMNCj4gICAgICAgICAgICBQcm9w b3NlZCBTdGFuZGFyZCBSRkMNCj4gDQo+IERlYyAyMDE0ICBQcm90b2NvbCBhbmQgbWV0YWRhdGEg Zm9yIHJlY29yZGluZyBvZiBkb2N1bWVudCAmDQo+ICAgICAgICAgICAgYXBwbGljYXRpb24gc2hh cmluZyB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KDQo= From iesg-secretary@ietf.org Tue Sep 17 07:56:44 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE4711E8466; Tue, 17 Sep 2013 07:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz9VaLn8ycc9; Tue, 17 Sep 2013 07:56:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B392111E836B; Tue, 17 Sep 2013 07:56:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130917145633.4165.70124.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 07:56:33 -0700 Cc: siprec@ietf.org Subject: [siprec] Last Call: (An Architecture for Media Recording using the Session Initiation Protocol) to Informational RFC X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:56:44 -0000 The IESG has received a request from the SIP Recording WG (siprec) to consider the following document: - 'An Architecture for Media Recording using the Session Initiation Protocol' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-siprec-architecture/ballot/ No IPR declarations have been submitted directly on this I-D. From pkyzivat@alum.mit.edu Wed Sep 18 13:06:26 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BDA11E8121 for ; Wed, 18 Sep 2013 13:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlYVjacU0SV0 for ; Wed, 18 Sep 2013 13:06:22 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9011E810B for ; Wed, 18 Sep 2013 13:06:21 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id Sj0p1m0081wpRvQ51k6Mr9; Wed, 18 Sep 2013 20:06:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id Sk6M1m0093ZTu2S3ek6Mv0; Wed, 18 Sep 2013 20:06:21 +0000 Message-ID: <523A07BC.8080209@alum.mit.edu> Date: Wed, 18 Sep 2013 16:06:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "siprec@ietf.org" Content-Type: multipart/mixed; boundary="------------050505090103020505090801" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379534781; bh=n6lB5kATOT8IPvihxtUjicDUN0NqklZVUuslczAPqdQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kkYLjPcK1EZlUSl3yNC86Bs/zUEyNP9ckjGQMGAckT46ebAjqMEFEroFEaRIgPHVR wu2Oqq8WhlaG+k41QXHE9wsXc/3At/btN5prL8uKUZMlxK5pM00egA6S+8dE+ZT5/V HZxrwBiFPQgWHsgHiwI3FVM17zBpOJa49sPoAkR6lElvJ1fBv/kKlXcUI1kP2ZJUs+ MoHj00911dJqPm5KYtteIHRD+B6Kzp51rrtxq1JPTZEXKWiRO42O3Gp7pZ2pF3NvrY haTy9KRenGfoDEVPOffSbmwDNNMyIW7hCJ9VwqR7JZOH+9L3elTLPQ1/6Eh1kvppAw sbXzzzTfKQKEg== Subject: [siprec] Proposal: new SIPREC work on conference recording (revised) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 20:06:27 -0000 This is a multi-part message in MIME format. --------------050505090103020505090801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (This includes revisions based on input from Simon Farrow and Michael Yan.) In Berlin I spoke about a proposal to extend the siprec charter to more fully address conference recording. There was good feedback during that meeting about where to focus, and significant interest in going forward with this. Since then Simon Romano, my associate Michael Yan, and I have refined a use case and requirements draft about that, which was just posted. The announcement of that draft is attached. I request that all you SIPRECers please review and comment on this draft. I'd appreciate feedback to make it better. In conjunction with that, below are are specific siprec charter change proposals, to extend our scope to cover this work. I'm also soliciting comments on these. After some list discussion on the draft and the charter changes, I hope we can have a session at ietf88 to progress this. Thanks, Paul --------------------------------------------------------------------- PROPOSED SIPREC CHARTER REVISION (as deltas to current charter): --------------------------------------------------------------------- > The Session Recording Protocol (SIPREC) working group is chartered to > define a SIP-based protocol for controlling a session (media) recorder. > > Session recording is a critical requirement in many business > communications environments such as call centers and financial trading > floors. [Replace above sentence with:] Session recording is a critical requirement in many business communications environments such as call centers, financial trading floors, emergency (first-responder) service bureaus, and multimedia conferences. > In some of these environments, all calls must be recorded for > regulatory and compliance reasons. In others, calls may be recorded for > quality control, business analytics, or consumer protection. Recording > is typically done by sending a copy of the media to the recording > devices. The working group will determine requirements and produce a > specification for a protocol that will manage delivery of media [Insert:] (including audio, video, MSRP instant message sessions, and real-time sharing of documents, applications, and computer screens) > from an > end-point that originates media, or that has access to it, to a > recording device. PBX and recording vendors today implement proprietary, > incompatible mechanisms to facilitate recording. A standard protocol > will reduce the complexity and cost of providing such recording > services. > > The Session Recording problem presents certain unique requirements that > are not addressed in the current SIP protocol specification. These > include requirements such as the need for a distinction between the > session that is being recorded versus the session that has been > established for recording. > > Privacy and security of conversations are significant concerns. The > working group will make sure that any protocol specified addresses these > concerns and includes mechanisms to alert users to the fact that a > session they are participating in is being recorded. > > The working group must take care that the session recording requirements > and protocol does not conflict with the IETF statement on wiretapping > contained in RFC 2804. > > The SIPREC Working Group will thoroughly identify use cases, provide > example system architectures and deployment scenarios, and define > requirements. > > The scope of the activity includes: > > * Recorder Control > > * Session metadata content and format > > * Security mechanisms, including transport and media encryption > > * Privacy concerns, including end-user notification > > * Negotiation of recording media streams > > The group will define these issues and rationalize with IETF standards > and practices. This includes encryption, NAT traversal, operations and > manageability, SIP-enabled firewalls, authorization, and security. > > The group will produce: > > * Updated Requirements, Use Cases, Architecture draft > > * Specification for Session Recording Protocol [Insert:] and Metadata > > Milestones > Done Use Cases and Requirements to IESG as Informational RFC > Jan 2013 Submit Architecture to IESG as Informational RFC > Apr 2013 Submit protocol draft to IESG as Proposed Standard RFC > Aug 2013 Submit Metadata model and format to IESG as Proposed > Standard RFC > Aug 2013 Submit SIPREC Call Flows draft to IESG as an > informational RFC. [additional milestones - optimistic dates:] Apr 2014 Conference Recording Use Cases and Requirements to IESG as Informational RFC Aug 2014 Conference Recording Architecture to IESG as Informational RFC Aug 2014 Protocol and metadata for MSRP recording to IESG as Proposed Standard RFC Dec 2014 Protocol and metadata for recording of document & application sharing to IESG as Proposed Standard RFC --------------050505090103020505090801 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: srs0=z8ty=sz=ietf.org=internet-drafts@alum.mit.edu Received: from imta37.westchester.pa.mail.comcast.net (LHLO imta37.westchester.pa.mail.comcast.net) (76.96.62.97) by sz0055.wc.mail.comcast.net with LMTP; Fri, 13 Sep 2013 05:56:05 +0000 (UTC) Received: from alum-mailsec-relay-9.mit.edu ([18.7.68.29]) by imta37.westchester.pa.mail.comcast.net with comcast id QVw41m01D0dt8C20cVw45g; Fri, 13 Sep 2013 05:56:05 +0000 X-CAA-SPAM: 00000 X-Authority-Analysis: v=2.1 cv=e4I/F8Z/ c=1 sm=1 tr=0 a=MRj2BPNAhLswQ1TjTjGTrQ==:117 a=GU4rwa5YvsQnE15YQEkOQw==:17 a=C_IRinGWAAAA:8 a=lS0MHldHvS4A:10 a=DoyLNiy-LgAA:10 a=LSVET5z0puwA:10 a=Y8pcNLQseH4A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=T4iP7njNTVoA:10 a=zzPzetCxK8GqC5mrGfoA:9 a=8NNSE5sbPybOGbzR:21 a=xKt_Q0fzxkLi1MIo:21 a=QEXdDO2ut3YA:10 Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by alum-mailsec-relay-9.mit.edu (8.14.7/8.12.8) with ESMTP id r8D5tkbt011309 for ; Fri, 13 Sep 2013 01:56:04 -0400 X-AuditID: 1207440c-b7fdf6d000001b94-be-5232a8f31d45 Authentication-Results: symauth.service.identifier Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 54.1D.07060.3F8A2325; Fri, 13 Sep 2013 01:56:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED8911E8164; Thu, 12 Sep 2013 22:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5VEr6BMNNaJ; Thu, 12 Sep 2013 22:56:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6893A11E80FB; Thu, 12 Sep 2013 22:56:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: "Paul H. Kyzivat" , Simon Pietro Romano , Michael Yan , Paul Kyzivat , Simon Romano Subject: New Version Notification for draft-kyzivat-siprec-conference-use-cases-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913055602.10539.20347.idtracker@ietfa.amsl.com> Date: Thu, 12 Sep 2013 22:56:02 -0700 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRWlGSWpSXmKPExsXCI2Ylp/t5hVGQwe1fihYrNhxgdWD0+Pv+ A1MAYxSXTUpqTmZZapG+XQJXxv+m++wFT7kr9t5/xdLA2MjZxcjJISFgItG/+jo7iM0oYCSx +9wrVoi4mMSFe+vZuhi5OIQEjjBK3NrynwXCmcQoMXHvF2aIKg2JGSsvMEIktjFKdO29zArh TGOUuPvuNgtIFa+AoMTJmU+AbA4OZgFNifW79EHCzALaEssWvgYbxCYgJ7H61TSwQSICJxgl Di/8xAiSEBaIkPh+9AcbxDYRiXdXH0JtlpRYMeMFK8TdchI/jj1mArEFBAQk/k26ALXXUeLF nBVgcRYBVYnp886xTGAUmYXkpFkIJ81CctICRuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbqG ermZJXqpKaWbGIGBL8TuwrOD8ds6mUOMAhyMSjy8HTFGQUKsiWXFlbmHGCU5mJREeVMWAoX4 kvJTKjMSizPii0pzUosPMUpwMCuJ8AotAsrxpiRWVqUW5cOkpDlYlMR5VZeo+wkJpCeWpGan phakFsFkmTjYDzHKcHAoSfD+Xg7ULViUmp5akZaZU4KshhNEcIGs4QFa0w5SyFtckJhbnJkO UXSKUVFKnFcdmG6EBEASGaV5cANgyeoSo6yUMC8jAwODEA/QBUCPo8o/YhTkeMkuxMbFlJon oCvFkpefl/qKURwYEMK8oiCTeTLzSuA2vgI6hgnomO+++iDHlCQipKQaGPNmTZ7qxP0n17xe jKMvabbiS0Otw/Z3Ow15j15+/fr7qx2rFxisLvfr9mr45+4RYNcTohLP82B9/p3uq0WPC2J6 ln8u82rZwRJa93eHorCP5LWpjbxGyTpnpbvcHPz+8N7KVco35qhssp37q9VTaVf0b6nPphXN 363n3LSpuSnmez46oOCWEktxRqKhFnNRcSIAkjU/wmUDAAA= A new version of I-D, draft-kyzivat-siprec-conference-use-cases-00.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-siprec-conference-use-cases Revision: 00 Title: Multimedia Conference Recording Use Cases and Requirements Creation date: 2013-09-13 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-siprec-c= onference-use-cases-00.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-siprec-confe= rence-use-cases Htmlized: http://tools.ietf.org/html/draft-kyzivat-siprec-conference= -use-cases-00 Abstract: The current work of SIPREC will soon finish. As conferences are the key requirement for some environments, it is worth to explore several extensions and additional functionalities to support multimedia conference recording. SIPREC is not sufficient to record all the conference sessions via certain interactive media channels, like multi-user chat or screen sharing. This draft tries to show the use cases for multimedia conference recording and the requirements for how to work well under SIPREC mechanism. = = Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------050505090103020505090801-- From eckelcu@cisco.com Thu Sep 19 15:50:31 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A676921F84E0 for ; Thu, 19 Sep 2013 15:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_50=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7uAjqErN+st for ; Thu, 19 Sep 2013 15:50:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B32C221F8AF4 for ; Thu, 19 Sep 2013 15:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18061; q=dns/txt; s=iport; t=1379631022; x=1380840622; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kkh/czjIaOHG5TWS469fiaiqjRK7qSzl3TUJN4UxAYg=; b=ckPYS4VmOIPvZO0GZjkuDfYdjG83LwVn6Q2gwezWG7/PL7HDzz0Uw+H5 LiTY7fSioUzQw2mI3DYX7cm/edYEfuVlO5hpST16ud+rssHM1LxOMEbfb oQQOjqEyDK7NO+Rd0qRgAtMhxjB07/sSbBrnoiDhLAd9cZ5smA3Ws3y/F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFACx/O1KtJV2b/2dsb2JhbABbDoJ5OFKtBpNdSoEfFnSCJQEBAQQBAQFkAQYCGwEIDgoKSwslAQEEARIIE4dnAQy6O44eCoEMAjiDHoEAA5QfhQyQRoJlP4FoCRci X-IronPort-AV: E=Sophos;i="4.90,940,1371081600"; d="scan'208";a="262151323" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 19 Sep 2013 22:50:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8JMoLuv012968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 22:50:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.239]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 17:50:21 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-protocol-10 Thread-Index: Ac6tNc3U21dTN5ARRzalEAmqIGrqxABZOR4AAbfJ34A= Date: Thu, 19 Sep 2013 22:50:21 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882805C2500A@xmb-aln-x08.cisco.com> In-Reply-To: <522F95DC.3030904@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [171.68.20.129] Content-Type: text/plain; charset="Windows-1252" Content-ID: <88C3716E6C7A244C8F4B4C8698AE115C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] WGLC on draft-ietf-siprec-protocol-10 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 22:50:31 -0000 Hi Paul, I appreciate review careful review of the draft in its entirety. Please see comments inline. On 9/10/13 2:57 PM, "Paul Kyzivat" wrote: >I hadn't read this all the way through for a long time. (I've just been >looking at the diffs.) It is instructive to read it all. I found a lot >of relatively minor stuff, and one thing that is going to require more >thought and discussion. > >Many places containing ABNF: > >The operator "/=3D" is being used, but the correct operator is "=3D/". >This suggests that a syntax verification of the ABNF is called for. >There is a tool for that. But to do it right requires extracting all the >ABNF, merging with the referenced ABNF, and then running the tool. Sounds worthwhile. I did not add the ABNF and I'm not familiar with the tool. Any volunteers? > >The remaining comments follow the order of text in the document. > >Section 5: > > Section 6 describes SIP the handling in a recording session between a > SRC and a SRS, and the procedures for recording-aware user agents > participating in a CS. > >I can't parse the beginning of this sentence. I think you might mean: > > Section 6 describes the SIP handling in a recording session between > a SRC and a SRS, ... How about "=8A describes the SIP communication in a recording =8A" > >Section 6.1.1.1: > > In addition, when an SRC sends a REGISTER request > to a registrar, the SRC MUST include the '+sip.src' feature tag to > indicate the that it is a SRC. > >This could be misinterpreted. And I'm not sure it should always be true. > >Consider an ordinary UA that sometimes or always acts as an SRC to >record its own calls. Why would it want to indicate this to a registrar. >That might be a good thing, if a caller wants to use callerprefs to >select a callee UA that can record calls. But that is an odd thing to do. > >It could be a good thing if there is a pool of B2BUAs that are >registered to a common AOR. It would allow recruiting one by sending an >INVITE to it. But this is also very obscure usage. Normally B2BUAs are >selected more overtly, and not by the UAC. > >Its especially bad if this is taken literally by a box that is don't >registrations of contact URIs other than its own. For instance, a PBX >B2BUA box that is an SRC, but that also registers contact URIs on behalf >of its endpoints. It would not want to do this on behalf of those >endpoints. > >So can someone refresh my memory about why this is a good thing? Sorry, not sure. Seems it could be useful in some cases, but MAY seems more appropriate than MUST. > >If this is to be kept, then it would be better if it is worded as: > > When the URI of an SRC is included in a REGISTER request to a > registrar, then the '+sip.src' feature tag SHOULD be included in the > contact URI for the SRC. Fine by me, but unless someone knows why it should be stronger, MAY seems more appropriate to me. > >Section 6.2: > >Similar issue to the one above for section 6.1.1.1. > > In addition, when > an SRS sends a REGISTER request to a registrar, the SRS MUST include > the '+sip.srs' feature tag to indicate that it is a SRS. > >At least it is more likely that an SRC might be sending an INVITE to an >AOR in order to reach an SRS, so this might have some utility. (But >would an AOR used to describe SRSs have any registrations for non-SRSs? >And some of the problem cases I mentioned re SRCs are less likely for >SRSs. But I still recommend the analogous text change here: > > When the URI of an SRS is included in a REGISTER request to a > registrar, then the '+sip.srs' feature tag SHOULD be included in the > contact URI for the SRS. Works for me. > >Section 6.3: > > A recording-aware UA MUST be prepared to provide recording indication > to the end user through an appropriate user interface an indication > whether recording is on, off, or paused for each medium. > >I can't parse this sentence. How about: > > A recording-aware UA MUST be prepared to provide a recording > indication to the end user through an appropriate user interface, > indicating whether recording is on, off, or paused for each medium. Sounds good. > >Section 7.1.1.1: > >The following is slightly ambiguous: > > Note that a CS > itself may change the media stream direction by updating the SDP, for > example, by setting a=3Dinactive for SDP hold. Media stream direction > changes in CS are conveyed in the metadata by the SRC. The SRC MUST > NOT modify the media stream with a=3Dinactive for SDP hold on the CS > since this operation is reserved for pausing the RS media, however, > an SRC can have a local policy to pause the RS media when the CS is > placed on hold. > >In the last sentence above, it isn't clear which media stream is being >referenced in "The SRC MUST NOT modify the media stream". So I suggest >changing this to: > > The SRC MUST > NOT modify the RS media stream with a=3Dinactive for SDP hold on the C= S > since this operation is reserved for pausing the RS media, ... Yes, I that is how more clear. =20 > >Section 7.1.3: > > When the SRC receives the a=3Drecordpref SDP in an SDP offer or answer= , > the SRC chooses to honor the preference to record based on local > policy at the SRC. Whether or not the SRC honors the recording > preference, the SRC MUST update the a=3Drecord attribute to indicate > the current state of the recording (on/off/paused). > >Its unclear to me what the MUST means. The following are some things >that might be done: > >- if the a=3Drecordpref is received in an offer, put the resulting > a=3Drecord setting in the answer. > >- if the a=3Drecordpref is received in an offer or answer, send a new > offer *soon* to all CS legs with the resulting a=3Drecord. > >- same as above. Unconditionally send to leg that changed a=3Drecordpref, > but don't send again to other legs if recording state remains > as it was. > >Also, ISTM that once a UA has put a=3Drecordpref in its SDP, it will >probably leave it there, unchanged, through subsequent O/A cycles. That >means, for the above, every time it sends an offer or answer, it will be >sending a=3Drecordpref again. It would be unfortunate if that forced the >SRC to send *another* offer. (It could lead to an infinite o/a loop.) > >I *don't* think it is a good idea to treat this as a one-time request. > >So I suggest that both a=3Drecordpref and a=3Drecord should be viewed as >*state* that is announced in every offer or answer. As long as the state >remains unchanged, it is just put into each offer or answer when they >are required for other purposes. When one of them changes state, then an >offer or answer must be sent asap to announce the change. Works for me. > >Section 7.3: (THE BIG ISSUE IS HERE) > >This section brings up the situation where there are multiple SRCs in >the CS. That presents some other issues that I don't think we have >considered. Suppose we have: > >UA1 ----- SRC1 ---- B2BUA ---- SRC2 ----- UA2 > >(UA1, B2BUA, and UA2 all indicate they are recording aware.) > >Now suppose SRC1 is recording, and SRC2 is not recording. What sort of >recording indications do we have in the CS signaling? > >Initially >- SRC1 would send a=3Drecording:on to UA1 and B2BUA >- SRC2 would send a=3Drecording:off to UA2 and B2BUA >- B2BUA would propagate a=3Drecording:on to SRC2 > and propagate a=3Drecording:off to SRC1 ??? > >Then, what do SRC1 and SRC2 do when they receive these values from the >B2BUA? > >This is actually quite a mess. I think *somebody* needs to keep a count >of recordings. Either we put the count into the attributes, or we make >some of the components keep the count. The latter might be easier. I >think only recording aware B2BUAs and conference foci (including those >that are SRCs) would need to do this. They would need to keep a count >over all their legs. (And an SRC B2BUA would include its own recording >in this count.) When the count is zero the recording state is off, else >it is on. (Need more analysis for what to do with pause.) > >Some similar treatment is probably required for recordpref. My head >hurts now, so I'm not doing it here. > >I think we need some list discussion on this! Note that the solution to >this will probably invalidate the suggestion I made for 7.1.3. Why not treat each as a separate RS, resulting in multiple recordings of the same CS. If we are an endpoint in such a CS, you may receive different recording indications from each of your peers (in a peer to peer CS), or an XOR of the recording indications from an MCU (in an MCU hosted conference). > >Section 8.1.5.1: > >Do we want to reference the new mechanism for chooseing CNAME that has >been proposed by EKR? (I forget the draft name, or if it has become and >RFC.) I think so. > >Section 8.2: > >First paragraph: > > There are numerous ways in which an SRC may do this is, including but > not limited to, appearing as a UA within a CS, or as a B2BUA between > UAs within a CS. > >s/do this is/do this/ Yep. > >Section 8.3: > > An SRC may > choose to use one or more of the RTP session usages within a single > RS. For the purpose of base interoperability between SRC and SRS, an > SRC MUST support separate m-lines in SDP, one per CS media direction. > >I find the above confusing. (But maybe just because I don't understand >enough about RTP.) Isn't the SRC the one that is deciding what usage to >employ? If so, and if it must support separate m-lines, then under what >circumstance would it employ anything else? An SRC could mix both direction into a single mixed stream. If the SRS does not support this, it could fall back to separate streams. > >Is the intended to be determined by configuration during deployment? >Or my multiple o/a attempts? Or by CAPNEG? Or what? config - probably multiple o/a attempts - potentially CAPNEG - doubt it > >Section 8.3.1: > > Additionally, the SRC SHOULD map each > unique combination of CNAME/SSRC within the CSs to a unique CNAME/ > SSRC within the RS. > >Isn't it ok to map both CNAME1/SSRC1 and CNAME1/SSRC2 in the CS to >CNAMEn/SSRCn in the RS? The above statement seems to suggest not. It is okay, but they the RS looses the ability to distinguish between the two. If two CNAME/SSRC combinations are combined by the SRC, the SRS will not be able to pull them back apart. > >Section 8.4: > >IIUC, normal draft style is to indent notes relative to the surrounding >text. Okay with me, but probably better to replace "Note that these =8A" with "These =8A" > >Section 9.1: > > When the SRC sends a full metadata snapshot, the SRC MUST > send an INVITE or an UPDATE request ... A > partial update sent by the SRC can be an INVITE request or response > with an SDP offer, or an INVITE/UPDATE request or response containing > a "recording-session" disposition, or an INVITE request containing > both an SDP offer and the "recording-session" disposition. > >I find the above confusing. > >For one thing, disposition is associated with a body part, not a >request. A request can have multiple body parts, each with its own >disposition. Offers and answers are carried in body parts with >disposition "session". (Its the default, so you don't often see it >written.) There could also be other body parts. We don't care about >those so we ignore them. In principle a given body part with a >particular disposition might be valid with any of a variety of content >types. But in practice, session always contains application/sdp and >recording-session always contains application/rs-metadata or >application/rs-metadata-request. So we can simply talk about the >possibilities in terms of the content types it contains. In the case of >SDP, it may be either an offer or answer. That is only determined by >context - you cant tell by looking at a single message. > >AFAIK we have the following valid sip signaling possibilities on the RS: > >- INVITE by SRC: offer-sdp, metadata > response by SRS: answer-sdp >- INVITE by SRC: offer-sdp > response by SRS: answer-sdp >- INVITE by SRS: > response by SRC: offer-sdp, metadata >- INVITE by SRS: > response by SRC: offer-sdp >- UPDATE by SRC: offer-sdp, metadata > response by SRC: answer-sdp >- UPDATE by SRC: offer-sdp > response by SRS: answer-sdp >- UPDATE by SRS: > response by SRC: >- UPDATE by SRS: offer-sdp > response by SRC: answer-sdp >- UPDATE by SRS: metadata-request > response by SRC: > >Of those, only three carry metadata: > >- INVITE by SRC: offer-sdp, metadata >- INVITE by SRS: > response by SRC: offer-sdp, metadata >- UPDATE by SRC: offer-sdp, metadata > >That is independent of whether the metadata is a snapshot or a partial. >The special case for a snapshot request is: > >- UPDATE by SRS: metadata-request > response by SRC: > >and followed by one of the two above initiated by the SRC: > >- INVITE by SRC: offer-sdp, metadata >- UPDATE by SRC: offer-sdp, metadata > >So how to say all that in a comprehensible way? How about replacing that >entire paragraph with the following: > >"Metadata sent by the SRC can be categorized as either a full metadata >snapshot or partial update. A full metadata snapshot describes all the >recorded streams and all metadata associated with the recording session. >The SRC MAY send a full metadata snapshot at any time. The SRC MAY send >a partial update if a full metadata snapshot has previously been sent. >If the SRC receives a snapshot request from the SRS, then it MUST >immediately send a full metadata snapshot. > >The SRC MAY send metadata (either a full metadata shapshot or a partial >update) in either an INVITE request, an UPDATE request, or in the final >(200) response to an offerless INVITE from the SRS. If any of the >metadata being sent contains a reference to any SDP labels, then the >request containing the metadata MUST also contain an SDP offer that >defines those labels. > >When an INVITE or UPDATE request contains both an SDP offer and >metadata, then the request body has content type multipart/mixed, with >one subordinate body part containing the SDP offer and another >containing the metadata. When an INVITE contains only an SDP offer or >metadata, then the multipart/mixed container is optional." Sounds reasonable, but I defer to others who have more experience with this mechanism. > >Figure 11: > >(A nit) there is no need for "application/rs-metadata" in the Accept. >(This only describes what can be *received*, and the SRC will never >receive this.) Agreed. > >Section 9.2: > > When the SRS explicitly requests for a full metadata snapshot, the > SRS MUST send an UPDATE request without an SDP offer. A metadata > snapshot request contains a content with the content disposition type > "recording-session". ... > >The above is at least awkward. How about: > > The SRS MAY explicitly request a full metadata snapshot by sending > an UPDATE request. This request MUST contain a body with a content > disposition type "recording-session", and MUST NOT contain an SDP > body part. ... > >Then further into this section: > > When the SRC receives the request for a metadata snapshot, the SRC > MUST provide a full metadata snapshot in a separate INVITE or UPDATE > transaction, along with an SDP offer. All subsequent metadata > updates sent by the SRC MUST be based on the new metadata snapshot. > >Most of the time SDP will be required. But its possible that there are >currently no media streams, and hence no references to SDP. In that case >the SDP isn't needed. (To avoid the SDP, the metadata would need to be >sent in an UPDATE.) I covered the cases where SDP must be sent in my >proposed changes above, so it doesn't really need to be mentioned here. > >Also, subsequent partial updates could depend on future full snapshots, >not just this one. > >So how about changing the above to: > > When the SRC receives a request for a metadata snapshot, it MUST > immediately provide a full metadata snapshot in a separate INVITE or > UPDATE transaction. Any subsequent partial updates will not be > dependent on any metadata sent prior to this full metadata snapshot. > >Section 9.2.1: > >The ABNF references TEXT-UTF8-TRIM, but doesn't specify where this is >defined. (It comes from 3261.) > >Section 11.5.1, 11.5.2: > >These list Leon with his Nice email address. This should probably be >changed. > >Section 12: > >Have we had a security review yet? I asked Richard Barnes to review specific sections in the past, but I am not aware of a full security review. Cheers, Charles > >Section 12.2: > >Authors Addresses: > >Lean is still shown at Nice. > >That's all. > > Thanks, > Paul > >On 9/9/13 4:23 AM, Hutton, Andrew wrote: >> We would like to start a working group last call of >> _http://tools.ietf.org/html/draft-ietf-siprec-protocol-10_ >> Please send comments by the end of the day on September 22^nd (Two >>weeks). >> The deadline for requesting a meeting during IETF88 (Vancouver) is Sept >> 23^rd and whether or not there are WGLC comments on this draft may >> determine whether we need a SIPREC meeting in Vancouver. >> Regards >> Andy (SIPREC Co-Chair). >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec