From henry.lum@genesyslab.com Wed Jul 3 21:32:43 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 44ECE11E80D1 for ; Wed, 3 Jul 2013 21:32:43 -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 SNSnGxm5LmIu for ; Wed, 3 Jul 2013 21:32:37 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 961FC11E8125 for ; Wed, 3 Jul 2013 21:32:37 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Thu, 04 Jul 2013 00:32:34 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 21:32:32 -0700 From: Henry Lum To: "siprec@ietf.org" Thread-Topic: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOeG7m+U/RGXD6L0ClgjKYqCRXQ5lT7VSH Date: Thu, 4 Jul 2013 04:32:31 +0000 Message-ID: References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> In-Reply-To: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.212.200.234] MIME-Version: 1.0 X-MC-Unique: 113070400323400302 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Thu, 04 Jul 2013 04:32:43 -0000 Hi - this is an initial draft about recording IVR sessions. I want to see i= f there is interest in working out more details about IVR recording=0A=0AI'= d be happy to present for the meeting if there is time for this.=0A=0AThank= s=0AHenry=0A=0A________________________________________=0AFrom: internet-dr= afts@ietf.org [internet-drafts@ietf.org]=0ASent: Thursday, July 04, 2013 12= :28 AM=0ATo: Henry Lum=0ASubject: New Version Notification for draft-lum-si= prec-vxml-00.txt=0A=0AA new version of I-D, draft-lum-siprec-vxml-00.txt=0A= has been successfully submitted by Henry Lum and posted to the=0AIETF repos= itory.=0A=0AFilename: draft-lum-siprec-vxml=0ARevision: 00=0A= Title: Recording VoiceXML sessions with SIPREC=0ACreation date: = 2013-07-04=0AGroup: Individual Submission=0ANumber of pages: 6= =0AURL: http://www.ietf.org/internet-drafts/draft-lum-siprec-vx= ml-00.txt=0AStatus: http://datatracker.ietf.org/doc/draft-lum-sipr= ec-vxml=0AHtmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml= -00=0A=0A=0AAbstract:=0A This document addresses the use case of recordin= g Interactive Voice=0A Response (IVR) VoiceXML applications using the SIP= REC protocol. This=0A document also provides a potential solution for ca= pturing additional=0A information about the call flow within the VoiceXML= application from=0A a recording perspective.=0A=0A=0A=0A=0AThe IETF Secr= etariat=0A=0A From pkyzivat@alum.mit.edu Sun Jul 7 11:50:46 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 296CD21F9A57 for ; Sun, 7 Jul 2013 11:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=0.403, 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 0EGMVC0HXyyO for ; Sun, 7 Jul 2013 11:50:41 -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 3A84B21F9A61 for ; Sun, 7 Jul 2013 11:50:40 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id xVP61l0011ei1Bg51WqbC0; Sun, 07 Jul 2013 18:50:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id xWqb1l0083ZTu2S3kWqbWq; Sun, 07 Jul 2013 18:50:35 +0000 Message-ID: <51D9B87A.3080409@alum.mit.edu> Date: Sun, 07 Jul 2013 14:50:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: siprec@ietf.org References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373223035; bh=wmQzAmtZUIpczQzuTudvttFz3eNhrTaUGrakHPxKBMc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=haIrDio5dodLcQEY2xEDyMbvejU7c8doljnern9JUXhDoPCgAZdr3eae60/BsU19G 9a3/nCHJmNK7D1tbRTppocsLO8OOhfYA+GZiUhSMcXkryJvrmYqwCKu6e1DLcNhXD1 wTy91lRGc+eWRhIWfhkS0rfNTlnfQn/hLALvwu0SJJn/q3Sufjb+zPcZVVJ58b2Qij COPWQsuxEvCpfC/6oDscqXGUMwp+ufC3K9nKGoVDmrhOoNLVRs/XkVqbqrt6J/km09 OfPbnU0Z8MP4XOaoj2KGkXB4VQ5kSt/EjCsBE+2J5nQQERDtK3VPqXGuu2043aqMlW xZQqlAM3h8R/A== Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Sun, 07 Jul 2013 18:50:46 -0000 On 7/4/13 12:32 AM, Henry Lum wrote: > Hi - this is an initial draft about recording IVR sessions. I want to see if there is interest in working out more details about IVR recording I'm interested in hearing what you have in mind. At one level these should already be covered. You must want to capture some additional information. Is it that you want to record the VXML? Thanks, Paul > I'd be happy to present for the meeting if there is time for this. > > Thanks > Henry > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Thursday, July 04, 2013 12:28 AM > To: Henry Lum > Subject: New Version Notification for draft-lum-siprec-vxml-00.txt > > A new version of I-D, draft-lum-siprec-vxml-00.txt > has been successfully submitted by Henry Lum and posted to the > IETF repository. > > Filename: draft-lum-siprec-vxml > Revision: 00 > Title: Recording VoiceXML sessions with SIPREC > Creation date: 2013-07-04 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-lum-siprec-vxml-00.txt > Status: http://datatracker.ietf.org/doc/draft-lum-siprec-vxml > Htmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml-00 > > > Abstract: > This document addresses the use case of recording Interactive Voice > Response (IVR) VoiceXML applications using the SIPREC protocol. This > document also provides a potential solution for capturing additional > information about the call flow within the VoiceXML application from > a recording perspective. > > > > > The IETF Secretariat > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From krehor@cisco.com Sun Jul 7 12:05:03 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 4996221F9B0A for ; Sun, 7 Jul 2013 12:05:03 -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 rtva3cqi8qap for ; Sun, 7 Jul 2013 12:04:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7471121F99CF for ; Sun, 7 Jul 2013 12:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2393; q=dns/txt; s=iport; t=1373223898; x=1374433498; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Vj03ZOyMVEmuuafh7ho5SPzgvCVIMdUVOhoTkb6xr7g=; b=JF/35z/mXteYzHK4hCyxBEPXLO4W67TVeURgx6Ny8c7TI7yzc6hs/PJP IR0bVhUhER3D0KMx0nAuPJUzK3++yvkA6CmPQ/MBePJzIcs0lUHA+bK/W 6plHJUXxCkitQGFnmV71b5hspQA6MtfMu7RhRcegYm1K8BfDsDtybdknx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAM+62VGtJXG8/2dsb2JhbABaDoJ7MkrAYIEIFnSCIwEBAQEDAQEBNzQJFAEIDgMEAQEBChQ3CxwBCAIEARIIARKHdAy3Z486OIMGaQOYfJAfglM+gig X-IronPort-AV: E=Sophos;i="4.87,1014,1363132800"; d="scan'208";a="231829695" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2013 19:04:58 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r67J4vWA011772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Jul 2013 19:04:57 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.92]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 7 Jul 2013 14:04:57 -0500 From: "Ken Rehor (krehor)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOe0TfO1jk8X2CsUOKG2GFzQEpiA== Date: Sun, 7 Jul 2013 19:04:57 +0000 Message-ID: <9A740EB0DAB93C45A43D8EC2B61A18F81DC3E53C@xmb-aln-x09.cisco.com> In-Reply-To: <51D9B87A.3080409@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.20.172.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <4EC68F7B1BBE084D91CE3C430A21D8BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Sun, 07 Jul 2013 19:05:03 -0000 Yes, there are many use cases for recording the IVR portion of a call. FYI I worked out a lot of design ideas several years ago when we were still working on VoiceXML 3.0 in the W3C. I'll dig up my proposal and forward to the group. Ken On 7/7/13 11:50 AM, "Paul Kyzivat" wrote: >On 7/4/13 12:32 AM, Henry Lum wrote: >> Hi - this is an initial draft about recording IVR sessions. I want to >>see if there is interest in working out more details about IVR recording > >I'm interested in hearing what you have in mind. >At one level these should already be covered. You must want to capture >some additional information. Is it that you want to record the VXML? > > Thanks, > Paul > >> I'd be happy to present for the meeting if there is time for this. >> >> Thanks >> Henry >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Thursday, July 04, 2013 12:28 AM >> To: Henry Lum >> Subject: New Version Notification for draft-lum-siprec-vxml-00.txt >> >> A new version of I-D, draft-lum-siprec-vxml-00.txt >> has been successfully submitted by Henry Lum and posted to the >> IETF repository. >> >> Filename: draft-lum-siprec-vxml >> Revision: 00 >> Title: Recording VoiceXML sessions with SIPREC >> Creation date: 2013-07-04 >> Group: Individual Submission >> Number of pages: 6 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-lum-siprec-vxml-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lum-siprec-vxml >> Htmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml-00 >> >> >> Abstract: >> This document addresses the use case of recording Interactive Voice >> Response (IVR) VoiceXML applications using the SIPREC protocol. >>This >> document also provides a potential solution for capturing additional >> information about the call flow within the VoiceXML application from >> a recording perspective. >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> 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 michael.yan@huawei.com Sun Jul 7 19:54:34 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 628FC21F874E for ; Sun, 7 Jul 2013 19:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8mXUxAI+Uy2 for ; Sun, 7 Jul 2013 19:54:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADBEB21F8E97 for ; Sun, 7 Jul 2013 19:54:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUT61120; Mon, 08 Jul 2013 02:54:19 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 03:54:04 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Jul 2013 03:54:16 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.161]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Mon, 8 Jul 2013 10:54:09 +0800 From: "Yanqiang (Michael)" To: Henry Lum , "siprec@ietf.org" Thread-Topic: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: Ac57hmqOWYNNqUo6RIKhk9o42fsOMw== Date: Mon, 8 Jul 2013 02:54:09 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B3137234F@szxeml561-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Mon, 08 Jul 2013 02:54:34 -0000 SGkgSGVucnksDQoNCglUaGF0J3MgY29vbCB0byBzZWUgeW91IG1ha2UgYSBzdGFydCBmb3IgdGhl IElWUiByZWNvcmRpbmcuIEkgYWdyZWUgdGhlIElWUiByZWNvcmRpbmcgaXMgYWxzbyBub3QgZnVs ZmlsbGVkIHdlbGwgYXMgY29uZmVyZW5jZSBjYXNlLCB0aG91Z2ggUkZDNjM0MSBoYWQgYWxyZWFk eSBkZWZpbmVkIElWUiByZWNvcmRpbmcgY2FzZS4NCg0KCU1vc3QgdGltZSB3ZSByZWNvcmQgdGhl IGVudGlyZSBJVlIgdHJhY2sgaXMgdG8gbWFrZSBhIHN0YXRpc3RpYyB0aGF0IHdpbGwgYmUgaGVs cGZ1bCB0byB0dW5lIHRoZSBJVlIgbm9kZXMgZm9yIGJldHRlciBjdXN0b21lcidzIHNlcnZpY2Ug cGVyZm9ybWFuY2UgKHRoYXQncyBhcHBsaWNhdGlvbiBwZXJmb3JtYW5jZSB0dW5pbmcgYXMgeW91 IG1lbnRpb25lZCkuIEFuZCBpbiBvdGhlciB0aW1lLCB3ZSByZWNvcmQgdGhlIHZvaWNlIGFubm91 bmNlbWVudCwgbGlrZSBiYWxhbmNlIG9mIGRlYml0IGNhcmQsIHRvIGRlYWwgdGhlIGN1c3RvbWVy J3MgY29tcGxhaW50cyBvciBkaXNwdXRlcyAoaXMgaXQgdGhlIHZvaWNlIGFwcGxpY2F0aW9uIHJl Y29yZGluZyB5b3UgbWVudGlvbmVkPykuIEl0IHdpbGwgYmUgYXBwcmVjaWF0ZWQgdG8gZmlndXJl IG91dCBtb3JlIHB1cnBvc2VzIHdoaWNoIG1pZ2h0IGhlbHAgc29tZXRoaW5nIG9uIHRoZSBwcm9w b3NhbCBvZiByZXF1aXJlbWVudCBhbmQgc29sdXRpb24uIDopDQoNClRoYW5rcywNCk1pY2hhZWwN Cg== From henry.lum@genesyslab.com Mon Jul 8 13:00: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 DAE5A21F93E5 for ; Mon, 8 Jul 2013 13:00:33 -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 X1JPkXPovsoq for ; Mon, 8 Jul 2013 13:00:28 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id C4AE721F9473 for ; Mon, 8 Jul 2013 13:00:25 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Mon, 08 Jul 2013 16:00:21 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 13:00:18 -0700 From: Henry Lum To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOe0LlglPBNJwrXk+qoccqgtS+qplbM1bg Date: Mon, 8 Jul 2013 20:00:17 +0000 Message-ID: References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> In-Reply-To: <51D9B87A.3080409@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.16] MIME-Version: 1.0 X-MC-Unique: 113070816002103401 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Mon, 08 Jul 2013 20:00:34 -0000 Beyond the additional controls available in the VXML session itself, one us= e case for additional metadata collection is important waypoints and data i= n the VXML session. While it's possible to simply log all forms and fields = entered but that can be way too much detail for a complex VXML application.= Instead, it would be useful on the recording side to know whether the sess= ion have arrived at a certain point in the application and whether certain = pieces of data has been collected. I mentioned the use of namelist w= hich is a standard mechanism in RFC5552 for passing parameters at the end o= f the session. Regards, Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: July-07-13 2:51 PM To: siprec@ietf.org Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxm= l-00.txt On 7/4/13 12:32 AM, Henry Lum wrote: > Hi - this is an initial draft about recording IVR sessions. I want to see= if there is interest in working out more details about IVR recording I'm interested in hearing what you have in mind. At one level these should already be covered. You must want to capture=20 some additional information. Is it that you want to record the VXML? =09Thanks, =09Paul > I'd be happy to present for the meeting if there is time for this. > > Thanks > Henry > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Thursday, July 04, 2013 12:28 AM > To: Henry Lum > Subject: New Version Notification for draft-lum-siprec-vxml-00.txt > > A new version of I-D, draft-lum-siprec-vxml-00.txt > has been successfully submitted by Henry Lum and posted to the > IETF repository. > > Filename: draft-lum-siprec-vxml > Revision: 00 > Title: Recording VoiceXML sessions with SIPREC > Creation date: 2013-07-04 > Group: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-lum-siprec-vxm= l-00.txt > Status: http://datatracker.ietf.org/doc/draft-lum-siprec-vxml > Htmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml-00 > > > Abstract: > This document addresses the use case of recording Interactive Voice > Response (IVR) VoiceXML applications using the SIPREC protocol. This > document also provides a potential solution for capturing additional > information about the call flow within the VoiceXML application from > a recording perspective. > > > > > The IETF Secretariat > > > > _______________________________________________ > 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 internet-drafts@ietf.org Sat Jul 13 09:34:47 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 B752421F9E0C; Sat, 13 Jul 2013 09:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 s7MtjCgz2SBd; Sat, 13 Jul 2013 09:34:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF621F9D31; Sat, 13 Jul 2013 09:34:47 -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.51.p2 Message-ID: <20130713163447.27470.77122.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 09:34:47 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-callflows-01.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: Sat, 13 Jul 2013 16:34:47 -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 Initiation Protocol (SIP) Recording Call Flows Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-callflows-01.txt Pages : 31 Date : 2013-07-13 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 lists call flows that has snapshot of metadata sent from SRC to SRS, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined in the metadata draft. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-callflows-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-callflows-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rmohanr@cisco.com Sat Jul 13 09:39: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 DE81721F9ECE for ; Sat, 13 Jul 2013 09:39:01 -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 AWJVDHwfTsCJ for ; Sat, 13 Jul 2013 09:38:57 -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 13AB821F9EAD for ; Sat, 13 Jul 2013 09:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2927; q=dns/txt; s=iport; t=1373733537; x=1374943137; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+XMhzbsHSbfr9nuDP9Cwsl+N9KXaynFD27PgVjLNBHQ=; b=UCzCs3fwmwXPDkqbrtWuG7M+lyc64nCXBzbDNULZzUbW8sp0vbBT+alF TJoYY3AjktZ5cwihwn0ziDHA2XAGvW88KM3nrNk8e9ibj+JQnmt7B5lgC jB36fniNBfXER1YrLMwDtltKXe8RjZrcI6FHA9gFVOM/99kSONSL2gnHL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAAKC4VGtJXG9/2dsb2JhbABagwY0SQbBW4EIFnSCIwEBAQQBAQE3NBsCAQgRAQMBAQsUECcLFwYIAgQTCAGIBwcFthaPMziDC20DmQWQJIMSgig X-IronPort-AV: E=Sophos;i="4.89,659,1367971200"; d="scan'208";a="234243145" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jul 2013 16:38:56 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6DGcuCp010070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 13 Jul 2013 16:38:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.242]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sat, 13 Jul 2013 11:38:55 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-callflows-01.txt Thread-Index: AQHOf+b7raG+riAIbUWl4KNT3DvGRplizm7W Date: Sat, 13 Jul 2013 16:38:55 +0000 Message-ID: References: <20130713163447.27470.77122.idtracker@ietfa.amsl.com> In-Reply-To: <20130713163447.27470.77122.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.53.239] 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-callflows-01.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: Sat, 13 Jul 2013 16:39:02 -0000 Hi All,=0A= =0A= I just published a new revision of call flow draft.=0A= =0A= To summarise the changes are:=0A= 1) Added SIP snippets to all the messages.=0A= 2) Re-arranged the flows in to three major categories depending on the arc= hitecture the SRC is in. =0A= 3)Added more examples than what was in previous revision.=0A= 4) Incorporated the comments on hold/resume that was discussed after IETF 8= 6 ( representing hold and resume by the presence or absence of and <= recv> XML tags)=0A= =0A= Your comments and suggestions on how to improve the document are welcome. = =0A= =0A= Regards,=0A= Ram=0A= =0A= ________________________________________=0A= From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] on behalf of intern= et-drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Saturday, July 13, 2013 10:04 PM=0A= To: i-d-announce@ietf.org=0A= Cc: siprec@ietf.org=0A= Subject: [siprec] I-D Action: draft-ietf-siprec-callflows-01.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the SIP Recording Working Group of the IETF.= =0A= =0A= Title : Session Initiation Protocol (SIP) Recording Call = Flows=0A= Author(s) : Ram Mohan Ravindranath=0A= Parthasarathi Ravindran=0A= Paul Kyzivat=0A= Filename : draft-ietf-siprec-callflows-01.txt=0A= Pages : 31=0A= Date : 2013-07-13=0A= =0A= Abstract:=0A= Session recording is a critical requirement in many communications=0A= environments such as call centers and financial trading. In some of=0A= these environments, all calls must be recorded for regulatory,=0A= compliance, and consumer protection reasons. Recording of a session=0A= is typically performed by sending a copy of a media stream to a=0A= recording device. This document lists call flows that has snapshot=0A= of metadata sent from SRC to SRS, the metadata format for which is=0A= described in [I-D.ietf-siprec-metadata] . This is purely an=0A= informational document that is written to support the model defined=0A= in the metadata draft.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-siprec-callflows=0A= =0A= There's also a htmlized version available at:=0A= http://tools.ietf.org/html/draft-ietf-siprec-callflows-01=0A= =0A= A diff from the previous version is available at:=0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-callflows-01=0A= =0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= _______________________________________________=0A= siprec mailing list=0A= siprec@ietf.org=0A= https://www.ietf.org/mailman/listinfo/siprec=0A= From andrew.hutton@siemens-enterprise.com Mon Jul 15 07:30:38 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C920811E814C for ; Mon, 15 Jul 2013 07:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 bgzSLVuvoBbP for ; Mon, 15 Jul 2013 07:30:29 -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 5A66111E813D for ; Mon, 15 Jul 2013 07:30:05 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5415E1EB85E9; Mon, 15 Jul 2013 16:30:04 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 16:30:04 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" , Paul Kyzivat , Henry Lum Thread-Topic: IETF87 SIPREC Draft Agenda Thread-Index: Ac6BZ8tZgh1LBqG6SQKiRjZUujJnkQ== Date: Mon, 15 Jul 2013 14:30:03 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11645356@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_9F33F40F6F2CD847824537F3C4E37DDF11645356MCHP04MSXglobal_" MIME-Version: 1.0 Cc: "Rosen, Brian" Subject: [siprec] IETF87 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, 15 Jul 2013 14:30:39 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF11645356MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I posted a draft agenda for the IETF87 SIPREC Meeting. Please check and let me know if you have any issues or requests relating to= the agenda. Regards Andy --_000_9F33F40F6F2CD847824537F3C4E37DDF11645356MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I posted a draft agenda for the IETF87 SIPREC Meeting.
 
Please check and let me know if you have any issues or requests relati= ng to the agenda.
 
Regards
Andy
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF11645356MCHP04MSXglobal_-- From pkyzivat@alum.mit.edu Mon Jul 15 08:07:37 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 94D6B11E8126 for ; Mon, 15 Jul 2013 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=0.243, 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 aC0Ol35sIuN2 for ; Mon, 15 Jul 2013 08:07:31 -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 87D9C11E80FF for ; Mon, 15 Jul 2013 08:07:30 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id 0be11m0030QuhwU51f7WRa; Mon, 15 Jul 2013 15:07:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 0f7V1m00x3ZTu2S3Nf7VKZ; Mon, 15 Jul 2013 15:07:30 +0000 Message-ID: <51E41031.7040903@alum.mit.edu> Date: Mon, 15 Jul 2013 11:07:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Hutton, Andrew" References: <9F33F40F6F2CD847824537F3C4E37DDF11645356@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF11645356@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373900850; bh=ZxnN9xB15HB+8PGi8W6PfVWcRPmsqo2mBfcuVJsovuE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EpK5QF67jOZRKWnUV5vPGx0DYNmHF2zd+1bMYujgcENuCbXFbxvfXvfNc9SsDKUz1 62B6Jb0L7akuA3v+5Kxhp4Rs6rpx5o/QGrb1hoXKirsq006SKZXY0jhp7f6q7PVzfz uYvGbxsBWiB9eLKMknG3lf9dO0e8raHBoHvmZJTXKrt35lXmaPqfwo68rzoTLdyXvv 6OI0RHKGb++Olr4jQ7vU1J1w3CEr/18jPwFIYd/T6vsFLyXnvgY3uSeJFZIb/FT5YG PQ0XnOSlurOX7iHlqsBqQgNbQiOrf4wfOjTSFVega8V3KijS0CCSYKZPNSWSw9/Ba5 bDTZpRIanwRlQ== Cc: "siprec@ietf.org" , "Rosen, Brian" Subject: Re: [siprec] IETF87 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, 15 Jul 2013 15:07:37 -0000 Perhaps during status update we can talk about what, if anything, is preventing us from finishing up the current work. Thanks, Paul On 7/15/13 10:30 AM, Hutton, Andrew wrote: > Hi All, > I posted a draft agenda for the IETF87 SIPREC Meeting. > Please check and let me know if you have any issues or requests relating > to the agenda. > Regards > Andy From andrew.hutton@siemens-enterprise.com Mon Jul 15 08:18:26 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2015B21E80B5 for ; Mon, 15 Jul 2013 08:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 x7WdxaZzghug for ; Mon, 15 Jul 2013 08:18:21 -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 E0F7411E80DC for ; Mon, 15 Jul 2013 08:18:20 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 722581EB856B; Mon, 15 Jul 2013 17:18:19 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Mon, 15 Jul 2013 17:18:19 +0200 From: "Hutton, Andrew" To: Paul Kyzivat Thread-Topic: IETF87 SIPREC Draft Agenda Thread-Index: Ac6BZ8tZgh1LBqG6SQKiRjZUujJnkf//6O2A///bsrA= Date: Mon, 15 Jul 2013 15:18:18 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF11645597@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF11645356@MCHP04MSX.global-ad.net> <51E41031.7040903@alum.mit.edu> In-Reply-To: <51E41031.7040903@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 Cc: "siprec@ietf.org" , "Rosen, Brian" Subject: Re: [siprec] IETF87 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, 15 Jul 2013 15:18:26 -0000 Yes of course. The main issue as I see it is lack of review of the metadata and the real-w= orld examples that we asked for. Regards Andy > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 15 July 2013 16:07 > To: Hutton, Andrew > Cc: siprec@ietf.org; Henry Lum; Rosen, Brian > Subject: Re: IETF87 SIPREC Draft Agenda >=20 > Perhaps during status update we can talk about what, if anything, is > preventing us from finishing up the current work. >=20 > Thanks, > Paul >=20 > On 7/15/13 10:30 AM, Hutton, Andrew wrote: > > Hi All, > > I posted a draft agenda for the IETF87 SIPREC Meeting. > > Please check and let me know if you have any issues or requests > relating > > to the agenda. > > Regards > > Andy From michael.yan@huawei.com Wed Jul 17 00:42: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 3DC4D21F92C2 for ; Wed, 17 Jul 2013 00:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giDGzbov7yJB for ; Wed, 17 Jul 2013 00:42:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70BE921F8C71 for ; Wed, 17 Jul 2013 00:42:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVC16142; Wed, 17 Jul 2013 07:42:51 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 08:41:55 +0100 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 08:42:47 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.161]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 15:42:14 +0800 From: "Yanqiang (Michael)" To: Henry Lum , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOe0LlglPBNJwrXk+qoccqgtS+qplbM1bggAvHrlA= Date: Wed, 17 Jul 2013 07:42:14 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B31374748@szxeml561-mbx.china.huawei.com> References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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, 17 Jul 2013 07:42:59 -0000 SGkgSGVucnksDQoNCglJIHdlbnQgdGhyb3VnaCB5b3VyIGRyYWZ0IGRyYWZ0LWx1bS1zaXByZWMt dnhtbC0wMCBhbmQgcmZjNTU1MiAoaGF2ZW4ndCByZWFkIHRoZSBkZXRhaWxzIGJlZm9yZSkgYW5k IGdvdCBzZXZlcmFsIHF1ZXN0aW9ucy4gQ2FuIHlvdSBoZWxwIHRvIGZpZ3VyZSB0aGVtIG91dD8g OikNCg0KMS4gCSBEZWZpbml0aW9uIG9mIHZ4bWwgYXBwbGljYXRpb24oSVZSKSwgdnhtbCBtZWRp YSBzZXJ2ZXIsIHZ4bWwgaW50ZXJwcmV0ZXI/DQpUaGUgMS4yIHNlY3Rpb24gc2F5cyB0aGF0ICJU aGUgSVZSIGluIHRoaXMgY2FzZSBjYW4gYmUgYSBTSVBSRUMtYXdhcmUgU0lQIFVBIGFuZCByZWxp ZXMgb24gYSBzZXBhcmF0ZSBTUkMgdG8gcHJvdmlkZSByZWNvcmRpbmcgY2FwYWJpbGl0aWVzIi4g RG9lcyBpdCBtZWFuIHRoYXQgU0lQUkVDLWF3YXJlIFNJUCBVQSBydW5zIHRoZSB2eG1sIGFwcGxp Y2F0aW9uKElWUiBhcHBsaWNhdGlvbiksIGFuZCB0aGUgdnhtbCBtZWRpYSBzZXJ2ZXIgYWN0ZWQg YXMgdGhlIFNSQyB0byBwcm92aWRlIHJlY29yZGluZyBjYXBhYmlsaXRpZXM/IFJmYzU1NTIgaGFz IGRlZmluZWQgdGhlIHZ4bWwgbWVkaWEgc2VydmVyKHZ4bWwgaW50ZXJwcmV0ZXIgYXMgd2VsbD8p IGFuZCB2eG1sIGFwcGxpY2F0aW9uIHdoaWNoIG9mZmVycyB0aGUgSVZSIChhcyBhIHNlcnZpY2Up LiBSZmM1NTUyIHNheXMgdnhtbCBhcHBsaWNhdGlvbiBjYW4gYmUgZGVwbG95ZWQgb24gYW4gYXBw bGljYXRpb24gc2VydmVyLCBhIHNlcGFyYXRlZCBvbmUgb3IgdGhlIHZ4bWwgbWVkaWEgc2VydmVy IGRpcmVjdGx5LiBEbyB3ZSBuZWVkIHRvIG1ha2UgYSBkZWZpbml0aW9uIGluIHRoaXMgZHJhZnQg dG8gY29uZm9ybSB0byA1NTUyPw0KDQoyLiAJVGhlIGNvbW11bmljYXRpb24gbWVjaGFuaXNtIGlu IElWUiByZWNvcmRpbmcuIA0KVGhlIGRyYWZ0IHRhbGtzIGFib3V0IGhvdyB0aGUgdnhtbCBtZWRp YSBzZXJ2ZXIgb3IgSVZSIGl0c2VsZiByZXNwb25kIHRoZSBhY3Rpb25zIGxpa2Ugc3RhcnQvc3Rv cC9wYXVzZS9yZXN1bWUgYXMgdGhlIFNSQyB2aWEgNTU1Mi4gSWYgSSBkaWRuJ3QgbWFrZSBhIHdy b25nIHVuZGVyc3RhbmRpbmcsIGhlcmUgbWVhbnMgSVZSIGNhbiBjb21tdW5pY2F0ZSB3aXRoIHZ4 bWwgbWVkaWEgc2VydmVyIHZpYSA1NTUyLCBhbmQgdnhtbCBtZWRpYSBzZXJ2ZXIgY2FuIGJlIHRo ZSBTUkMgdmlhIGN1cnJlbnQgU0lQUkVDIG1lY2hhbmlzbS4gTWF5YmUgYSBzaW1wbGUgZHJhdyBj YW4gaGVscCB0byB1bmRlcnN0YW5kIGl0IGJldHRlci4NCg0KMy4JIEhvdyB0byBzdXBwb3J0IHR1 bmluZyBJVlIgcGVyZm9ybWFuY2UgdmlhIGVzc2VudGlhbCBtZXRhZGF0YSA/DQpBcyB0aGUgVXNl IENhc2UgNiBzYXlzIGluIDYzNDEsIHR1bmluZyBJVlIgcGVyZm9ybWFuY2UgaXMgb25lIG9mIHRo ZSBjYXNlIGFib3V0IElWUiByZWNvcmRpbmcuIEJ1dCBvYnZpb3VzbHksIGl0IHNlZW1zIHRvIGJl IGEgYml0IGNvbXBsaWNhdGVkIHRvIHJlY29yZCB0aGUgZW50aXJlIElWUiB0cmFjZS4gVGhpcyBk cmFmdCdzIFJFUTYgc2F5cywgIiBEZWZpbmUgYWRkaXRpb25hbCBtZXRhZGF0YSB0byBwcm92aWRl IGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhcHBsaWNhdGlvbiBleGVjdXRlZC4iIEJ1 dCB3aGF0IGtpbmQgb2Ygd2F5cG9pbnRzIG9yIG5vZGVzIG9mIElWUiB3b3VsZCBiZSB1c2VkIGZv ciB0dW5pbmc/IFRoZSA8ZXhpdD4gbmFtZWxpc3QgaXMgZ29vZCBidXQgaXQgaXMgZW5vdWdoIGZv ciBJVlIgdHVuaW5nPw0KIA0KVGhhbmtzLA0KTWljaGFlbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHNpcHJlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwcmVj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBIZW5yeSBMdW0NCj4gU2VudDogVHVl c2RheSwgSnVseSAwOSwgMjAxMyA0OjAwIEFNDQo+IFRvOiBQYXVsIEt5eml2YXQ7IHNpcHJlY0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcHJlY10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3INCj4gZHJhZnQtbHVtLXNpcHJlYy12eG1sLTAwLnR4dA0KPiANCj4gQmV5b25kIHRo ZSBhZGRpdGlvbmFsIGNvbnRyb2xzIGF2YWlsYWJsZSBpbiB0aGUgVlhNTCBzZXNzaW9uIGl0c2Vs Ziwgb25lIHVzZQ0KPiBjYXNlIGZvciBhZGRpdGlvbmFsIG1ldGFkYXRhIGNvbGxlY3Rpb24gaXMg aW1wb3J0YW50IHdheXBvaW50cyBhbmQgZGF0YSBpbiB0aGUNCj4gVlhNTCBzZXNzaW9uLiBXaGls ZSBpdCdzIHBvc3NpYmxlIHRvIHNpbXBseSBsb2cgYWxsIGZvcm1zIGFuZCBmaWVsZHMgZW50ZXJl ZCBidXQNCj4gdGhhdCBjYW4gYmUgd2F5IHRvbyBtdWNoIGRldGFpbCBmb3IgYSBjb21wbGV4IFZY TUwgYXBwbGljYXRpb24uIEluc3RlYWQsIGl0DQo+IHdvdWxkIGJlIHVzZWZ1bCBvbiB0aGUgcmVj b3JkaW5nIHNpZGUgdG8ga25vdyB3aGV0aGVyIHRoZSBzZXNzaW9uIGhhdmUNCj4gYXJyaXZlZCBh dCBhIGNlcnRhaW4gcG9pbnQgaW4gdGhlIGFwcGxpY2F0aW9uIGFuZCB3aGV0aGVyIGNlcnRhaW4g cGllY2VzIG9mIGRhdGENCj4gaGFzIGJlZW4gY29sbGVjdGVkLiBJIG1lbnRpb25lZCB0aGUgdXNl IG9mIDxleGl0PiBuYW1lbGlzdCB3aGljaCBpcyBhIHN0YW5kYXJkDQo+IG1lY2hhbmlzbSBpbiBS RkM1NTUyIGZvciBwYXNzaW5nIHBhcmFtZXRlcnMgYXQgdGhlIGVuZCBvZiB0aGUgc2Vzc2lvbi4N Cj4gDQo+IFJlZ2FyZHMsDQo+IEhlbnJ5DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBzaXByZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcHJlYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gUGF1bCBLeXppdmF0DQo+IFNlbnQ6IEp1bHktMDct MTMgMjo1MSBQTQ0KPiBUbzogc2lwcmVjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2lwcmVj XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1sdW0tc2lwcmVjLXZ4 bWwtMDAudHh0DQo+IA0KPiBPbiA3LzQvMTMgMTI6MzIgQU0sIEhlbnJ5IEx1bSB3cm90ZToNCj4g PiBIaSAtIHRoaXMgaXMgYW4gaW5pdGlhbCBkcmFmdCBhYm91dCByZWNvcmRpbmcgSVZSIHNlc3Np b25zLiBJIHdhbnQgdG8gc2VlIGlmIHRoZXJlIGlzDQo+IGludGVyZXN0IGluIHdvcmtpbmcgb3V0 IG1vcmUgZGV0YWlscyBhYm91dCBJVlIgcmVjb3JkaW5nDQo+IA0KPiBJJ20gaW50ZXJlc3RlZCBp biBoZWFyaW5nIHdoYXQgeW91IGhhdmUgaW4gbWluZC4NCj4gQXQgb25lIGxldmVsIHRoZXNlIHNo b3VsZCBhbHJlYWR5IGJlIGNvdmVyZWQuIFlvdSBtdXN0IHdhbnQgdG8gY2FwdHVyZQ0KPiBzb21l IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uIElzIGl0IHRoYXQgeW91IHdhbnQgdG8gcmVjb3JkIHRo ZSBWWE1MPw0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+ID4gSSdkIGJlIGhhcHB5IHRv IHByZXNlbnQgZm9yIHRoZSBtZWV0aW5nIGlmIHRoZXJlIGlzIHRpbWUgZm9yIHRoaXMuDQo+ID4N Cj4gPiBUaGFua3MNCj4gPiBIZW5yeQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA0LCAyMDEz IDEyOjI4IEFNDQo+ID4gVG86IEhlbnJ5IEx1bQ0KPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtbHVtLXNpcHJlYy12eG1sLTAwLnR4dA0KPiA+DQo+ID4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWx1bS1zaXByZWMtdnhtbC0wMC50eHQNCj4gPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEhlbnJ5IEx1bSBhbmQgcG9zdGVkIHRvIHRo ZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IEZpbGVuYW1lOiAgICAgICAgZHJhZnQt bHVtLXNpcHJlYy12eG1sDQo+ID4gUmV2aXNpb246ICAgICAgICAwMA0KPiA+IFRpdGxlOiAgICAg ICAgICAgUmVjb3JkaW5nIFZvaWNlWE1MIHNlc3Npb25zIHdpdGggU0lQUkVDDQo+ID4gQ3JlYXRp b24gZGF0ZTogICAyMDEzLTA3LTA0DQo+ID4gR3JvdXA6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gPiBOdW1iZXIgb2YgcGFnZXM6IDYNCj4gPiBVUkw6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWx1bS1zaXByZWMtdnhtbC0wMC50eHQNCj4g PiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bHVtLXNpcHJlYy12eG1sDQo+ID4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1sdW0tc2lwcmVjLXZ4bWwtMDANCj4gPg0KPiA+DQo+ID4gQWJzdHJhY3Q6 DQo+ID4gICAgIFRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZSB1c2UgY2FzZSBvZiByZWNvcmRp bmcgSW50ZXJhY3RpdmUgVm9pY2UNCj4gPiAgICAgUmVzcG9uc2UgKElWUikgVm9pY2VYTUwgYXBw bGljYXRpb25zIHVzaW5nIHRoZSBTSVBSRUMgcHJvdG9jb2wuICBUaGlzDQo+ID4gICAgIGRvY3Vt ZW50IGFsc28gcHJvdmlkZXMgYSBwb3RlbnRpYWwgc29sdXRpb24gZm9yIGNhcHR1cmluZyBhZGRp dGlvbmFsDQo+ID4gICAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjYWxsIGZsb3cgd2l0aGluIHRo ZSBWb2ljZVhNTCBhcHBsaWNhdGlvbiBmcm9tDQo+ID4gICAgIGEgcmVjb3JkaW5nIHBlcnNwZWN0 aXZlLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0K PiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IHNpcHJlYyBtYWlsaW5nIGxpc3QNCj4gPiBzaXByZWNAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0KPiA+DQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXByZWMg bWFpbGluZyBsaXN0DQo+IHNpcHJlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwcmVjIG1haWxpbmcgbGlzdA0KPiBzaXByZWNAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXByZWMNCg== From henry.lum@genesyslab.com Wed Jul 17 08:52:38 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3631B21F8FD8 for ; Wed, 17 Jul 2013 08:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=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 tRrs92OXCsZD for ; Wed, 17 Jul 2013 08:52:33 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2865811E8103 for ; Wed, 17 Jul 2013 08:52:28 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service108-us.mimecast.com; Wed, 17 Jul 2013 11:52:14 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 08:52:11 -0700 From: Henry Lum To: "Yanqiang (Michael)" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOgsG+LEwHvGjtjkyQX0XVw+rcNplo/DEA Date: Wed, 17 Jul 2013 15:52:10 +0000 Message-ID: References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <21794EB0EE82B0458A524942A141542B31374748@szxeml561-mbx.china.huawei.com> In-Reply-To: <21794EB0EE82B0458A524942A141542B31374748@szxeml561-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.16] MIME-Version: 1.0 X-MC-Unique: 113071711521435202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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, 17 Jul 2013 15:52:38 -0000 SGkgTWljaGFlbCAtIHBsZWFzZSBzZWUgaW5saW5lLg0KDQpIZW5yeQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogWWFucWlhbmcgKE1pY2hhZWwpIFttYWlsdG86bWljaGFlbC55 YW5AaHVhd2VpLmNvbV0gDQpTZW50OiBKdWx5LTE3LTEzIDM6NDIgQU0NClRvOiBIZW5yeSBMdW07 IFBhdWwgS3l6aXZhdDsgc2lwcmVjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NpcHJlY10gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbHVtLXNpcHJlYy12eG1sLTAwLnR4 dA0KDQpIaSBIZW5yeSwNCg0KCUkgd2VudCB0aHJvdWdoIHlvdXIgZHJhZnQgZHJhZnQtbHVtLXNp cHJlYy12eG1sLTAwIGFuZCByZmM1NTUyIChoYXZlbid0IHJlYWQgdGhlIGRldGFpbHMgYmVmb3Jl KSBhbmQgZ290IHNldmVyYWwgcXVlc3Rpb25zLiBDYW4geW91IGhlbHAgdG8gZmlndXJlIHRoZW0g b3V0PyA6KQ0KDQoxLiAJIERlZmluaXRpb24gb2YgdnhtbCBhcHBsaWNhdGlvbihJVlIpLCB2eG1s IG1lZGlhIHNlcnZlciwgdnhtbCBpbnRlcnByZXRlcj8NClRoZSAxLjIgc2VjdGlvbiBzYXlzIHRo YXQgIlRoZSBJVlIgaW4gdGhpcyBjYXNlIGNhbiBiZSBhIFNJUFJFQy1hd2FyZSBTSVAgVUEgYW5k IHJlbGllcyBvbiBhIHNlcGFyYXRlIFNSQyB0byBwcm92aWRlIHJlY29yZGluZyBjYXBhYmlsaXRp ZXMiLiBEb2VzIGl0IG1lYW4gdGhhdCBTSVBSRUMtYXdhcmUgU0lQIFVBIHJ1bnMgdGhlIHZ4bWwg YXBwbGljYXRpb24oSVZSIGFwcGxpY2F0aW9uKSwgYW5kIHRoZSB2eG1sIG1lZGlhIHNlcnZlciBh Y3RlZCBhcyB0aGUgU1JDIHRvIHByb3ZpZGUgcmVjb3JkaW5nIGNhcGFiaWxpdGllcz8gUmZjNTU1 MiBoYXMgZGVmaW5lZCB0aGUgdnhtbCBtZWRpYSBzZXJ2ZXIodnhtbCBpbnRlcnByZXRlciBhcyB3 ZWxsPykgYW5kIHZ4bWwgYXBwbGljYXRpb24gd2hpY2ggb2ZmZXJzIHRoZSBJVlIgKGFzIGEgc2Vy dmljZSkuIFJmYzU1NTIgc2F5cyB2eG1sIGFwcGxpY2F0aW9uIGNhbiBiZSBkZXBsb3llZCBvbiBh biBhcHBsaWNhdGlvbiBzZXJ2ZXIsIGEgc2VwYXJhdGVkIG9uZSBvciB0aGUgdnhtbCBtZWRpYSBz ZXJ2ZXIgZGlyZWN0bHkuIERvIHdlIG5lZWQgdG8gbWFrZSBhIGRlZmluaXRpb24gaW4gdGhpcyBk cmFmdCB0byBjb25mb3JtIHRvIDU1NTI/DQoNCltobHVtXSBJIHRoaW5rIHRoZXJlIGFyZSBvcHRp b25zIGluIHRlcm1zIG9mIGltcGxlbWVudGF0aW9uIG9mIHRoZSBWWE1MIG1lZGlhIHNlcnZlciBh cyBhIFNJUCBVQS4gSXQgY2FuIGVpdGhlciBiZSBhIFNJUFJFQy1hd2FyZSBVQSB0aGF0IHJlbGll cyBvbiBhIHNlcGFyYXRlIFNSQyB0byBwZXJmb3JtIHRoZSByZWNvcmRpbmcsIHRoZSBWWE1MIG1l ZGlhIHNlcnZlciBjYW4gYmUgdGhlIFNSQyBpdHNlbGYgYW5kIHByb3ZpZGUgcmVjb3JkaW5nIGRp cmVjdGx5LiBUaGUgVlhNTCBhcHBsaWNhdGlvbiBpdHNlbGYgZG9lcyBub3QgcGVyZm9ybSByZWNv cmRpbmcgc28gdGhpcyBkcmFmdCBpcyBub3QgbWFraW5nIGNoYW5nZXMgdG8gdGhpcyBkZWZpbml0 aW9uOyBwZXJoYXBzIHdlIGNhbiBqdXN0IHJlZmVyIHRvIDU1NTIgZm9yIHRoZSBkZWZpbml0aW9u Lg0KDQoyLiAJVGhlIGNvbW11bmljYXRpb24gbWVjaGFuaXNtIGluIElWUiByZWNvcmRpbmcuIA0K VGhlIGRyYWZ0IHRhbGtzIGFib3V0IGhvdyB0aGUgdnhtbCBtZWRpYSBzZXJ2ZXIgb3IgSVZSIGl0 c2VsZiByZXNwb25kIHRoZSBhY3Rpb25zIGxpa2Ugc3RhcnQvc3RvcC9wYXVzZS9yZXN1bWUgYXMg dGhlIFNSQyB2aWEgNTU1Mi4gSWYgSSBkaWRuJ3QgbWFrZSBhIHdyb25nIHVuZGVyc3RhbmRpbmcs IGhlcmUgbWVhbnMgSVZSIGNhbiBjb21tdW5pY2F0ZSB3aXRoIHZ4bWwgbWVkaWEgc2VydmVyIHZp YSA1NTUyLCBhbmQgdnhtbCBtZWRpYSBzZXJ2ZXIgY2FuIGJlIHRoZSBTUkMgdmlhIGN1cnJlbnQg U0lQUkVDIG1lY2hhbmlzbS4gTWF5YmUgYSBzaW1wbGUgZHJhdyBjYW4gaGVscCB0byB1bmRlcnN0 YW5kIGl0IGJldHRlci4NCg0KW2hsdW1dIEFncmVlZCAtIGEgZHJhd2luZyB3b3VsZCBoZWxwIHRv IGV4cGxhaW4gdGhlIGRpZmZlcmVuY2UgaW4gaW1wbGVtZW50YXRpb24gdHlwZXMgZm9yIHRoZSBt ZWRpYSBzZXJ2ZXIgYW5kIGhvdyB0aGUgbWVjaGFuaWNzIGNhbiB3b3JrLiBMZXQgbWUgc3RhcnQg d2l0aCBzbGlkZXMgZmlyc3QgYW5kIHRoZW4gdHJhbnNsYXRlIHRoYXQgaW50byB0aGUgbmV4dCBk cmFmdCByZXZpc2lvbi4NCg0KMy4JIEhvdyB0byBzdXBwb3J0IHR1bmluZyBJVlIgcGVyZm9ybWFu Y2UgdmlhIGVzc2VudGlhbCBtZXRhZGF0YSA/DQpBcyB0aGUgVXNlIENhc2UgNiBzYXlzIGluIDYz NDEsIHR1bmluZyBJVlIgcGVyZm9ybWFuY2UgaXMgb25lIG9mIHRoZSBjYXNlIGFib3V0IElWUiBy ZWNvcmRpbmcuIEJ1dCBvYnZpb3VzbHksIGl0IHNlZW1zIHRvIGJlIGEgYml0IGNvbXBsaWNhdGVk IHRvIHJlY29yZCB0aGUgZW50aXJlIElWUiB0cmFjZS4gVGhpcyBkcmFmdCdzIFJFUTYgc2F5cywg IiBEZWZpbmUgYWRkaXRpb25hbCBtZXRhZGF0YSB0byBwcm92aWRlIGRldGFpbGVkIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBhcHBsaWNhdGlvbiBleGVjdXRlZC4iIEJ1dCB3aGF0IGtpbmQgb2Ygd2F5 cG9pbnRzIG9yIG5vZGVzIG9mIElWUiB3b3VsZCBiZSB1c2VkIGZvciB0dW5pbmc/IFRoZSA8ZXhp dD4gbmFtZWxpc3QgaXMgZ29vZCBidXQgaXQgaXMgZW5vdWdoIGZvciBJVlIgdHVuaW5nPw0KDQpb aGx1bV0gSVZSIHR1bmluZyBjYW4gbWVhbiBhIGxvdCBvZiB0aGluZ3MsIGl0IGNhbiBiZSBlaXRo ZXIgdHVuaW5nIHlvdXIgc3BlZWNoIGdyYW1tYXIgdG8gY2F0Y2ggbW9yZSBwaHJhc2VzIHRoYXQg dXNlcnMgYWN0dWFsbHkgc3BlYWssIHR1bmluZyB0aGUgYXBwbGljYXRpb24gdG8gaGVscCB1c2Vy cyBjb21wbGV0ZSB0aGVpciB0cmFuc2FjdGlvbnMsIG9yIGV2ZW4gdHVuaW5nIGlucHV0LXRvLXBy b21wdCBsYXRlbmNpZXMuIEluIGdlbmVyYWwgSSB0aGluayB0aGUgbW9yZSBpbmZvcm1hdGlvbiBh dmFpbGFibGUgdGhlIGJldHRlciBidXQgd2UgZG9uJ3Qgd2FudCB0byB0dXJuIFNJUFJFQyBpbnRv IGEgbG9nZ2luZyBvciBkZWJ1ZyBmYWNpbGl0eS4gVGhhdCdzIHdoeSBJIHRoaW5rIHdlIGNhbiBw cm92aWRlIHNvbWUgc3VnZ2VzdGlvbnMgZm9yIHRoZSBJVlIgdG8gcHJvdmlkZSBzb21lIHVzZWZ1 bCBidXQgbm90IGV4Y2Vzc2l2ZSBpbmZvcm1hdGlvbiBpbiBhZGRpdGlvbiB0byB0aGUgYXVkaW8g aXRzZWxmIHRvIGFkZHJlc3MgdGhlIHR1bmluZyB1c2UgY2FzZS4NCg0KVGhhbmtzLA0KTWljaGFl bA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcHJlYy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c2lwcmVjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0K PiBIZW5yeSBMdW0NCj4gU2VudDogVHVlc2RheSwgSnVseSAwOSwgMjAxMyA0OjAwIEFNDQo+IFRv OiBQYXVsIEt5eml2YXQ7IHNpcHJlY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcHJlY10g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtbHVtLXNpcHJlYy12eG1s LTAwLnR4dA0KPiANCj4gQmV5b25kIHRoZSBhZGRpdGlvbmFsIGNvbnRyb2xzIGF2YWlsYWJsZSBp biB0aGUgVlhNTCBzZXNzaW9uIGl0c2VsZiwgb25lIHVzZQ0KPiBjYXNlIGZvciBhZGRpdGlvbmFs IG1ldGFkYXRhIGNvbGxlY3Rpb24gaXMgaW1wb3J0YW50IHdheXBvaW50cyBhbmQgZGF0YSBpbiB0 aGUNCj4gVlhNTCBzZXNzaW9uLiBXaGlsZSBpdCdzIHBvc3NpYmxlIHRvIHNpbXBseSBsb2cgYWxs IGZvcm1zIGFuZCBmaWVsZHMgZW50ZXJlZCBidXQNCj4gdGhhdCBjYW4gYmUgd2F5IHRvbyBtdWNo IGRldGFpbCBmb3IgYSBjb21wbGV4IFZYTUwgYXBwbGljYXRpb24uIEluc3RlYWQsIGl0DQo+IHdv dWxkIGJlIHVzZWZ1bCBvbiB0aGUgcmVjb3JkaW5nIHNpZGUgdG8ga25vdyB3aGV0aGVyIHRoZSBz ZXNzaW9uIGhhdmUNCj4gYXJyaXZlZCBhdCBhIGNlcnRhaW4gcG9pbnQgaW4gdGhlIGFwcGxpY2F0 aW9uIGFuZCB3aGV0aGVyIGNlcnRhaW4gcGllY2VzIG9mIGRhdGENCj4gaGFzIGJlZW4gY29sbGVj dGVkLiBJIG1lbnRpb25lZCB0aGUgdXNlIG9mIDxleGl0PiBuYW1lbGlzdCB3aGljaCBpcyBhIHN0 YW5kYXJkDQo+IG1lY2hhbmlzbSBpbiBSRkM1NTUyIGZvciBwYXNzaW5nIHBhcmFtZXRlcnMgYXQg dGhlIGVuZCBvZiB0aGUgc2Vzc2lvbi4NCj4gDQo+IFJlZ2FyZHMsDQo+IEhlbnJ5DQo+IA0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXByZWMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNpcHJlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gUGF1bCBL eXppdmF0DQo+IFNlbnQ6IEp1bHktMDctMTMgMjo1MSBQTQ0KPiBUbzogc2lwcmVjQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbc2lwcmVjXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv cg0KPiBkcmFmdC1sdW0tc2lwcmVjLXZ4bWwtMDAudHh0DQo+IA0KPiBPbiA3LzQvMTMgMTI6MzIg QU0sIEhlbnJ5IEx1bSB3cm90ZToNCj4gPiBIaSAtIHRoaXMgaXMgYW4gaW5pdGlhbCBkcmFmdCBh Ym91dCByZWNvcmRpbmcgSVZSIHNlc3Npb25zLiBJIHdhbnQgdG8gc2VlIGlmIHRoZXJlIGlzDQo+ IGludGVyZXN0IGluIHdvcmtpbmcgb3V0IG1vcmUgZGV0YWlscyBhYm91dCBJVlIgcmVjb3JkaW5n DQo+IA0KPiBJJ20gaW50ZXJlc3RlZCBpbiBoZWFyaW5nIHdoYXQgeW91IGhhdmUgaW4gbWluZC4N Cj4gQXQgb25lIGxldmVsIHRoZXNlIHNob3VsZCBhbHJlYWR5IGJlIGNvdmVyZWQuIFlvdSBtdXN0 IHdhbnQgdG8gY2FwdHVyZQ0KPiBzb21lIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uIElzIGl0IHRo YXQgeW91IHdhbnQgdG8gcmVjb3JkIHRoZSBWWE1MPw0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwN Cj4gDQo+ID4gSSdkIGJlIGhhcHB5IHRvIHByZXNlbnQgZm9yIHRoZSBtZWV0aW5nIGlmIHRoZXJl IGlzIHRpbWUgZm9yIHRoaXMuDQo+ID4NCj4gPiBUaGFua3MNCj4gPiBIZW5yeQ0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+IFNlbnQ6 IFRodXJzZGF5LCBKdWx5IDA0LCAyMDEzIDEyOjI4IEFNDQo+ID4gVG86IEhlbnJ5IEx1bQ0KPiA+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbHVtLXNpcHJlYy12 eG1sLTAwLnR4dA0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWx1bS1zaXBy ZWMtdnhtbC0wMC50eHQNCj4gPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEhl bnJ5IEx1bSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+ IEZpbGVuYW1lOiAgICAgICAgZHJhZnQtbHVtLXNpcHJlYy12eG1sDQo+ID4gUmV2aXNpb246ICAg ICAgICAwMA0KPiA+IFRpdGxlOiAgICAgICAgICAgUmVjb3JkaW5nIFZvaWNlWE1MIHNlc3Npb25z IHdpdGggU0lQUkVDDQo+ID4gQ3JlYXRpb24gZGF0ZTogICAyMDEzLTA3LTA0DQo+ID4gR3JvdXA6 ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBOdW1iZXIgb2YgcGFnZXM6IDYN Cj4gPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWx1 bS1zaXByZWMtdnhtbC0wMC50eHQNCj4gPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbHVtLXNpcHJlYy12eG1sDQo+ID4gSHRtbGl6ZWQ6ICAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sdW0tc2lwcmVjLXZ4bWwtMDAN Cj4gPg0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgIFRoaXMgZG9jdW1lbnQgYWRkcmVzc2Vz IHRoZSB1c2UgY2FzZSBvZiByZWNvcmRpbmcgSW50ZXJhY3RpdmUgVm9pY2UNCj4gPiAgICAgUmVz cG9uc2UgKElWUikgVm9pY2VYTUwgYXBwbGljYXRpb25zIHVzaW5nIHRoZSBTSVBSRUMgcHJvdG9j b2wuICBUaGlzDQo+ID4gICAgIGRvY3VtZW50IGFsc28gcHJvdmlkZXMgYSBwb3RlbnRpYWwgc29s dXRpb24gZm9yIGNhcHR1cmluZyBhZGRpdGlvbmFsDQo+ID4gICAgIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBjYWxsIGZsb3cgd2l0aGluIHRoZSBWb2ljZVhNTCBhcHBsaWNhdGlvbiBmcm9tDQo+ID4g ICAgIGEgcmVjb3JkaW5nIHBlcnNwZWN0aXZlLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNpcHJlYyBtYWlsaW5nIGxpc3QNCj4g PiBzaXByZWNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcHJlYw0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBzaXByZWMgbWFpbGluZyBsaXN0DQo+IHNpcHJlY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcHJlYw0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwcmVjIG1h aWxpbmcgbGlzdA0KPiBzaXByZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXByZWMNCg== From pkyzivat@alum.mit.edu Wed Jul 17 14:52:58 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6921F889C for ; Wed, 17 Jul 2013 14:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=0.203, 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 lk5vOZTaw27Q for ; Wed, 17 Jul 2013 14:52:53 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7A721F8956 for ; Wed, 17 Jul 2013 14:52:52 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id 1Q2c1m00417dt5G54Zsre1; Wed, 17 Jul 2013 21:52:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id 1Zsr1m00h3ZTu2S3ZZsry6; Wed, 17 Jul 2013 21:52:51 +0000 Message-ID: <51E71231.7070507@alum.mit.edu> Date: Wed, 17 Jul 2013 17:52:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Henry Lum References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> 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=1374097971; bh=E1KzTfoC85Leht1KLczuXSoI0OB2CStbkpwTMUnLrp4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Kc1hYfUBqeA7YUwrNsPWCVDSQG41aK0mVDye4NHYCFF1N6T3qVLuMXPxgfmii4wrR 0EYaPKMaghGTuj0Bn0sqxpVnFdfKrdSoaM23dPh1infQ84POKB/+G3KcIWwJURshoA qzAGPlY/d/WcFQ3wW2uIYI+55+B98bARjpCwdhXP7xYK4ipf9spesvUlPApXhzqk6E 7STcPOe49vF5wqGrJn/USUbyiaNOkVnCbojOLHPp+oaB7V6gVoDNv9TFnReXUElbb5 KbTGFCzb+3jd4vBeVd8W2ohvLryHdZYB3QQxc/JvIjJgq8o7LRNnsIYZ/2REeaf8uD IZcg4Z5LQNt9Q== Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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, 17 Jul 2013 21:52:58 -0000 Henry, I read this draft. It does seem natural that siprec work well with IVRs. Some questions for you: Recording indication & pause/resume: This is trivial when the IVR acts as an SRC. But when there is a separate SRC, we have defined the UA control over recording to be strictly advisory. So the IVR could *request* that recording stop. Then it must simply wait to see if it gets a signal back that recording has stopped, which may or may not be coming. Is that good enough for the IVR application needs? How long will it wait? And of course the indication that recording has stopped could be a lie. Is that OK? Metadata: When the SRC is separate from the IVR, how would the SRC obtain this additional information that is to be included in the metadata? Coordination of SRCs: (You don't have a section on this.) If the IVR acts as its own SRC, do we care if there is another SRC? If so, do we expect them to coordinate so that they use the same identifiers? Some cases where this may be the case: - a call center recording all calls coming in, and then using an IVR for part of the call handling. - a PBX that handles some incoming calls via an IVR and then eventually transfers them to a phone hanging off the pbx. We made the *provision* in the metadata for multiple SRCs to coordinate, but left the coordination out of scope. Does adding explict support here require putting that back in scope? Thanks, Paul On 7/8/13 4:00 PM, Henry Lum wrote: > Beyond the additional controls available in the VXML session itself, one use case for additional metadata collection is important waypoints and data in the VXML session. While it's possible to simply log all forms and fields entered but that can be way too much detail for a complex VXML application. Instead, it would be useful on the recording side to know whether the session have arrived at a certain point in the application and whether certain pieces of data has been collected. I mentioned the use of namelist which is a standard mechanism in RFC5552 for passing parameters at the end of the session. > > Regards, > Henry > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: July-07-13 2:51 PM > To: siprec@ietf.org > Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt > > On 7/4/13 12:32 AM, Henry Lum wrote: >> Hi - this is an initial draft about recording IVR sessions. I want to see if there is interest in working out more details about IVR recording > > I'm interested in hearing what you have in mind. > At one level these should already be covered. You must want to capture > some additional information. Is it that you want to record the VXML? > > Thanks, > Paul > >> I'd be happy to present for the meeting if there is time for this. >> >> Thanks >> Henry >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Thursday, July 04, 2013 12:28 AM >> To: Henry Lum >> Subject: New Version Notification for draft-lum-siprec-vxml-00.txt >> >> A new version of I-D, draft-lum-siprec-vxml-00.txt >> has been successfully submitted by Henry Lum and posted to the >> IETF repository. >> >> Filename: draft-lum-siprec-vxml >> Revision: 00 >> Title: Recording VoiceXML sessions with SIPREC >> Creation date: 2013-07-04 >> Group: Individual Submission >> Number of pages: 6 >> URL: http://www.ietf.org/internet-drafts/draft-lum-siprec-vxml-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lum-siprec-vxml >> Htmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml-00 >> >> >> Abstract: >> This document addresses the use case of recording Interactive Voice >> Response (IVR) VoiceXML applications using the SIPREC protocol. This >> document also provides a potential solution for capturing additional >> information about the call flow within the VoiceXML application from >> a recording perspective. >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> 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 henry.lum@genesyslab.com Thu Jul 18 14:24:21 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 2796A21E8099 for ; Thu, 18 Jul 2013 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 GCQNSXrMrVKU for ; Thu, 18 Jul 2013 14:24:16 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8A11E8216 for ; Thu, 18 Jul 2013 14:24:15 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Thu, 18 Jul 2013 17:24:11 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 14:24:09 -0700 From: Henry Lum To: Paul Kyzivat Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOgzf882kUd618MkOY+4A8adA8zZlq7mrA Date: Thu, 18 Jul 2013 21:24:09 +0000 Message-ID: References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <51E71231.7070507@alum.mit.edu> In-Reply-To: <51E71231.7070507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.16] MIME-Version: 1.0 X-MC-Unique: 113071817241102302 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Thu, 18 Jul 2013 21:24:21 -0000 Hi Paul, please see inline. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: July-17-13 5:53 PM To: Henry Lum Cc: siprec@ietf.org Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxm= l-00.txt Henry, I read this draft. It does seem natural that siprec work well with IVRs.=20 Some questions for you: Recording indication & pause/resume: This is trivial when the IVR acts as an SRC. But when there is a=20 separate SRC, we have defined the UA control over recording to be=20 strictly advisory. So the IVR could *request* that recording stop. Then=20 it must simply wait to see if it gets a signal back that recording has=20 stopped, which may or may not be coming. Is that good enough for the IVR=20 application needs?=20 [hlum] Since request to pause is advisory, the same problem exists for a co= ntact center agent needing to manually pause the recording before taking se= nsitive information. The only feedback for the agent to proceed with taking= the sensitive information is by observing the recording indicator that it = is currently paused. For an IVR application this can be harder since the pr= otocol does not define how long must an SRC provide a change in recording i= ndication, so it will have to be up to the IVR to determine how long to wai= t before proceeding to a form or field taking sensitive information. Perhap= s when something times out or the request is not honoured, the interpreter = can throw an event so you can get out of the form without taking the inform= ation.=20 How long will it wait? And of course the indication=20 that recording has stopped could be a lie. Is that OK? [hlum] I guess an IVR can't do anything about an SRC lying about the record= ing indication. If the deployment needs the IVR to be absolutely sure about= this, then the IVR must have to become the SRC itself or at least own the = SRC policy. Metadata: When the SRC is separate from the IVR, how would the SRC obtain this=20 additional information that is to be included in the metadata? [hlum] That's a good point since there is no such communication for transpo= rting additional metadata for SIPREC-aware UA. I wonder if it makes sense t= o define additional communication to tunnel metadata to SRC and send over t= o SRS. In this case perhaps the IVR will have to provide the metadata to SR= S through other mechanisms. Coordination of SRCs: (You don't have a section on this.) If the IVR acts as its own SRC, do=20 we care if there is another SRC? If so, do we expect them to coordinate=20 so that they use the same identifiers? Some cases where this may be the=20 case: - a call center recording all calls coming in, and then using an IVR for part of the call handling. - a PBX that handles some incoming calls via an IVR and then eventually transfers them to a phone hanging off the pbx. We made the *provision* in the metadata for multiple SRCs to coordinate,=20 but left the coordination out of scope. Does adding explict support here=20 require putting that back in scope? [hlum] It's likely we want some form of coordination, since it typical that= an agent gets involved with IVR applications. If the contact center is ser= ved by a different SRC and the SRC for the IVR, then it makes sense to prov= ide some form of coordination so that the SRS can figure out which portion = of a customer call is related to IVR and which portion is related to agents= . The latest protocol revision added the statement that the SRS allows such= coordination, but I don't see how we can mandate all SRCs coordinate if th= e SRCs happen to record the same CS.=20 =09Thanks, =09Paul On 7/8/13 4:00 PM, Henry Lum wrote: > Beyond the additional controls available in the VXML session itself, one = use case for additional metadata collection is important waypoints and data= in the VXML session. While it's possible to simply log all forms and field= s entered but that can be way too much detail for a complex VXML applicatio= n. Instead, it would be useful on the recording side to know whether the se= ssion have arrived at a certain point in the application and whether certai= n pieces of data has been collected. I mentioned the use of namelist= which is a standard mechanism in RFC5552 for passing parameters at the end= of the session. > > Regards, > Henry > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: July-07-13 2:51 PM > To: siprec@ietf.org > Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-v= xml-00.txt > > On 7/4/13 12:32 AM, Henry Lum wrote: >> Hi - this is an initial draft about recording IVR sessions. I want to se= e if there is interest in working out more details about IVR recording > > I'm interested in hearing what you have in mind. > At one level these should already be covered. You must want to capture > some additional information. Is it that you want to record the VXML? > > =09Thanks, > =09Paul > >> I'd be happy to present for the meeting if there is time for this. >> >> Thanks >> Henry >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Thursday, July 04, 2013 12:28 AM >> To: Henry Lum >> Subject: New Version Notification for draft-lum-siprec-vxml-00.txt >> >> A new version of I-D, draft-lum-siprec-vxml-00.txt >> has been successfully submitted by Henry Lum and posted to the >> IETF repository. >> >> Filename: draft-lum-siprec-vxml >> Revision: 00 >> Title: Recording VoiceXML sessions with SIPREC >> Creation date: 2013-07-04 >> Group: Individual Submission >> Number of pages: 6 >> URL: http://www.ietf.org/internet-drafts/draft-lum-siprec-vx= ml-00.txt >> Status: http://datatracker.ietf.org/doc/draft-lum-siprec-vxml >> Htmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml-00 >> >> >> Abstract: >> This document addresses the use case of recording Interactive Voice >> Response (IVR) VoiceXML applications using the SIPREC protocol. Th= is >> document also provides a potential solution for capturing additiona= l >> information about the call flow within the VoiceXML application fro= m >> a recording perspective. >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> 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 Thu Jul 18 16:43: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 9CA6121E8178 for ; Thu, 18 Jul 2013 16:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=0.188, 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 Kch+CNRUz+uE for ; Thu, 18 Jul 2013 16:43:08 -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 C795621E8175 for ; Thu, 18 Jul 2013 16:43:07 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id 1z3N1m0040EZKEL56zj7J1; Thu, 18 Jul 2013 23:43:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id 1zj61m00n3ZTu2S3Mzj693; Thu, 18 Jul 2013 23:43:07 +0000 Message-ID: <51E87D8A.7050001@alum.mit.edu> Date: Thu, 18 Jul 2013 19:43:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Henry Lum References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <51E71231.7070507@alum.mit.edu> 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=1374190987; bh=UxC2eKMgArTEWRRRp8s/MxCmPAN1BgqQ6yzcpNjdioY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WgYmnMa/BUT0dH/ZPIkmeok8evw6pJd1AIFLlefaNkfdjI/OqQx4avAn3zK5AA0uK 7ap0nctoqx1rJoNi8Se2tL910gpYd6zc2plEJ4Zlm3g8+qKQupMMjqI+OuDD0THMTE llyrzTab2y/M6J4euHksdUmC5wC8XKNK9FdlRmPk70xKXrMhgGcJLx+V7aMVVe5DQ6 TousLzmElXEYf0KXp1hAlmV/JJNX1gcOlzBOhJQ8j1buM22GehiCsQX5W2J3VjH/2p eS9o57hEzerOHqLgrTdGikJpfXVWmTaWCwxmmETAoHs4p6ld53pIOZLkwxJwCbRNVS 6DYY4Isr1Wbtg== Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Thu, 18 Jul 2013 23:43:12 -0000 Henry, Thanks for the clarifications here. I don't have any answers. But these sorts of considerations should probably make it into the draft in some form. Thanks, Paul On 7/18/13 5:24 PM, Henry Lum wrote: > Hi Paul, please see inline. > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: July-17-13 5:53 PM > To: Henry Lum > Cc: siprec@ietf.org > Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt > > Henry, > > I read this draft. It does seem natural that siprec work well with IVRs. > Some questions for you: > > Recording indication & pause/resume: > > This is trivial when the IVR acts as an SRC. But when there is a > separate SRC, we have defined the UA control over recording to be > strictly advisory. So the IVR could *request* that recording stop. Then > it must simply wait to see if it gets a signal back that recording has > stopped, which may or may not be coming. Is that good enough for the IVR > application needs? > > [hlum] Since request to pause is advisory, the same problem exists for a contact center agent needing to manually pause the recording before taking sensitive information. The only feedback for the agent to proceed with taking the sensitive information is by observing the recording indicator that it is currently paused. For an IVR application this can be harder since the protocol does not define how long must an SRC provide a change in recording indication, so it will have to be up to the IVR to determine how long to wait before proceeding to a form or field taking sensitive information. Perhaps when something times out or the request is not honoured, the interpreter can throw an event so you can get out of the form without taking the information. > > How long will it wait? And of course the indication > that recording has stopped could be a lie. Is that OK? > > [hlum] I guess an IVR can't do anything about an SRC lying about the recording indication. If the deployment needs the IVR to be absolutely sure about this, then the IVR must have to become the SRC itself or at least own the SRC policy. > > > Metadata: > > When the SRC is separate from the IVR, how would the SRC obtain this > additional information that is to be included in the metadata? > > [hlum] That's a good point since there is no such communication for transporting additional metadata for SIPREC-aware UA. I wonder if it makes sense to define additional communication to tunnel metadata to SRC and send over to SRS. In this case perhaps the IVR will have to provide the metadata to SRS through other mechanisms. > > Coordination of SRCs: > > (You don't have a section on this.) If the IVR acts as its own SRC, do > we care if there is another SRC? If so, do we expect them to coordinate > so that they use the same identifiers? Some cases where this may be the > case: > > - a call center recording all calls coming in, and then using an > IVR for part of the call handling. > > - a PBX that handles some incoming calls via an IVR and then eventually > transfers them to a phone hanging off the pbx. > > We made the *provision* in the metadata for multiple SRCs to coordinate, > but left the coordination out of scope. Does adding explict support here > require putting that back in scope? > > [hlum] It's likely we want some form of coordination, since it typical that an agent gets involved with IVR applications. If the contact center is served by a different SRC and the SRC for the IVR, then it makes sense to provide some form of coordination so that the SRS can figure out which portion of a customer call is related to IVR and which portion is related to agents. The latest protocol revision added the statement that the SRS allows such coordination, but I don't see how we can mandate all SRCs coordinate if the SRCs happen to record the same CS. > > Thanks, > Paul > > On 7/8/13 4:00 PM, Henry Lum wrote: >> Beyond the additional controls available in the VXML session itself, one use case for additional metadata collection is important waypoints and data in the VXML session. While it's possible to simply log all forms and fields entered but that can be way too much detail for a complex VXML application. Instead, it would be useful on the recording side to know whether the session have arrived at a certain point in the application and whether certain pieces of data has been collected. I mentioned the use of namelist which is a standard mechanism in RFC5552 for passing parameters at the end of the session. >> >> Regards, >> Henry >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: July-07-13 2:51 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt >> >> On 7/4/13 12:32 AM, Henry Lum wrote: >>> Hi - this is an initial draft about recording IVR sessions. I want to see if there is interest in working out more details about IVR recording >> >> I'm interested in hearing what you have in mind. >> At one level these should already be covered. You must want to capture >> some additional information. Is it that you want to record the VXML? >> >> Thanks, >> Paul >> >>> I'd be happy to present for the meeting if there is time for this. >>> >>> Thanks >>> Henry >>> >>> ________________________________________ >>> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >>> Sent: Thursday, July 04, 2013 12:28 AM >>> To: Henry Lum >>> Subject: New Version Notification for draft-lum-siprec-vxml-00.txt >>> >>> A new version of I-D, draft-lum-siprec-vxml-00.txt >>> has been successfully submitted by Henry Lum and posted to the >>> IETF repository. >>> >>> Filename: draft-lum-siprec-vxml >>> Revision: 00 >>> Title: Recording VoiceXML sessions with SIPREC >>> Creation date: 2013-07-04 >>> Group: Individual Submission >>> Number of pages: 6 >>> URL: http://www.ietf.org/internet-drafts/draft-lum-siprec-vxml-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-lum-siprec-vxml >>> Htmlized: http://tools.ietf.org/html/draft-lum-siprec-vxml-00 >>> >>> >>> Abstract: >>> This document addresses the use case of recording Interactive Voice >>> Response (IVR) VoiceXML applications using the SIPREC protocol. This >>> document also provides a potential solution for capturing additional >>> information about the call flow within the VoiceXML application from >>> a recording perspective. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> 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 michael.yan@huawei.com Fri Jul 19 01:27:51 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 E363221E80F2 for ; Fri, 19 Jul 2013 01:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48PryHhz-Dpv for ; Fri, 19 Jul 2013 01:27:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7AF11E81F3 for ; Fri, 19 Jul 2013 01:27:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO98934; Fri, 19 Jul 2013 08:27:37 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 09:26:52 +0100 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 09:27:34 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.161]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 16:27:20 +0800 From: "Yanqiang (Michael)" To: Henry Lum , Paul Kyzivat Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOg/0vmuKsiHqf80WmjI0Lr44sDJlrTydA Date: Fri, 19 Jul 2013 08:27:19 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B31375339@szxeml561-mbx.china.huawei.com> References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <51E71231.7070507@alum.mit.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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, 19 Jul 2013 08:27:51 -0000 SGkgQWxsLA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lLg0KDQo+IFJlY29yZGluZyBpbmRpY2F0aW9u ICYgcGF1c2UvcmVzdW1lOg0KPiANCj4gVGhpcyBpcyB0cml2aWFsIHdoZW4gdGhlIElWUiBhY3Rz IGFzIGFuIFNSQy4gQnV0IHdoZW4gdGhlcmUgaXMgYQ0KPiBzZXBhcmF0ZSBTUkMsIHdlIGhhdmUg ZGVmaW5lZCB0aGUgVUEgY29udHJvbCBvdmVyIHJlY29yZGluZyB0byBiZQ0KPiBzdHJpY3RseSBh ZHZpc29yeS4gU28gdGhlIElWUiBjb3VsZCAqcmVxdWVzdCogdGhhdCByZWNvcmRpbmcgc3RvcC4g VGhlbg0KPiBpdCBtdXN0IHNpbXBseSB3YWl0IHRvIHNlZSBpZiBpdCBnZXRzIGEgc2lnbmFsIGJh Y2sgdGhhdCByZWNvcmRpbmcgaGFzDQo+IHN0b3BwZWQsIHdoaWNoIG1heSBvciBtYXkgbm90IGJl IGNvbWluZy4gSXMgdGhhdCBnb29kIGVub3VnaCBmb3IgdGhlIElWUg0KPiBhcHBsaWNhdGlvbiBu ZWVkcz8NCj4gDQo+IFtobHVtXSBTaW5jZSByZXF1ZXN0IHRvIHBhdXNlIGlzIGFkdmlzb3J5LCB0 aGUgc2FtZSBwcm9ibGVtIGV4aXN0cyBmb3IgYSBjb250YWN0DQo+IGNlbnRlciBhZ2VudCBuZWVk aW5nIHRvIG1hbnVhbGx5IHBhdXNlIHRoZSByZWNvcmRpbmcgYmVmb3JlIHRha2luZyBzZW5zaXRp dmUNCj4gaW5mb3JtYXRpb24uIFRoZSBvbmx5IGZlZWRiYWNrIGZvciB0aGUgYWdlbnQgdG8gcHJv Y2VlZCB3aXRoIHRha2luZyB0aGUNCj4gc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGlzIGJ5IG9ic2Vy dmluZyB0aGUgcmVjb3JkaW5nIGluZGljYXRvciB0aGF0IGl0IGlzIGN1cnJlbnRseQ0KPiBwYXVz ZWQuIEZvciBhbiBJVlIgYXBwbGljYXRpb24gdGhpcyBjYW4gYmUgaGFyZGVyIHNpbmNlIHRoZSBw cm90b2NvbCBkb2VzIG5vdA0KPiBkZWZpbmUgaG93IGxvbmcgbXVzdCBhbiBTUkMgcHJvdmlkZSBh IGNoYW5nZSBpbiByZWNvcmRpbmcgaW5kaWNhdGlvbiwgc28gaXQgd2lsbA0KPiBoYXZlIHRvIGJl IHVwIHRvIHRoZSBJVlIgdG8gZGV0ZXJtaW5lIGhvdyBsb25nIHRvIHdhaXQgYmVmb3JlIHByb2Nl ZWRpbmcgdG8gYQ0KPiBmb3JtIG9yIGZpZWxkIHRha2luZyBzZW5zaXRpdmUgaW5mb3JtYXRpb24u IFBlcmhhcHMgd2hlbiBzb21ldGhpbmcgdGltZXMgb3V0DQo+IG9yIHRoZSByZXF1ZXN0IGlzIG5v dCBob25vdXJlZCwgdGhlIGludGVycHJldGVyIGNhbiB0aHJvdyBhbiBldmVudCBzbyB5b3UgY2Fu DQo+IGdldCBvdXQgb2YgdGhlIGZvcm0gd2l0aG91dCB0YWtpbmcgdGhlIGluZm9ybWF0aW9uLg0K PiANCj4gSG93IGxvbmcgd2lsbCBpdCB3YWl0PyBBbmQgb2YgY291cnNlIHRoZSBpbmRpY2F0aW9u DQo+IHRoYXQgcmVjb3JkaW5nIGhhcyBzdG9wcGVkIGNvdWxkIGJlIGEgbGllLiBJcyB0aGF0IE9L Pw0KPiANCj4gW2hsdW1dIEkgZ3Vlc3MgYW4gSVZSIGNhbid0IGRvIGFueXRoaW5nIGFib3V0IGFu IFNSQyBseWluZyBhYm91dCB0aGUgcmVjb3JkaW5nDQo+IGluZGljYXRpb24uIElmIHRoZSBkZXBs b3ltZW50IG5lZWRzIHRoZSBJVlIgdG8gYmUgYWJzb2x1dGVseSBzdXJlIGFib3V0IHRoaXMsDQo+ IHRoZW4gdGhlIElWUiBtdXN0IGhhdmUgdG8gYmVjb21lIHRoZSBTUkMgaXRzZWxmIG9yIGF0IGxl YXN0IG93biB0aGUgU1JDIHBvbGljeS4NCj4gDQpNYXliZSBhIGJldHRlciB3YXkgaXMgdG8gZGlz Y3VzcyB0aGVtIHNlcGFyYXRlbHksIA0KMSkgSVZSIGlzIHRoZSBTSVBSRUMtYXdhcmUgU0lQIFVB LCBhbmQgbmVlZCBhIHNlcGFyYXRlIFNSQyB0byByZWNvcmQgaXRzIHNlc3Npb24NCjIpIElWUiBp cyB0aGUgU1JDIGl0c2VsZiB3aXRoIGNlcnRhaW4gbWVkaWEgYWJpbGl0eT8gDQpFc3BlY2lhbGx5 IGlmIElWUiBpcyAjMSBjYXNlLCBkbyB3ZSBuZWVkIHRvIG1ha2UgYSBydWxlIGluIFNJUFJFQyBm b3IgdGhlIG1lY2hhbmlzbSBhYm91dCBob3cgU1JDIHJlY2VpdmVzIG9yIGFuc3dlcnMgd2l0aCBJ VlIoU0lQIFVBKT8gVGhlIDU1NTIgbWlnaHQgYmUgb25lIHdheSB0byBkbyBpdC4gSWYgSSBkb24n dCBtYWtlIGEgbWlzdGFrZSwgdGhlIENTVEEgc3RhbmRhcmQgbWlnaHQgYWxzbyBzdXBwb3J0IHRo ZSByZWNvcmRpbmcgaW5kaWNhdGlvbiAmIHBhdXNlL3Jlc3VtZSBiZXR3ZWVuIElWUi9hZ2VudCBh bmQgdGhlIFNSQyBpbiAjMSBjYXNlIChtaWdodCBiZSBhIG1lZGlhIHNlcnZlciBvciBBQ0QsIHRo ZSBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgYmUgc29tZSBldmVudHMgbm90aWZpY2F0aW9uKS4g V2UgY2FuIGNoZWNrIGh0dHA6Ly93d3cuZWNtYS1pbnRlcm5hdGlvbmFsLm9yZy9wdWJsaWNhdGlv bnMvZmlsZXMvRUNNQS1TVC9FQ01BLTI2OS5wZGYgZm9yIGRldGFpbHMgb24gc2VjdGlvbiAyNi4x LjkvMjYuMi45Lg0KDQo+IA0KPiBNZXRhZGF0YToNCj4gDQo+IFdoZW4gdGhlIFNSQyBpcyBzZXBh cmF0ZSBmcm9tIHRoZSBJVlIsIGhvdyB3b3VsZCB0aGUgU1JDIG9idGFpbiB0aGlzDQo+IGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gdGhhdCBpcyB0byBiZSBpbmNsdWRlZCBpbiB0aGUgbWV0YWRhdGE/ DQo+IA0KPiBbaGx1bV0gVGhhdCdzIGEgZ29vZCBwb2ludCBzaW5jZSB0aGVyZSBpcyBubyBzdWNo IGNvbW11bmljYXRpb24gZm9yIHRyYW5zcG9ydGluZw0KPiBhZGRpdGlvbmFsIG1ldGFkYXRhIGZv ciBTSVBSRUMtYXdhcmUgVUEuIEkgd29uZGVyIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGRlZmluZQ0K PiBhZGRpdGlvbmFsIGNvbW11bmljYXRpb24gdG8gdHVubmVsIG1ldGFkYXRhIHRvIFNSQyBhbmQg c2VuZCBvdmVyIHRvIFNSUy4gSW4NCj4gdGhpcyBjYXNlIHBlcmhhcHMgdGhlIElWUiB3aWxsIGhh dmUgdG8gcHJvdmlkZSB0aGUgbWV0YWRhdGEgdG8gU1JTIHRocm91Z2gNCj4gb3RoZXIgbWVjaGFu aXNtcy4NCj4gDQpJICp0aGluayogY3VycmVudCBkcmFmdCB0cmllZCB0byB1c2UgNTU1MiBtZWNo YW5pc20gKG1heWJlIG5vdCBlbm91Z2gpIHRvIHRyYW5zcG9ydCBjZXJ0YWluIGluZm9ybWF0aW9u IGZyb20gSVZSIChhbHNvIGFzIHZ4bWwgYXBwbGljYXRpb24pIHRvIFNSQy4gVGhlcmUgbWlnaHQg YmUgYSBnb29kIHdheSBvciBvdGhlcnMgYmV0dGVyIGFzIHdoYXQgeW91IHNhaWQgYXQgbGFzdC4g V2hhdCBJIG1vcmUgY2FyZSBhYm91dCBpcyB3aGF0IHdpbGwgYmUgdGhvc2UgYWRkaXRpb25hbCBt ZXRhZGF0YT8gV2lsbCBpdCBtYWtlIHRoZSBtZXRhZGF0YSBzdGFuZGFyZCBiZWNvbWUgYSBsb2dn aW5nIG9uZSwgYWZ0ZXIgd2UgYWNjZXB0IGNhc2VzIGFuZCByZXF1aXJlbWVudHMgbGlrZSBJVlIg cmVjb3JkaW5nIGZvciB0dW5pbmcgYW5kIGNvbmZlcmVuY2UgcmVjb3JkaW5nIGZvciB0cmFpbmlu Zy4gTm8gbWF0dGVyIGhvdywgSSBhZ3JlZSBTSVBSRUMgbmVlZCB0byBkZWZpbmUgdGhlIGZvcm1h dCBhbmQgY29udGVudCBvZiBhZGRpdGlvbmFsIG1ldGFkYXRhIGZvciB0aGUgY2FzZXMgYWJvdmUg aWYgd2Ugd291bGQgYWNjZXB0LCB3aGljaCBjb3VsZCBiZSB1c2VkIGZvciBpbXBsZW1lbnRpbmcg U1JDL1NSUyB3aGljaCBmb2xsb3cgU0lQUkVDLg0KDQo+IENvb3JkaW5hdGlvbiBvZiBTUkNzOg0K PiANCj4gKFlvdSBkb24ndCBoYXZlIGEgc2VjdGlvbiBvbiB0aGlzLikgSWYgdGhlIElWUiBhY3Rz IGFzIGl0cyBvd24gU1JDLCBkbw0KPiB3ZSBjYXJlIGlmIHRoZXJlIGlzIGFub3RoZXIgU1JDPyBJ ZiBzbywgZG8gd2UgZXhwZWN0IHRoZW0gdG8gY29vcmRpbmF0ZQ0KPiBzbyB0aGF0IHRoZXkgdXNl IHRoZSBzYW1lIGlkZW50aWZpZXJzPyBTb21lIGNhc2VzIHdoZXJlIHRoaXMgbWF5IGJlIHRoZQ0K PiBjYXNlOg0KPiANCj4gLSBhIGNhbGwgY2VudGVyIHJlY29yZGluZyBhbGwgY2FsbHMgY29taW5n IGluLCBhbmQgdGhlbiB1c2luZyBhbg0KPiAgICBJVlIgZm9yIHBhcnQgb2YgdGhlIGNhbGwgaGFu ZGxpbmcuDQo+IA0KPiAtIGEgUEJYIHRoYXQgaGFuZGxlcyBzb21lIGluY29taW5nIGNhbGxzIHZp YSBhbiBJVlIgYW5kIHRoZW4gZXZlbnR1YWxseQ0KPiAgICB0cmFuc2ZlcnMgdGhlbSB0byBhIHBo b25lIGhhbmdpbmcgb2ZmIHRoZSBwYnguDQo+IA0KPiBXZSBtYWRlIHRoZSAqcHJvdmlzaW9uKiBp biB0aGUgbWV0YWRhdGEgZm9yIG11bHRpcGxlIFNSQ3MgdG8gY29vcmRpbmF0ZSwNCj4gYnV0IGxl ZnQgdGhlIGNvb3JkaW5hdGlvbiBvdXQgb2Ygc2NvcGUuIERvZXMgYWRkaW5nIGV4cGxpY3Qgc3Vw cG9ydCBoZXJlDQo+IHJlcXVpcmUgcHV0dGluZyB0aGF0IGJhY2sgaW4gc2NvcGU/DQo+IA0KPiBb aGx1bV0gSXQncyBsaWtlbHkgd2Ugd2FudCBzb21lIGZvcm0gb2YgY29vcmRpbmF0aW9uLCBzaW5j ZSBpdCB0eXBpY2FsIHRoYXQgYW4NCj4gYWdlbnQgZ2V0cyBpbnZvbHZlZCB3aXRoIElWUiBhcHBs aWNhdGlvbnMuIElmIHRoZSBjb250YWN0IGNlbnRlciBpcyBzZXJ2ZWQgYnkgYQ0KPiBkaWZmZXJl bnQgU1JDIGFuZCB0aGUgU1JDIGZvciB0aGUgSVZSLCB0aGVuIGl0IG1ha2VzIHNlbnNlIHRvIHBy b3ZpZGUgc29tZSBmb3JtDQo+IG9mIGNvb3JkaW5hdGlvbiBzbyB0aGF0IHRoZSBTUlMgY2FuIGZp Z3VyZSBvdXQgd2hpY2ggcG9ydGlvbiBvZiBhIGN1c3RvbWVyIGNhbGwgaXMNCj4gcmVsYXRlZCB0 byBJVlIgYW5kIHdoaWNoIHBvcnRpb24gaXMgcmVsYXRlZCB0byBhZ2VudHMuIFRoZSBsYXRlc3Qg cHJvdG9jb2wNCj4gcmV2aXNpb24gYWRkZWQgdGhlIHN0YXRlbWVudCB0aGF0IHRoZSBTUlMgYWxs b3dzIHN1Y2ggY29vcmRpbmF0aW9uLCBidXQgSSBkb24ndA0KPiBzZWUgaG93IHdlIGNhbiBtYW5k YXRlIGFsbCBTUkNzIGNvb3JkaW5hdGUgaWYgdGhlIFNSQ3MgaGFwcGVuIHRvIHJlY29yZCB0aGUN Cj4gc2FtZSBDUy4NCj4gDQpGb3IgYSBjYWxsIGNlbnRlciBoYW5kbGluZyB3aXRoIGluY29taW5n IGNhbGxzIHdvdWxkIGhhdmUgYWdlbnRzIGFuZCBJVlIgdG9nZXRoZXIgd29ya2luZyBpbiBnZW5l cmFsIHRpbWUuIFRoZSBmdWxsIHJlY29yZGluZyByZXF1aXJlbWVudCBpbiB0aGlzIGNhc2Ugd291 bGQgYXNrIHRvIHJlY29yZCBtZWRpYSBmcm9tIGRpZmZlcmVudCBTUkNzLCBhbmQgbWlnaHQgcmVj b3JkIHRoZSBzYW1lIENTICh0aGUgY2FsbCB0cmFuc2ZlcnJlZCBmcm9tIElWUiB0byBhZ2VudCwg YW5kIHNlc3Npb24gYmFzZWQgb24gY3VzdG9tZXIgc2lkZSkuIEkgbm90aWNlIGRyYWZ0LWlldGYt c2lwcmVjLW1ldGFkYXRhLTEyIHNlY3Rpb24gNi4xMCB0YWxrcyBhYm91dCB0aGUgSUQgZm9yIG11 bHRpcGxlIFNSQ3MgY29vcmRpbmF0aW9uLCBhbmQgZHJhZnQtaWV0Zi1zaXByZWMtcHJvdG9jb2wt MTAgc2VjdGlvbiA3LjMuMSBzYXlzIGluIG11bHRpcGxlIFNSQ3MgY2FzZSB0aGUgZW5kcG9pbnQg b25seSBrbm93cyB0aGF0IHRoZSBjYWxsIGlzIGJlaW5nIHJlY29yZGVkIHZpYSByZWNvcmRpbmcg aW5kaWNhdGlvbi4gU28gSSBzdGlsbCBkb24ndCBnZXQgdGhlIGFuc3dlciBvciB3aGF0IG5lZWQg dG8gYmUgYWRkZWQgaWYgd2UgbmVlZCB0byBjb29yZGluYXRlIHRoZSBTUkNzIGZvciBJVlIgYW5k IG90aGVyIFVBcy4NCg0KVGhhbmtzLA0KTWljaGFlbA0K From michael.yan@huawei.com Fri Jul 19 01:37:58 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB7F21E8145 for ; Fri, 19 Jul 2013 01:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Qt1btgtisH for ; Fri, 19 Jul 2013 01:37:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 892B721E812B for ; Fri, 19 Jul 2013 01:37:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVF26698; Fri, 19 Jul 2013 08:37:46 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 09:36:46 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 09:37:44 +0100 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.161]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 16:37:41 +0800 From: "Yanqiang (Michael)" To: Henry Lum , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOe0LlglPBNJwrXk+qoccqgtS+qplbM1bggAvHrlCAAZOLAIADLo7A Date: Fri, 19 Jul 2013 08:37:41 +0000 Message-ID: <21794EB0EE82B0458A524942A141542B31375353@szxeml561-mbx.china.huawei.com> References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <21794EB0EE82B0458A524942A141542B31374748@szxeml561-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.98.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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, 19 Jul 2013 08:37:58 -0000 SGkgSGVucnksDQoNCglQbGVhc2UgY2hlY2sgaW5saW5lLg0KDQo+IAlJIHdlbnQgdGhyb3VnaCB5 b3VyIGRyYWZ0IGRyYWZ0LWx1bS1zaXByZWMtdnhtbC0wMCBhbmQgcmZjNTU1MiAoaGF2ZW4ndA0K PiByZWFkIHRoZSBkZXRhaWxzIGJlZm9yZSkgYW5kIGdvdCBzZXZlcmFsIHF1ZXN0aW9ucy4gQ2Fu IHlvdSBoZWxwIHRvIGZpZ3VyZSB0aGVtDQo+IG91dD8gOikNCj4gDQo+IDEuIAkgRGVmaW5pdGlv biBvZiB2eG1sIGFwcGxpY2F0aW9uKElWUiksIHZ4bWwgbWVkaWEgc2VydmVyLCB2eG1sIGludGVy cHJldGVyPw0KPiBUaGUgMS4yIHNlY3Rpb24gc2F5cyB0aGF0ICJUaGUgSVZSIGluIHRoaXMgY2Fz ZSBjYW4gYmUgYSBTSVBSRUMtYXdhcmUgU0lQIFVBIGFuZA0KPiByZWxpZXMgb24gYSBzZXBhcmF0 ZSBTUkMgdG8gcHJvdmlkZSByZWNvcmRpbmcgY2FwYWJpbGl0aWVzIi4gRG9lcyBpdCBtZWFuIHRo YXQNCj4gU0lQUkVDLWF3YXJlIFNJUCBVQSBydW5zIHRoZSB2eG1sIGFwcGxpY2F0aW9uKElWUiBh cHBsaWNhdGlvbiksIGFuZCB0aGUgdnhtbA0KPiBtZWRpYSBzZXJ2ZXIgYWN0ZWQgYXMgdGhlIFNS QyB0byBwcm92aWRlIHJlY29yZGluZyBjYXBhYmlsaXRpZXM/IFJmYzU1NTIgaGFzDQo+IGRlZmlu ZWQgdGhlIHZ4bWwgbWVkaWEgc2VydmVyKHZ4bWwgaW50ZXJwcmV0ZXIgYXMgd2VsbD8pIGFuZCB2 eG1sIGFwcGxpY2F0aW9uDQo+IHdoaWNoIG9mZmVycyB0aGUgSVZSIChhcyBhIHNlcnZpY2UpLiBS ZmM1NTUyIHNheXMgdnhtbCBhcHBsaWNhdGlvbiBjYW4gYmUNCj4gZGVwbG95ZWQgb24gYW4gYXBw bGljYXRpb24gc2VydmVyLCBhIHNlcGFyYXRlZCBvbmUgb3IgdGhlIHZ4bWwgbWVkaWEgc2VydmVy DQo+IGRpcmVjdGx5LiBEbyB3ZSBuZWVkIHRvIG1ha2UgYSBkZWZpbml0aW9uIGluIHRoaXMgZHJh ZnQgdG8gY29uZm9ybSB0byA1NTUyPw0KPiANCj4gW2hsdW1dIEkgdGhpbmsgdGhlcmUgYXJlIG9w dGlvbnMgaW4gdGVybXMgb2YgaW1wbGVtZW50YXRpb24gb2YgdGhlIFZYTUwgbWVkaWENCj4gc2Vy dmVyIGFzIGEgU0lQIFVBLiBJdCBjYW4gZWl0aGVyIGJlIGEgU0lQUkVDLWF3YXJlIFVBIHRoYXQg cmVsaWVzIG9uIGEgc2VwYXJhdGUNCj4gU1JDIHRvIHBlcmZvcm0gdGhlIHJlY29yZGluZywgdGhl IFZYTUwgbWVkaWEgc2VydmVyIGNhbiBiZSB0aGUgU1JDIGl0c2VsZiBhbmQNCj4gcHJvdmlkZSBy ZWNvcmRpbmcgZGlyZWN0bHkuIFRoZSBWWE1MIGFwcGxpY2F0aW9uIGl0c2VsZiBkb2VzIG5vdCBw ZXJmb3JtDQo+IHJlY29yZGluZyBzbyB0aGlzIGRyYWZ0IGlzIG5vdCBtYWtpbmcgY2hhbmdlcyB0 byB0aGlzIGRlZmluaXRpb247IHBlcmhhcHMgd2UgY2FuDQo+IGp1c3QgcmVmZXIgdG8gNTU1MiBm b3IgdGhlIGRlZmluaXRpb24uDQo+IA0KQWdyZWVkLiBJdCB3aWxsIGJlIGFwcHJlY2lhdGVkIHdl IGNvdWxkIG1lbnRpb24gdGhlc2UgZGVmaW5pdGlvbnMgd2hlbiBkaXNjdXNzaW5nIHRoaXMgZHJh ZnQgb24gODd0aC4NCg0KPiAyLiAJVGhlIGNvbW11bmljYXRpb24gbWVjaGFuaXNtIGluIElWUiBy ZWNvcmRpbmcuDQo+IFRoZSBkcmFmdCB0YWxrcyBhYm91dCBob3cgdGhlIHZ4bWwgbWVkaWEgc2Vy dmVyIG9yIElWUiBpdHNlbGYgcmVzcG9uZCB0aGUNCj4gYWN0aW9ucyBsaWtlIHN0YXJ0L3N0b3Av cGF1c2UvcmVzdW1lIGFzIHRoZSBTUkMgdmlhIDU1NTIuIElmIEkgZGlkbid0IG1ha2UgYQ0KPiB3 cm9uZyB1bmRlcnN0YW5kaW5nLCBoZXJlIG1lYW5zIElWUiBjYW4gY29tbXVuaWNhdGUgd2l0aCB2 eG1sIG1lZGlhIHNlcnZlcg0KPiB2aWEgNTU1MiwgYW5kIHZ4bWwgbWVkaWEgc2VydmVyIGNhbiBi ZSB0aGUgU1JDIHZpYSBjdXJyZW50IFNJUFJFQyBtZWNoYW5pc20uDQo+IE1heWJlIGEgc2ltcGxl IGRyYXcgY2FuIGhlbHAgdG8gdW5kZXJzdGFuZCBpdCBiZXR0ZXIuDQo+IA0KPiBbaGx1bV0gQWdy ZWVkIC0gYSBkcmF3aW5nIHdvdWxkIGhlbHAgdG8gZXhwbGFpbiB0aGUgZGlmZmVyZW5jZSBpbg0K PiBpbXBsZW1lbnRhdGlvbiB0eXBlcyBmb3IgdGhlIG1lZGlhIHNlcnZlciBhbmQgaG93IHRoZSBt ZWNoYW5pY3MgY2FuIHdvcmsuDQo+IExldCBtZSBzdGFydCB3aXRoIHNsaWRlcyBmaXJzdCBhbmQg dGhlbiB0cmFuc2xhdGUgdGhhdCBpbnRvIHRoZSBuZXh0IGRyYWZ0IHJldmlzaW9uLg0KPiANCkRl ZmluaXRlbHkuIExvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHNsaWRlLg0KDQo+IDMuCSBIb3cgdG8g c3VwcG9ydCB0dW5pbmcgSVZSIHBlcmZvcm1hbmNlIHZpYSBlc3NlbnRpYWwgbWV0YWRhdGEgPw0K PiBBcyB0aGUgVXNlIENhc2UgNiBzYXlzIGluIDYzNDEsIHR1bmluZyBJVlIgcGVyZm9ybWFuY2Ug aXMgb25lIG9mIHRoZSBjYXNlIGFib3V0DQo+IElWUiByZWNvcmRpbmcuIEJ1dCBvYnZpb3VzbHks IGl0IHNlZW1zIHRvIGJlIGEgYml0IGNvbXBsaWNhdGVkIHRvIHJlY29yZCB0aGUNCj4gZW50aXJl IElWUiB0cmFjZS4gVGhpcyBkcmFmdCdzIFJFUTYgc2F5cywgIiBEZWZpbmUgYWRkaXRpb25hbCBt ZXRhZGF0YSB0byBwcm92aWRlDQo+IGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhcHBs aWNhdGlvbiBleGVjdXRlZC4iIEJ1dCB3aGF0IGtpbmQgb2YNCj4gd2F5cG9pbnRzIG9yIG5vZGVz IG9mIElWUiB3b3VsZCBiZSB1c2VkIGZvciB0dW5pbmc/IFRoZSA8ZXhpdD4gbmFtZWxpc3QgaXMN Cj4gZ29vZCBidXQgaXQgaXMgZW5vdWdoIGZvciBJVlIgdHVuaW5nPw0KPiANCj4gW2hsdW1dIElW UiB0dW5pbmcgY2FuIG1lYW4gYSBsb3Qgb2YgdGhpbmdzLCBpdCBjYW4gYmUgZWl0aGVyIHR1bmlu ZyB5b3VyIHNwZWVjaA0KPiBncmFtbWFyIHRvIGNhdGNoIG1vcmUgcGhyYXNlcyB0aGF0IHVzZXJz IGFjdHVhbGx5IHNwZWFrLCB0dW5pbmcgdGhlIGFwcGxpY2F0aW9uDQo+IHRvIGhlbHAgdXNlcnMg Y29tcGxldGUgdGhlaXIgdHJhbnNhY3Rpb25zLCBvciBldmVuIHR1bmluZyBpbnB1dC10by1wcm9t cHQNCj4gbGF0ZW5jaWVzLiBJbiBnZW5lcmFsIEkgdGhpbmsgdGhlIG1vcmUgaW5mb3JtYXRpb24g YXZhaWxhYmxlIHRoZSBiZXR0ZXIgYnV0IHdlDQo+IGRvbid0IHdhbnQgdG8gdHVybiBTSVBSRUMg aW50byBhIGxvZ2dpbmcgb3IgZGVidWcgZmFjaWxpdHkuIFRoYXQncyB3aHkgSSB0aGluayB3ZQ0K PiBjYW4gcHJvdmlkZSBzb21lIHN1Z2dlc3Rpb25zIGZvciB0aGUgSVZSIHRvIHByb3ZpZGUgc29t ZSB1c2VmdWwgYnV0IG5vdA0KPiBleGNlc3NpdmUgaW5mb3JtYXRpb24gaW4gYWRkaXRpb24gdG8g dGhlIGF1ZGlvIGl0c2VsZiB0byBhZGRyZXNzIHRoZSB0dW5pbmcgdXNlDQo+IGNhc2UuDQo+IA0K SSBkb24ndCB3YW50IHRoZSBTSVBSRUMgYmVjb21lIGEgbG9nZ2luZyBzdGFuZGFyZCwgZXNwZWNp YWxseSBmb3IgbWV0YWRhdGEgcGFydC4gQW5kIG15IG9waW5pb24gaXMgd2Ugc2hvdWxkIGRpc2N1 c3MgdGhlIElWUiByZWNvcmRpbmcgY2FzZXMgY2FyZWZ1bGx5IHRvIGZpbmQgd2hhdCBpdCBuZWVk IGluIG1pbmltdW0uIA0KU2ltaWxhcmx5LCBJJ2QgbGlrZSB5b3UgdG8gZ2l2ZSBzb21lIGhlbHAg dG8gdGhlIGNvbmZlcmVuY2UgcmVjb3JkaW5nIGRyYWZ0LCB3aGljaCBhbHNvIGZhY2VzIHRoZSBp c3N1ZSBhYm91dCBhZGRpdGlvbmFsIG1ldGFkYXRhIGNob29zaW5nLg0KDQpUaGFua3MsDQpNaWNo YWVsDQo= From henry.lum@genesyslab.com Thu Jul 25 07:57: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 98B8521F89C3 for ; Thu, 25 Jul 2013 07:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 biFWoAn3I8PA for ; Thu, 25 Jul 2013 07:57:47 -0700 (PDT) Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 046A521F8994 for ; Thu, 25 Jul 2013 07:57:45 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Thu, 25 Jul 2013 10:57:41 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 07:57:39 -0700 From: Henry Lum To: "Yanqiang (Michael)" , Paul Kyzivat Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOgzf882kUd618MkOY+4A8adA8zZlq7mrAgAE0D4CABRzyAA== Date: Thu, 25 Jul 2013 14:57:39 +0000 Message-ID: References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <51E71231.7070507@alum.mit.edu> <21794EB0EE82B0458A524942A141542B31375339@szxeml561-mbx.china.huawei.com> In-Reply-To: <21794EB0EE82B0458A524942A141542B31375339@szxeml561-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.17.178.16] MIME-Version: 1.0 X-MC-Unique: 113072510574103501 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Thu, 25 Jul 2013 14:57:52 -0000 SGkgTWljaGFlbCAtIHBsZWFzZSBzZWUgaW5saW5lLg0KDQpIZW5yeQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogWWFucWlhbmcgKE1pY2hhZWwpIFttYWlsdG86bWljaGFlbC55 YW5AaHVhd2VpLmNvbV0gDQpTZW50OiBKdWx5LTE5LTEzIDQ6MjcgQU0NClRvOiBIZW5yeSBMdW07 IFBhdWwgS3l6aXZhdA0KQ2M6IHNpcHJlY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzaXByZWNd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWx1bS1zaXByZWMtdnhtbC0w MC50eHQNCg0KSGkgQWxsLA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lLg0KDQo+IFJlY29yZGluZyBp bmRpY2F0aW9uICYgcGF1c2UvcmVzdW1lOg0KPiANCj4gVGhpcyBpcyB0cml2aWFsIHdoZW4gdGhl IElWUiBhY3RzIGFzIGFuIFNSQy4gQnV0IHdoZW4gdGhlcmUgaXMgYQ0KPiBzZXBhcmF0ZSBTUkMs IHdlIGhhdmUgZGVmaW5lZCB0aGUgVUEgY29udHJvbCBvdmVyIHJlY29yZGluZyB0byBiZQ0KPiBz dHJpY3RseSBhZHZpc29yeS4gU28gdGhlIElWUiBjb3VsZCAqcmVxdWVzdCogdGhhdCByZWNvcmRp bmcgc3RvcC4gVGhlbg0KPiBpdCBtdXN0IHNpbXBseSB3YWl0IHRvIHNlZSBpZiBpdCBnZXRzIGEg c2lnbmFsIGJhY2sgdGhhdCByZWNvcmRpbmcgaGFzDQo+IHN0b3BwZWQsIHdoaWNoIG1heSBvciBt YXkgbm90IGJlIGNvbWluZy4gSXMgdGhhdCBnb29kIGVub3VnaCBmb3IgdGhlIElWUg0KPiBhcHBs aWNhdGlvbiBuZWVkcz8NCj4gDQo+IFtobHVtXSBTaW5jZSByZXF1ZXN0IHRvIHBhdXNlIGlzIGFk dmlzb3J5LCB0aGUgc2FtZSBwcm9ibGVtIGV4aXN0cyBmb3IgYSBjb250YWN0DQo+IGNlbnRlciBh Z2VudCBuZWVkaW5nIHRvIG1hbnVhbGx5IHBhdXNlIHRoZSByZWNvcmRpbmcgYmVmb3JlIHRha2lu ZyBzZW5zaXRpdmUNCj4gaW5mb3JtYXRpb24uIFRoZSBvbmx5IGZlZWRiYWNrIGZvciB0aGUgYWdl bnQgdG8gcHJvY2VlZCB3aXRoIHRha2luZyB0aGUNCj4gc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGlz IGJ5IG9ic2VydmluZyB0aGUgcmVjb3JkaW5nIGluZGljYXRvciB0aGF0IGl0IGlzIGN1cnJlbnRs eQ0KPiBwYXVzZWQuIEZvciBhbiBJVlIgYXBwbGljYXRpb24gdGhpcyBjYW4gYmUgaGFyZGVyIHNp bmNlIHRoZSBwcm90b2NvbCBkb2VzIG5vdA0KPiBkZWZpbmUgaG93IGxvbmcgbXVzdCBhbiBTUkMg cHJvdmlkZSBhIGNoYW5nZSBpbiByZWNvcmRpbmcgaW5kaWNhdGlvbiwgc28gaXQgd2lsbA0KPiBo YXZlIHRvIGJlIHVwIHRvIHRoZSBJVlIgdG8gZGV0ZXJtaW5lIGhvdyBsb25nIHRvIHdhaXQgYmVm b3JlIHByb2NlZWRpbmcgdG8gYQ0KPiBmb3JtIG9yIGZpZWxkIHRha2luZyBzZW5zaXRpdmUgaW5m b3JtYXRpb24uIFBlcmhhcHMgd2hlbiBzb21ldGhpbmcgdGltZXMgb3V0DQo+IG9yIHRoZSByZXF1 ZXN0IGlzIG5vdCBob25vdXJlZCwgdGhlIGludGVycHJldGVyIGNhbiB0aHJvdyBhbiBldmVudCBz byB5b3UgY2FuDQo+IGdldCBvdXQgb2YgdGhlIGZvcm0gd2l0aG91dCB0YWtpbmcgdGhlIGluZm9y bWF0aW9uLg0KPiANCj4gSG93IGxvbmcgd2lsbCBpdCB3YWl0PyBBbmQgb2YgY291cnNlIHRoZSBp bmRpY2F0aW9uDQo+IHRoYXQgcmVjb3JkaW5nIGhhcyBzdG9wcGVkIGNvdWxkIGJlIGEgbGllLiBJ cyB0aGF0IE9LPw0KPiANCj4gW2hsdW1dIEkgZ3Vlc3MgYW4gSVZSIGNhbid0IGRvIGFueXRoaW5n IGFib3V0IGFuIFNSQyBseWluZyBhYm91dCB0aGUgcmVjb3JkaW5nDQo+IGluZGljYXRpb24uIElm IHRoZSBkZXBsb3ltZW50IG5lZWRzIHRoZSBJVlIgdG8gYmUgYWJzb2x1dGVseSBzdXJlIGFib3V0 IHRoaXMsDQo+IHRoZW4gdGhlIElWUiBtdXN0IGhhdmUgdG8gYmVjb21lIHRoZSBTUkMgaXRzZWxm IG9yIGF0IGxlYXN0IG93biB0aGUgU1JDIHBvbGljeS4NCj4gDQpNYXliZSBhIGJldHRlciB3YXkg aXMgdG8gZGlzY3VzcyB0aGVtIHNlcGFyYXRlbHksIA0KMSkgSVZSIGlzIHRoZSBTSVBSRUMtYXdh cmUgU0lQIFVBLCBhbmQgbmVlZCBhIHNlcGFyYXRlIFNSQyB0byByZWNvcmQgaXRzIHNlc3Npb24N CjIpIElWUiBpcyB0aGUgU1JDIGl0c2VsZiB3aXRoIGNlcnRhaW4gbWVkaWEgYWJpbGl0eT8gDQpb aGx1bV0gSXQgbG9va3MgbGlrZSB0aGVzZSBzb2x1dGlvbiBkbyBkaXZlcmdlIGEgbGl0dGxlIGJp dCBzbyBpdCBtYXkgYmUgd29ydGh3aGlsZSB0byB0YWxrIGFib3V0IHRoZW0gc2VwYXJhdGVseQ0K DQpFc3BlY2lhbGx5IGlmIElWUiBpcyAjMSBjYXNlLCBkbyB3ZSBuZWVkIHRvIG1ha2UgYSBydWxl IGluIFNJUFJFQyBmb3IgdGhlIG1lY2hhbmlzbSBhYm91dCBob3cgU1JDIHJlY2VpdmVzIG9yIGFu c3dlcnMgd2l0aCBJVlIoU0lQIFVBKT8gVGhlIDU1NTIgbWlnaHQgYmUgb25lIHdheSB0byBkbyBp dC4gSWYgSSBkb24ndCBtYWtlIGEgbWlzdGFrZSwgdGhlIENTVEEgc3RhbmRhcmQgbWlnaHQgYWxz byBzdXBwb3J0IHRoZSByZWNvcmRpbmcgaW5kaWNhdGlvbiAmIHBhdXNlL3Jlc3VtZSBiZXR3ZWVu IElWUi9hZ2VudCBhbmQgdGhlIFNSQyBpbiAjMSBjYXNlIChtaWdodCBiZSBhIG1lZGlhIHNlcnZl ciBvciBBQ0QsIHRoZSBmZWVkYmFjayBtZWNoYW5pc20gd291bGQgYmUgc29tZSBldmVudHMgbm90 aWZpY2F0aW9uKS4gV2UgY2FuIGNoZWNrIGh0dHA6Ly93d3cuZWNtYS1pbnRlcm5hdGlvbmFsLm9y Zy9wdWJsaWNhdGlvbnMvZmlsZXMvRUNNQS1TVC9FQ01BLTI2OS5wZGYgZm9yIGRldGFpbHMgb24g c2VjdGlvbiAyNi4xLjkvMjYuMi45Lg0KDQpbaGx1bV0gU2luY2Ugd2UgYXJlIGZvY3VzZWQgb24g U0lQUkVDIGFuZCBTSVAgb25seSwgSSB0aGluayA1NTUyIGlzIHRoZSBvbmx5IHNwZWNpZmljYXRp b24gdGhhdCB0YWxrcyBhYm91dCBpbnRlZ3JhdGlvbiB3aXRoIFZYTUwgd2l0aCBTSVAuIEkgYW0g bm90IHN1cmUgaG93IHRvIHRpZSB0aGF0IHdpdGggQ1NUQSBpbnRlcmZhY2UgYXMgd2UgYXJlIG9u bHkgZm9jdXNpbmcgb24gU0lQIG9ubHkuDQoNCj4gDQo+IE1ldGFkYXRhOg0KPiANCj4gV2hlbiB0 aGUgU1JDIGlzIHNlcGFyYXRlIGZyb20gdGhlIElWUiwgaG93IHdvdWxkIHRoZSBTUkMgb2J0YWlu IHRoaXMNCj4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aGF0IGlzIHRvIGJlIGluY2x1ZGVkIGlu IHRoZSBtZXRhZGF0YT8NCj4gDQo+IFtobHVtXSBUaGF0J3MgYSBnb29kIHBvaW50IHNpbmNlIHRo ZXJlIGlzIG5vIHN1Y2ggY29tbXVuaWNhdGlvbiBmb3IgdHJhbnNwb3J0aW5nDQo+IGFkZGl0aW9u YWwgbWV0YWRhdGEgZm9yIFNJUFJFQy1hd2FyZSBVQS4gSSB3b25kZXIgaWYgaXQgbWFrZXMgc2Vu c2UgdG8gZGVmaW5lDQo+IGFkZGl0aW9uYWwgY29tbXVuaWNhdGlvbiB0byB0dW5uZWwgbWV0YWRh dGEgdG8gU1JDIGFuZCBzZW5kIG92ZXIgdG8gU1JTLiBJbg0KPiB0aGlzIGNhc2UgcGVyaGFwcyB0 aGUgSVZSIHdpbGwgaGF2ZSB0byBwcm92aWRlIHRoZSBtZXRhZGF0YSB0byBTUlMgdGhyb3VnaA0K PiBvdGhlciBtZWNoYW5pc21zLg0KPiANCkkgKnRoaW5rKiBjdXJyZW50IGRyYWZ0IHRyaWVkIHRv IHVzZSA1NTUyIG1lY2hhbmlzbSAobWF5YmUgbm90IGVub3VnaCkgdG8gdHJhbnNwb3J0IGNlcnRh aW4gaW5mb3JtYXRpb24gZnJvbSBJVlIgKGFsc28gYXMgdnhtbCBhcHBsaWNhdGlvbikgdG8gU1JD LiBUaGVyZSBtaWdodCBiZSBhIGdvb2Qgd2F5IG9yIG90aGVycyBiZXR0ZXIgYXMgd2hhdCB5b3Ug c2FpZCBhdCBsYXN0LiBXaGF0IEkgbW9yZSBjYXJlIGFib3V0IGlzIHdoYXQgd2lsbCBiZSB0aG9z ZSBhZGRpdGlvbmFsIG1ldGFkYXRhPyBXaWxsIGl0IG1ha2UgdGhlIG1ldGFkYXRhIHN0YW5kYXJk IGJlY29tZSBhIGxvZ2dpbmcgb25lLCBhZnRlciB3ZSBhY2NlcHQgY2FzZXMgYW5kIHJlcXVpcmVt ZW50cyBsaWtlIElWUiByZWNvcmRpbmcgZm9yIHR1bmluZyBhbmQgY29uZmVyZW5jZSByZWNvcmRp bmcgZm9yIHRyYWluaW5nLiBObyBtYXR0ZXIgaG93LCBJIGFncmVlIFNJUFJFQyBuZWVkIHRvIGRl ZmluZSB0aGUgZm9ybWF0IGFuZCBjb250ZW50IG9mIGFkZGl0aW9uYWwgbWV0YWRhdGEgZm9yIHRo ZSBjYXNlcyBhYm92ZSBpZiB3ZSB3b3VsZCBhY2NlcHQsIHdoaWNoIGNvdWxkIGJlIHVzZWQgZm9y IGltcGxlbWVudGluZyBTUkMvU1JTIHdoaWNoIGZvbGxvdyBTSVBSRUMuDQoNCltobHVtXSBQZXJo YXBzIHdlIHNob3VsZCBmaW5kIG91dCB3aGF0IHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB3ZSBuZWVk IGZvciB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIHVzZSBjYXNlcy4gVGhpcyBjYW4gaGVscCB1cyBz cGVjaWZ5IHRoZSBtZXRhZGF0YSBmb3JtYXQuDQoNCj4gQ29vcmRpbmF0aW9uIG9mIFNSQ3M6DQo+ IA0KPiAoWW91IGRvbid0IGhhdmUgYSBzZWN0aW9uIG9uIHRoaXMuKSBJZiB0aGUgSVZSIGFjdHMg YXMgaXRzIG93biBTUkMsIGRvDQo+IHdlIGNhcmUgaWYgdGhlcmUgaXMgYW5vdGhlciBTUkM/IElm IHNvLCBkbyB3ZSBleHBlY3QgdGhlbSB0byBjb29yZGluYXRlDQo+IHNvIHRoYXQgdGhleSB1c2Ug dGhlIHNhbWUgaWRlbnRpZmllcnM/IFNvbWUgY2FzZXMgd2hlcmUgdGhpcyBtYXkgYmUgdGhlDQo+ IGNhc2U6DQo+IA0KPiAtIGEgY2FsbCBjZW50ZXIgcmVjb3JkaW5nIGFsbCBjYWxscyBjb21pbmcg aW4sIGFuZCB0aGVuIHVzaW5nIGFuDQo+ICAgIElWUiBmb3IgcGFydCBvZiB0aGUgY2FsbCBoYW5k bGluZy4NCj4gDQo+IC0gYSBQQlggdGhhdCBoYW5kbGVzIHNvbWUgaW5jb21pbmcgY2FsbHMgdmlh IGFuIElWUiBhbmQgdGhlbiBldmVudHVhbGx5DQo+ICAgIHRyYW5zZmVycyB0aGVtIHRvIGEgcGhv bmUgaGFuZ2luZyBvZmYgdGhlIHBieC4NCj4gDQo+IFdlIG1hZGUgdGhlICpwcm92aXNpb24qIGlu IHRoZSBtZXRhZGF0YSBmb3IgbXVsdGlwbGUgU1JDcyB0byBjb29yZGluYXRlLA0KPiBidXQgbGVm dCB0aGUgY29vcmRpbmF0aW9uIG91dCBvZiBzY29wZS4gRG9lcyBhZGRpbmcgZXhwbGljdCBzdXBw b3J0IGhlcmUNCj4gcmVxdWlyZSBwdXR0aW5nIHRoYXQgYmFjayBpbiBzY29wZT8NCj4gDQo+IFto bHVtXSBJdCdzIGxpa2VseSB3ZSB3YW50IHNvbWUgZm9ybSBvZiBjb29yZGluYXRpb24sIHNpbmNl IGl0IHR5cGljYWwgdGhhdCBhbg0KPiBhZ2VudCBnZXRzIGludm9sdmVkIHdpdGggSVZSIGFwcGxp Y2F0aW9ucy4gSWYgdGhlIGNvbnRhY3QgY2VudGVyIGlzIHNlcnZlZCBieSBhDQo+IGRpZmZlcmVu dCBTUkMgYW5kIHRoZSBTUkMgZm9yIHRoZSBJVlIsIHRoZW4gaXQgbWFrZXMgc2Vuc2UgdG8gcHJv dmlkZSBzb21lIGZvcm0NCj4gb2YgY29vcmRpbmF0aW9uIHNvIHRoYXQgdGhlIFNSUyBjYW4gZmln dXJlIG91dCB3aGljaCBwb3J0aW9uIG9mIGEgY3VzdG9tZXIgY2FsbCBpcw0KPiByZWxhdGVkIHRv IElWUiBhbmQgd2hpY2ggcG9ydGlvbiBpcyByZWxhdGVkIHRvIGFnZW50cy4gVGhlIGxhdGVzdCBw cm90b2NvbA0KPiByZXZpc2lvbiBhZGRlZCB0aGUgc3RhdGVtZW50IHRoYXQgdGhlIFNSUyBhbGxv d3Mgc3VjaCBjb29yZGluYXRpb24sIGJ1dCBJIGRvbid0DQo+IHNlZSBob3cgd2UgY2FuIG1hbmRh dGUgYWxsIFNSQ3MgY29vcmRpbmF0ZSBpZiB0aGUgU1JDcyBoYXBwZW4gdG8gcmVjb3JkIHRoZQ0K PiBzYW1lIENTLg0KPiANCkZvciBhIGNhbGwgY2VudGVyIGhhbmRsaW5nIHdpdGggaW5jb21pbmcg Y2FsbHMgd291bGQgaGF2ZSBhZ2VudHMgYW5kIElWUiB0b2dldGhlciB3b3JraW5nIGluIGdlbmVy YWwgdGltZS4gVGhlIGZ1bGwgcmVjb3JkaW5nIHJlcXVpcmVtZW50IGluIHRoaXMgY2FzZSB3b3Vs ZCBhc2sgdG8gcmVjb3JkIG1lZGlhIGZyb20gZGlmZmVyZW50IFNSQ3MsIGFuZCBtaWdodCByZWNv cmQgdGhlIHNhbWUgQ1MgKHRoZSBjYWxsIHRyYW5zZmVycmVkIGZyb20gSVZSIHRvIGFnZW50LCBh bmQgc2Vzc2lvbiBiYXNlZCBvbiBjdXN0b21lciBzaWRlKS4gSSBub3RpY2UgZHJhZnQtaWV0Zi1z aXByZWMtbWV0YWRhdGEtMTIgc2VjdGlvbiA2LjEwIHRhbGtzIGFib3V0IHRoZSBJRCBmb3IgbXVs dGlwbGUgU1JDcyBjb29yZGluYXRpb24sIGFuZCBkcmFmdC1pZXRmLXNpcHJlYy1wcm90b2NvbC0x MCBzZWN0aW9uIDcuMy4xIHNheXMgaW4gbXVsdGlwbGUgU1JDcyBjYXNlIHRoZSBlbmRwb2ludCBv bmx5IGtub3dzIHRoYXQgdGhlIGNhbGwgaXMgYmVpbmcgcmVjb3JkZWQgdmlhIHJlY29yZGluZyBp bmRpY2F0aW9uLiBTbyBJIHN0aWxsIGRvbid0IGdldCB0aGUgYW5zd2VyIG9yIHdoYXQgbmVlZCB0 byBiZSBhZGRlZCBpZiB3ZSBuZWVkIHRvIGNvb3JkaW5hdGUgdGhlIFNSQ3MgZm9yIElWUiBhbmQg b3RoZXIgVUFzLg0KDQpbaGx1bV0gV2UgYWRkZWQgdGhhdCBzdGF0ZW1lbnQgaW4gdGhlIHByb3Rv Y29sIGRyYWZ0IHRvIGFsbG93IHRoZSBTUkMgdG8gZGVmaW5lIHNvbWUgc29ydCBvZiBjb21tb24g aWRlbnRpZmllciB0byBsaW5rIGEgY2FsbCBzZXNzaW9uIHdoZW4gdGhlIFNSQ3MgYXJlIHNlbmRp bmcgdG8gdGhlIHNhbWUgU1JTLCBhbmQgeW91ciBjb250YWN0IGNlbnRlciBleGFtcGxlIGlzIG9u ZSBvZiB0aGUgdXNlIGNhc2VzLiBJIGRvbid0IGtub3cgaG93IHdlIGNhbiBzdGFuZGFyZGl6ZSBv biB0aGUgY29vcmRpbmF0aW9uIG9mIHRoZSBiZXR3ZWVuIFNSQ3MgYXMgdGhleSBjYW4gYmUgaW5k ZXBlbmRlbnQgc3lzdGVtcyB0byBkaWZmZXJlbnQgU1JTczsgYWxsIHdlIGNhbiBzYXkgaXMgdGhh dCB0aGUgU1JDcyBjYW4gaGF2ZSBhIHdheSB0byBjb29yZGluYXRlIGFtb25nIHRoZW1zZWx2ZXMu DQoNClRoYW5rcywNCk1pY2hhZWwNCg== From pkyzivat@alum.mit.edu Thu Jul 25 09:22: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 8A64021F99BA for ; Thu, 25 Jul 2013 09:22:09 -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_24=0.6, J_CHICKENPOX_33=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 rCvhxllvCU5a for ; Thu, 25 Jul 2013 09:22:04 -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 7821E21F99B0 for ; Thu, 25 Jul 2013 09:22:03 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id 4fg61m0050SCNGk51gN3hn; Thu, 25 Jul 2013 16:22:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 4gN31m00X3ZTu2S3VgN3gU; Thu, 25 Jul 2013 16:22:03 +0000 Message-ID: <51F150AA.3070106@alum.mit.edu> Date: Thu, 25 Jul 2013 12:22:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Henry Lum References: <20130704042814.18074.61653.idtracker@ietfa.amsl.com> <51D9B87A.3080409@alum.mit.edu> <51E71231.7070507@alum.mit.edu> <21794EB0EE82B0458A524942A141542B31375339@szxeml561-mbx.china.huawei.com> 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=1374769323; bh=BKJrAsH37Sg8rBbzVT4dnJCw1JDSFeweFBCA3aUC3+E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j0FJnlRuXtr3K7Ay370e6fwmwAzwXE3M/1e6nYgPaK+aziqmTyRWN2WQE0wW9BE+O SYhfOt6T4BniFetWhA7lEL0ivXTOFO3eZYuTGbtlV7VzeRhvhaGSPpbLz2uXBloXOZ Pu+U6O4aOXXERKXqZ76CwZoqK6gpE+OsCdxXVN+oKGH/URPJhnrIWq1z208fJAelOY A8AkZ9K5hPlQGsznNlctr+60pOyRb/if8rhQJAu7ygRgwn64ZgRHocpeF2tdbjQoFn /w1Xqeto77A80dQoCZWZHWPH/2tc7VLE9uMgIOOEZpYbxr141zvtvaQ92F30Ox1vIa +YBvNTNEenu0w== Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Thu, 25 Jul 2013 16:22:09 -0000 Henry, I'd like to hear more of your thinking regarding using 5552 (or some other standard) for communicating extra information between the IVR and the SRC. Are you imagining something like section 1.1.1 of 5552, where the AS is also acting as an SRC? (That seems hard, since the AS doesn't have access to the media.) ISTM that for our purposes we would consider the AS+VXML server as an IVR. Thanks, Paul On 7/25/13 10:57 AM, Henry Lum wrote: > Hi Michael - please see inline. > > Henry > > -----Original Message----- > From: Yanqiang (Michael) [mailto:michael.yan@huawei.com] > Sent: July-19-13 4:27 AM > To: Henry Lum; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt > > Hi All, > > Please check inline. > >> Recording indication & pause/resume: >> >> This is trivial when the IVR acts as an SRC. But when there is a >> separate SRC, we have defined the UA control over recording to be >> strictly advisory. So the IVR could *request* that recording stop. Then >> it must simply wait to see if it gets a signal back that recording has >> stopped, which may or may not be coming. Is that good enough for the IVR >> application needs? >> >> [hlum] Since request to pause is advisory, the same problem exists for a contact >> center agent needing to manually pause the recording before taking sensitive >> information. The only feedback for the agent to proceed with taking the >> sensitive information is by observing the recording indicator that it is currently >> paused. For an IVR application this can be harder since the protocol does not >> define how long must an SRC provide a change in recording indication, so it will >> have to be up to the IVR to determine how long to wait before proceeding to a >> form or field taking sensitive information. Perhaps when something times out >> or the request is not honoured, the interpreter can throw an event so you can >> get out of the form without taking the information. >> >> How long will it wait? And of course the indication >> that recording has stopped could be a lie. Is that OK? >> >> [hlum] I guess an IVR can't do anything about an SRC lying about the recording >> indication. If the deployment needs the IVR to be absolutely sure about this, >> then the IVR must have to become the SRC itself or at least own the SRC policy. >> > Maybe a better way is to discuss them separately, > 1) IVR is the SIPREC-aware SIP UA, and need a separate SRC to record its session > 2) IVR is the SRC itself with certain media ability? > [hlum] It looks like these solution do diverge a little bit so it may be worthwhile to talk about them separately > > Especially if IVR is #1 case, do we need to make a rule in SIPREC for the mechanism about how SRC receives or answers with IVR(SIP UA)? The 5552 might be one way to do it. If I don't make a mistake, the CSTA standard might also support the recording indication & pause/resume between IVR/agent and the SRC in #1 case (might be a media server or ACD, the feedback mechanism would be some events notification). We can check http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-269.pdf for details on section 26.1.9/26.2.9. > > [hlum] Since we are focused on SIPREC and SIP only, I think 5552 is the only specification that talks about integration with VXML with SIP. I am not sure how to tie that with CSTA interface as we are only focusing on SIP only. > >> >> Metadata: >> >> When the SRC is separate from the IVR, how would the SRC obtain this >> additional information that is to be included in the metadata? >> >> [hlum] That's a good point since there is no such communication for transporting >> additional metadata for SIPREC-aware UA. I wonder if it makes sense to define >> additional communication to tunnel metadata to SRC and send over to SRS. In >> this case perhaps the IVR will have to provide the metadata to SRS through >> other mechanisms. >> > I *think* current draft tried to use 5552 mechanism (maybe not enough) to transport certain information from IVR (also as vxml application) to SRC. There might be a good way or others better as what you said at last. What I more care about is what will be those additional metadata? Will it make the metadata standard become a logging one, after we accept cases and requirements like IVR recording for tuning and conference recording for training. No matter how, I agree SIPREC need to define the format and content of additional metadata for the cases above if we would accept, which could be used for implementing SRC/SRS which follow SIPREC. > > [hlum] Perhaps we should find out what pieces of information we need for the different types of use cases. This can help us specify the metadata format. > >> Coordination of SRCs: >> >> (You don't have a section on this.) If the IVR acts as its own SRC, do >> we care if there is another SRC? If so, do we expect them to coordinate >> so that they use the same identifiers? Some cases where this may be the >> case: >> >> - a call center recording all calls coming in, and then using an >> IVR for part of the call handling. >> >> - a PBX that handles some incoming calls via an IVR and then eventually >> transfers them to a phone hanging off the pbx. >> >> We made the *provision* in the metadata for multiple SRCs to coordinate, >> but left the coordination out of scope. Does adding explict support here >> require putting that back in scope? >> >> [hlum] It's likely we want some form of coordination, since it typical that an >> agent gets involved with IVR applications. If the contact center is served by a >> different SRC and the SRC for the IVR, then it makes sense to provide some form >> of coordination so that the SRS can figure out which portion of a customer call is >> related to IVR and which portion is related to agents. The latest protocol >> revision added the statement that the SRS allows such coordination, but I don't >> see how we can mandate all SRCs coordinate if the SRCs happen to record the >> same CS. >> > For a call center handling with incoming calls would have agents and IVR together working in general time. The full recording requirement in this case would ask to record media from different SRCs, and might record the same CS (the call transferred from IVR to agent, and session based on customer side). I notice draft-ietf-siprec-metadata-12 section 6.10 talks about the ID for multiple SRCs coordination, and draft-ietf-siprec-protocol-10 section 7.3.1 says in multiple SRCs case the endpoint only knows that the call is being recorded via recording indication. So I still don't get the answer or what need to be added if we need to coordinate the SRCs for IVR and other UAs. > > [hlum] We added that statement in the protocol draft to allow the SRC to define some sort of common identifier to link a call session when the SRCs are sending to the same SRS, and your contact center example is one of the use cases. I don't know how we can standardize on the coordination of the between SRCs as they can be independent systems to different SRSs; all we can say is that the SRCs can have a way to coordinate among themselves. > > Thanks, > Michael > From andrew.hutton@siemens-enterprise.com Fri Jul 26 04:19: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 A4B1F21F90A7 for ; Fri, 26 Jul 2013 04:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 G6SRuTGYkWWF for ; Fri, 26 Jul 2013 04:19:19 -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 ABA1921F90FB for ; Fri, 26 Jul 2013 04:19:14 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 323B81EB85A7 for ; Fri, 26 Jul 2013 13:19:09 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.93]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Fri, 26 Jul 2013 13:19:08 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: Berlin Meeting - Agenda, Slides, Scribes etc. Thread-Index: Ac6J8fHJZ1tXhSOTSEC4B6zYHHD/QA== Date: Fri, 26 Jul 2013 11:19:08 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF14B1F481@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_9F33F40F6F2CD847824537F3C4E37DDF14B1F481MCHP04MSXglobal_" MIME-Version: 1.0 Subject: [siprec] Berlin Meeting - Agenda, Slides, Scribes etc. 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, 26 Jul 2013 11:19:23 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF14B1F481MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Really looking forward to seeing you all in Berlin next week. To reduce stress and have an effective meeting it really helps if you can g= et the slides in early. Also please read the drafts under discussion - see http://www.ietf.org/proc= eedings/87/agenda/agenda-87-siprec. Volunteers for scribes and jabber monitoring would also be very much apprec= iated. Regards Andy --_000_9F33F40F6F2CD847824537F3C4E37DDF14B1F481MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Really looking forward to seeing you all in Berlin next week.
 
To reduce stress and have an effective meeting it really helps if you = can get the slides in early.
 
Also please read the drafts under discussion – see http://www.ietf.org/proceedings/87/agenda/agenda-87-siprec.
 
Volunteers for scribes and jabber monitoring would also be very much a= ppreciated.
 
Regards
Andy
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF14B1F481MCHP04MSXglobal_-- From henry.lum@genesyslab.com Fri Jul 26 20:14:04 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 7BC5D11E81BB for ; Fri, 26 Jul 2013 20:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=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 zC9wK--CGkiG for ; Fri, 26 Jul 2013 20:13:59 -0700 (PDT) Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id CED3F11E81C7 for ; Fri, 26 Jul 2013 20:13:57 -0700 (PDT) Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service108-us.mimecast.com; Fri, 26 Jul 2013 23:13:54 -0400 Received: from GENSJZMBX02.msg.int.genesyslab.com ([fe80::64cd:bb44:81d2:5bca]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 20:13:52 -0700 From: Henry Lum To: Paul Kyzivat Thread-Topic: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.txt Thread-Index: AQHOgzf882kUd618MkOY+4A8adA8zZlq7mrAgAE0D4CABRzyAIAE1a0AgAIFZYA= Date: Sat, 27 Jul 2013 03:13:52 +0000 Message-ID: In-Reply-To: <51F150AA.3070106@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: [24.212.200.234] Content-ID: <770661ED93551E489DD30FC1CD04491E@genesyslab.com> MIME-Version: 1.0 X-MC-Unique: 113072623135400202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: "siprec@ietf.org" Subject: Re: [siprec] FW: New Version Notification for draft-lum-siprec-vxml-00.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: Sat, 27 Jul 2013 03:14:04 -0000 I am thinking that the AS can be the SRC as it can be a contact center that executes VXML page for IVR portion. The AS as a SIP B2BUA will have to use another media server to access the media path to record. It's true that we can also see AS+VXML as the IVR itself, or the SIP User Agent is the SRC; in this case the interface to AS as per RFC5552 doesn't really apply here and there are no standard application data to be passed outside of the AS. Regards, Henry On 2013-07-25 12:22 PM, "Paul Kyzivat" wrote: >Henry, > >I'd like to hear more of your thinking regarding using 5552 (or some >other standard) for communicating extra information between the IVR and >the SRC. > >Are you imagining something like section 1.1.1 of 5552, where the AS is >also acting as an SRC? (That seems hard, since the AS doesn't have >access to the media.) > >ISTM that for our purposes we would consider the AS+VXML server as an IVR. > >=09Thanks, >=09Paul > >On 7/25/13 10:57 AM, Henry Lum wrote: >> Hi Michael - please see inline. >> >> Henry >> >> -----Original Message----- >> From: Yanqiang (Michael) [mailto:michael.yan@huawei.com] >> Sent: July-19-13 4:27 AM >> To: Henry Lum; Paul Kyzivat >> Cc: siprec@ietf.org >> Subject: RE: [siprec] FW: New Version Notification for >>draft-lum-siprec-vxml-00.txt >> >> Hi All, >> >> Please check inline. >> >>> Recording indication & pause/resume: >>> >>> This is trivial when the IVR acts as an SRC. But when there is a >>> separate SRC, we have defined the UA control over recording to be >>> strictly advisory. So the IVR could *request* that recording stop. Then >>> it must simply wait to see if it gets a signal back that recording has >>> stopped, which may or may not be coming. Is that good enough for the >>>IVR >>> application needs? >>> >>> [hlum] Since request to pause is advisory, the same problem exists for >>>a contact >>> center agent needing to manually pause the recording before taking >>>sensitive >>> information. The only feedback for the agent to proceed with taking the >>> sensitive information is by observing the recording indicator that it >>>is currently >>> paused. For an IVR application this can be harder since the protocol >>>does not >>> define how long must an SRC provide a change in recording indication, >>>so it will >>> have to be up to the IVR to determine how long to wait before >>>proceeding to a >>> form or field taking sensitive information. Perhaps when something >>>times out >>> or the request is not honoured, the interpreter can throw an event so >>>you can >>> get out of the form without taking the information. >>> >>> How long will it wait? And of course the indication >>> that recording has stopped could be a lie. Is that OK? >>> >>> [hlum] I guess an IVR can't do anything about an SRC lying about the >>>recording >>> indication. If the deployment needs the IVR to be absolutely sure >>>about this, >>> then the IVR must have to become the SRC itself or at least own the >>>SRC policy. >>> >> Maybe a better way is to discuss them separately, >> 1) IVR is the SIPREC-aware SIP UA, and need a separate SRC to record >>its session >> 2) IVR is the SRC itself with certain media ability? >> [hlum] It looks like these solution do diverge a little bit so it may >>be worthwhile to talk about them separately >> >> Especially if IVR is #1 case, do we need to make a rule in SIPREC for >>the mechanism about how SRC receives or answers with IVR(SIP UA)? The >>5552 might be one way to do it. If I don't make a mistake, the CSTA >>standard might also support the recording indication & pause/resume >>between IVR/agent and the SRC in #1 case (might be a media server or >>ACD, the feedback mechanism would be some events notification). We can >>check=20 >>http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-269.pdf >> for details on section 26.1.9/26.2.9. >> >> [hlum] Since we are focused on SIPREC and SIP only, I think 5552 is the >>only specification that talks about integration with VXML with SIP. I am >>not sure how to tie that with CSTA interface as we are only focusing on >>SIP only. >> >>> >>> Metadata: >>> >>> When the SRC is separate from the IVR, how would the SRC obtain this >>> additional information that is to be included in the metadata? >>> >>> [hlum] That's a good point since there is no such communication for >>>transporting >>> additional metadata for SIPREC-aware UA. I wonder if it makes sense to >>>define >>> additional communication to tunnel metadata to SRC and send over to >>>SRS. In >>> this case perhaps the IVR will have to provide the metadata to SRS >>>through >>> other mechanisms. >>> >> I *think* current draft tried to use 5552 mechanism (maybe not enough) >>to transport certain information from IVR (also as vxml application) to >>SRC. There might be a good way or others better as what you said at >>last. What I more care about is what will be those additional metadata? >>Will it make the metadata standard become a logging one, after we accept >>cases and requirements like IVR recording for tuning and conference >>recording for training. No matter how, I agree SIPREC need to define the >>format and content of additional metadata for the cases above if we >>would accept, which could be used for implementing SRC/SRS which follow >>SIPREC. >> >> [hlum] Perhaps we should find out what pieces of information we need >>for the different types of use cases. This can help us specify the >>metadata format. >> >>> Coordination of SRCs: >>> >>> (You don't have a section on this.) If the IVR acts as its own SRC, do >>> we care if there is another SRC? If so, do we expect them to coordinate >>> so that they use the same identifiers? Some cases where this may be the >>> case: >>> >>> - a call center recording all calls coming in, and then using an >>> IVR for part of the call handling. >>> >>> - a PBX that handles some incoming calls via an IVR and then eventually >>> transfers them to a phone hanging off the pbx. >>> >>> We made the *provision* in the metadata for multiple SRCs to >>>coordinate, >>> but left the coordination out of scope. Does adding explict support >>>here >>> require putting that back in scope? >>> >>> [hlum] It's likely we want some form of coordination, since it typical >>>that an >>> agent gets involved with IVR applications. If the contact center is >>>served by a >>> different SRC and the SRC for the IVR, then it makes sense to provide >>>some form >>> of coordination so that the SRS can figure out which portion of a >>>customer call is >>> related to IVR and which portion is related to agents. The latest >>>protocol >>> revision added the statement that the SRS allows such coordination, >>>but I don't >>> see how we can mandate all SRCs coordinate if the SRCs happen to >>>record the >>> same CS. >>> >> For a call center handling with incoming calls would have agents and >>IVR together working in general time. The full recording requirement in >>this case would ask to record media from different SRCs, and might >>record the same CS (the call transferred from IVR to agent, and session >>based on customer side). I notice draft-ietf-siprec-metadata-12 section >>6.10 talks about the ID for multiple SRCs coordination, and >>draft-ietf-siprec-protocol-10 section 7.3.1 says in multiple SRCs case >>the endpoint only knows that the call is being recorded via recording >>indication. So I still don't get the answer or what need to be added if >>we need to coordinate the SRCs for IVR and other UAs. >> >> [hlum] We added that statement in the protocol draft to allow the SRC >>to define some sort of common identifier to link a call session when the >>SRCs are sending to the same SRS, and your contact center example is one >>of the use cases. I don't know how we can standardize on the >>coordination of the between SRCs as they can be independent systems to >>different SRSs; all we can say is that the SRCs can have a way to >>coordinate among themselves. >> >> Thanks, >> Michael >> > From mary.ietf.barnes@gmail.com Tue Jul 30 07:25:38 2013 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE221E80E4 for ; Tue, 30 Jul 2013 07:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jb6SLnLGEss3 for ; Tue, 30 Jul 2013 07:25:33 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D89521F99C7 for ; Tue, 30 Jul 2013 07:25:08 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cr7so2401983qab.1 for ; Tue, 30 Jul 2013 07:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cQWsJnoH4Ri5uIu0bFAzhIuYzO+7mF3ziGBiOeztOTs=; b=l8jXSZkzezxAM4MZ2uo4hexdP4Ldc6nV+BsH+rurxvD2j77s9YMgbX+zVdWUMvgkOt UyS80pJ+Eeeatt1AhWRj3zx+UW9gaImnsdOF/lvL4MJM5FgmlMoTYJ6wbXTwcFKFRN05 L7yVQyhnSzpmfp2NWikIDolYx2TVn/XBOiv0dpgB6ag3m22hh2De2mPkC/TmT8j4zyPw mBO0kOzxjPL4qIkh7T+QPF5YPi/qWN3pR76mhHHQjP1kaVOyJ4Yb887izOdmqUDphO6y MC3n4wJvyUhl5VLynpgJeRgxGCoB9CpuUIFJpT3cpdBhzeO7ycxEd/KxZNuSkzfBAu6q 0spg== MIME-Version: 1.0 X-Received: by 10.224.161.76 with SMTP id q12mr61302601qax.3.1375194307637; Tue, 30 Jul 2013 07:25:07 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Tue, 30 Jul 2013 07:25:07 -0700 (PDT) Date: Tue, 30 Jul 2013 09:25:07 -0500 Message-ID: From: Mary Barnes To: "siprec@ietf.org" Content-Type: multipart/alternative; boundary=089e0149528e3436b304e2bb6033 Subject: [siprec] Reviews of draft-ietf-siprec-metadata-12 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, 30 Jul 2013 14:25:38 -0000 --089e0149528e3436b304e2bb6033 Content-Type: text/plain; charset=ISO-8859-1 Following up on what review is still required for this document, it seems to me that there have been past reviews by folks that know XML well. So, I don't think that should be a worry - it's not clear to me why Paul is concerned about that aspect. As was suggested, the feedback you need is from folks that have implemented. Of course, that's always a very good thing, but I don't know that you need to hold-up this document for that. However, it's probably prudent to wait until the WG feels the call flows are in good shape. One suggestion I have is to include at least one reference to a description of UML notation. Personally, I don't find that it adds any clarity to the document, in particular since it's the text and XML schema that's normative, but I know you all made that decision a long while back. I have a few specific comments: - Section 9. -- The last sentence says "the following sections" but there's only one section. You could probably merge. -- I think this section would be much more useful if it referred to the security provided by the protocol document since that seems to be all you're really talking about. I would think that it would be important to identify information in the metadata that is sensitive and might be subject to privacy considerations. Given the discussion when this WG was chartered, I would think this would be important. Also, this is discussed in the requirements document as well. I can see that you discuss the metadata in the protocol document. I would think this should at least be discussed in more detail in the metadata document. - IANA Registrations: -- the reference to the XML schema in the IANA section is wrong (it says section 6 - it should be 8). While one might think the RFC editor would fix, I've seen a number of docs where this has been missed. Mary. --089e0149528e3436b304e2bb6033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Following up on what review is still required for this doc= ument, it seems to me that there have been past reviews by folks that know = XML well. So, I don't think that should be a worry - it's not clear= to me why Paul is concerned about that aspect. =A0 As was suggested, the f= eedback you need is from folks that have implemented. =A0Of course, that= 9;s always a very good thing, but I don't know that you need to hold-up= this document for that. =A0However, it's probably prudent to wait unti= l the WG feels the call flows are in good shape.

One suggestion I have is to include at least one reference t= o a description of UML notation. Personally, I don't find that it adds = any clarity to the document, in particular since it's the text and XML = schema that's normative, but I know you all made that decision a long w= hile back.=A0

I have a few specific comments:=A0
- Section = 9.=A0
-- The last sentence says "the following sections"= ; but there's only one section. =A0You could probably merge.=A0
-- I think this section would be much more useful if it referred to the = security provided by the protocol document since that seems to be all you&#= 39;re really talking about. =A0 I would think that it would be important to= identify information in the metadata that is sensitive and might be subjec= t to privacy considerations. =A0Given the discussion when this WG was chart= ered, I would think this would be important. Also, this is discussed in the= requirements document as well. =A0I can see that you discuss the metadata = in the protocol document. =A0I would think this should at least be discusse= d in more detail in the metadata document.=A0

- IANA Registrations: =A0
-- =A0the reference= to the XML schema in the IANA section is wrong (it says section 6 - it sho= uld be 8). =A0While one might think the RFC editor would fix, I've seen= a number of docs where this has been missed.=A0



Mary.=A0
--089e0149528e3436b304e2bb6033-- From rmohanr@cisco.com Tue Jul 30 21:40:42 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 3F3FC21E8055 for ; Tue, 30 Jul 2013 21:40:42 -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 0jY1EfqYhw0c for ; Tue, 30 Jul 2013 21:40:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD511E80E4 for ; Tue, 30 Jul 2013 21:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3105; q=dns/txt; s=iport; t=1375245636; x=1376455236; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=iBbn4+3TLgQiv926qakHR+3XxT8/FodHe4oBgdsusRs=; b=SNjz4fVXtohvrf20DPBqtvFi5CrYjmy6MH0B14RSbR89tp2KR+/hTT3A s8EfxylPxVednmJdtHiPecx6P51NwvO0wEAjsfJhgLQb6wmWwbuudNt4n Yc/sKompLroq395wu/O3Mw080xcoFcvA9FAiHZvgN4x05rWC//67GQEmc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAPeU+FGtJXG9/2dsb2JhbABRCoMGgQW+G4EZFnSCJAEBAQMBOkQNAQgiFDERJQIEARIIh3YDCQawBw2IXo0NgS+BETiDGHEDlXaOD4UmgxSCKg X-IronPort-AV: E=Sophos;i="4.89,784,1367971200"; d="scan'208";a="241590173" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 04:40:35 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6V4eYLJ029671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 04:40:34 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.123]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 23:40:34 -0500 From: "Ram Mohan R (rmohanr)" To: Mary Barnes , "siprec@ietf.org" Thread-Topic: [siprec] Reviews of draft-ietf-siprec-metadata-12 Thread-Index: AQHOjagY2vBHm4Tzo0CI34fm/Jn9bA== Date: Wed, 31 Jul 2013 04:40:34 +0000 Message-ID: In-Reply-To: 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: [72.163.212.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C627561D77EC0469119C720918DCEF6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Reviews of draft-ietf-siprec-metadata-12 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, 31 Jul 2013 04:40:42 -0000 Inline for some of my comments- > On 30/07/13 7:55 PM, "Mary Barnes" wrote: >Following up on what review is still required for this document, it seems >to me that there have been past reviews by folks that know XML well. So, >I don't think that should be a worry - it's not clear to me why Paul is >concerned about that aspect. On the metadata draft (draft-ietf-siprec-metadata), I feel we have had enough reviews . I believe it covers most of the discussed Requirements/call flows that we have discussed till now. I do see a set of new requirements that Henry an Paul have brought in. Excluding those, metadata IMO has taken care of most of the current requirements. I do agree it will be nice to get feedback from some one who have implemented. We have been asking the same from almost 1+ year but have not got much response yet. I wonder if we would need hold-up the document for too long waiting for implementation feedback. On the call flow draft (draft-ietf-siprec-callflow) I agree there is some more reviews needed. > As was suggested, the feedback you need is from folks that have >implemented. Of course, that's always a very good thing, but I don't >know that you need to hold-up this document for that. However, it's >probably prudent to wait until the WG feels the call > flows are in good shape. > > >One suggestion I have is to include at least one reference to a >description of UML notation. Sure. I will add a reference to the same in the next revision > Personally, I don't find that it adds any clarity to the document, in >particular since it's the text and XML schema that's normative, but I >know you all made that > decision a long while back. > > >I have a few specific comments: >- Section 9.=20 >-- The last sentence says "the following sections" but there's only one >section. You could probably merge. I will correct this text >=20 >-- I think this section would be much more useful if it referred to the >security provided by the protocol document since that seems to be all >you're really talking about. I would think that it would be important >to identify information in the metadata > that is sensitive and might be subject to privacy considerations. Given >the discussion when this WG was chartered, I would think this would be >important. Also, this is discussed in the requirements document as well. >I can see that you discuss the metadata > in the protocol document. I would think this should at least be >discussed in more detail in the metadata document. I will try to come up with some text for security considerations for the metadata portion and send to the list soon. >=20 > > >- IANA Registrations: >-- the reference to the XML schema in the IANA section is wrong (it says >section 6 - it should be 8). While one might think the RFC editor would >fix, I've seen a number of docs where this has been missed. Thanks for pointing this out. Will fix it in the next revision Regards, Ram >=20 > > > > > >Mary.=20 > > > From partha@parthasarathi.co.in Wed Jul 31 11:51:04 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 E2A7C21F94FD for ; Wed, 31 Jul 2013 11:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 ZvEtrkDWLdjv for ; Wed, 31 Jul 2013 11:50:59 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id 385E421F8F3C for ; Wed, 31 Jul 2013 11:50:59 -0700 (PDT) Received: from userPC (unknown [122.166.142.27]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 4F5C86381DB; Wed, 31 Jul 2013 18:50:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375296658; bh=ZgdpdZcrO2DMNXiORdNGT6eEqZvzGC120p3226UvjMQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NPsesAkrj2dlqu6Ft7fZxkGAh2dClMUKznkTO4KVwqTmgVj/F9YuTcTpkL1PiyMQO IVj9PV3aviAEMNQxB5M+zwQ81Vx0FmlMgk3VdGK0t5s+aoCUGFZ4n3gQ6WWiKOhyKQ eSPaCY9dfV4oW65fVvbIJpJXNrWk0wP++S0D26xw= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , "'Mary Barnes'" , References: In-Reply-To: Date: Thu, 1 Aug 2013 00:20:45 +0530 Message-ID: <007501ce8e1e$e2541f50$a6fc5df0$@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: AQHOjagY2vBHm4Tzo0CI34fm/Jn9bJl/GvWw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0206.51F95C92.0078, 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.142 Subject: Re: [siprec] Reviews of draft-ietf-siprec-metadata-12 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, 31 Jul 2013 18:51:05 -0000 Hi all, I'm hearing the same argument of metadata implementers review for more than 1 year without having any major review comments. By Google search (http://www.linkedin.com/groups/Who-is-using-SIPREC-4263898.S.176535181), I noticed that the couple SIPREC products from different vendors namely ACME, NICE, Broadsoft, HP, OrecX. In case somebody has serious technical issues in implementing the metadata draft, it would have heard in SIPREC WG by now. I have trouble in agree to the statement that we need to hear from implementers for moving forward. Also, I know of the companies which will implement SIPREC once it becomes RFC to avoid double SIPREC implementation. IMO, the moving document to WGLC will bring the left out review comments. SIPREC example draft was written 1 years back after the comment that metadata draft was not very clear for implementation. Here, it is good to have the original SIPREC logs as an example but I haven't heard any volunteer till now. In fact, the draft has received the comments from NICE (existing SIPREC implementers) and it was incorporated long back. Thanks Partha > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ram Mohan R (rmohanr) > Sent: Wednesday, July 31, 2013 10:11 AM > To: Mary Barnes; siprec@ietf.org > Subject: Re: [siprec] Reviews of draft-ietf-siprec-metadata-12 > > Inline for some of my comments- > > > On 30/07/13 7:55 PM, "Mary Barnes" > wrote: > > >Following up on what review is still required for this document, it > seems > >to me that there have been past reviews by folks that know XML well. > So, > >I don't think that should be a worry - it's not clear to me why Paul > is > >concerned about that aspect. > > On the metadata draft (draft-ietf-siprec-metadata), I feel we have had > enough reviews . I believe it covers most of the discussed > Requirements/call flows that we have discussed till now. I do see a set > of > new requirements that Henry an Paul have brought in. Excluding those, > metadata IMO has taken care of most of the current requirements. > > I do agree it will be nice to get feedback from some one who have > implemented. We have been asking the same from almost 1+ year but have > not > got much response yet. I wonder if we would need hold-up the document > for > too long waiting for implementation feedback. > > On the call flow draft (draft-ietf-siprec-callflow) I agree there is > some > more reviews needed. > > > > As was suggested, the feedback you need is from folks that have > >implemented. Of course, that's always a very good thing, but I don't > >know that you need to hold-up this document for that. However, it's > >probably prudent to wait until the WG feels the call > > flows are in good shape. > > > > > >One suggestion I have is to include at least one reference to a > >description of UML notation. > > Sure. I will add a reference to the same in the next revision > > > > Personally, I don't find that it adds any clarity to the document, in > >particular since it's the text and XML schema that's normative, but I > >know you all made that > > decision a long while back. > > > > > >I have a few specific comments: > >- Section 9. > >-- The last sentence says "the following sections" but there's only > one > >section. You could probably merge. > > I will correct this text > > > > >-- I think this section would be much more useful if it referred to > the > >security provided by the protocol document since that seems to be all > >you're really talking about. I would think that it would be > important > >to identify information in the metadata > > that is sensitive and might be subject to privacy considerations. > Given > >the discussion when this WG was chartered, I would think this would be > >important. Also, this is discussed in the requirements document as > well. > >I can see that you discuss the metadata > > in the protocol document. I would think this should at least be > >discussed in more detail in the metadata document. > > I will try to come up with some text for security considerations for > the > metadata portion and send to the list soon. > > > > > > > > >- IANA Registrations: > >-- the reference to the XML schema in the IANA section is wrong (it > says > >section 6 - it should be 8). While one might think the RFC editor > would > >fix, I've seen a number of docs where this has been missed. > > Thanks for pointing this out. Will fix it in the next revision > > Regards, > Ram > > > > > > > > > > > > > > >Mary. > > > > > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec