From br@brianrosen.net Fri Oct 11 05:58:12 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 5F91A21E8165 for ; Fri, 11 Oct 2013 05:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.277 X-Spam-Level: X-Spam-Status: No, score=-103.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 OrZMazcOzZW9 for ; Fri, 11 Oct 2013 05:58:07 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AE21F9CAD for ; Fri, 11 Oct 2013 05:57:43 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so2847210qcr.20 for ; Fri, 11 Oct 2013 05:57:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=VDY0bgv2PSMW6aDs1Llm3dI7ojsuGjGofSlGASQb5bc=; b=V9kk4abT/c65wZoq7JFkIq2R4okbxeCDCPkP+jEy5mnvHQv4/krxKSIzRK/1KVDDZt Pkzzi5L/KT79YF3LeXlBakAbrRXF1BX+wRbkKSXHaZBlHOzhRWewc8Wvq88zxTgpSsIM D+eNHVAjzQZqQRUt6tFMQcAEmbSigNA6+4fO0gMuPNexvwS6rmQUYjSA6L/mIl8+OWk/ fElJ5+PCyd4IUw1G1CND3bFt22FFI3GzjdJGSWbNgoMoYwe5q5Umgir3EncCq1j8zdgB vJ56Hofdz9aaRoYIvD9Y8xyTbSZCkGrlWKXPQDGAe7MX8+m5XkJfojxF9N+K2//n3CpL bbyQ== X-Gm-Message-State: ALoCoQk0aC7oEJH5zjxp66XhcmMzrOCCvLa/qqIlGzmHjdM+wIWs8DnB6BWOHXGtgeW5hFXti1c3 X-Received: by 10.224.6.10 with SMTP id 10mr16547543qax.31.1381496262649; Fri, 11 Oct 2013 05:57:42 -0700 (PDT) Received: from [10.33.193.37] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id h2sm97006596qev.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Oct 2013 05:57:42 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628" Date: Fri, 11 Oct 2013 08:57:40 -0400 References: <52579E47.6020706@ericsson.com> To: p2psip@ietf.org, siprec@ietf.org Message-Id: <6CCB5952-2369-4E74-A4B8-B3E102CFEC1A@brianrosen.net> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [siprec] Fwd: [RAI] NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV 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, 11 Oct 2013 12:58:12 -0000 --Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Gonzalo Camarillo > Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - = APP, OAM, RAI, TSV > Date: October 11, 2013 2:44:23 AM EDT > To: >=20 > Folks, >=20 > we need more volunteers (see email below). If you are thinking of > running but still have some doubts about it, feel free to talk with me > (or with any of the former RAI ADs) and we will be happy to clarify > everything for you. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > -------- Original Message -------- > Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, = RAI, TSV > Date: Tue, 8 Oct 2013 11:45:14 -0700 > From: NomCom Chair > Reply-To: > To: IETF Announcement List > CC: >=20 > UPDATE: nominations are too sparse in several of the IESG areas: APP, = OAM, > RAI, and TSV. If you know one or more of those areas, exercise your = social > network and submit nominations. We'll be very grateful! >=20 > Is there someone you work with at IETF who has leadership potential = and a > growing track record? Please read this Nomcom call for nominations and > consider > nominating her or him. Or several folks! Deadline for nominations is > October 18. > Nominate soon to give your nominee(s) plenty time to fill in the > questionnaire. >=20 > If you're nominated, even if you support the present incumbent, being > reviewed > by Nomcom is great IETF experience. The questionnaire offers a chance = to > think about IETF and about your area. Whether or not your candidacy > progresses > this time, you'll have gained some valuable insights, and you'll have > contributed > greatly. This process only works because many IETFers take part; = please > join in. >=20 > Lots more, including which positions are open, how to make a = nomination > (including nomination of yourself), and how to send us your feedback = on > the desired expertise, follows. >=20 > IETFers, let's hear from you! Make nominations, accept nominations! >=20 > If you have any questions about the process, feel free to get in touch > with me. >=20 > Best regards, >=20 > Allison for the Nomcom >=20 > Allison Mankin > Nomcom Chair 2013-14 >=20 > ----- The Info You Need for Nominating ----- >=20 > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website: >=20 > https://datatracker.ietf.org/nomcom/2013/ >=20 > Information about the desired expertise for positions is here: > https://datatracker.ietf.org/nomcom/2013/expertise >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL: >=20 > https://datatracker.ietf.org/nomcom/2013/nominate/ >=20 > Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the = Subject > and indicate in the email who is being nominated, their email address = (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate = email for > each person you nominate, and for each position (if you are nominating = one > person for multiple positions). >=20 > Self-nomination is welcome! No need to be shy. >=20 > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and = will > not be disclosed. >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > Nomcom on or before October 18, 2013. Please submit your nominations > as early as possible for the sake of your nominees, as we've set the > questionnaire submission deadline for October 25, 2013. >=20 > The list of people and posts whose terms end with the March 2014 IETF > meeting, > and thus the positions for which we are accepting nominations: >=20 > IAOC > Chris Griffiths >=20 > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting = nominations > you receive. >=20 > The summaries of the desired expertise for the positions, developed by = the > respective bodies, are found at: >=20 > https://datatracker.ietf.org/nomcom/2013/expertise/ >=20 > In addition to nominations, the Nomcom seeks community input on > the positions themselves. We need and welcome the community's > views and input on the jobs within each organization. If you > have ideas on the positions' responsibilities (more, less, > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. >=20 > Thank you for your help in nominating a great pool of strong and = interesting > nominees! >=20 >=20 >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai --Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Gonzalo Camarillo = <Gonzalo.Camarillo@ericsson.= com>
Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for = Nominations - APP, OAM, RAI, TSV
Date: October 11, 2013 = 2:44:23 AM EDT

Folks,

we need more volunteers (see email below). If you are = thinking of
running but still have some doubts about it, feel free to = talk with me
(or with any of the former RAI ADs) and we will be happy = to clarify
everything for = you.

Cheers,

Gonzalo


-------- Original Message = --------
Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - = APP, OAM, RAI, TSV
Date: Tue, 8 Oct 2013 11:45:14 -0700
From: = NomCom Chair <nomcom-chair@ietf.org>
Rep= ly-To: <nomcom-chair-2013@ietf.org&= gt;
To: IETF Announcement List <ietf-announce@ietf.org>
C= C: <ietf@ietf.org>

UPDATE: = nominations are too sparse in several of the IESG areas:  APP, = OAM,
RAI, and TSV.  If you know one or more of those areas, = exercise your social
network and submit nominations.  We'll be = very grateful!

Is there someone you work with at IETF who has = leadership potential and a
growing track record? Please read this = Nomcom call for nominations and
consider
nominating her or him. Or = several folks! Deadline for nominations is
October 18.
Nominate = soon to give your nominee(s) plenty time to fill in = the
questionnaire.

If you're nominated, even if you support = the present incumbent, being
reviewed
by Nomcom is great IETF = experience.  The questionnaire offers a chance to
think about = IETF and about your area.  Whether or not your = candidacy
progresses
this time, you'll have gained some valuable = insights, and you'll have
contributed
greatly. This process only = works because many IETFers take part; please
join in.

Lots = more, including which positions are open, how to make a = nomination
(including nomination of yourself), and how to send us = your feedback on
the desired expertise, follows.

IETFers, = let's hear from you!  Make nominations, accept = nominations!

If you have any questions about the process, feel = free to get in touch
with me.

Best regards,

Allison for = the Nomcom

Allison Mankin
Nomcom Chair 2013-14

----- = The Info You Need for Nominating -----

The 2013-14 Nominating = Committee (Nomcom) is seeking nominations
from now until October 18, = 2013. The open positions being considered
by this year's Nomcom can = be found later in this section, and also on
this year's Nomcom = website:

https://datatracker.iet= f.org/nomcom/2013/

Information about the desired expertise = for positions is here:
=          https://datatracker.= ietf.org/nomcom/2013/expertise

Nominations may be made by = selecting the Nominate link at the top of
the Nomcom 2013 home page, = or by visiting the following = URL:

https://datatracker.ietf.org/nomcom/2013/nominate/

Note= that nominations made using the web tool require an = ietf.org
datatracker account. You can create a datatracker ietf.org = account
if you don't have one already by visiting the following = URL:

https://datatracker.ietf.org/accounts/create/

Nominatio= ns may also be made by email to nomcom13 at ietf.org.
If you nominate = by email, please include the word "Nominate" in the Subject
and = indicate in the email who is being nominated, their email address = (to
confirm acceptance of the nomination), and the position for which = you
are making the nomination. If you use email, please use a = separate email for
each person you nominate, and for each position = (if you are nominating one
person for multiple = positions).

Self-nomination is welcome!  No need to be = shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure = of Willing
Nominees" described in RFC 5680.  As stated in RFC = 5680: "The list of
nominees willing to be considered for positions = under review in the
current Nomcom cycle is not confidential". = Willing nominees for each
position will be listed in a publicly = accessible way - anyone with a
datatracker account may access the = lists.  In all other ways, the
confidentiality requirements of = RFC 3777/BCP10 remain in effect.  All
feedback and all Nomcom = deliberations will remain confidential and will
not be = disclosed.

In order to ensure time to collect sufficient = community feedback about
each of the willing nominees, nominations = must be received by the
Nomcom on or before October 18, 2013. =  Please submit your nominations
as early as possible for the = sake of your nominees, as we've set the
questionnaire submission = deadline for October 25, 2013.

The list of people and posts whose = terms end with the March 2014 IETF
meeting,
and thus the positions = for which we are accepting nominations:

IAOC
Chris = Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross = Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba = (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations = and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant = (Routing)
Sean Turner (Security)
Martin Stiemerling = (Transport)

Please be resourceful in identifying possible = candidates for these
positions, as developing our talent is a very = crucial requirement for
the IETF.  Also, please give serious = consideration to accepting nominations
you receive.

The = summaries of the desired expertise for the positions, developed by = the
respective bodies, are found = at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In = addition to nominations, the Nomcom seeks community input on
the = positions themselves.  We need and welcome the community's
views = and input on the jobs within each organization. If you
have ideas on = the positions' responsibilities (more, less,
different), please let = us know.  You can send us email about this to
nomcom13 at = ietf.org, and we will use this feedback actively.

Thank you for = your help in nominating a great pool of strong and = interesting
nominees!



__________________________________= _____________
RAI mailing = list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

= --Apple-Mail=_976302EF-32B0-4CEC-9808-E22DAE128628-- From henry.lum@genesyslab.com Tue Oct 15 20:06:18 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 0AC8711E80EA for ; Tue, 15 Oct 2013 20:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, URI_NOVOWEL=0.5] 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 68MOiruNjNFb for ; Tue, 15 Oct 2013 20:06:13 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5521F9DB8 for ; Tue, 15 Oct 2013 20:05:56 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Tue, 15 Oct 2013 23:05:50 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 20:05:46 -0700 From: Henry Lum To: "Charles Eckel (eckelcu)" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-protocol-10 Thread-Index: Ac6tNc3U21dTN5ARRzalEAmqIGrqxABdagAAAcZ1RIADpKMgUA== Date: Wed, 16 Oct 2013 03:05:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.0.219.108] Content-ID: MIME-Version: 1.0 X-MC-Unique: 113101523055004801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 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: Wed, 16 Oct 2013 03:06:18 -0000 SGkgUGF1bCAtIFNvcnJ5IEkgaGF2ZSBiZWVuIHJlYWxseSBiZWhpbmQgaW4gdXBkYXRpbmcgdGhl IGRyYWZ0IHRvDQppbmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzLiBJJ2xsIGhhdmUgYW4gdXBkYXRl IHRoaXMgd2Vlay4NCg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQoNCg0KSGVucnkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KQ2hhcmxl cyBFY2tlbCAoZWNrZWxjdSkNClNlbnQ6IFNlcHRlbWJlci0xOS0xMyA2OjUwIFBNDQpUbzogUGF1 bCBLeXppdmF0OyBzaXByZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwcmVjXSBXR0xDIG9u IGRyYWZ0LWlldGYtc2lwcmVjLXByb3RvY29sLTEwDQoNCkhpIFBhdWwsDQoNCkkgYXBwcmVjaWF0 ZSByZXZpZXcgY2FyZWZ1bCByZXZpZXcgb2YgdGhlIGRyYWZ0IGluIGl0cyBlbnRpcmV0eS4gUGxl YXNlDQpzZWUgY29tbWVudHMgaW5saW5lLg0KDQpPbiA5LzEwLzEzIDI6NTcgUE0sICJQYXVsIEt5 eml2YXQiIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KDQo+SSBoYWRuJ3QgcmVhZCB0 aGlzIGFsbCB0aGUgd2F5IHRocm91Z2ggZm9yIGEgbG9uZyB0aW1lLiAoSSd2ZSBqdXN0IGJlZW4N Cj5sb29raW5nIGF0IHRoZSBkaWZmcy4pIEl0IGlzIGluc3RydWN0aXZlIHRvIHJlYWQgaXQgYWxs LiBJIGZvdW5kIGEgbG90DQo+b2YgcmVsYXRpdmVseSBtaW5vciBzdHVmZiwgYW5kIG9uZSB0aGlu ZyB0aGF0IGlzIGdvaW5nIHRvIHJlcXVpcmUgbW9yZQ0KPnRob3VnaHQgYW5kIGRpc2N1c3Npb24u DQo+DQo+TWFueSBwbGFjZXMgY29udGFpbmluZyBBQk5GOg0KPg0KPlRoZSBvcGVyYXRvciAiLz0i IGlzIGJlaW5nIHVzZWQsIGJ1dCB0aGUgY29ycmVjdCBvcGVyYXRvciBpcyAiPS8iLg0KPlRoaXMg c3VnZ2VzdHMgdGhhdCBhIHN5bnRheCB2ZXJpZmljYXRpb24gb2YgdGhlIEFCTkYgaXMgY2FsbGVk IGZvci4NCj5UaGVyZSBpcyBhIHRvb2wgZm9yIHRoYXQuIEJ1dCB0byBkbyBpdCByaWdodCByZXF1 aXJlcyBleHRyYWN0aW5nIGFsbCB0aGUNCj5BQk5GLCBtZXJnaW5nIHdpdGggdGhlIHJlZmVyZW5j ZWQgQUJORiwgYW5kIHRoZW4gcnVubmluZyB0aGUgdG9vbC4NCg0KU291bmRzIHdvcnRod2hpbGUu IEkgZGlkIG5vdCBhZGQgdGhlIEFCTkYgYW5kIEknbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUNCnRv b2wuIEFueSB2b2x1bnRlZXJzPw0KDQpbaGx1bV0gSSdsbCB3b3JrIG9uIHJ1bm5pbmcgYSB0b29s IGFnYWluc3QgdGhlIEFCTkYuDQoNCj4NCj5UaGUgcmVtYWluaW5nIGNvbW1lbnRzIGZvbGxvdyB0 aGUgb3JkZXIgb2YgdGV4dCBpbiB0aGUgZG9jdW1lbnQuDQo+DQo+U2VjdGlvbiA1Og0KPg0KPiAg ICBTZWN0aW9uIDYgZGVzY3JpYmVzIFNJUCB0aGUgaGFuZGxpbmcgaW4gYSByZWNvcmRpbmcgc2Vz c2lvbiBiZXR3ZWVuIGENCj4gICAgU1JDIGFuZCBhIFNSUywgYW5kIHRoZSBwcm9jZWR1cmVzIGZv ciByZWNvcmRpbmctYXdhcmUgdXNlciBhZ2VudHMNCj4gICAgcGFydGljaXBhdGluZyBpbiBhIENT Lg0KPg0KPkkgY2FuJ3QgcGFyc2UgdGhlIGJlZ2lubmluZyBvZiB0aGlzIHNlbnRlbmNlLiBJIHRo aW5rIHlvdSBtaWdodCBtZWFuOg0KPg0KPiAgICBTZWN0aW9uIDYgZGVzY3JpYmVzIHRoZSBTSVAg aGFuZGxpbmcgaW4gYSByZWNvcmRpbmcgc2Vzc2lvbiBiZXR3ZWVuDQo+ICAgIGEgU1JDIGFuZCBh IFNSUywgLi4uDQoNCkhvdyBhYm91dCAixaAgZGVzY3JpYmVzIHRoZSBTSVAgY29tbXVuaWNhdGlv biBpbiBhIHJlY29yZGluZyDFoCINCg0KW2hsdW1dIHdpbGwgZml4IHRoaXMuDQoNCj4NCj5TZWN0 aW9uIDYuMS4xLjE6DQo+DQo+ICAgIEluIGFkZGl0aW9uLCB3aGVuIGFuIFNSQyBzZW5kcyBhIFJF R0lTVEVSIHJlcXVlc3QNCj4gICAgdG8gYSByZWdpc3RyYXIsIHRoZSBTUkMgTVVTVCBpbmNsdWRl IHRoZSAnK3NpcC5zcmMnIGZlYXR1cmUgdGFnIHRvDQo+ICAgIGluZGljYXRlIHRoZSB0aGF0IGl0 IGlzIGEgU1JDLg0KPg0KPlRoaXMgY291bGQgYmUgbWlzaW50ZXJwcmV0ZWQuIEFuZCBJJ20gbm90 IHN1cmUgaXQgc2hvdWxkIGFsd2F5cyBiZSB0cnVlLg0KPg0KPkNvbnNpZGVyIGFuIG9yZGluYXJ5 IFVBIHRoYXQgc29tZXRpbWVzIG9yIGFsd2F5cyBhY3RzIGFzIGFuIFNSQyB0bw0KPnJlY29yZCBp dHMgb3duIGNhbGxzLiBXaHkgd291bGQgaXQgd2FudCB0byBpbmRpY2F0ZSB0aGlzIHRvIGEgcmVn aXN0cmFyLg0KPlRoYXQgbWlnaHQgYmUgYSBnb29kIHRoaW5nLCBpZiBhIGNhbGxlciB3YW50cyB0 byB1c2UgY2FsbGVycHJlZnMgdG8NCj5zZWxlY3QgYSBjYWxsZWUgVUEgdGhhdCBjYW4gcmVjb3Jk IGNhbGxzLiBCdXQgdGhhdCBpcyBhbiBvZGQgdGhpbmcgdG8gZG8uDQo+DQo+SXQgY291bGQgYmUg YSBnb29kIHRoaW5nIGlmIHRoZXJlIGlzIGEgcG9vbCBvZiBCMkJVQXMgdGhhdCBhcmUNCj5yZWdp c3RlcmVkIHRvIGEgY29tbW9uIEFPUi4gSXQgd291bGQgYWxsb3cgcmVjcnVpdGluZyBvbmUgYnkg c2VuZGluZyBhbg0KPklOVklURSB0byBpdC4gQnV0IHRoaXMgaXMgYWxzbyB2ZXJ5IG9ic2N1cmUg dXNhZ2UuIE5vcm1hbGx5IEIyQlVBcyBhcmUNCj5zZWxlY3RlZCBtb3JlIG92ZXJ0bHksIGFuZCBu b3QgYnkgdGhlIFVBQy4NCj4NCj5JdHMgZXNwZWNpYWxseSBiYWQgaWYgdGhpcyBpcyB0YWtlbiBs aXRlcmFsbHkgYnkgYSBib3ggdGhhdCBpcyBkb24ndA0KPnJlZ2lzdHJhdGlvbnMgb2YgY29udGFj dCBVUklzIG90aGVyIHRoYW4gaXRzIG93bi4gRm9yIGluc3RhbmNlLCBhIFBCWA0KPkIyQlVBIGJv eCB0aGF0IGlzIGFuIFNSQywgYnV0IHRoYXQgYWxzbyByZWdpc3RlcnMgY29udGFjdCBVUklzIG9u IGJlaGFsZg0KPm9mIGl0cyBlbmRwb2ludHMuIEl0IHdvdWxkIG5vdCB3YW50IHRvIGRvIHRoaXMg b24gYmVoYWxmIG9mIHRob3NlDQo+ZW5kcG9pbnRzLg0KPg0KPlNvIGNhbiBzb21lb25lIHJlZnJl c2ggbXkgbWVtb3J5IGFib3V0IHdoeSB0aGlzIGlzIGEgZ29vZCB0aGluZz8NCg0KU29ycnksIG5v dCBzdXJlLiBTZWVtcyBpdCBjb3VsZCBiZSB1c2VmdWwgaW4gc29tZSBjYXNlcywgYnV0IE1BWSBz ZWVtcw0KbW9yZSBhcHByb3ByaWF0ZSB0aGFuIE1VU1QuDQoNCj4NCj5JZiB0aGlzIGlzIHRvIGJl IGtlcHQsIHRoZW4gaXQgd291bGQgYmUgYmV0dGVyIGlmIGl0IGlzIHdvcmRlZCBhczoNCj4NCj4g ICAgV2hlbiB0aGUgVVJJIG9mIGFuIFNSQyBpcyBpbmNsdWRlZCBpbiBhIFJFR0lTVEVSIHJlcXVl c3QgdG8gYQ0KPiAgICByZWdpc3RyYXIsIHRoZW4gdGhlICcrc2lwLnNyYycgZmVhdHVyZSB0YWcg U0hPVUxEIGJlIGluY2x1ZGVkIGluIHRoZQ0KPiAgICBjb250YWN0IFVSSSBmb3IgdGhlIFNSQy4N Cg0KRmluZSBieSBtZSwgYnV0IHVubGVzcyBzb21lb25lIGtub3dzIHdoeSBpdCBzaG91bGQgYmUg c3Ryb25nZXIsIE1BWSBzZWVtcw0KbW9yZSBhcHByb3ByaWF0ZSB0byBtZS4NCg0KW2hsdW1dIEkg dGhpbmsgdGhlIHN0cmVuZ3RoIG9mIHRoZSB3b3JkaW5nIGZvciByZWdpc3RyYXRpb24gYXBwbGll cyBtb3JlDQpmb3IgYW4gU1JTIHNpbmNlIHdlIG5lZWQgYW4gU1JDIHRvIGZpbmQgd2hlcmUgdGhl IFNSUyBpcywgYnV0IEkgYWdyZWUgdGhhdA0KVUFzIHRoYXQgaGF2ZSBtdWx0aXBsZSBkdXRpZXMg dXNpbmcgdGhlIHNhbWUgQU9SIHNob3VsZCBub3QgYmUgbGltaXRlZCB0bw0KYWx3YXlzIGluY2x1 ZGUgdGhpcyB0YWcuIEkgd2lsbCBjaGFuZ2UgaXQgdG8gTUFZIGZvciBTUkMgYW5kIFNIT1VMRCBm b3INClNSUy4NCg0KPg0KPlNlY3Rpb24gNi4yOg0KPg0KPlNpbWlsYXIgaXNzdWUgdG8gdGhlIG9u ZSBhYm92ZSBmb3Igc2VjdGlvbiA2LjEuMS4xLg0KPg0KPiAgICBJbiBhZGRpdGlvbiwgd2hlbg0K PiAgICBhbiBTUlMgc2VuZHMgYSBSRUdJU1RFUiByZXF1ZXN0IHRvIGEgcmVnaXN0cmFyLCB0aGUg U1JTIE1VU1QgaW5jbHVkZQ0KPiAgICB0aGUgJytzaXAuc3JzJyBmZWF0dXJlIHRhZyB0byBpbmRp Y2F0ZSB0aGF0IGl0IGlzIGEgU1JTLg0KPg0KPkF0IGxlYXN0IGl0IGlzIG1vcmUgbGlrZWx5IHRo YXQgYW4gU1JDIG1pZ2h0IGJlIHNlbmRpbmcgYW4gSU5WSVRFIHRvIGFuDQo+QU9SIGluIG9yZGVy IHRvIHJlYWNoIGFuIFNSUywgc28gdGhpcyBtaWdodCBoYXZlIHNvbWUgdXRpbGl0eS4gKEJ1dA0K PndvdWxkIGFuIEFPUiB1c2VkIHRvIGRlc2NyaWJlIFNSU3MgaGF2ZSBhbnkgcmVnaXN0cmF0aW9u cyBmb3Igbm9uLVNSU3M/DQo+QW5kIHNvbWUgb2YgdGhlIHByb2JsZW0gY2FzZXMgSSBtZW50aW9u ZWQgcmUgU1JDcyBhcmUgbGVzcyBsaWtlbHkgZm9yDQo+U1JTcy4gQnV0IEkgc3RpbGwgcmVjb21t ZW5kIHRoZSBhbmFsb2dvdXMgdGV4dCBjaGFuZ2UgaGVyZToNCj4NCj4gICAgV2hlbiB0aGUgVVJJ IG9mIGFuIFNSUyBpcyBpbmNsdWRlZCBpbiBhIFJFR0lTVEVSIHJlcXVlc3QgdG8gYQ0KPiAgICBy ZWdpc3RyYXIsIHRoZW4gdGhlICcrc2lwLnNycycgZmVhdHVyZSB0YWcgU0hPVUxEIGJlIGluY2x1 ZGVkIGluIHRoZQ0KPiAgICBjb250YWN0IFVSSSBmb3IgdGhlIFNSUy4NCg0KV29ya3MgZm9yIG1l Lg0KDQoNCj4NCj5TZWN0aW9uIDYuMzoNCj4NCj4gICAgQSByZWNvcmRpbmctYXdhcmUgVUEgTVVT VCBiZSBwcmVwYXJlZCB0byBwcm92aWRlIHJlY29yZGluZyBpbmRpY2F0aW9uDQo+ICAgIHRvIHRo ZSBlbmQgdXNlciB0aHJvdWdoIGFuIGFwcHJvcHJpYXRlIHVzZXIgaW50ZXJmYWNlIGFuIGluZGlj YXRpb24NCj4gICAgd2hldGhlciByZWNvcmRpbmcgaXMgb24sIG9mZiwgb3IgcGF1c2VkIGZvciBl YWNoIG1lZGl1bS4NCj4NCj5JIGNhbid0IHBhcnNlIHRoaXMgc2VudGVuY2UuIEhvdyBhYm91dDoN Cj4NCj4gICAgQSByZWNvcmRpbmctYXdhcmUgVUEgTVVTVCBiZSBwcmVwYXJlZCB0byBwcm92aWRl IGEgcmVjb3JkaW5nDQo+ICAgIGluZGljYXRpb24gdG8gdGhlIGVuZCB1c2VyIHRocm91Z2ggYW4g YXBwcm9wcmlhdGUgdXNlciBpbnRlcmZhY2UsDQo+ICAgIGluZGljYXRpbmcgd2hldGhlciByZWNv cmRpbmcgaXMgb24sIG9mZiwgb3IgcGF1c2VkIGZvciBlYWNoIG1lZGl1bS4NCg0KU291bmRzIGdv b2QuDQoNCltobHVtXSBnb29kIGZvciBtZS4gdGhhbmtzDQoNCj4NCj5TZWN0aW9uIDcuMS4xLjE6 DQo+DQo+VGhlIGZvbGxvd2luZyBpcyBzbGlnaHRseSBhbWJpZ3VvdXM6DQo+DQo+ICAgIE5vdGUg dGhhdCBhIENTDQo+ICAgIGl0c2VsZiBtYXkgY2hhbmdlIHRoZSBtZWRpYSBzdHJlYW0gZGlyZWN0 aW9uIGJ5IHVwZGF0aW5nIHRoZSBTRFAsIGZvcg0KPiAgICBleGFtcGxlLCBieSBzZXR0aW5nIGE9 aW5hY3RpdmUgZm9yIFNEUCBob2xkLiAgTWVkaWEgc3RyZWFtIGRpcmVjdGlvbg0KPiAgICBjaGFu Z2VzIGluIENTIGFyZSBjb252ZXllZCBpbiB0aGUgbWV0YWRhdGEgYnkgdGhlIFNSQy4gIFRoZSBT UkMgTVVTVA0KPiAgICBOT1QgbW9kaWZ5IHRoZSBtZWRpYSBzdHJlYW0gd2l0aCBhPWluYWN0aXZl IGZvciBTRFAgaG9sZCBvbiB0aGUgQ1MNCj4gICAgc2luY2UgdGhpcyBvcGVyYXRpb24gaXMgcmVz ZXJ2ZWQgZm9yIHBhdXNpbmcgdGhlIFJTIG1lZGlhLCBob3dldmVyLA0KPiAgICBhbiBTUkMgY2Fu IGhhdmUgYSBsb2NhbCBwb2xpY3kgdG8gcGF1c2UgdGhlIFJTIG1lZGlhIHdoZW4gdGhlIENTIGlz DQo+ICAgIHBsYWNlZCBvbiBob2xkLg0KPg0KPkluIHRoZSBsYXN0IHNlbnRlbmNlIGFib3ZlLCBp dCBpc24ndCBjbGVhciB3aGljaCBtZWRpYSBzdHJlYW0gaXMgYmVpbmcNCj5yZWZlcmVuY2VkIGlu ICJUaGUgU1JDIE1VU1QgTk9UIG1vZGlmeSB0aGUgbWVkaWEgc3RyZWFtIi4gU28gSSBzdWdnZXN0 DQo+Y2hhbmdpbmcgdGhpcyB0bzoNCj4NCj4gICAgVGhlIFNSQyBNVVNUDQo+ICAgIE5PVCBtb2Rp ZnkgdGhlIFJTIG1lZGlhIHN0cmVhbSB3aXRoIGE9aW5hY3RpdmUgZm9yIFNEUCBob2xkIG9uIHRo ZSBDUw0KPiAgICBzaW5jZSB0aGlzIG9wZXJhdGlvbiBpcyByZXNlcnZlZCBmb3IgcGF1c2luZyB0 aGUgUlMgbWVkaWEsIC4uLg0KDQoNClllcywgSSB0aGF0IGlzIGhvdyBtb3JlIGNsZWFyLg0KDQpb aGx1bV0gd2lsbCBmaXgNCiANCj4NCj5TZWN0aW9uIDcuMS4zOg0KPg0KPiAgICBXaGVuIHRoZSBT UkMgcmVjZWl2ZXMgdGhlIGE9cmVjb3JkcHJlZiBTRFAgaW4gYW4gU0RQIG9mZmVyIG9yIGFuc3dl ciwNCj4gICAgdGhlIFNSQyBjaG9vc2VzIHRvIGhvbm9yIHRoZSBwcmVmZXJlbmNlIHRvIHJlY29y ZCBiYXNlZCBvbiBsb2NhbA0KPiAgICBwb2xpY3kgYXQgdGhlIFNSQy4gIFdoZXRoZXIgb3Igbm90 IHRoZSBTUkMgaG9ub3JzIHRoZSByZWNvcmRpbmcNCj4gICAgcHJlZmVyZW5jZSwgdGhlIFNSQyBN VVNUIHVwZGF0ZSB0aGUgYT1yZWNvcmQgYXR0cmlidXRlIHRvIGluZGljYXRlDQo+ICAgIHRoZSBj dXJyZW50IHN0YXRlIG9mIHRoZSByZWNvcmRpbmcgKG9uL29mZi9wYXVzZWQpLg0KPg0KPkl0cyB1 bmNsZWFyIHRvIG1lIHdoYXQgdGhlIE1VU1QgbWVhbnMuIFRoZSBmb2xsb3dpbmcgYXJlIHNvbWUg dGhpbmdzDQo+dGhhdCBtaWdodCBiZSBkb25lOg0KPg0KPi0gaWYgdGhlIGE9cmVjb3JkcHJlZiBp cyByZWNlaXZlZCBpbiBhbiBvZmZlciwgcHV0IHRoZSByZXN1bHRpbmcNCj4gICBhPXJlY29yZCBz ZXR0aW5nIGluIHRoZSBhbnN3ZXIuDQo+DQo+LSBpZiB0aGUgYT1yZWNvcmRwcmVmIGlzIHJlY2Vp dmVkIGluIGFuIG9mZmVyIG9yIGFuc3dlciwgc2VuZCBhIG5ldw0KPiAgIG9mZmVyICpzb29uKiB0 byBhbGwgQ1MgbGVncyB3aXRoIHRoZSByZXN1bHRpbmcgYT1yZWNvcmQuDQo+DQo+LSBzYW1lIGFz IGFib3ZlLiBVbmNvbmRpdGlvbmFsbHkgc2VuZCB0byBsZWcgdGhhdCBjaGFuZ2VkIGE9cmVjb3Jk cHJlZiwNCj4gICBidXQgZG9uJ3Qgc2VuZCBhZ2FpbiB0byBvdGhlciBsZWdzIGlmIHJlY29yZGlu ZyBzdGF0ZSByZW1haW5zDQo+ICAgYXMgaXQgd2FzLg0KPg0KPkFsc28sIElTVE0gdGhhdCBvbmNl IGEgVUEgaGFzIHB1dCBhPXJlY29yZHByZWYgaW4gaXRzIFNEUCwgaXQgd2lsbA0KPnByb2JhYmx5 IGxlYXZlIGl0IHRoZXJlLCB1bmNoYW5nZWQsIHRocm91Z2ggc3Vic2VxdWVudCBPL0EgY3ljbGVz LiBUaGF0DQo+bWVhbnMsIGZvciB0aGUgYWJvdmUsIGV2ZXJ5IHRpbWUgaXQgc2VuZHMgYW4gb2Zm ZXIgb3IgYW5zd2VyLCBpdCB3aWxsIGJlDQo+c2VuZGluZyBhPXJlY29yZHByZWYgYWdhaW4uIEl0 IHdvdWxkIGJlIHVuZm9ydHVuYXRlIGlmIHRoYXQgZm9yY2VkIHRoZQ0KPlNSQyB0byBzZW5kICph bm90aGVyKiBvZmZlci4gKEl0IGNvdWxkIGxlYWQgdG8gYW4gaW5maW5pdGUgby9hIGxvb3AuKQ0K Pg0KPkkgKmRvbid0KiB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byB0cmVhdCB0aGlzIGFzIGEg b25lLXRpbWUgcmVxdWVzdC4NCj4NCj5TbyBJIHN1Z2dlc3QgdGhhdCBib3RoIGE9cmVjb3JkcHJl ZiBhbmQgYT1yZWNvcmQgc2hvdWxkIGJlIHZpZXdlZCBhcw0KPipzdGF0ZSogdGhhdCBpcyBhbm5v dW5jZWQgaW4gZXZlcnkgb2ZmZXIgb3IgYW5zd2VyLiBBcyBsb25nIGFzIHRoZSBzdGF0ZQ0KPnJl bWFpbnMgdW5jaGFuZ2VkLCBpdCBpcyBqdXN0IHB1dCBpbnRvIGVhY2ggb2ZmZXIgb3IgYW5zd2Vy IHdoZW4gdGhleQ0KPmFyZSByZXF1aXJlZCBmb3Igb3RoZXIgcHVycG9zZXMuIFdoZW4gb25lIG9m IHRoZW0gY2hhbmdlcyBzdGF0ZSwgdGhlbiBhbg0KPm9mZmVyIG9yIGFuc3dlciBtdXN0IGJlIHNl bnQgYXNhcCB0byBhbm5vdW5jZSB0aGUgY2hhbmdlLg0KDQoNCldvcmtzIGZvciBtZS4NCg0KW2hs dW1dIEkgYWdyZWUgdGhlIHdvcmRpbmcgaXNuJ3QgY2xlYXIgaGVyZTsgdGhlIGludGVudGlvbiBp cyBub3QgdG8gZm9yY2UNCmFub3RoZXIgb2ZmZXIvYW5zd2VyIGV2ZXJ5IHRpbWUgYSByZWNvcmRw cmVmIGFwcGVhcnMuIExldCdzIHRyeSByZXdvcmRpbmcNCjcuMS4zOg0KDQogICBXaGVuIHRoZSBT UkMgcmVjZWl2ZXMgdGhlIGE9cmVjb3JkcHJlZiBTRFAgaW4gYW4gU0RQIG9mZmVyIG9yIGFuc3dl ciwNCiAgIHRoZSBTUkMgY2hvb3NlcyB0byBob25vciB0aGUgcHJlZmVyZW5jZSB0byByZWNvcmQg YmFzZWQgb24gbG9jYWwNCiAgIHBvbGljeSBhdCB0aGUgU1JDLiBJZiB0aGUgU1JDIG1ha2VzIGEg Y2hhbmdlIGluIHJlY29yZGluZyBzdGF0ZSwgdGhlbg0KICAgdGhlIFNSQyByZXBvcnRzIHRoZSBy ZWNvcmRpbmcgc3RhdGUgaW4gdGhlIGE9cmVjb3JkIGF0dHJpYnV0ZSBpbiB0aGUNCiAgIFNEUCBh bnN3ZXIgb3IgaW4gYSBzdWJzZXF1ZW50IFNEUCBvZmZlci9hbnN3ZXIuDQogDQoNCg0KPg0KPlNl Y3Rpb24gNy4zOiAoVEhFIEJJRyBJU1NVRSBJUyBIRVJFKQ0KPg0KPlRoaXMgc2VjdGlvbiBicmlu Z3MgdXAgdGhlIHNpdHVhdGlvbiB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgU1JDcyBpbg0KPnRo ZSBDUy4gVGhhdCBwcmVzZW50cyBzb21lIG90aGVyIGlzc3VlcyB0aGF0IEkgZG9uJ3QgdGhpbmsg d2UgaGF2ZQ0KPmNvbnNpZGVyZWQuIFN1cHBvc2Ugd2UgaGF2ZToNCj4NCj5VQTEgLS0tLS0gU1JD MSAtLS0tIEIyQlVBIC0tLS0gU1JDMiAtLS0tLSBVQTINCj4NCj4oVUExLCBCMkJVQSwgYW5kIFVB MiBhbGwgaW5kaWNhdGUgdGhleSBhcmUgcmVjb3JkaW5nIGF3YXJlLikNCj4NCj5Ob3cgc3VwcG9z ZSBTUkMxIGlzIHJlY29yZGluZywgYW5kIFNSQzIgaXMgbm90IHJlY29yZGluZy4gV2hhdCBzb3J0 IG9mDQo+cmVjb3JkaW5nIGluZGljYXRpb25zIGRvIHdlIGhhdmUgaW4gdGhlIENTIHNpZ25hbGlu Zz8NCj4NCj5Jbml0aWFsbHkNCj4tIFNSQzEgd291bGQgc2VuZCBhPXJlY29yZGluZzpvbiB0byBV QTEgYW5kIEIyQlVBDQo+LSBTUkMyIHdvdWxkIHNlbmQgYT1yZWNvcmRpbmc6b2ZmIHRvIFVBMiBh bmQgQjJCVUENCj4tIEIyQlVBIHdvdWxkIHByb3BhZ2F0ZSBhPXJlY29yZGluZzpvbiB0byBTUkMy DQo+ICAgYW5kIHByb3BhZ2F0ZSBhPXJlY29yZGluZzpvZmYgdG8gU1JDMSA/Pz8NCj4NCj5UaGVu LCB3aGF0IGRvIFNSQzEgYW5kIFNSQzIgZG8gd2hlbiB0aGV5IHJlY2VpdmUgdGhlc2UgdmFsdWVz IGZyb20gdGhlDQo+QjJCVUE/DQoNCltobHVtXSBJIHRoaW5rIHRoaXMgaXMgcmVhbGx5IHVwIHRv IHRoZSBCMkJVQSB0byBkZWNpZGUgd2hhdCByZWNvcmRpbmcNCmluZGljYXRvciBhbmQgcmVjb3Jk aW5nIHByZWZlcmVuY2UgdG8gZXhwb3NlIHRvIFNSQzIgaWYgU1JDMSBpcyByZWNvcmRpbmcNCnRo ZSBjYWxsLiBJIGRvbid0IHRoaW5rIHdlIGNhbiByZWFsbHkgbWFuZGF0ZSBhIHNwZWNpZmljIGJl aGF2aW91ciBmb3INCkIyQlVBLiBMZXQncyBzYXkgQjJCVUEgZGVjaWRlcyB0byBwYXNzIG9uIGE6 cmVjb3JkPW9uIHRvIFNSQzIsIFNSQzIgbWF5DQpzdGlsbCBkZWNpZGUgdG8gcmVjb3JkIHRoZSBj YWxsIGFnYWluIHNpbmNlIGl0IGlzIGFuIFNSQyBhbmQgaXQgc2hvdWxkIGJlDQphYmxlIHRvIGRv IHNvLiBJZiB0aGUgQjJCVUEgY2hvb3NlcyBub3Qgbm90IHBhc3Mgb24gdGhpcyBpbmRpY2F0b3Ig dGhlbg0KdGhlcmUgaXMgbm90aGluZyBTUkMyIGFuZCBVQTIgY2FuIGRvIHRvIGtub3cgdGhhdCB0 aGUgY2FsbCBpcyBhY3R1YWxseQ0KYmVpbmcgcmVjb3JkZWQuDQoNCklmIHdlIGxvb2sgYXQgYSBz aW1wbGUgY2FzZSB3aGVyZSB0d28gVUEgaW4gYSBDUyBhcmUgYWxzbyBTUkMgYW5kIGFyZSBib3Ro DQpyZWNvcmRpbmcgdGhlIGNhbGwsIHRoZW4gdGhlIFNEUCBvZmZlci9hbnN3ZXIgc2VudCBieSBi b3RoIFVBIHdpbGwgaW5jbHVkZQ0KYT1yZWNvcmQ6b24uIFRoZSBVQSB0aGF0IHJlY2VpdmVzIHRo ZSBpbml0aWFsIElOVklURSB3aXRoIGE9cmVjb3JkOm9uIG1heQ0Kc3RpbGwgZGVjaWRlIHRvIHJl Y29yZCB0aGUgY2FsbCBldmVuIGlmIGFub3RoZXIgU1JDIGlzIGFscmVhZHkgcmVjb3JkaW5nDQp0 aGUgY2FsbC4gSSBkb24ndCBzZWUgYSBjb25mbGljdCB3aXRoIHRoaXMuDQoNCg0KPg0KPlRoaXMg aXMgYWN0dWFsbHkgcXVpdGUgYSBtZXNzLiBJIHRoaW5rICpzb21lYm9keSogbmVlZHMgdG8ga2Vl cCBhIGNvdW50DQo+b2YgcmVjb3JkaW5ncy4gRWl0aGVyIHdlIHB1dCB0aGUgY291bnQgaW50byB0 aGUgYXR0cmlidXRlcywgb3Igd2UgbWFrZQ0KPnNvbWUgb2YgdGhlIGNvbXBvbmVudHMga2VlcCB0 aGUgY291bnQuIFRoZSBsYXR0ZXIgbWlnaHQgYmUgZWFzaWVyLiBJDQo+dGhpbmsgb25seSByZWNv cmRpbmcgYXdhcmUgQjJCVUFzIGFuZCBjb25mZXJlbmNlIGZvY2kgKGluY2x1ZGluZyB0aG9zZQ0K PnRoYXQgYXJlIFNSQ3MpIHdvdWxkIG5lZWQgdG8gZG8gdGhpcy4gVGhleSB3b3VsZCBuZWVkIHRv IGtlZXAgYSBjb3VudA0KPm92ZXIgYWxsIHRoZWlyIGxlZ3MuIChBbmQgYW4gU1JDIEIyQlVBIHdv dWxkIGluY2x1ZGUgaXRzIG93biByZWNvcmRpbmcNCj5pbiB0aGlzIGNvdW50LikgV2hlbiB0aGUg Y291bnQgaXMgemVybyB0aGUgcmVjb3JkaW5nIHN0YXRlIGlzIG9mZiwgZWxzZQ0KPml0IGlzIG9u LiAoTmVlZCBtb3JlIGFuYWx5c2lzIGZvciB3aGF0IHRvIGRvIHdpdGggcGF1c2UuKQ0KDQpbaGx1 bV0gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIG5lZWQgdG8ga2VlcCB0cmFjayBvZiB0aGUgbnVt YmVyIG9mDQpyZWNvcmRpbmdzIGluIHRoZSBjYWxsIGNoYWluLiBBbGwgYW4gZW5kLXVzZXIgbmVl ZCB0byBrbm93IGlzIHdoZXRoZXIgdGhlDQpjYWxsIGlzIGJlaW5nIHJlY29yZGVkIG9yIG5vdC4g SG93IG1hbnkgcmVjb3JkZXJzIGFyZSByZWNvcmRpbmcgdGhlIGNhbGwNCmlzIGlycmVsZXZhbnQg dG8gdGhlIHVzZXIuIElmIGFuIGVsZW1lbnQgaW4gdGhlIGNhbGwgY2hhaW4gaXMgYW4gU1JDIHRo YXQNCnJlY2VpdmVzIGFuIFNEUCBvZmZlciB3aXRoIGE9cmVjb3JkOm9mZiBidXQgdGhpcyBTUkMg aXMgc3RpbGwgcmVjb3JkaW5nDQp0aGUgY2FsbCwgdGhlIFNSQyBzaG91bGQgc3RpbGwgY29udmV5 IHRoYXQgdGhlIGNhbGwgaXMgYmVpbmcgcmVjb3JkZWQuDQoNCj4NCj5Tb21lIHNpbWlsYXIgdHJl YXRtZW50IGlzIHByb2JhYmx5IHJlcXVpcmVkIGZvciByZWNvcmRwcmVmLiBNeSBoZWFkDQo+aHVy dHMgbm93LCBzbyBJJ20gbm90IGRvaW5nIGl0IGhlcmUuDQoNCltobHVtXSByZWNvcmRwcmVmIGlz IGFjdHVhbGx5IHNpbWlsYXIgdG8gcmVjb3JkaW5nIGluZGljYXRvci4gTGV0J3Mgc2F5IGENCnVz ZXIgbmVlZHMgdG8gcGF1c2UgdGhlIHJlY29yZGluZywgdGhlIFVBIHNlbmRzIGFuIFNEUCBvZmZl ciB3aXRoDQpyZWNvcmRwcmVmPXBhdXNlLiBBcyBsb25nIGFzIHRoZSBjYWxsIGNoYWluIHBhc3Nl cyBvbiB0aGUgU0RQIG9mZmVyIHdpdGgNCnRoZSBzYW1lIHByZWZlcmVuY2UgYWxsIHRoZSB3YXkg dGhyb3VnaCwgdGhlIGFsbCBTUkNzIGluIHRoZSBjYWxsIGNoYWluDQp3b3VsZCBlbmQgdXAgaG9u b3JpbmcgdGhhdCByZXF1ZXN0IHRvIHBhdXNlIHRoZSByZWNvcmRpbmcuDQoNCg0KPg0KPkkgdGhp bmsgd2UgbmVlZCBzb21lIGxpc3QgZGlzY3Vzc2lvbiBvbiB0aGlzISBOb3RlIHRoYXQgdGhlIHNv bHV0aW9uIHRvDQo+dGhpcyB3aWxsIHByb2JhYmx5IGludmFsaWRhdGUgdGhlIHN1Z2dlc3Rpb24g SSBtYWRlIGZvciA3LjEuMy4NCg0KV2h5IG5vdCB0cmVhdCBlYWNoIGFzIGEgc2VwYXJhdGUgUlMs IHJlc3VsdGluZyBpbiBtdWx0aXBsZSByZWNvcmRpbmdzIG9mDQp0aGUgc2FtZSBDUy4gSWYgd2Ug YXJlIGFuIGVuZHBvaW50IGluIHN1Y2ggYSBDUywgeW91IG1heSByZWNlaXZlIGRpZmZlcmVudA0K cmVjb3JkaW5nIGluZGljYXRpb25zIGZyb20gZWFjaCBvZiB5b3VyIHBlZXJzIChpbiBhIHBlZXIg dG8gcGVlciBDUyksIG9yDQphbiBYT1Igb2YgdGhlIHJlY29yZGluZyBpbmRpY2F0aW9ucyBmcm9t IGFuIE1DVSAoaW4gYW4gTUNVIGhvc3RlZA0KY29uZmVyZW5jZSkuDQoNCj4NCj5TZWN0aW9uIDgu MS41LjE6DQo+DQo+RG8gd2Ugd2FudCB0byByZWZlcmVuY2UgdGhlIG5ldyBtZWNoYW5pc20gZm9y IGNob29zZWluZyBDTkFNRSB0aGF0IGhhcw0KPmJlZW4gcHJvcG9zZWQgYnkgRUtSPyAoSSBmb3Jn ZXQgdGhlIGRyYWZ0IG5hbWUsIG9yIGlmIGl0IGhhcyBiZWNvbWUgYW5kDQo+UkZDLikNCg0KSSB0 aGluayBzby4NCg0KPg0KPlNlY3Rpb24gOC4yOg0KPg0KPkZpcnN0IHBhcmFncmFwaDoNCj4NCj4g ICAgVGhlcmUgYXJlIG51bWVyb3VzIHdheXMgaW4gd2hpY2ggYW4gU1JDIG1heSBkbyB0aGlzIGlz LCBpbmNsdWRpbmcgYnV0DQo+ICAgIG5vdCBsaW1pdGVkIHRvLCBhcHBlYXJpbmcgYXMgYSBVQSB3 aXRoaW4gYSBDUywgb3IgYXMgYSBCMkJVQSBiZXR3ZWVuDQo+ICAgIFVBcyB3aXRoaW4gYSBDUy4N Cj4NCj5zL2RvIHRoaXMgaXMvZG8gdGhpcy8NCg0KWWVwLg0KDQo+DQo+U2VjdGlvbiA4LjM6DQo+ DQo+ICAgIEFuIFNSQyBtYXkNCj4gICAgY2hvb3NlIHRvIHVzZSBvbmUgb3IgbW9yZSBvZiB0aGUg UlRQIHNlc3Npb24gdXNhZ2VzIHdpdGhpbiBhIHNpbmdsZQ0KPiAgICBSUy4gIEZvciB0aGUgcHVy cG9zZSBvZiBiYXNlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBTUkMgYW5kIFNSUywgYW4NCj4g ICAgU1JDIE1VU1Qgc3VwcG9ydCBzZXBhcmF0ZSBtLWxpbmVzIGluIFNEUCwgb25lIHBlciBDUyBt ZWRpYSBkaXJlY3Rpb24uDQo+DQo+SSBmaW5kIHRoZSBhYm92ZSBjb25mdXNpbmcuIChCdXQgbWF5 YmUganVzdCBiZWNhdXNlIEkgZG9uJ3QgdW5kZXJzdGFuZA0KPmVub3VnaCBhYm91dCBSVFAuKSBJ c24ndCB0aGUgU1JDIHRoZSBvbmUgdGhhdCBpcyBkZWNpZGluZyB3aGF0IHVzYWdlIHRvDQo+ZW1w bG95PyBJZiBzbywgYW5kIGlmIGl0IG11c3Qgc3VwcG9ydCBzZXBhcmF0ZSBtLWxpbmVzLCB0aGVu IHVuZGVyIHdoYXQNCj5jaXJjdW1zdGFuY2Ugd291bGQgaXQgZW1wbG95IGFueXRoaW5nIGVsc2U/ DQoNCkFuIFNSQyBjb3VsZCBtaXggYm90aCBkaXJlY3Rpb24gaW50byBhIHNpbmdsZSBtaXhlZCBz dHJlYW0uIElmIHRoZSBTUlMNCmRvZXMgbm90IHN1cHBvcnQgdGhpcywgaXQgY291bGQgZmFsbCBi YWNrIHRvIHNlcGFyYXRlIHN0cmVhbXMuDQoNCj4NCj5JcyB0aGUgaW50ZW5kZWQgdG8gYmUgZGV0 ZXJtaW5lZCBieSBjb25maWd1cmF0aW9uIGR1cmluZyBkZXBsb3ltZW50Pw0KPk9yIG15IG11bHRp cGxlIG8vYSBhdHRlbXB0cz8gT3IgYnkgQ0FQTkVHPyBPciB3aGF0Pw0KDQpjb25maWcgLSBwcm9i YWJseQ0KbXVsdGlwbGUgby9hIGF0dGVtcHRzIC0gcG90ZW50aWFsbHkNCkNBUE5FRyAtIGRvdWJ0 IGl0DQoNCg0KPg0KPlNlY3Rpb24gOC4zLjE6DQo+DQo+ICAgIEFkZGl0aW9uYWxseSwgdGhlIFNS QyBTSE9VTEQgbWFwIGVhY2gNCj4gICAgdW5pcXVlIGNvbWJpbmF0aW9uIG9mIENOQU1FL1NTUkMg d2l0aGluIHRoZSBDU3MgdG8gYSB1bmlxdWUgQ05BTUUvDQo+ICAgIFNTUkMgd2l0aGluIHRoZSBS Uy4NCj4NCj5Jc24ndCBpdCBvayB0byBtYXAgYm90aCBDTkFNRTEvU1NSQzEgYW5kIENOQU1FMS9T U1JDMiBpbiB0aGUgQ1MgdG8NCj5DTkFNRW4vU1NSQ24gaW4gdGhlIFJTPyBUaGUgYWJvdmUgc3Rh dGVtZW50IHNlZW1zIHRvIHN1Z2dlc3Qgbm90Lg0KDQpJdCBpcyBva2F5LCBidXQgdGhleSB0aGUg UlMgbG9vc2VzIHRoZSBhYmlsaXR5IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlDQp0d28uIElm IHR3byBDTkFNRS9TU1JDIGNvbWJpbmF0aW9ucyBhcmUgY29tYmluZWQgYnkgdGhlIFNSQywgdGhl IFNSUyB3aWxsDQpub3QgYmUgYWJsZSB0byBwdWxsIHRoZW0gYmFjayBhcGFydC4NCg0KPg0KPlNl Y3Rpb24gOC40Og0KPg0KPklJVUMsIG5vcm1hbCBkcmFmdCBzdHlsZSBpcyB0byBpbmRlbnQgbm90 ZXMgcmVsYXRpdmUgdG8gdGhlIHN1cnJvdW5kaW5nDQo+dGV4dC4NCg0KDQpPa2F5IHdpdGggbWUs IGJ1dCBwcm9iYWJseSBiZXR0ZXIgdG8gcmVwbGFjZSAiTm90ZSB0aGF0IHRoZXNlIMWgIiB3aXRo DQoiVGhlc2UgxaAiDQpbaGx1bV0gZml4ZWQuDQoNCj4NCj5TZWN0aW9uIDkuMToNCj4NCj4gICAg V2hlbiB0aGUgU1JDIHNlbmRzIGEgZnVsbCBtZXRhZGF0YSBzbmFwc2hvdCwgdGhlIFNSQyBNVVNU DQo+ICAgIHNlbmQgYW4gSU5WSVRFIG9yIGFuIFVQREFURSByZXF1ZXN0IC4uLiBBDQo+ICAgIHBh cnRpYWwgdXBkYXRlIHNlbnQgYnkgdGhlIFNSQyBjYW4gYmUgYW4gSU5WSVRFIHJlcXVlc3Qgb3Ig cmVzcG9uc2UNCj4gICAgd2l0aCBhbiBTRFAgb2ZmZXIsIG9yIGFuIElOVklURS9VUERBVEUgcmVx dWVzdCBvciByZXNwb25zZSBjb250YWluaW5nDQo+ICAgIGEgInJlY29yZGluZy1zZXNzaW9uIiBk aXNwb3NpdGlvbiwgb3IgYW4gSU5WSVRFIHJlcXVlc3QgY29udGFpbmluZw0KPiAgICBib3RoIGFu IFNEUCBvZmZlciBhbmQgdGhlICJyZWNvcmRpbmctc2Vzc2lvbiIgZGlzcG9zaXRpb24uDQo+DQo+ SSBmaW5kIHRoZSBhYm92ZSBjb25mdXNpbmcuDQo+DQo+Rm9yIG9uZSB0aGluZywgZGlzcG9zaXRp b24gaXMgYXNzb2NpYXRlZCB3aXRoIGEgYm9keSBwYXJ0LCBub3QgYQ0KPnJlcXVlc3QuIEEgcmVx dWVzdCBjYW4gaGF2ZSBtdWx0aXBsZSBib2R5IHBhcnRzLCBlYWNoIHdpdGggaXRzIG93bg0KPmRp c3Bvc2l0aW9uLiBPZmZlcnMgYW5kIGFuc3dlcnMgYXJlIGNhcnJpZWQgaW4gYm9keSBwYXJ0cyB3 aXRoDQo+ZGlzcG9zaXRpb24gInNlc3Npb24iLiAoSXRzIHRoZSBkZWZhdWx0LCBzbyB5b3UgZG9u J3Qgb2Z0ZW4gc2VlIGl0DQo+d3JpdHRlbi4pIFRoZXJlIGNvdWxkIGFsc28gYmUgb3RoZXIgYm9k eSBwYXJ0cy4gV2UgZG9uJ3QgY2FyZSBhYm91dA0KPnRob3NlIHNvIHdlIGlnbm9yZSB0aGVtLiBJ biBwcmluY2lwbGUgYSBnaXZlbiBib2R5IHBhcnQgd2l0aCBhDQo+cGFydGljdWxhciBkaXNwb3Np dGlvbiBtaWdodCBiZSB2YWxpZCB3aXRoIGFueSBvZiBhIHZhcmlldHkgb2YgY29udGVudA0KPnR5 cGVzLiBCdXQgaW4gcHJhY3RpY2UsIHNlc3Npb24gYWx3YXlzIGNvbnRhaW5zIGFwcGxpY2F0aW9u L3NkcCBhbmQNCj5yZWNvcmRpbmctc2Vzc2lvbiBhbHdheXMgY29udGFpbnMgYXBwbGljYXRpb24v cnMtbWV0YWRhdGEgb3INCj5hcHBsaWNhdGlvbi9ycy1tZXRhZGF0YS1yZXF1ZXN0LiBTbyB3ZSBj YW4gc2ltcGx5IHRhbGsgYWJvdXQgdGhlDQo+cG9zc2liaWxpdGllcyBpbiB0ZXJtcyBvZiB0aGUg Y29udGVudCB0eXBlcyBpdCBjb250YWlucy4gSW4gdGhlIGNhc2Ugb2YNCj5TRFAsIGl0IG1heSBi ZSBlaXRoZXIgYW4gb2ZmZXIgb3IgYW5zd2VyLiBUaGF0IGlzIG9ubHkgZGV0ZXJtaW5lZCBieQ0K PmNvbnRleHQgLSB5b3UgY2FudCB0ZWxsIGJ5IGxvb2tpbmcgYXQgYSBzaW5nbGUgbWVzc2FnZS4N Cj4NCj5BRkFJSyB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgdmFsaWQgc2lwIHNpZ25hbGluZyBwb3Nz aWJpbGl0aWVzIG9uIHRoZSBSUzoNCj4NCj4tIElOVklURSBieSBTUkM6ICAgb2ZmZXItc2RwLCBt ZXRhZGF0YQ0KPiAgIHJlc3BvbnNlIGJ5IFNSUzogYW5zd2VyLXNkcA0KPi0gSU5WSVRFIGJ5IFNS QzogICBvZmZlci1zZHANCj4gICByZXNwb25zZSBieSBTUlM6IGFuc3dlci1zZHANCj4tIElOVklU RSBieSBTUlM6DQo+ICAgcmVzcG9uc2UgYnkgU1JDOiBvZmZlci1zZHAsIG1ldGFkYXRhDQo+LSBJ TlZJVEUgYnkgU1JTOg0KPiAgIHJlc3BvbnNlIGJ5IFNSQzogb2ZmZXItc2RwDQo+LSBVUERBVEUg YnkgU1JDOiAgIG9mZmVyLXNkcCwgbWV0YWRhdGENCj4gICByZXNwb25zZSBieSBTUkM6IGFuc3dl ci1zZHANCj4tIFVQREFURSBieSBTUkM6ICAgb2ZmZXItc2RwDQo+ICAgcmVzcG9uc2UgYnkgU1JT OiBhbnN3ZXItc2RwDQo+LSBVUERBVEUgYnkgU1JTOg0KPiAgIHJlc3BvbnNlIGJ5IFNSQzoNCj4t IFVQREFURSBieSBTUlM6ICAgb2ZmZXItc2RwDQo+ICAgcmVzcG9uc2UgYnkgU1JDOiBhbnN3ZXIt c2RwDQo+LSBVUERBVEUgYnkgU1JTOiAgIG1ldGFkYXRhLXJlcXVlc3QNCj4gICByZXNwb25zZSBi eSBTUkM6DQo+DQo+T2YgdGhvc2UsIG9ubHkgdGhyZWUgY2FycnkgbWV0YWRhdGE6DQo+DQo+LSBJ TlZJVEUgYnkgU1JDOiAgIG9mZmVyLXNkcCwgbWV0YWRhdGENCj4tIElOVklURSBieSBTUlM6DQo+ ICAgcmVzcG9uc2UgYnkgU1JDOiBvZmZlci1zZHAsIG1ldGFkYXRhDQo+LSBVUERBVEUgYnkgU1JD OiAgIG9mZmVyLXNkcCwgbWV0YWRhdGENCj4NCj5UaGF0IGlzIGluZGVwZW5kZW50IG9mIHdoZXRo ZXIgdGhlIG1ldGFkYXRhIGlzIGEgc25hcHNob3Qgb3IgYSBwYXJ0aWFsLg0KPlRoZSBzcGVjaWFs IGNhc2UgZm9yIGEgc25hcHNob3QgcmVxdWVzdCBpczoNCj4NCj4tIFVQREFURSBieSBTUlM6ICAg bWV0YWRhdGEtcmVxdWVzdA0KPiAgIHJlc3BvbnNlIGJ5IFNSQzoNCj4NCj5hbmQgZm9sbG93ZWQg Ynkgb25lIG9mIHRoZSB0d28gYWJvdmUgaW5pdGlhdGVkIGJ5IHRoZSBTUkM6DQo+DQo+LSBJTlZJ VEUgYnkgU1JDOiAgIG9mZmVyLXNkcCwgbWV0YWRhdGENCj4tIFVQREFURSBieSBTUkM6ICAgb2Zm ZXItc2RwLCBtZXRhZGF0YQ0KPg0KPlNvIGhvdyB0byBzYXkgYWxsIHRoYXQgaW4gYSBjb21wcmVo ZW5zaWJsZSB3YXk/IEhvdyBhYm91dCByZXBsYWNpbmcgdGhhdA0KPmVudGlyZSBwYXJhZ3JhcGgg d2l0aCB0aGUgZm9sbG93aW5nOg0KPg0KPiJNZXRhZGF0YSBzZW50IGJ5IHRoZSBTUkMgY2FuIGJl IGNhdGVnb3JpemVkIGFzIGVpdGhlciBhIGZ1bGwgbWV0YWRhdGENCj5zbmFwc2hvdCBvciBwYXJ0 aWFsIHVwZGF0ZS4gIEEgZnVsbCBtZXRhZGF0YSBzbmFwc2hvdCBkZXNjcmliZXMgYWxsIHRoZQ0K PnJlY29yZGVkIHN0cmVhbXMgYW5kIGFsbCBtZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggdGhlIHJl Y29yZGluZyBzZXNzaW9uLg0KPlRoZSBTUkMgTUFZIHNlbmQgYSBmdWxsIG1ldGFkYXRhIHNuYXBz aG90IGF0IGFueSB0aW1lLiBUaGUgU1JDIE1BWSBzZW5kDQo+YSBwYXJ0aWFsIHVwZGF0ZSBpZiBh IGZ1bGwgbWV0YWRhdGEgc25hcHNob3QgaGFzIHByZXZpb3VzbHkgYmVlbiBzZW50Lg0KPklmIHRo ZSBTUkMgcmVjZWl2ZXMgYSBzbmFwc2hvdCByZXF1ZXN0IGZyb20gdGhlIFNSUywgdGhlbiBpdCBN VVNUDQo+aW1tZWRpYXRlbHkgc2VuZCBhIGZ1bGwgbWV0YWRhdGEgc25hcHNob3QuDQo+DQo+VGhl IFNSQyBNQVkgc2VuZCBtZXRhZGF0YSAoZWl0aGVyIGEgZnVsbCBtZXRhZGF0YSBzaGFwc2hvdCBv ciBhIHBhcnRpYWwNCj51cGRhdGUpIGluIGVpdGhlciBhbiBJTlZJVEUgcmVxdWVzdCwgYW4gVVBE QVRFIHJlcXVlc3QsIG9yIGluIHRoZSBmaW5hbA0KPigyMDApIHJlc3BvbnNlIHRvIGFuIG9mZmVy bGVzcyBJTlZJVEUgZnJvbSB0aGUgU1JTLiBJZiBhbnkgb2YgdGhlDQo+bWV0YWRhdGEgYmVpbmcg c2VudCBjb250YWlucyBhIHJlZmVyZW5jZSB0byBhbnkgU0RQIGxhYmVscywgdGhlbiB0aGUNCj5y ZXF1ZXN0IGNvbnRhaW5pbmcgdGhlIG1ldGFkYXRhIE1VU1QgYWxzbyBjb250YWluIGFuIFNEUCBv ZmZlciB0aGF0DQo+ZGVmaW5lcyB0aG9zZSBsYWJlbHMuDQo+DQo+V2hlbiBhbiBJTlZJVEUgb3Ig VVBEQVRFIHJlcXVlc3QgY29udGFpbnMgYm90aCBhbiBTRFAgb2ZmZXIgYW5kDQo+bWV0YWRhdGEs IHRoZW4gdGhlIHJlcXVlc3QgYm9keSBoYXMgY29udGVudCB0eXBlIG11bHRpcGFydC9taXhlZCwg d2l0aA0KPm9uZSBzdWJvcmRpbmF0ZSBib2R5IHBhcnQgY29udGFpbmluZyB0aGUgU0RQIG9mZmVy IGFuZCBhbm90aGVyDQo+Y29udGFpbmluZyB0aGUgbWV0YWRhdGEuIFdoZW4gYW4gSU5WSVRFIGNv bnRhaW5zIG9ubHkgYW4gU0RQIG9mZmVyIG9yDQo+bWV0YWRhdGEsIHRoZW4gdGhlIG11bHRpcGFy dC9taXhlZCBjb250YWluZXIgaXMgb3B0aW9uYWwuIg0KDQpTb3VuZHMgcmVhc29uYWJsZSwgYnV0 IEkgZGVmZXIgdG8gb3RoZXJzIHdobyBoYXZlIG1vcmUgZXhwZXJpZW5jZSB3aXRoDQp0aGlzIG1l Y2hhbmlzbS4NCg0KW2hsdW1dIFlvdSBhcmUgcmlnaHQgdGhhdCB0aGUgc3RhdGVtZW50IGRpZCBu b3QgY292ZXIgdGhlIG9mZmVybGVzcyBJTlZJVEUNCmZyb20gdGhlIFNSUyB0aGF0IGNvdWxkIHJl c3VsdCBpbiBhIHJlc3BvbnNlIHdpdGggYm90aCBTRFAgYW5kIG1ldGFkYXRhLg0KVGhlIG5ldyB3 b3JkaW5nIGRlZmluaXRlbHkgcHJvdmlkZXMgbW9yZSBjbGFyaXR5IHRoYW4gdGhlIGV4aXN0aW5n IG9uZTsNCkknbGwgdXBkYXRlIHRoYXQuDQoNCj4NCj5GaWd1cmUgMTE6DQo+DQo+KEEgbml0KSB0 aGVyZSBpcyBubyBuZWVkIGZvciAiYXBwbGljYXRpb24vcnMtbWV0YWRhdGEiIGluIHRoZSBBY2Nl cHQuDQo+KFRoaXMgb25seSBkZXNjcmliZXMgd2hhdCBjYW4gYmUgKnJlY2VpdmVkKiwgYW5kIHRo ZSBTUkMgd2lsbCBuZXZlcg0KPnJlY2VpdmUgdGhpcy4pDQoNCkFncmVlZC4NCg0KW2hsdW1dIGZp eGVkLg0KDQo+DQo+U2VjdGlvbiA5LjI6DQo+DQo+ICAgIFdoZW4gdGhlIFNSUyBleHBsaWNpdGx5 IHJlcXVlc3RzIGZvciBhIGZ1bGwgbWV0YWRhdGEgc25hcHNob3QsIHRoZQ0KPiAgICBTUlMgTVVT VCBzZW5kIGFuIFVQREFURSByZXF1ZXN0IHdpdGhvdXQgYW4gU0RQIG9mZmVyLiAgQSBtZXRhZGF0 YQ0KPiAgICBzbmFwc2hvdCByZXF1ZXN0IGNvbnRhaW5zIGEgY29udGVudCB3aXRoIHRoZSBjb250 ZW50IGRpc3Bvc2l0aW9uIHR5cGUNCj4gICAgInJlY29yZGluZy1zZXNzaW9uIi4gLi4uDQo+DQo+ VGhlIGFib3ZlIGlzIGF0IGxlYXN0IGF3a3dhcmQuIEhvdyBhYm91dDoNCj4NCj4gICAgVGhlIFNS UyBNQVkgZXhwbGljaXRseSByZXF1ZXN0IGEgZnVsbCBtZXRhZGF0YSBzbmFwc2hvdCBieSBzZW5k aW5nDQo+ICAgIGFuIFVQREFURSByZXF1ZXN0LiBUaGlzIHJlcXVlc3QgTVVTVCBjb250YWluIGEg Ym9keSB3aXRoIGEgY29udGVudA0KPiAgICBkaXNwb3NpdGlvbiB0eXBlICJyZWNvcmRpbmctc2Vz c2lvbiIsIGFuZCBNVVNUIE5PVCBjb250YWluIGFuIFNEUA0KPiAgICBib2R5IHBhcnQuIC4uLg0K DQpbaGx1bV0gSSBhZ3JlZSB0aGlzIHNlbnRlbmNlIHNvdW5kcyBiZXR0ZXIuDQoNCj4NCj5UaGVu IGZ1cnRoZXIgaW50byB0aGlzIHNlY3Rpb246DQo+DQo+ICAgIFdoZW4gdGhlIFNSQyByZWNlaXZl cyB0aGUgcmVxdWVzdCBmb3IgYSBtZXRhZGF0YSBzbmFwc2hvdCwgdGhlIFNSQw0KPiAgICBNVVNU IHByb3ZpZGUgYSBmdWxsIG1ldGFkYXRhIHNuYXBzaG90IGluIGEgc2VwYXJhdGUgSU5WSVRFIG9y IFVQREFURQ0KPiAgICB0cmFuc2FjdGlvbiwgYWxvbmcgd2l0aCBhbiBTRFAgb2ZmZXIuICBBbGwg c3Vic2VxdWVudCBtZXRhZGF0YQ0KPiAgICB1cGRhdGVzIHNlbnQgYnkgdGhlIFNSQyBNVVNUIGJl IGJhc2VkIG9uIHRoZSBuZXcgbWV0YWRhdGEgc25hcHNob3QuDQo+DQo+TW9zdCBvZiB0aGUgdGlt ZSBTRFAgd2lsbCBiZSByZXF1aXJlZC4gQnV0IGl0cyBwb3NzaWJsZSB0aGF0IHRoZXJlIGFyZQ0K PmN1cnJlbnRseSBubyBtZWRpYSBzdHJlYW1zLCBhbmQgaGVuY2Ugbm8gcmVmZXJlbmNlcyB0byBT RFAuIEluIHRoYXQgY2FzZQ0KPnRoZSBTRFAgaXNuJ3QgbmVlZGVkLiAoVG8gYXZvaWQgdGhlIFNE UCwgdGhlIG1ldGFkYXRhIHdvdWxkIG5lZWQgdG8gYmUNCj5zZW50IGluIGFuIFVQREFURS4pIEkg Y292ZXJlZCB0aGUgY2FzZXMgd2hlcmUgU0RQIG11c3QgYmUgc2VudCBpbiBteQ0KPnByb3Bvc2Vk IGNoYW5nZXMgYWJvdmUsIHNvIGl0IGRvZXNuJ3QgcmVhbGx5IG5lZWQgdG8gYmUgbWVudGlvbmVk IGhlcmUuDQo+DQo+QWxzbywgc3Vic2VxdWVudCBwYXJ0aWFsIHVwZGF0ZXMgY291bGQgZGVwZW5k IG9uIGZ1dHVyZSBmdWxsIHNuYXBzaG90cywNCj5ub3QganVzdCB0aGlzIG9uZS4NCg0KW2hsdW1d IFJpZ2h0IHRoaXMgaXMgYSBnb29kIHBvaW50OyB0aGUgY3VycmVudCB3b3JkaW5nIGlzIHRvbyBy ZXN0cmljdGl2ZS4NCg0KPg0KPlNvIGhvdyBhYm91dCBjaGFuZ2luZyB0aGUgYWJvdmUgdG86DQo+ DQo+ICAgIFdoZW4gdGhlIFNSQyByZWNlaXZlcyBhIHJlcXVlc3QgZm9yIGEgbWV0YWRhdGEgc25h cHNob3QsIGl0IE1VU1QNCj4gICAgaW1tZWRpYXRlbHkgcHJvdmlkZSBhIGZ1bGwgbWV0YWRhdGEg c25hcHNob3QgaW4gYSBzZXBhcmF0ZSBJTlZJVEUgb3INCj4gICAgVVBEQVRFIHRyYW5zYWN0aW9u LiBBbnkgc3Vic2VxdWVudCBwYXJ0aWFsIHVwZGF0ZXMgd2lsbCBub3QgYmUNCj4gICAgZGVwZW5k ZW50IG9uIGFueSBtZXRhZGF0YSBzZW50IHByaW9yIHRvIHRoaXMgZnVsbCBtZXRhZGF0YSBzbmFw c2hvdC4NCg0KW2hsdW1dIEFncmVlZC4NCg0KDQo+DQo+U2VjdGlvbiA5LjIuMToNCj4NCj5UaGUg QUJORiByZWZlcmVuY2VzIFRFWFQtVVRGOC1UUklNLCBidXQgZG9lc24ndCBzcGVjaWZ5IHdoZXJl IHRoaXMgaXMNCj5kZWZpbmVkLiAoSXQgY29tZXMgZnJvbSAzMjYxLikNCj4NCj5TZWN0aW9uIDEx LjUuMSwgMTEuNS4yOg0KPg0KPlRoZXNlIGxpc3QgTGVvbiB3aXRoIGhpcyBOaWNlIGVtYWlsIGFk ZHJlc3MuIFRoaXMgc2hvdWxkIHByb2JhYmx5IGJlDQo+Y2hhbmdlZC4NCg0KW2hsdW1dIHNlbnQg YSBtZXNzYWdlIHRvIExlb24gYXNraW5nIGZvciBhbiB1cGRhdGUuDQoNCj4NCj5TZWN0aW9uIDEy Og0KPg0KPkhhdmUgd2UgaGFkIGEgc2VjdXJpdHkgcmV2aWV3IHlldD8NCg0KSSBhc2tlZCBSaWNo YXJkIEJhcm5lcyB0byByZXZpZXcgc3BlY2lmaWMgc2VjdGlvbnMgaW4gdGhlIHBhc3QsIGJ1dCBJ IGFtDQpub3QgYXdhcmUgb2YgYSBmdWxsIHNlY3VyaXR5IHJldmlldy4NCg0KQ2hlZXJzLA0KQ2hh cmxlcw0KDQo+DQo+U2VjdGlvbiAxMi4yOg0KPg0KPkF1dGhvcnMgQWRkcmVzc2VzOg0KPg0KPkxl YW4gaXMgc3RpbGwgc2hvd24gYXQgTmljZS4NCj4NCj5UaGF0J3MgYWxsLg0KPg0KPglUaGFua3Ms DQo+CVBhdWwNCj4NCj5PbiA5LzkvMTMgNDoyMyBBTSwgSHV0dG9uLCBBbmRyZXcgd3JvdGU6DQo+ PiBXZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb2YNCj4+ IF9odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcHJlYy1wcm90b2NvbC0x MF8NCj4+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIGJ5IHRoZSBlbmQgb2YgdGhlIGRheSBvbiBTZXB0 ZW1iZXIgMjJebmQgKFR3bw0KPj53ZWVrcykuDQo+PiBUaGUgZGVhZGxpbmUgZm9yIHJlcXVlc3Rp bmcgYSBtZWV0aW5nIGR1cmluZyBJRVRGODggKFZhbmNvdXZlcikgaXMgU2VwdA0KPj4gMjNecmQg YW5kIHdoZXRoZXIgb3Igbm90IHRoZXJlIGFyZSBXR0xDIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQg bWF5DQo+PiBkZXRlcm1pbmUgd2hldGhlciB3ZSBuZWVkIGEgU0lQUkVDIG1lZXRpbmcgaW4gVmFu Y291dmVyLg0KPj4gUmVnYXJkcw0KPj4gQW5keSAoU0lQUkVDIENvLUNoYWlyKS4NCj4+DQo+Pg0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNp cHJlYyBtYWlsaW5nIGxpc3QNCj4+IHNpcHJlY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCj4+DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaXByZWMgbWFpbGluZyBsaXN0DQo+c2lw cmVjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBy ZWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNp cHJlYyBtYWlsaW5nIGxpc3QNCnNpcHJlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXByZWMNCg0KDQowMO6SnOmMn+y4qw0K4r+o0KToh6jLv05TSlpN QlgwMy5tc2cuaW50LmdlbmVzeXNsYWIuY29tPg0KDQo= From pkyzivat@alum.mit.edu Wed Oct 16 07:11:08 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 6414421F9C9B for ; Wed, 16 Oct 2013 07:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.282 X-Spam-Level: X-Spam-Status: No, score=-0.282 tagged_above=-999 required=5 tests=[AWL=0.155, 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 CigWEbyXF7jE for ; Wed, 16 Oct 2013 07:11:02 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id C858221F9BB6 for ; Wed, 16 Oct 2013 07:11:00 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta15.westchester.pa.mail.comcast.net with comcast id dni61m0011ei1Bg5FqB0vm; Wed, 16 Oct 2013 14:11:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id dqAz1m00N3ZTu2S3kqAz2U; Wed, 16 Oct 2013 14:10:59 +0000 Message-ID: <525E9E73.7010003@alum.mit.edu> Date: Wed, 16 Oct 2013 10:10:59 -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: Henry Lum References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381932660; bh=6I+H7+6pMw8Bef2RXHj9ct7gw0mgIbRyu0D49EXlP50=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NszHSc60mfd8+p8VQ9nJGJbc6U3RczraIz+DVlqWCsY2Vj7by6j0W3D1HLALyd+F2 n2GKXMAzQvyhLrg0oE0x6+AfbxVQY/RmYiz07Cz3/FiDVyLfRi3QuoXFrb9SxOpcHH deSsb2O6Ul4YsjsEn0Ac7CZcOImy1yt8l0e7S2R6zdjHLH1VwG1PQjArIwW4Sj5c7+ g5s+rkU0AmAVQjvQqcYaMYv5yJStg+B6c8f0riJ0bUY9SCP9T0at5h98xDWSZdjkHj zC1ip4j4nIQg1/jrXMDERg+FohC9wMRy4UQ7/X5ThdcSNgGOePqY6Tk6L2jMoFVmAs ZVjl4pWPcc3Eg== Cc: "siprec@ietf.org" 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: Wed, 16 Oct 2013 14:11:08 -0000 I'm just following up on my "big" issue here, inline. On 10/15/13 11:05 PM, Henry Lum wrote: >> 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? > > [hlum] I think this is really up to the B2BUA to decide what recording > indicator and recording preference to expose to SRC2 if SRC1 is recording > the call. I don't think we can really mandate a specific behaviour for > B2BUA. Let's say B2BUA decides to pass on a:record=on to SRC2, SRC2 may > still decide to record the call again since it is an SRC and it should be > able to do so. If the B2BUA chooses not not pass on this indicator then > there is nothing SRC2 and UA2 can do to know that the call is actually > being recorded. If we give the B2BUA discretion about this, then we are giving it discretion about informing SRC2 that recording is going on. If it was an SRC, then it would be obligated to report that recording is on. As a B2BUA, it effectively encapsulates the behavior of everything behind it. So again it should be obligated to report. > If we look at a simple case where two UA in a CS are also SRC and are both > recording the call, then the SDP offer/answer sent by both UA will include > a=record:on. The UA that receives the initial INVITE with a=record:on may > still decide to record the call even if another SRC is already recording > the call. I don't see a conflict with this. My concern is not about an SRC deciding if it needs to record. My concern is that UAs know when they are being recorded, so that they may report that fact to their users. >> 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.) > > [hlum] I don't think there is a need to keep track of the number of > recordings in the call chain. All an end-user need to know is whether the > call is being recorded or not. How many recorders are recording the call > is irrelevant to the user. If an element in the call chain is an SRC that > receives an SDP offer with a=record:off but this SRC is still recording > the call, the SRC should still convey that the call is being recorded. Perhaps "counting" implies more work than I mean. In the case of a B2BUA with two "sides", all it needs to do is keep track of the recording state on each side, and report that to the other side. But in the case of a a conference focus, more record keeping is required, since any of the participants could be recording. Counting is one way. OR, the focus could be more sophisticated, and only indicate recording to a participant if the media to/from that participant is being recorded. >> Some similar treatment is probably required for recordpref. My head >> hurts now, so I'm not doing it here. > > [hlum] recordpref is actually similar to recording indicator. Let's say a > user needs to pause the recording, the UA sends an SDP offer with > recordpref=pause. As long as the call chain passes on the SDP offer with > the same preference all the way through, the all SRCs in the call chain > would end up honoring that request to pause the recording. The analysis is similar to that for the record indicator. All the different preferences for recording need to be aggregated and made available to all the SRCs. (Or the SRC needs to do the aggregation.) >> 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. Treat what as a separate RS? The RSs are clear. But the UAs don't have visibility to the RSs, only to the indicators. 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). I think you mean OR, not XOR. If the MCU (focus) maintains a separate recording state for each leg, then it can OR those together to get the aggregate state at any point in time. Then it needs to report state changes to each leg. Counting is one way to do that. But I agree there are other ways. My point is that there is a real obligation here, to preserve the essential properties of these indicators. So I think we need to include some normative behavior about it. Thanks, Paul From andrew.hutton@unify.com Wed Oct 16 09:04:59 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 AF8AC21F84D9 for ; Wed, 16 Oct 2013 09:04:48 -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, 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 AhI34qHJMwon for ; Wed, 16 Oct 2013 09:04:43 -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 7CA6B21F9CDF for ; Wed, 16 Oct 2013 09:04:33 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 56E7423F0574 for ; Wed, 16 Oct 2013 18:04:31 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 18:03:49 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Meeting in Vancouver (IETF88) Thread-Index: Ac7KiWRurHB1HBlnTGiFyANME0ORuw== Date: Wed, 16 Oct 2013 16:04:29 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BF578E@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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17BF578EMCHP04MSXglobal_" MIME-Version: 1.0 Subject: [siprec] SIPREC Meeting in Vancouver (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: Wed, 16 Oct 2013 16:05:02 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17BF578EMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, SIPREC has been allocated a session at IETF88 on Monday afternoon (13:00) s= o no chance to arrive middle of the week this time. The full IETF88 agenda= is here https://datatracker.ietf.org/meeting/88/agenda.html The primary purpose for meeting this time is to review the proposal for new= work and the update to the charter, see http://www.ietf.org/mail-archive/w= eb/siprec/current/msg03786.html. Feedback on this proposal would be most appreciated now on the mailing list= . Please let me know if you want to request agenda time for other topics. Regards Andy (SIPREC Co-Chair). --_000_9F33F40F6F2CD847824537F3C4E37DDF17BF578EMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
SIPREC has been allocated a session at IETF88 on Monday afternoon (13:= 00) so no chance to arrive middle of the week this time.  The full IET= F88 agenda is here https://datatracker.ietf.org/meeting/88/age= nda.html
 
The primary purpose for meeting this time is to review the proposal fo= r new work and the update to the charter, see ht= tp://www.ietf.org/mail-archive/web/siprec/current/msg03786.html<= /a>.
 
Feedback on this proposal would be most appreciated now on the mailing= list.
 
Please let me know if you want to request agenda time for other topics= .
 
Regards
Andy (SIPREC Co-Chair).
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF17BF578EMCHP04MSXglobal_-- From spromano@unina.it Wed Oct 16 11:02:14 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 01A3A21F9ED1 for ; Wed, 16 Oct 2013 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=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 M+n9qMcS5-pg for ; Wed, 16 Oct 2013 11:02:10 -0700 (PDT) Received: from relay1.tre.it (mailout.tre.it [62.13.171.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6913121F9ECA for ; Wed, 16 Oct 2013 11:02:07 -0700 (PDT) Received: from [192.168.1.100] ([10.119.31.88]) by relay1.tre.it with ESMTP id r9GHtdMl012816-r9GHtdMm012816; Wed, 16 Oct 2013 19:55:40 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DBC99B31-684D-4764-8518-B35E082C514F" From: Simon Pietro Romano In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BF578E@MCHP04MSX.global-ad.net> Date: Wed, 16 Oct 2013 20:02:05 +0200 Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF17BF578E@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1283) Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC Meeting in Vancouver (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: Wed, 16 Oct 2013 18:02:14 -0000 --Apple-Mail=_DBC99B31-684D-4764-8518-B35E082C514F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Andy and all, > The primary purpose for meeting this time is to review the proposal = for new work and the update to the charter, see = http://www.ietf.org/mail-archive/web/siprec/current/msg03786.html. > =20 > Feedback on this proposal would be most appreciated now on the mailing = list. With respect to this point, I do believe the charter changes can be = adopted, given the fact that we are not proposing any disruptive = modification to the current organization of the siprec WG. Let me also seize this occasion to solicit WG feedback on the list of = use cases and requirements we have identified in = draft-kyzivat-siprec-conference-use-cases-00. Cheers, Simon > =20 > Please let me know if you want to request agenda time for other = topics. > =20 > Regards > Andy (SIPREC Co-Chair). > =20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_DBC99B31-684D-4764-8518-B35E082C514F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello Andy and = all,

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_DBC99B31-684D-4764-8518-B35E082C514F-- From eckelcu@cisco.com Wed Oct 16 12:47:20 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 247C121F9B91 for ; Wed, 16 Oct 2013 12:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 KbdOuom4rWMa for ; Wed, 16 Oct 2013 12:47:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3021F849C for ; Wed, 16 Oct 2013 12:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6368; q=dns/txt; s=iport; t=1381952828; x=1383162428; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Au2w1tTfYH/UF8cJ14BDK1BNDXhK3JZYwrWpZ6nRHN0=; b=Pg0CuKkPzjHy+7lKFCF+OI2/2Vu5D2sw6ed6bqzh2b/r58aLG65/SIe/ uaeODYZsf3cPDNKJmghjptDlbql3YqQRkCd42IXiAPhRM5zVXpEyxcdUI dOhF+z8fHwkTB7B0OF9TnE5Yuje5seX/u+jmILJ1fycO14B8D12LkMQ20 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAFHsXlKtJXHA/2dsb2JhbABaDoJ5gQq9dIEfFnSCJQEBAQQ6LhESAQgOCgoUQiUBAQQBDQUIE4dqAb9Ljx4CMQeDH4EGA6oGgmU/gik X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="272766894" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 16 Oct 2013 19:47:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9GJl7Q6008632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 19:47:07 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.239]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 14:47:07 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , Henry Lum Thread-Topic: [siprec] WGLC on draft-ietf-siprec-protocol-10 Thread-Index: Ac6tNc3U21dTN5ARRzalEAmqIGrqxABdagAAAcZ1RIADpKMgUAGS5seA///oj4A= Date: Wed, 16 Oct 2013 19:47:06 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882805C34A65@xmb-aln-x08.cisco.com> In-Reply-To: <525E9E73.7010003@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.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <4834556092672340808A25023B736820@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" 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: Wed, 16 Oct 2013 19:47:20 -0000 My assumption on the recording indicator is that the recording indicator is not per RS but rather set to true if any RS is known to be recording the RS. So in the cases described below, the SRC would propagate a record:on regardless of whether or not it was recording. The only way it would change this to record:off is if it stopped providing the media or the UA on whose behalf it is acting, in which case that users media is truly no longer being recorded. Cheers, Charles On 10/16/13 7:10 AM, "Paul Kyzivat" wrote: >I'm just following up on my "big" issue here, inline. > >On 10/15/13 11:05 PM, Henry Lum wrote: > >>> 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? >> >> [hlum] I think this is really up to the B2BUA to decide what recording >> indicator and recording preference to expose to SRC2 if SRC1 is >>recording >> the call. I don't think we can really mandate a specific behaviour for >> B2BUA. Let's say B2BUA decides to pass on a:record=3Don to SRC2, SRC2 ma= y >> still decide to record the call again since it is an SRC and it should >>be >> able to do so. If the B2BUA chooses not not pass on this indicator then >> there is nothing SRC2 and UA2 can do to know that the call is actually >> being recorded. > >If we give the B2BUA discretion about this, then we are giving it >discretion about informing SRC2 that recording is going on. > >If it was an SRC, then it would be obligated to report that recording is >on. As a B2BUA, it effectively encapsulates the behavior of everything >behind it. So again it should be obligated to report. > >> If we look at a simple case where two UA in a CS are also SRC and are >>both >> recording the call, then the SDP offer/answer sent by both UA will >>include >> a=3Drecord:on. The UA that receives the initial INVITE with a=3Drecord:o= n >>may >> still decide to record the call even if another SRC is already recording >> the call. I don't see a conflict with this. > >My concern is not about an SRC deciding if it needs to record. >My concern is that UAs know when they are being recorded, so that they >may report that fact to their users. > >>> 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.) >> >> [hlum] I don't think there is a need to keep track of the number of >> recordings in the call chain. All an end-user need to know is whether >>the >> call is being recorded or not. How many recorders are recording the call >> is irrelevant to the user. If an element in the call chain is an SRC >>that >> receives an SDP offer with a=3Drecord:off but this SRC is still recordin= g >> the call, the SRC should still convey that the call is being recorded. > >Perhaps "counting" implies more work than I mean. In the case of a B2BUA >with two "sides", all it needs to do is keep track of the recording >state on each side, and report that to the other side. > >But in the case of a a conference focus, more record keeping is >required, since any of the participants could be recording. Counting is >one way. OR, the focus could be more sophisticated, and only indicate >recording to a participant if the media to/from that participant is >being recorded. > >>> Some similar treatment is probably required for recordpref. My head >>> hurts now, so I'm not doing it here. >> >> [hlum] recordpref is actually similar to recording indicator. Let's say >>a >> user needs to pause the recording, the UA sends an SDP offer with >> recordpref=3Dpause. As long as the call chain passes on the SDP offer wi= th >> the same preference all the way through, the all SRCs in the call chain >> would end up honoring that request to pause the recording. > >The analysis is similar to that for the record indicator. All the >different preferences for recording need to be aggregated and made >available to all the SRCs. (Or the SRC needs to do the aggregation.) > >>> 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. > >Treat what as a separate RS? The RSs are clear. But the UAs don't have >visibility to the RSs, only to the indicators. > > 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). > >I think you mean OR, not XOR. > >If the MCU (focus) maintains a separate recording state for each leg, >then it can OR those together to get the aggregate state at any point in >time. Then it needs to report state changes to each leg. Counting is one >way to do that. But I agree there are other ways. > >My point is that there is a real obligation here, to preserve the >essential properties of these indicators. So I think we need to include >some normative behavior about it. > > Thanks, > Paul > > > From pkyzivat@alum.mit.edu Wed Oct 16 13:20:01 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 1CDA511E82DD for ; Wed, 16 Oct 2013 13:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 EzJJwm9i4KrP for ; Wed, 16 Oct 2013 13:19:55 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 2256D11E813A for ; Wed, 16 Oct 2013 13:19:54 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id dncn1m0021ap0As5FwKuju; Wed, 16 Oct 2013 20:19:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id dwKu1m0043ZTu2S3iwKumM; Wed, 16 Oct 2013 20:19:54 +0000 Message-ID: <525EF4E9.906@alum.mit.edu> Date: Wed, 16 Oct 2013 16:19:53 -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: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C0882805C34A65@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882805C34A65@xmb-aln-x08.cisco.com> 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=1381954794; bh=ms0MEL27OY+BQ+h1JHjhxLywR0bPRHDwbEWVq/TYVyA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=biLRs/0V9DqSluuCx2Py0h7N/eSQ84xDBhiY25NRtYPAjfjH1uMDdZoW0lnp0gxa1 76CImhoVjZfOKMRH2U1Rn63RKk0Ev3m+RLszMiJ+ToUcU2hAdPsnW5Zc3ymfJX7Hv8 foeq4za0bVRHfq/lft3a1/6jSxD3Ewvfes6w9xP9+3g285G1iLCt9/O2prx38MhPAh UF4yYEHeMEpLAqMMNczhCWfh6rI+NgZRchkc0je6IG1ulK4QYpxCKqVj/YDwSLXy1c bU57OqQzFyHFagWffawQLkUuCqmYdOesDJKsQ7gvF6/yiHHD8bHH1RKMtEQsagRfJ/ mbYd4eSPcuKCQ== Cc: "siprec@ietf.org" 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: Wed, 16 Oct 2013 20:20:01 -0000 On 10/16/13 3:47 PM, Charles Eckel (eckelcu) wrote: > My assumption on the recording indicator is that the recording indicator > is not per RS but rather set to true if any RS is known to be recording > the RS. So in the cases described below, the SRC would propagate a > record:on regardless of whether or not it was recording. The only way it > would change this to record:off is if it stopped providing the media or > the UA on whose behalf it is acting, in which case that users media is > truly no longer being recorded. I think we agree conceptually on what needs to be done. We just need to be sure the text says that. I think this means that boxes that join multiple UAs (B2BUAs and focuses) need to keep a recording state for each leg, and then "mix" the state from those legs to the other legs. And if the box is also a SRC then it has to mix in its own recording state too. My earlier mention of "counting" was a poor man's way of doing that. But it might not even work. Thanks, Paul > Cheers, > Charles > > On 10/16/13 7:10 AM, "Paul Kyzivat" wrote: > >> I'm just following up on my "big" issue here, inline. >> >> On 10/15/13 11:05 PM, Henry Lum wrote: >> >>>> 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? >>> >>> [hlum] I think this is really up to the B2BUA to decide what recording >>> indicator and recording preference to expose to SRC2 if SRC1 is >>> recording >>> the call. I don't think we can really mandate a specific behaviour for >>> B2BUA. Let's say B2BUA decides to pass on a:record=on to SRC2, SRC2 may >>> still decide to record the call again since it is an SRC and it should >>> be >>> able to do so. If the B2BUA chooses not not pass on this indicator then >>> there is nothing SRC2 and UA2 can do to know that the call is actually >>> being recorded. >> >> If we give the B2BUA discretion about this, then we are giving it >> discretion about informing SRC2 that recording is going on. >> >> If it was an SRC, then it would be obligated to report that recording is >> on. As a B2BUA, it effectively encapsulates the behavior of everything >> behind it. So again it should be obligated to report. >> >>> If we look at a simple case where two UA in a CS are also SRC and are >>> both >>> recording the call, then the SDP offer/answer sent by both UA will >>> include >>> a=record:on. The UA that receives the initial INVITE with a=record:on >>> may >>> still decide to record the call even if another SRC is already recording >>> the call. I don't see a conflict with this. >> >> My concern is not about an SRC deciding if it needs to record. >> My concern is that UAs know when they are being recorded, so that they >> may report that fact to their users. >> >>>> 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.) >>> >>> [hlum] I don't think there is a need to keep track of the number of >>> recordings in the call chain. All an end-user need to know is whether >>> the >>> call is being recorded or not. How many recorders are recording the call >>> is irrelevant to the user. If an element in the call chain is an SRC >>> that >>> receives an SDP offer with a=record:off but this SRC is still recording >>> the call, the SRC should still convey that the call is being recorded. >> >> Perhaps "counting" implies more work than I mean. In the case of a B2BUA >> with two "sides", all it needs to do is keep track of the recording >> state on each side, and report that to the other side. >> >> But in the case of a a conference focus, more record keeping is >> required, since any of the participants could be recording. Counting is >> one way. OR, the focus could be more sophisticated, and only indicate >> recording to a participant if the media to/from that participant is >> being recorded. >> >>>> Some similar treatment is probably required for recordpref. My head >>>> hurts now, so I'm not doing it here. >>> >>> [hlum] recordpref is actually similar to recording indicator. Let's say >>> a >>> user needs to pause the recording, the UA sends an SDP offer with >>> recordpref=pause. As long as the call chain passes on the SDP offer with >>> the same preference all the way through, the all SRCs in the call chain >>> would end up honoring that request to pause the recording. >> >> The analysis is similar to that for the record indicator. All the >> different preferences for recording need to be aggregated and made >> available to all the SRCs. (Or the SRC needs to do the aggregation.) >> >>>> 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. >> >> Treat what as a separate RS? The RSs are clear. But the UAs don't have >> visibility to the RSs, only to the indicators. >> >> 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). >> >> I think you mean OR, not XOR. >> >> If the MCU (focus) maintains a separate recording state for each leg, >> then it can OR those together to get the aggregate state at any point in >> time. Then it needs to report state changes to each leg. Counting is one >> way to do that. But I agree there are other ways. >> >> My point is that there is a real obligation here, to preserve the >> essential properties of these indicators. So I think we need to include >> some normative behavior about it. >> >> Thanks, >> Paul >> >> >> > > From henry.lum@genesyslab.com Wed Oct 16 19:48:09 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 8371721F9D0A for ; Wed, 16 Oct 2013 19:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-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 6O4d12QEaNyY for ; Wed, 16 Oct 2013 19:47:54 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3C311E80F8 for ; Wed, 16 Oct 2013 19:47:49 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Wed, 16 Oct 2013 22:47:48 -0400 Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 19:47:46 -0700 From: Henry Lum To: Paul Kyzivat , "Charles Eckel (eckelcu)" Thread-Topic: [siprec] WGLC on draft-ietf-siprec-protocol-10 Thread-Index: Ac6tNc3U21dTN5ARRzalEAmqIGrqxABdagAAAcZ1RIADpKMgUAGXF6mAAAu9HgAAASUcgAAFKeEA Date: Thu, 17 Oct 2013 02:47:46 +0000 Message-ID: In-Reply-To: <525EF4E9.906@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.4.120824 x-originating-ip: [192.0.219.108] Content-ID: MIME-Version: 1.0 X-MC-Unique: 113101622474800201 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" 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, 17 Oct 2013 02:48:09 -0000 I am okay adding a MUST statement to ensure that the recording indicator is presented to the user even when the call is traversed through some B2BUA or conference focus. Let me try to reword section 7.3.1: When a recording-aware UA receives an SDP offer or answer that includes the a=3Drecord attribute, the UA MUST provide the recording indication to the end user whether the recording is on, off, or paused for each medium based on the most recently received a=3Drecord SDP attribute for that medium. When a CS is traversed through multiple UAs such as a B2BUA or a conference focus, each UA involved in the CS that is aware that the CS is being recorded MUST provide the recording indication through the a=3Drecord attribute to all=20 other parties in the CS. =20 It is possible that more than one SRC can be in the call path recording the=20 same CS, but the recording indication attribute does not provide any hint as=20 to which SRC is actually performing the recording. This means that an endpoint=20 only knows that the call is being recorded through the recording indicator.=20 This attribute is also not used as an indication to negotiate which SRC in the call path will perform recording and is not used as a request to start/stop recording if there are multiple SRCs in the call path. Regards, Henry On 2013-10-16 4:19 PM, "Paul Kyzivat" wrote: > > >On 10/16/13 3:47 PM, Charles Eckel (eckelcu) wrote: >> My assumption on the recording indicator is that the recording indicator >> is not per RS but rather set to true if any RS is known to be recording >> the RS. So in the cases described below, the SRC would propagate a >> record:on regardless of whether or not it was recording. The only way it >> would change this to record:off is if it stopped providing the media or >> the UA on whose behalf it is acting, in which case that users media is >> truly no longer being recorded. > >I think we agree conceptually on what needs to be done. >We just need to be sure the text says that. > >I think this means that boxes that join multiple UAs (B2BUAs and >focuses) need to keep a recording state for each leg, and then "mix" the >state from those legs to the other legs. And if the box is also a SRC >then it has to mix in its own recording state too. > >My earlier mention of "counting" was a poor man's way of doing that. But >it might not even work. > >=09Thanks, >=09Paul > >> Cheers, >> Charles >> >> On 10/16/13 7:10 AM, "Paul Kyzivat" wrote: >> >>> I'm just following up on my "big" issue here, inline. >>> >>> On 10/15/13 11:05 PM, Henry Lum wrote: >>> >>>>> 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? >>>> >>>> [hlum] I think this is really up to the B2BUA to decide what recording >>>> indicator and recording preference to expose to SRC2 if SRC1 is >>>> recording >>>> the call. I don't think we can really mandate a specific behaviour for >>>> B2BUA. Let's say B2BUA decides to pass on a:record=3Don to SRC2, SRC2 >>>>may >>>> still decide to record the call again since it is an SRC and it should >>>> be >>>> able to do so. If the B2BUA chooses not not pass on this indicator >>>>then >>>> there is nothing SRC2 and UA2 can do to know that the call is actually >>>> being recorded. >>> >>> If we give the B2BUA discretion about this, then we are giving it >>> discretion about informing SRC2 that recording is going on. >>> >>> If it was an SRC, then it would be obligated to report that recording >>>is >>> on. As a B2BUA, it effectively encapsulates the behavior of everything >>> behind it. So again it should be obligated to report. >>> >>>> If we look at a simple case where two UA in a CS are also SRC and are >>>> both >>>> recording the call, then the SDP offer/answer sent by both UA will >>>> include >>>> a=3Drecord:on. The UA that receives the initial INVITE with a=3Drecord= :on >>>> may >>>> still decide to record the call even if another SRC is already >>>>recording >>>> the call. I don't see a conflict with this. >>> >>> My concern is not about an SRC deciding if it needs to record. >>> My concern is that UAs know when they are being recorded, so that they >>> may report that fact to their users. >>> >>>>> 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.) >>>> >>>> [hlum] I don't think there is a need to keep track of the number of >>>> recordings in the call chain. All an end-user need to know is whether >>>> the >>>> call is being recorded or not. How many recorders are recording the >>>>call >>>> is irrelevant to the user. If an element in the call chain is an SRC >>>> that >>>> receives an SDP offer with a=3Drecord:off but this SRC is still >>>>recording >>>> the call, the SRC should still convey that the call is being recorded. >>> >>> Perhaps "counting" implies more work than I mean. In the case of a >>>B2BUA >>> with two "sides", all it needs to do is keep track of the recording >>> state on each side, and report that to the other side. >>> >>> But in the case of a a conference focus, more record keeping is >>> required, since any of the participants could be recording. Counting is >>> one way. OR, the focus could be more sophisticated, and only indicate >>> recording to a participant if the media to/from that participant is >>> being recorded. >>> >>>>> Some similar treatment is probably required for recordpref. My head >>>>> hurts now, so I'm not doing it here. >>>> >>>> [hlum] recordpref is actually similar to recording indicator. Let's >>>>say >>>> a >>>> user needs to pause the recording, the UA sends an SDP offer with >>>> recordpref=3Dpause. As long as the call chain passes on the SDP offer >>>>with >>>> the same preference all the way through, the all SRCs in the call >>>>chain >>>> would end up honoring that request to pause the recording. >>> >>> The analysis is similar to that for the record indicator. All the >>> different preferences for recording need to be aggregated and made >>> available to all the SRCs. (Or the SRC needs to do the aggregation.) >>> >>>>> 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. >>> >>> Treat what as a separate RS? The RSs are clear. But the UAs don't have >>> visibility to the RSs, only to the indicators. >>> >>> 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). >>> >>> I think you mean OR, not XOR. >>> >>> If the MCU (focus) maintains a separate recording state for each leg, >>> then it can OR those together to get the aggregate state at any point >>>in >>> time. Then it needs to report state changes to each leg. Counting is >>>one >>> way to do that. But I agree there are other ways. >>> >>> My point is that there is a real obligation here, to preserve the >>> essential properties of these indicators. So I think we need to include >>> some normative behavior about it. >>> >>> =09Thanks, >>> =09Paul >>> >>> >>> >> >> > From pkyzivat@alum.mit.edu Thu Oct 17 12:08:59 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 2952E11E82CB for ; Thu, 17 Oct 2013 12:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_16=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=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 Ez7HMLMxyFL1 for ; Thu, 17 Oct 2013 12:08:53 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id CA20511E82CA for ; Thu, 17 Oct 2013 12:08:40 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id eD4S1m00H1uE5Es5DK8gy0; Thu, 17 Oct 2013 19:08:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id eK8f1m00h3ZTu2S3cK8gti; Thu, 17 Oct 2013 19:08:40 +0000 Message-ID: <526035B6.9000705@alum.mit.edu> Date: Thu, 17 Oct 2013 15:08:38 -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: Henry Lum References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382036920; bh=sNqB0r4ZQ7ZXsV9tWLM1mDMlVmT0DTlDTyrGowsOStI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a/w0f8WWjzVXUz0o/n1s/2goVOohy4cexhnDUSYwHYUs9/AHGDRRZ4MDmn7zA7PyN mCJuYnPT0qM4duJRnjuTTr++eaSvDHKnXH+RNjrEY27kX1w2PHHhMok7mukEwMB/Zh /vYJ/Cydox5kyFAEy0loVj1Qkuj5153pKnFjBfyCudhGYYOHamNvCil0szQYVyjOMF qLyZGe1Gf6pE+FPXnNf4KLPAPvEPI2X1BxUi0u8b/ahU/f1iHxsyqZs1EWdZ3g7MD0 9LAb5CQ9pTijcrAiuDHIhEFbzOa6lp0CFWOnyD80ED3PoobO/oLMpjwBWPAwJ6HhFc ge2NOlYNS0X0w== Cc: "siprec@ietf.org" 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, 17 Oct 2013 19:08:59 -0000 Henry, Thanks. This seems sufficient to me. Paul On 10/16/13 10:47 PM, Henry Lum wrote: > I am okay adding a MUST statement to ensure that the recording indicator > is presented to the user even when the call is traversed through some > B2BUA or conference focus. > > > Let me try to reword section 7.3.1: > > When a recording-aware UA receives an SDP offer or answer that > includes the a=record attribute, the UA MUST provide the recording > indication to the end user whether the recording is on, off, or > paused for each medium based on the most recently received a=record > SDP attribute for that medium. > > When a CS is traversed through multiple UAs such as a B2BUA or a > conference > focus, each UA involved in the CS that is aware that the CS is being > recorded > MUST provide the recording indication through the a=record attribute to > all > other parties in the CS. > > It is possible that more than one SRC can be in the call path recording > the > same CS, but the recording indication attribute does not provide any > hint as > to which SRC is actually performing the recording. This means that an > endpoint > only knows that the call is being recorded through the recording > indicator. > This attribute is also not used as an indication to negotiate which SRC > in > the call path will perform recording and is not used as a request to > start/stop recording if there are multiple SRCs in the call path. > > > > > Regards, > Henry > > > On 2013-10-16 4:19 PM, "Paul Kyzivat" wrote: > >> >> >> On 10/16/13 3:47 PM, Charles Eckel (eckelcu) wrote: >>> My assumption on the recording indicator is that the recording indicator >>> is not per RS but rather set to true if any RS is known to be recording >>> the RS. So in the cases described below, the SRC would propagate a >>> record:on regardless of whether or not it was recording. The only way it >>> would change this to record:off is if it stopped providing the media or >>> the UA on whose behalf it is acting, in which case that users media is >>> truly no longer being recorded. >> >> I think we agree conceptually on what needs to be done. >> We just need to be sure the text says that. >> >> I think this means that boxes that join multiple UAs (B2BUAs and >> focuses) need to keep a recording state for each leg, and then "mix" the >> state from those legs to the other legs. And if the box is also a SRC >> then it has to mix in its own recording state too. >> >> My earlier mention of "counting" was a poor man's way of doing that. But >> it might not even work. >> >> Thanks, >> Paul >> >>> Cheers, >>> Charles >>> >>> On 10/16/13 7:10 AM, "Paul Kyzivat" wrote: >>> >>>> I'm just following up on my "big" issue here, inline. >>>> >>>> On 10/15/13 11:05 PM, Henry Lum wrote: >>>> >>>>>> 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? >>>>> >>>>> [hlum] I think this is really up to the B2BUA to decide what recording >>>>> indicator and recording preference to expose to SRC2 if SRC1 is >>>>> recording >>>>> the call. I don't think we can really mandate a specific behaviour for >>>>> B2BUA. Let's say B2BUA decides to pass on a:record=on to SRC2, SRC2 >>>>> may >>>>> still decide to record the call again since it is an SRC and it should >>>>> be >>>>> able to do so. If the B2BUA chooses not not pass on this indicator >>>>> then >>>>> there is nothing SRC2 and UA2 can do to know that the call is actually >>>>> being recorded. >>>> >>>> If we give the B2BUA discretion about this, then we are giving it >>>> discretion about informing SRC2 that recording is going on. >>>> >>>> If it was an SRC, then it would be obligated to report that recording >>>> is >>>> on. As a B2BUA, it effectively encapsulates the behavior of everything >>>> behind it. So again it should be obligated to report. >>>> >>>>> If we look at a simple case where two UA in a CS are also SRC and are >>>>> both >>>>> recording the call, then the SDP offer/answer sent by both UA will >>>>> include >>>>> a=record:on. The UA that receives the initial INVITE with a=record:on >>>>> may >>>>> still decide to record the call even if another SRC is already >>>>> recording >>>>> the call. I don't see a conflict with this. >>>> >>>> My concern is not about an SRC deciding if it needs to record. >>>> My concern is that UAs know when they are being recorded, so that they >>>> may report that fact to their users. >>>> >>>>>> 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.) >>>>> >>>>> [hlum] I don't think there is a need to keep track of the number of >>>>> recordings in the call chain. All an end-user need to know is whether >>>>> the >>>>> call is being recorded or not. How many recorders are recording the >>>>> call >>>>> is irrelevant to the user. If an element in the call chain is an SRC >>>>> that >>>>> receives an SDP offer with a=record:off but this SRC is still >>>>> recording >>>>> the call, the SRC should still convey that the call is being recorded. >>>> >>>> Perhaps "counting" implies more work than I mean. In the case of a >>>> B2BUA >>>> with two "sides", all it needs to do is keep track of the recording >>>> state on each side, and report that to the other side. >>>> >>>> But in the case of a a conference focus, more record keeping is >>>> required, since any of the participants could be recording. Counting is >>>> one way. OR, the focus could be more sophisticated, and only indicate >>>> recording to a participant if the media to/from that participant is >>>> being recorded. >>>> >>>>>> Some similar treatment is probably required for recordpref. My head >>>>>> hurts now, so I'm not doing it here. >>>>> >>>>> [hlum] recordpref is actually similar to recording indicator. Let's >>>>> say >>>>> a >>>>> user needs to pause the recording, the UA sends an SDP offer with >>>>> recordpref=pause. As long as the call chain passes on the SDP offer >>>>> with >>>>> the same preference all the way through, the all SRCs in the call >>>>> chain >>>>> would end up honoring that request to pause the recording. >>>> >>>> The analysis is similar to that for the record indicator. All the >>>> different preferences for recording need to be aggregated and made >>>> available to all the SRCs. (Or the SRC needs to do the aggregation.) >>>> >>>>>> 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. >>>> >>>> Treat what as a separate RS? The RSs are clear. But the UAs don't have >>>> visibility to the RSs, only to the indicators. >>>> >>>> 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). >>>> >>>> I think you mean OR, not XOR. >>>> >>>> If the MCU (focus) maintains a separate recording state for each leg, >>>> then it can OR those together to get the aggregate state at any point >>>> in >>>> time. Then it needs to report state changes to each leg. Counting is >>>> one >>>> way to do that. But I agree there are other ways. >>>> >>>> My point is that there is a real obligation here, to preserve the >>>> essential properties of these indicators. So I think we need to include >>>> some normative behavior about it. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>> >>> >> > > > From internet-drafts@ietf.org Thu Oct 17 13:28:59 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 8CCF111E8118; Thu, 17 Oct 2013 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Fz19-Lrec4cc; Thu, 17 Oct 2013 13:28:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D5711E8249; Thu, 17 Oct 2013 13:28:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017202852.32550.95967.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 13:28:52 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-11.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 20:28:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-11.txt Pages : 42 Date : 2013-10-17 Abstract: This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Oct 18 03:57:23 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 0BAAD11E81CA; Fri, 18 Oct 2013 03:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 uCm--5b5w3xR; Fri, 18 Oct 2013 03:57:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6256221F9C37; Fri, 18 Oct 2013 03:57:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018105709.2277.86896.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 03:57:09 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-09.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 10:57:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : An Architecture for Media Recording using the Session In= itiation Protocol Author(s) : Andrew Hutton Leon Portman Rajnish Jain Ken Rehor Filename : draft-ietf-siprec-architecture-09.txt Pages : 16 Date : 2013-10-18 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-architecture-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-architecture-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Fri Oct 18 09:43: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 43E2C11E8288 for ; Fri, 18 Oct 2013 09:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.171, 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 gg1mmnEoQpWP for ; Fri, 18 Oct 2013 09:43:28 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE011E810F for ; Fri, 18 Oct 2013 09:43:19 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id efhG1m0021swQuc56gjKPV; Fri, 18 Oct 2013 16:43:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id egjK1m0033ZTu2S3bgjKtL; Fri, 18 Oct 2013 16:43:19 +0000 Message-ID: <52616526.30602@alum.mit.edu> Date: Fri, 18 Oct 2013 12:43:18 -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: <20131018105709.2277.86896.idtracker@ietfa.amsl.com> In-Reply-To: <20131018105709.2277.86896.idtracker@ietfa.amsl.com> 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=1382114599; bh=dTB0gjCARDjsshiUjxwXlzkDKoMG8DMvCJuDsEXFin8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hES2qYlUqkiPDTi7LrSEvF9mMAEDR1hBDOgdQykcZjGF8rO9faU0lyYYkLGbEisK6 T1wuBgak9gYiIvYG/yb8t4zD0Dvlt4RJMjFnKJFT+UAIGBS+up5KwIJbTA7LmK4a1j yTlOPe0E3enHURwADrZJqC6tw5yCAfD9Hex3HaOMHSVEkImOkXeiL/DBEiuKCMjkeq bAGH++afqEDJLTMaIMQkGepjI0tIBpNlER68ljOrCNvmkggrDRA3WxrlJZzxkiFVg9 30WxSN/EFU1Ugnnc8IZ2iIbFT7RDnkDDGiEv0pkOPriWnu7AhzvozYRqNbRfudcdiU ufQahBWes2sMg== Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-09.txt 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, 18 Oct 2013 16:43:33 -0000 I just looked at the diffs for this new version. All seem benign editorial things, except for one. The most recent change in section 3.1.3 garbled things. That change should be undone. Thanks, Paul On 10/18/13 6:57 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP Recording Working Group of the IETF. > > Title : An Architecture for Media Recording using the Session Initiation Protocol > Author(s) : Andrew Hutton > Leon Portman > Rajnish Jain > Ken Rehor > Filename : draft-ietf-siprec-architecture-09.txt > Pages : 16 > Date : 2013-10-18 > > 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 IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-siprec-architecture-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-siprec-architecture-09 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@unify.com Wed Oct 23 08:39:18 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 E308E11E842E for ; Wed, 23 Oct 2013 08:39:17 -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.000, 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 y-94+tYWkQwZ for ; Wed, 23 Oct 2013 08:39:08 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBDF11E83A2 for ; Wed, 23 Oct 2013 08:38:44 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id D66971EB85FC for ; Wed, 23 Oct 2013 17:38:42 +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; Wed, 23 Oct 2013 17:38:42 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF 88 - SIPREC Draft Agenda Thread-Index: Ac7QBfK35f3xBYKDRfqfYdPjGeXjUg== Date: Wed, 23 Oct 2013 15:38:41 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@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] IETF 88 - SIPREC Draft Agenda 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, 23 Oct 2013 15:39:18 -0000 Hi All, I posted a draft agenda which can be found at: https://datatracker.ietf.org= /meeting/88/agenda/siprec/. Please let me have any requests for changes/additions by Sunday 27th of Oct= ober. Regards Andy From rmohanr@cisco.com Wed Oct 23 08:56:17 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 D39E011E8391 for ; Wed, 23 Oct 2013 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fwmq5y+364qQ for ; Wed, 23 Oct 2013 08:56:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9523311E8369 for ; Wed, 23 Oct 2013 08:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=968; q=dns/txt; s=iport; t=1382543772; x=1383753372; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=OSaBRBSnUrvxOfizLP9h1hSoJcPr7w03n9uSNg0CHyU=; b=VbOhLrHXuwZzgdlXZAd3Gip2NAbO4P4vwjfdCTwqkFuTwJzItvsfOeSi oMMlBOeEly4i6s0t174pRVsDdzEp+o5zVAzy3xcZPa80XfrO7MhPjyrf7 SsDbhgmzJEYNbNp5TtoC0oxJlM+41iTaDZBCQCPHe0NjI014GL16GfZo0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOXwZ1KtJV2b/2dsb2JhbABZgwc4VL4CS4EtFnSCJQEBAQQBAQE3NBcGAQgRAwECCxQ3Cx0IAgQBEgiHfg26eI8dBjIGgxmBCwOZOJBYgySCKg X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="275698940" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2013 15:56:11 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9NFuBMJ003801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 15:56:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.120]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 10:56:11 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] IETF 88 - SIPREC Draft Agenda Thread-Index: AQHO0AhkzKzOLskQY0areSK7un1MBQ== Date: Wed, 23 Oct 2013 15:56:10 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.65.51.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <5414AEA3AA8BBD48A3D45FAF839BA9D2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 23 Oct 2013 15:56:19 -0000 The agenda looks great. One thing I would like to hear is - Discuss on how to progress these two WG drafts: http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ We have not had much progress on either of these drafts for quite some time now due to lack of reviews. Can we get some help here ? Regards, Ram -----Original Message----- From: , Andrew Date: Wednesday, 23 October 2013 9:08 PM To: "siprec@ietf.org" Subject: [siprec] IETF 88 - SIPREC Draft Agenda >Hi All, > >I posted a draft agenda which can be found at: >https://datatracker.ietf.org/meeting/88/agenda/siprec/. > >Please let me have any requests for changes/additions by Sunday 27th of >October. > >Regards >Andy >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From partha@parthasarathi.co.in Mon Oct 28 09:17:29 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 C28E011E8260 for ; Mon, 28 Oct 2013 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_40=-0.185] 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 Uu2D2tZDzkSo for ; Mon, 28 Oct 2013 09:17:23 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7B37D11E8170 for ; Mon, 28 Oct 2013 09:17:21 -0700 (PDT) Received: from userPC (unknown [122.172.177.100]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 9F796868A55; Mon, 28 Oct 2013 16:17:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1382977040; bh=pclGWrM2Xu5m/UO/1L08XRJ5xYQ9MBVOsxMW0dA/DCg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CjbFKaKWiumaFHk71Ex8gLC1JFVcxhSGS5Yqp68FLX0z5+1AYXCvPyvS9lqufKMos tz9skF0pAhbUWZAZNsXsK9sYM5/A5QI2QpjTQ2M3xEWafW+KwOMQhXBjBIfQXpbgM/ GSLvcCHvCO1dIHXnPRa60Qgx24NmzNZKsYxESNkk= From: "Parthasarathi R" To: "'Hutton, Andrew'" , "'Brian Rosen'" References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> In-Reply-To: Date: Mon, 28 Oct 2013 21:47:12 +0530 Message-ID: <001501ced3f9$2cec6390$86c52ab0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHO0AhkzKzOLskQY0areSK7un1MBZoKSq3A Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0208.526E8E10.00D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.157 Cc: siprec@ietf.org Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 28 Oct 2013 16:17:30 -0000 Hi Andy/Brian, I had raised my concern regarding Metadata draft status (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) as there is no much progress for 1 years 3 months (from last Vancouver meeting) without any changes. The multiple SIPREC implementation exists from different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft (http://www.linkedin.com/groups/Who-is-using-SIPREC-4263898.S.176535181) already. The comments from ACME & NICE are already incorporated in the latest draft. This clearly indicates that the metadata draft is matured enough to implement. AFAIK, each implementation would have gone through the draft carefully before implementing and it shall be considered as the review. Could you please let us know when is the plan to start WGLC for the metadata drafts or any other blocking draft for this draft. I'm also interested in knowing whether the new charter will have the impact in metadata draft. IMO, the new use case has to be considered as an extension to the metadata drafts. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, October 23, 2013 9:26 PM > To: Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > The agenda looks great. One thing I would like to hear is - > > Discuss on how to progress these two WG drafts: > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ > > We have not had much progress on either of these drafts for quite some > time now due to lack of reviews. Can we get some help here ? > > Regards, > Ram > > -----Original Message----- > From: , Andrew > Date: Wednesday, 23 October 2013 9:08 PM > To: "siprec@ietf.org" > Subject: [siprec] IETF 88 - SIPREC Draft Agenda > > >Hi All, > > > >I posted a draft agenda which can be found at: > >https://datatracker.ietf.org/meeting/88/agenda/siprec/. > > > >Please let me have any requests for changes/additions by Sunday 27th > of > >October. > > > >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 andrew.hutton@unify.com Mon Oct 28 10:28: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 866CD11E828D for ; Mon, 28 Oct 2013 10:28:31 -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.000, 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 nByeJ30DSHJG for ; Mon, 28 Oct 2013 10:28:27 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A411E819B for ; Mon, 28 Oct 2013 10:28:26 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CFFF01EB84B0; Mon, 28 Oct 2013 18:28:24 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 18:28:24 +0100 From: "Hutton, Andrew" To: Parthasarathi R , 'Brian Rosen' Thread-Topic: [siprec] IETF 88 - SIPREC Draft Agenda Thread-Index: Ac7QBfK35f3xBYKDRfqfYdPjGeXjUpoKSq3AmgJSZJA= Date: Mon, 28 Oct 2013 17:28:23 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> <001501ced3f9$2cec6390$86c52ab0$@co.in> In-Reply-To: <001501ced3f9$2cec6390$86c52ab0$@co.in> 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 Cc: "siprec@ietf.org" Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 28 Oct 2013 17:28:31 -0000 Hi Partha, I understand and share your concern on the lack of progress regarding the m= etadata draft. However the following is taken from the minutes of the last IETF meeting in= Berlin. >Metadata draft needs more review there is no presentation during this meet= ing on metadata. >Companies implementing SIPREC for NENA are expected to be at an interop ev= ent for NG911 implementations scheduled for fall (Nov.?>). 3-4 Implementati= ons expected to be there. Brian will ask the implementers for a review. An = experienced IETF reviewer is also >needed. Biggest concern is if all necess= ary semantic are defined. >Targeting interop events to look for reviewers. >- Brian Rosen: NENA (Next Generation 911) >- Charles Eckel: IMTC SIP Parity groups >ACTION: Need to find reviewers for metadata draft. The NENA interop event appears to be planned for next week (Same week as IE= TF88) maybe Brian can update us this. The IMTC event will not take place until next May and might not test SIPREC= stuff so probably we should not wait for that. I would really like to encourage those that have implemented the metadata d= raft to provide feedback on the SIPREC mailing list. Regards Andy (SIPREC Co-Chair).=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 28 October 2013 16:17 > To: Hutton, Andrew; 'Brian Rosen' > Cc: 'Ram Mohan R (rmohanr)'; siprec@ietf.org > Subject: RE: [siprec] IETF 88 - SIPREC Draft Agenda >=20 > Hi Andy/Brian, >=20 > I had raised my concern regarding Metadata draft status > (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) as > there is no much progress for 1 years 3 months (from last Vancouver > meeting) > without any changes. The multiple SIPREC implementation exists from > different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft > (http://www.linkedin.com/groups/Who-is-using-SIPREC- > 4263898.S.176535181) > already. The comments from ACME & NICE are already incorporated in the > latest draft. This clearly indicates that the metadata draft is matured > enough to implement. AFAIK, each implementation would have gone through > the > draft carefully before implementing and it shall be considered as the > review. Could you please let us know when is the plan to start WGLC for > the > metadata drafts or any other blocking draft for this draft. >=20 > I'm also interested in knowing whether the new charter will have the > impact > in metadata draft. IMO, the new use case has to be considered as an > extension to the metadata drafts. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: Wednesday, October 23, 2013 9:26 PM > > To: Hutton, Andrew; siprec@ietf.org > > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > > > The agenda looks great. One thing I would like to hear is - > > > > Discuss on how to progress these two WG drafts: > > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ > > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ > > > > We have not had much progress on either of these drafts for quite > some > > time now due to lack of reviews. Can we get some help here ? > > > > Regards, > > Ram > > > > -----Original Message----- > > From: , Andrew > > Date: Wednesday, 23 October 2013 9:08 PM > > To: "siprec@ietf.org" > > Subject: [siprec] IETF 88 - SIPREC Draft Agenda > > > > >Hi All, > > > > > >I posted a draft agenda which can be found at: > > >https://datatracker.ietf.org/meeting/88/agenda/siprec/. > > > > > >Please let me have any requests for changes/additions by Sunday 27th > > of > > >October. > > > > > >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 DAVE.HIGTON@nice.com Mon Oct 28 10:33:14 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 E096311E828B for ; Mon, 28 Oct 2013 10:33:14 -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=[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 v0rn91icSh7L for ; Mon, 28 Oct 2013 10:33:11 -0700 (PDT) Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4266E11E8341 for ; Mon, 28 Oct 2013 10:32:55 -0700 (PDT) Received: from mail pickup service by soumd01.eu.nice.com with Microsoft SMTPSVC; Mon, 28 Oct 2013 17:32:51 +0000 Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 17:31:49 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Mon, 28 Oct 2013 17:31:48 +0000 From: "Dave Higton" To: Date: Mon, 28 Oct 2013 17:31:44 +0000 Thread-Topic: [siprec] IETF 88 - SIPREC Draft Agenda Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Thread-Index: Ac7QBfK35f3xBYKDRfqfYdPjGeXjUpoKSq3AmgJSZJC0BKJPgA== Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B69405B9BE60C1@SOUEXC01.eu.nice.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net><001501ced3f9$2cec6390$86c52ab0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2013 17:31:49.0403 (UTC) FILETIME=[953BAEB0:01CED403] Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 28 Oct 2013 17:33:15 -0000 I am in a position to confirm that ICE 8 (the NENA interop event) is = scheduled for next week. All the signs are that it will go ahead as = planned. Dave -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Hutton, Andrew Sent: 28 October 2013 17:28 To: Parthasarathi R; 'Brian Rosen' Cc: siprec@ietf.org Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda Hi Partha, I understand and share your concern on the lack of progress regarding = the metadata draft. However the following is taken from the minutes of the last IETF meeting = in Berlin. >Metadata draft needs more review there is no presentation during this = meeting on metadata. >Companies implementing SIPREC for NENA are expected to be at an interop = event for NG911 implementations scheduled for fall (Nov.?>). 3-4 = Implementations expected to be there. Brian will ask the implementers = for a review. An experienced IETF reviewer is also >needed. Biggest = concern is if all necessary semantic are defined. >Targeting interop events to look for reviewers. >- Brian Rosen: NENA (Next Generation 911) >- Charles Eckel: IMTC SIP Parity groups >ACTION: Need to find reviewers for metadata draft. The NENA interop event appears to be planned for next week (Same week as = IETF88) maybe Brian can update us this. The IMTC event will not take place until next May and might not test = SIPREC stuff so probably we should not wait for that. I would really like to encourage those that have implemented the = metadata draft to provide feedback on the SIPREC mailing list. Regards Andy (SIPREC Co-Chair).=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 28 October 2013 16:17 > To: Hutton, Andrew; 'Brian Rosen' > Cc: 'Ram Mohan R (rmohanr)'; siprec@ietf.org > Subject: RE: [siprec] IETF 88 - SIPREC Draft Agenda >=20 > Hi Andy/Brian, >=20 > I had raised my concern regarding Metadata draft status > (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) = as > there is no much progress for 1 years 3 months (from last Vancouver > meeting) > without any changes. The multiple SIPREC implementation exists from > different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft > (http://www.linkedin.com/groups/Who-is-using-SIPREC- > 4263898.S.176535181) > already. The comments from ACME & NICE are already incorporated in the > latest draft. This clearly indicates that the metadata draft is = matured > enough to implement. AFAIK, each implementation would have gone = through > the > draft carefully before implementing and it shall be considered as the > review. Could you please let us know when is the plan to start WGLC = for > the > metadata drafts or any other blocking draft for this draft. >=20 > I'm also interested in knowing whether the new charter will have the > impact > in metadata draft. IMO, the new use case has to be considered as an > extension to the metadata drafts. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: Wednesday, October 23, 2013 9:26 PM > > To: Hutton, Andrew; siprec@ietf.org > > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > > > The agenda looks great. One thing I would like to hear is - > > > > Discuss on how to progress these two WG drafts: > > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ > > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ > > > > We have not had much progress on either of these drafts for quite > some > > time now due to lack of reviews. Can we get some help here ? > > > > Regards, > > Ram > > > > -----Original Message----- > > From: , Andrew > > Date: Wednesday, 23 October 2013 9:08 PM > > To: "siprec@ietf.org" > > Subject: [siprec] IETF 88 - SIPREC Draft Agenda > > > > >Hi All, > > > > > >I posted a draft agenda which can be found at: > > >https://datatracker.ietf.org/meeting/88/agenda/siprec/. > > > > > >Please let me have any requests for changes/additions by Sunday = 27th > > of > > >October. > > > > > >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 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec NICE Systems UK Limited ("NICE") is registered in England under company = number, 3403044. The registered office of NICE is at Tollbar Way, Hedge = End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for = the above-named persons only and may be confidential and/or legally = privileged. Any opinions expressed in this communication are not = necessarily those of NICE. If this communication has come to you in = error you must take no action based on it, nor must you copy or show it = to anyone; please delete/destroy and inform the sender by e-mail = immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail = and attachments are free from any virus, we advise that in keeping with = good computing practice the recipient should ensure they are actually = virus free. From msmith@dss-corp.com Mon Oct 28 10:42:02 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 CD4D321F9DAF for ; Mon, 28 Oct 2013 10:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 IOvIDOYww9EG for ; Mon, 28 Oct 2013 10:41:58 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 27F0721F9D05 for ; Mon, 28 Oct 2013 10:41:58 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so12239633iec.0 for ; Mon, 28 Oct 2013 10:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=6RAGlHzO9LUZfGbM/qEOjxAgHH66bmqX9YVtEewHnDg=; b=fLZ/uY4df/hAwNED6oBUUzDTBTrbJcIgdSvjp7CAOkvtQxygrONbNH9M6G+ZMbf7Xr hdnBmuRXDL1dTPj4YFCdKagFm1LDvdlvmJG3XBgjcx/AT1YNNY6ZsbIvKDLJjjV+XNEq I87m9dXWv9ffFrMW9ejErk4OsW9kaUepc3lpzfFs7HE6btyYOmFbepY68+0F/+tyVKxt 2IeEsBxwOQ6GS1PvVJebbRHhzYh9d8xA2iNyZ1Y1TLj2r1y65pp5CNJur9yEOFBt7lsm Xsb618HEQrjU1lb1RattljuxsL/Y5AgnGT5SDTpIWQBbNKG2rcJMyVr13eRE9ft6ZPN3 2zxQ== X-Gm-Message-State: ALoCoQnqRcjpI+P8XWAspPpz3TQBtqzfsZpQJwa2n61KmTwvY49WHKUWVQVD6sOHxls+cB6YbxSL X-Received: by 10.42.172.67 with SMTP id m3mr14417701icz.21.1382982117474; Mon, 28 Oct 2013 10:41:57 -0700 (PDT) Received: from mlsAW ([65.24.145.64]) by mx.google.com with ESMTPSA id cl4sm15197099igc.1.2013.10.28.10.41.56 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Oct 2013 10:41:57 -0700 (PDT) From: "Michael Smith" To: "'Hutton, Andrew'" , "'Parthasarathi R'" , "'Brian Rosen'" References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> <001501ced3f9$2cec6390$86c52ab0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net> Date: Mon, 28 Oct 2013 13:41:15 -0400 Message-ID: <006401ced404$e7695240$b63bf6c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7QBfK35f3xBYKDRfqfYdPjGeXjUpoKSq3AmgJSZJC0BKG+kA== Content-Language: en-us Cc: siprec@ietf.org Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 28 Oct 2013 17:42:03 -0000 About the NENA interop event (ICE 8) - it is indeed next week. We have about 17 companies that have implemented siprec (either SRC or SRS functionality). We are testing metadata too. I think that those of us who are also on this list will be more than happy to provide feedback based on our own experiences with the drafts. I think we're all swamped right now getting ready for the event, so bear with us, and I'm sure we'll have some comments once the smoke has cleared. - Michael Smith, ICE 8 Planning Committee chair Michael Smith Chief Technologist, DSS Corp. Ph: 606.877.2788 | Mobile: 606.231.0243 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Monday, October 28, 2013 1:28 PM To: Parthasarathi R; 'Brian Rosen' Cc: siprec@ietf.org Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda Hi Partha, I understand and share your concern on the lack of progress regarding the metadata draft. However the following is taken from the minutes of the last IETF meeting in Berlin. >Metadata draft needs more review there is no presentation during this meeting on metadata. >Companies implementing SIPREC for NENA are expected to be at an interop event for NG911 implementations scheduled for fall (Nov.?>). 3-4 Implementations expected to be there. Brian will ask the implementers for a review. An experienced IETF reviewer is also >needed. Biggest concern is if all necessary semantic are defined. >Targeting interop events to look for reviewers. >- Brian Rosen: NENA (Next Generation 911) >- Charles Eckel: IMTC SIP Parity groups >ACTION: Need to find reviewers for metadata draft. The NENA interop event appears to be planned for next week (Same week as IETF88) maybe Brian can update us this. The IMTC event will not take place until next May and might not test SIPREC stuff so probably we should not wait for that. I would really like to encourage those that have implemented the metadata draft to provide feedback on the SIPREC mailing list. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 28 October 2013 16:17 > To: Hutton, Andrew; 'Brian Rosen' > Cc: 'Ram Mohan R (rmohanr)'; siprec@ietf.org > Subject: RE: [siprec] IETF 88 - SIPREC Draft Agenda > > Hi Andy/Brian, > > I had raised my concern regarding Metadata draft status > (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) > as there is no much progress for 1 years 3 months (from last Vancouver > meeting) > without any changes. The multiple SIPREC implementation exists from > different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft > (http://www.linkedin.com/groups/Who-is-using-SIPREC- > 4263898.S.176535181) > already. The comments from ACME & NICE are already incorporated in the > latest draft. This clearly indicates that the metadata draft is > matured enough to implement. AFAIK, each implementation would have > gone through the draft carefully before implementing and it shall be > considered as the review. Could you please let us know when is the > plan to start WGLC for the metadata drafts or any other blocking draft > for this draft. > > I'm also interested in knowing whether the new charter will have the > impact in metadata draft. IMO, the new use case has to be considered > as an extension to the metadata drafts. > > Thanks > Partha > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Ram Mohan R (rmohanr) > > Sent: Wednesday, October 23, 2013 9:26 PM > > To: Hutton, Andrew; siprec@ietf.org > > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > > > The agenda looks great. One thing I would like to hear is - > > > > Discuss on how to progress these two WG drafts: > > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ > > http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ > > > > We have not had much progress on either of these drafts for quite > some > > time now due to lack of reviews. Can we get some help here ? > > > > Regards, > > Ram > > > > -----Original Message----- > > From: , Andrew > > Date: Wednesday, 23 October 2013 9:08 PM > > To: "siprec@ietf.org" > > Subject: [siprec] IETF 88 - SIPREC Draft Agenda > > > > >Hi All, > > > > > >I posted a draft agenda which can be found at: > > >https://datatracker.ietf.org/meeting/88/agenda/siprec/. > > > > > >Please let me have any requests for changes/additions by Sunday > > >27th > > of > > >October. > > > > > >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 _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@unify.com Mon Oct 28 13:52:17 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 729FC11E81E9 for ; Mon, 28 Oct 2013 13:52:17 -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.000, 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 3mhOZ2T-YHR0 for ; Mon, 28 Oct 2013 13:52:13 -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 60A5411E80F7 for ; Mon, 28 Oct 2013 13:52:13 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0236523F0489; Mon, 28 Oct 2013 21:52:12 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 21:52:11 +0100 From: "Hutton, Andrew" To: Michael Smith Thread-Topic: [siprec] IETF 88 - SIPREC Draft Agenda Thread-Index: Ac7QBfK35f3xBYKDRfqfYdPjGeXjUpoKSq3AmgJSZJC0BKG+kJf29HBJ Date: Mon, 28 Oct 2013 20:52:10 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> <001501ced3f9$2cec6390$86c52ab0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net>, <006401ced404$e7695240$b63bf6c0$@com> In-Reply-To: <006401ced404$e7695240$b63bf6c0$@com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 28 Oct 2013 20:52:17 -0000 Hi Michael, Thanks feedback from this type of event is exactly what we need to move thi= ngs forward. Looking forward to hearing how the event goes. Regards Andy On 28 Oct 2013, at 17:42, "Michael Smith" wrote: > About the NENA interop event (ICE 8) - it is indeed next week. We have ab= out > 17 companies that have implemented siprec (either SRC or SRS functionalit= y). > We are testing metadata too. I think that those of us who are also on thi= s > list will be more than happy to provide feedback based on our own > experiences with the drafts. >=20 > I think we're all swamped right now getting ready for the event, so bear > with us, and I'm sure we'll have some comments once the smoke has cleared= . >=20 > - Michael Smith, ICE 8 Planning Committee chair >=20 > Michael Smith > Chief Technologist, DSS Corp. > Ph: 606.877.2788 | Mobile: 606.231.0243 >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of > Hutton, Andrew > Sent: Monday, October 28, 2013 1:28 PM > To: Parthasarathi R; 'Brian Rosen' > Cc: siprec@ietf.org > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda >=20 > Hi Partha, >=20 > I understand and share your concern on the lack of progress regarding the > metadata draft. >=20 > However the following is taken from the minutes of the last IETF meeting = in > Berlin. >=20 >> Metadata draft needs more review there is no presentation during this > meeting on metadata. >> Companies implementing SIPREC for NENA are expected to be at an interop > event for NG911 implementations scheduled for fall (Nov.?>). 3-4 > Implementations expected to be there. Brian will ask the implementers for= a > review. An experienced IETF reviewer is also >needed. Biggest concern is = if > all necessary semantic are defined. >> Targeting interop events to look for reviewers. >> - Brian Rosen: NENA (Next Generation 911) >> - Charles Eckel: IMTC SIP Parity groups >> ACTION: Need to find reviewers for metadata draft. >=20 > The NENA interop event appears to be planned for next week (Same week as > IETF88) maybe Brian can update us this. >=20 > The IMTC event will not take place until next May and might not test SIPR= EC > stuff so probably we should not wait for that. >=20 > I would really like to encourage those that have implemented the metadata > draft to provide feedback on the SIPREC mailing list. >=20 > Regards > Andy (SIPREC Co-Chair).=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >> Sent: 28 October 2013 16:17 >> To: Hutton, Andrew; 'Brian Rosen' >> Cc: 'Ram Mohan R (rmohanr)'; siprec@ietf.org >> Subject: RE: [siprec] IETF 88 - SIPREC Draft Agenda >>=20 >> Hi Andy/Brian, >>=20 >> I had raised my concern regarding Metadata draft status >> (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) =20 >> as there is no much progress for 1 years 3 months (from last Vancouver >> meeting) >> without any changes. The multiple SIPREC implementation exists from=20 >> different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft >> (http://www.linkedin.com/groups/Who-is-using-SIPREC- >> 4263898.S.176535181) >> already. The comments from ACME & NICE are already incorporated in the=20 >> latest draft. This clearly indicates that the metadata draft is=20 >> matured enough to implement. AFAIK, each implementation would have=20 >> gone through the draft carefully before implementing and it shall be=20 >> considered as the review. Could you please let us know when is the=20 >> plan to start WGLC for the metadata drafts or any other blocking draft=20 >> for this draft. >>=20 >> I'm also interested in knowing whether the new charter will have the=20 >> impact in metadata draft. IMO, the new use case has to be considered=20 >> as an extension to the metadata drafts. >>=20 >> Thanks >> Partha >>=20 >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: Wednesday, October 23, 2013 9:26 PM >>> To: Hutton, Andrew; siprec@ietf.org >>> Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda >>>=20 >>> The agenda looks great. One thing I would like to hear is - >>>=20 >>> Discuss on how to progress these two WG drafts: >>> http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ >>> http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ >>>=20 >>> We have not had much progress on either of these drafts for quite >> some >>> time now due to lack of reviews. Can we get some help here ? >>>=20 >>> Regards, >>> Ram >>>=20 >>> -----Original Message----- >>> From: , Andrew >>> Date: Wednesday, 23 October 2013 9:08 PM >>> To: "siprec@ietf.org" >>> Subject: [siprec] IETF 88 - SIPREC Draft Agenda >>>=20 >>>> Hi All, >>>>=20 >>>> I posted a draft agenda which can be found at: >>>> https://datatracker.ietf.org/meeting/88/agenda/siprec/. >>>>=20 >>>> Please let me have any requests for changes/additions by Sunday=20 >>>> 27th >>> of >>>> October. >>>>=20 >>>> Regards >>>> Andy >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>=20 >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From partha@parthasarathi.co.in Mon Oct 28 17:18:55 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 BA2A411E81CB for ; Mon, 28 Oct 2013 17:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 v4j3vHFMLvW2 for ; Mon, 28 Oct 2013 17:18:51 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 31C6721F9C00 for ; Mon, 28 Oct 2013 17:18:42 -0700 (PDT) Received: from userPC (unknown [122.179.62.237]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 108B81908109; Tue, 29 Oct 2013 00:18:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1383005919; bh=d8BW9ZGcJnaBcaId8MBKyW6VHS3BODX/jqNgpbwxE08=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NVH65tjFRK84KK2Gy5KDTHsJLYevDGjqML7qow8Y72qB+q7iz7zgLv/KfhzrPWU32 1yWrMABs18DZQt79ltGFlyNG2ce3tKLdztXgluGkjNeyS8MAMUaqOnbeRB+yZfjGzw RdqdgvQ3aGLheQGTnxn7QVjX+Bkh/aaJKfOd7nms= From: "Parthasarathi R" To: "'Hutton, Andrew'" , "'Michael Smith'" References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> <001501ced3f9$2cec6390$86c52ab0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net>, <006401ced404$e7695240$b63bf6c0$@com> In-Reply-To: Date: Tue, 29 Oct 2013 05:48:27 +0530 Message-ID: <002601ced43c$6a0ce7c0$3e26b740$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7QBfK35f3xBYKDRfqfYdPjGeXjUpoKSq3AmgJSZJC0BKG+kJf29HBJ///MBXA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.526EFEDF.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: siprec@ietf.org Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 29 Oct 2013 00:18:56 -0000 Hi Andy and Michael, Thanks for the info. It will be good to see the feedback from ICE 8. Also, I hope that the new charter will not impact the metadata draft progress and the new usecase will incorporate its metadata enhancement in the respective draft itself. Thanks Partha > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@unify.com] > Sent: Tuesday, October 29, 2013 2:22 AM > To: Michael Smith > Cc: Hutton, Andrew; Parthasarathi R; Brian Rosen; siprec@ietf.org > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > Hi Michael, > > Thanks feedback from this type of event is exactly what we need to move > things forward. > > Looking forward to hearing how the event goes. > > Regards > Andy > > On 28 Oct 2013, at 17:42, "Michael Smith" wrote: > > > About the NENA interop event (ICE 8) - it is indeed next week. We > have about > > 17 companies that have implemented siprec (either SRC or SRS > functionality). > > We are testing metadata too. I think that those of us who are also on > this > > list will be more than happy to provide feedback based on our own > > experiences with the drafts. > > > > I think we're all swamped right now getting ready for the event, so > bear > > with us, and I'm sure we'll have some comments once the smoke has > cleared. > > > > - Michael Smith, ICE 8 Planning Committee chair > > > > Michael Smith > > Chief Technologist, DSS Corp. > > Ph: 606.877.2788 | Mobile: 606.231.0243 > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of > > Hutton, Andrew > > Sent: Monday, October 28, 2013 1:28 PM > > To: Parthasarathi R; 'Brian Rosen' > > Cc: siprec@ietf.org > > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > > > Hi Partha, > > > > I understand and share your concern on the lack of progress regarding > the > > metadata draft. > > > > However the following is taken from the minutes of the last IETF > meeting in > > Berlin. > > > >> Metadata draft needs more review there is no presentation during > this > > meeting on metadata. > >> Companies implementing SIPREC for NENA are expected to be at an > interop > > event for NG911 implementations scheduled for fall (Nov.?>). 3-4 > > Implementations expected to be there. Brian will ask the implementers > for a > > review. An experienced IETF reviewer is also >needed. Biggest concern > is if > > all necessary semantic are defined. > >> Targeting interop events to look for reviewers. > >> - Brian Rosen: NENA (Next Generation 911) > >> - Charles Eckel: IMTC SIP Parity groups > >> ACTION: Need to find reviewers for metadata draft. > > > > The NENA interop event appears to be planned for next week (Same week > as > > IETF88) maybe Brian can update us this. > > > > The IMTC event will not take place until next May and might not test > SIPREC > > stuff so probably we should not wait for that. > > > > I would really like to encourage those that have implemented the > metadata > > draft to provide feedback on the SIPREC mailing list. > > > > Regards > > Andy (SIPREC Co-Chair). > > > > > > > >> -----Original Message----- > >> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > >> Sent: 28 October 2013 16:17 > >> To: Hutton, Andrew; 'Brian Rosen' > >> Cc: 'Ram Mohan R (rmohanr)'; siprec@ietf.org > >> Subject: RE: [siprec] IETF 88 - SIPREC Draft Agenda > >> > >> Hi Andy/Brian, > >> > >> I had raised my concern regarding Metadata draft status > >> (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) > >> as there is no much progress for 1 years 3 months (from last > Vancouver > >> meeting) > >> without any changes. The multiple SIPREC implementation exists from > >> different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft > >> (http://www.linkedin.com/groups/Who-is-using-SIPREC- > >> 4263898.S.176535181) > >> already. The comments from ACME & NICE are already incorporated in > the > >> latest draft. This clearly indicates that the metadata draft is > >> matured enough to implement. AFAIK, each implementation would have > >> gone through the draft carefully before implementing and it shall be > >> considered as the review. Could you please let us know when is the > >> plan to start WGLC for the metadata drafts or any other blocking > draft > >> for this draft. > >> > >> I'm also interested in knowing whether the new charter will have the > >> impact in metadata draft. IMO, the new use case has to be considered > >> as an extension to the metadata drafts. > >> > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Ram Mohan R (rmohanr) > >>> Sent: Wednesday, October 23, 2013 9:26 PM > >>> To: Hutton, Andrew; siprec@ietf.org > >>> Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > >>> > >>> The agenda looks great. One thing I would like to hear is - > >>> > >>> Discuss on how to progress these two WG drafts: > >>> http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ > >>> http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ > >>> > >>> We have not had much progress on either of these drafts for quite > >> some > >>> time now due to lack of reviews. Can we get some help here ? > >>> > >>> Regards, > >>> Ram > >>> > >>> -----Original Message----- > >>> From: , Andrew > >>> Date: Wednesday, 23 October 2013 9:08 PM > >>> To: "siprec@ietf.org" > >>> Subject: [siprec] IETF 88 - SIPREC Draft Agenda > >>> > >>>> Hi All, > >>>> > >>>> I posted a draft agenda which can be found at: > >>>> https://datatracker.ietf.org/meeting/88/agenda/siprec/. > >>>> > >>>> Please let me have any requests for changes/additions by Sunday > >>>> 27th > >>> of > >>>> October. > >>>> > >>>> 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 > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > From pkyzivat@alum.mit.edu Tue Oct 29 09:49:40 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 5C92721E8089 for ; Tue, 29 Oct 2013 09:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=0.202, 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 AqCiTzw4EyHU for ; Tue, 29 Oct 2013 09:49:35 -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 4031821F9BB1 for ; Tue, 29 Oct 2013 09:47:25 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id j2XM1m00X0mv7h05B4nE6d; Tue, 29 Oct 2013 16:47:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id j4nD1m0153ZTu2S3X4nDh2; Tue, 29 Oct 2013 16:47:13 +0000 Message-ID: <526FE691.8090005@alum.mit.edu> Date: Tue, 29 Oct 2013 12:47:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> <001501ced3f9$2cec6390$86c52ab0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net> <006401ced404$e7695240$b63bf6c0$@com> In-Reply-To: <006401ced404$e7695240$b63bf6c0$@com> 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=1383065234; bh=1oLxm/bEdtGiVz20RNx38q1pBEDZCh+UkkV9CTsd6o8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qAXWWvuNFnNf4My11fhnpstxWja1IyEEwky+4OBo/DUvgBlcwagYgt+PVHbRtS28q ADQ7b2cGny8W7QxCIxQSKy+N6NPsYaafF7+VgYRmzuNvpDTQx5dtQNMvTIFikRUvxW rRWQsFQpLNXHHCFm0HAMLpXK8pN95qYqr/aBiEho0M0hQL+0pDz6sxTfmNDoVmZAUB aPvZWrFJirmZDLLDOjf1leFXpRdLgU06jJsi30iniTqy4mql7cuKKkFRUISpYuNFPq gEd5+ouzEQuqK2Syt/LI4/f0k9DNyeM7wPNpeRdV1M+D4FgyOoePhzykG0L6wEM92Y nOA8vVUsyXtTA== Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 29 Oct 2013 16:49:40 -0000 This is great news. I look forward to the feedback. Even better if you can extract some real life examples from it, to replace or supplement the synthetic ones we have now. Thanks, Paul On 10/28/13 1:41 PM, Michael Smith wrote: > About the NENA interop event (ICE 8) - it is indeed next week. We have about > 17 companies that have implemented siprec (either SRC or SRS functionality). > We are testing metadata too. I think that those of us who are also on this > list will be more than happy to provide feedback based on our own > experiences with the drafts. > > I think we're all swamped right now getting ready for the event, so bear > with us, and I'm sure we'll have some comments once the smoke has cleared. > > - Michael Smith, ICE 8 Planning Committee chair > > Michael Smith > Chief Technologist, DSS Corp. > Ph: 606.877.2788 | Mobile: 606.231.0243 > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Hutton, Andrew > Sent: Monday, October 28, 2013 1:28 PM > To: Parthasarathi R; 'Brian Rosen' > Cc: siprec@ietf.org > Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda > > Hi Partha, > > I understand and share your concern on the lack of progress regarding the > metadata draft. > > However the following is taken from the minutes of the last IETF meeting in > Berlin. > >> Metadata draft needs more review there is no presentation during this > meeting on metadata. >> Companies implementing SIPREC for NENA are expected to be at an interop > event for NG911 implementations scheduled for fall (Nov.?>). 3-4 > Implementations expected to be there. Brian will ask the implementers for a > review. An experienced IETF reviewer is also >needed. Biggest concern is if > all necessary semantic are defined. >> Targeting interop events to look for reviewers. >> - Brian Rosen: NENA (Next Generation 911) >> - Charles Eckel: IMTC SIP Parity groups >> ACTION: Need to find reviewers for metadata draft. > > The NENA interop event appears to be planned for next week (Same week as > IETF88) maybe Brian can update us this. > > The IMTC event will not take place until next May and might not test SIPREC > stuff so probably we should not wait for that. > > I would really like to encourage those that have implemented the metadata > draft to provide feedback on the SIPREC mailing list. > > Regards > Andy (SIPREC Co-Chair). > > > >> -----Original Message----- >> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >> Sent: 28 October 2013 16:17 >> To: Hutton, Andrew; 'Brian Rosen' >> Cc: 'Ram Mohan R (rmohanr)'; siprec@ietf.org >> Subject: RE: [siprec] IETF 88 - SIPREC Draft Agenda >> >> Hi Andy/Brian, >> >> I had raised my concern regarding Metadata draft status >> (http://www.ietf.org/mail-archive/web/siprec/current/msg03771.html) >> as there is no much progress for 1 years 3 months (from last Vancouver >> meeting) >> without any changes. The multiple SIPREC implementation exists from >> different vendors namely ACME, NICE, AudioCodec, ORCx, HP, Broadsoft >> (http://www.linkedin.com/groups/Who-is-using-SIPREC- >> 4263898.S.176535181) >> already. The comments from ACME & NICE are already incorporated in the >> latest draft. This clearly indicates that the metadata draft is >> matured enough to implement. AFAIK, each implementation would have >> gone through the draft carefully before implementing and it shall be >> considered as the review. Could you please let us know when is the >> plan to start WGLC for the metadata drafts or any other blocking draft >> for this draft. >> >> I'm also interested in knowing whether the new charter will have the >> impact in metadata draft. IMO, the new use case has to be considered >> as an extension to the metadata drafts. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Ram Mohan R (rmohanr) >>> Sent: Wednesday, October 23, 2013 9:26 PM >>> To: Hutton, Andrew; siprec@ietf.org >>> Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda >>> >>> The agenda looks great. One thing I would like to hear is - >>> >>> Discuss on how to progress these two WG drafts: >>> http://tools.ietf.org/wg/siprec/draft-ietf-siprec-metadata/ >>> http://tools.ietf.org/wg/siprec/draft-ietf-siprec-callflows/ >>> >>> We have not had much progress on either of these drafts for quite >> some >>> time now due to lack of reviews. Can we get some help here ? >>> >>> Regards, >>> Ram >>> >>> -----Original Message----- >>> From: , Andrew >>> Date: Wednesday, 23 October 2013 9:08 PM >>> To: "siprec@ietf.org" >>> Subject: [siprec] IETF 88 - SIPREC Draft Agenda >>> >>>> Hi All, >>>> >>>> I posted a draft agenda which can be found at: >>>> https://datatracker.ietf.org/meeting/88/agenda/siprec/. >>>> >>>> Please let me have any requests for changes/additions by Sunday >>>> 27th >>> of >>>> October. >>>> >>>> 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 > > _______________________________________________ > 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 Oct 29 10:00:52 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 BAD1621E8097 for ; Tue, 29 Oct 2013 10:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.200, 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 hCwyWQpEH5e8 for ; Tue, 29 Oct 2013 10:00:47 -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 0BB5A21E8188 for ; Tue, 29 Oct 2013 09:45:16 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id izsX1m0041swQuc514lGfW; Tue, 29 Oct 2013 16:45:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id j4lF1m0163ZTu2S3b4lGPd; Tue, 29 Oct 2013 16:45:16 +0000 Message-ID: <526FE61B.6090204@alum.mit.edu> Date: Tue, 29 Oct 2013 12:45:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Parthasarathi R , "'Hutton, Andrew'" , 'Michael Smith' References: <9F33F40F6F2CD847824537F3C4E37DDF17C05C82@MCHP04MSX.global-ad.net> <001501ced3f9$2cec6390$86c52ab0$@co.in> <9F33F40F6F2CD847824537F3C4E37DDF17C20C0F@MCHP04MSX.global-ad.net>, <006401ced404$e7695240$b63bf6c0$@com> <002601ced43c$6a0ce7c0$3e26b740$@co.in> In-Reply-To: <002601ced43c$6a0ce7c0$3e26b740$@co.in> 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=1383065116; bh=GQgQMnXPhjtefbpGD4umPqOZZ/xwsum7gbgvoRoq6Us=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nr2xuVtw7dUvXmbcUr0jhW+VUTOR/z7aqfMGWmodIs4Qy2mZl84B1R9PEX8vrTV+y F2ClEvpbPwmqGrhjWpn2ciwSCHUBNGPcPPPndjFraMxNhoTMRJN409aKOd8tH73lnj o3GPczvH3u1M7/YXVkFLEmqu80Cqb8O30GgAB8NScQKMNfvNqRdjDLzuf19PDeKd26 M2WhwECz2ko/Vz//rgyrC8pC5lnv4kwu2Lgyw2Zetg27MBELoCQK0mfhtPiMcEuV4o mwwoltaz01OH2lEMiGfBP9PBeJjotIM+lrrCnjvwDXU//DCpkC8IUijZixgHzYWcAj KX9kHxWMk9/4g== Cc: siprec@ietf.org Subject: Re: [siprec] IETF 88 - SIPREC Draft Agenda 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, 29 Oct 2013 17:00:52 -0000 On 10/28/13 8:18 PM, Parthasarathi R wrote: > Also, I hope that the new charter will not impact the metadata draft > progress and the new usecase will incorporate its metadata enhancement in > the respective draft itself. It has never been our intent to slow down the existing work. We just want to prime the pipeline for things to follow that. IMO it would be fine for the chairs to do whatever they must to ensure work is suitably prioritized. In my own case, having been involved with the metadata from the beginning, I view my part as "done" unless reviews by others identify things that need fixing. Thanks, Paul From andrew.hutton@unify.com Wed Oct 30 08:47: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 3B9A221F8C65 for ; Wed, 30 Oct 2013 08:47:49 -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.000, 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 h57JA04bdHyU for ; Wed, 30 Oct 2013 08:47:45 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 29CEE11E8179 for ; Wed, 30 Oct 2013 08:47:19 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E64B51EB8598; Wed, 30 Oct 2013 16:47:10 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.69]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Wed, 30 Oct 2013 16:47:10 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-architecture-09.txt Thread-Index: AQHOzCExixzvPz408Eu3W6OhmjaQbJoNdi8A Date: Wed, 30 Oct 2013 15:47:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C260A9@MCHP04MSX.global-ad.net> References: <20131018105709.2277.86896.idtracker@ietfa.amsl.com> <52616526.30602@alum.mit.edu> In-Reply-To: <52616526.30602@alum.mit.edu> 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: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-09.txt 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, 30 Oct 2013 15:47:49 -0000 Hi Paul, Thanks for looking through the changes and spotting this I will fix this. Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 18 October 2013 17:43 > To: siprec@ietf.org > Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-09.txt >=20 > I just looked at the diffs for this new version. All seem benign > editorial things, except for one. The most recent change in section > 3.1.3 garbled things. That change should be undone. >=20 > Thanks, > Paul >=20 > On 10/18/13 6:57 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the SIP Recording Working Group of the > IETF. > > > > Title : An Architecture for Media Recording using the > Session Initiation Protocol > > Author(s) : Andrew Hutton > > Leon Portman > > Rajnish Jain > > Ken Rehor > > Filename : draft-ietf-siprec-architecture-09.txt > > Pages : 16 > > Date : 2013-10-18 > > > > 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 IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-siprec-architecture > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-siprec-architecture-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-architecture-09 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec