From exim@www1.ietf.org Tue Jul 1 04:12:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02461 for ; Tue, 1 Jul 2003 04:12:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h618C6p25292 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 04:12:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGF8-0006ZC-2f; Tue, 01 Jul 2003 04:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XGEB-0006Xf-Ny for avt@optimus.ietf.org; Tue, 01 Jul 2003 04:11:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02423 for ; Tue, 1 Jul 2003 04:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XGE7-0000qq-00 for avt@ietf.org; Tue, 01 Jul 2003 04:10:59 -0400 Received: from bang2.cs.ucl.ac.uk ([128.16.64.72] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19XGDw-0000qA-00 for avt@ietf.org; Tue, 01 Jul 2003 04:10:48 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6187FVA007245; Tue, 1 Jul 2003 04:07:16 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Tue, 1 Jul 2003 09:07:15 +0100 From: Colin Perkins To: avt@ietf.org Cc: casner@acm.org, magnus.westerlund@ericsson.com Subject: Re: [AVT] Meeting in Vienna Message-Id: <20030701090715.096032f1.csp@csperkins.org> In-Reply-To: <20030618161812.026ce541.csp@csperkins.org> References: <20030618161812.026ce541.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A reminder that the deadline for agenda slot requests is today. If you need an agenda slot in AVT, and have not already contacted the chairs, please do so shortly. Colin --> Colin Perkins writes: > Folks, > > The AVT working group is scheduled for one slot at the 57th IETF meeting > in Vienna. On the tentative agenda, this is from 9:00 to 11:30 on Monday > 14th July. This date is subject to change - DO NOT USE IT TO PLAN > TRAVEL. > > Those wanting agenda time at the meeting should contact the working group > chairs by 1st July. Submitting a draft does not automatically provide > agenda time. > > You are reminded that the cut-off date for -00 Internet Draft submissions > is Monday, 23rd June at 9:00am EDT (GMT -04:00). Unless you have prior > approval from the chairs, -00 submissions should have filenames with the > format draft-yourname-avt-...-00.txt. Be advised that updates to -00 > drafts received after 23rd June will not be accepted. > > All other Internet-Draft submissions must be made by Monday, 30th June at > 9:00am EDT. > > Drafts which are submitted late and do not make the cutoff date will not > be discussed at the meeting. > > -- > Colin Perkins > csp@csperkins.org > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 06:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05684 for ; Tue, 1 Jul 2003 06:47:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61Al3J18540 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 06:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XIf7-0004mz-Gu; Tue, 01 Jul 2003 06:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wxpd-0004RJ-1b for avt@optimus.ietf.org; Mon, 30 Jun 2003 08:32:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17761; Mon, 30 Jun 2003 08:31:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wxp6-00070M-00; Mon, 30 Jun 2003 08:31:56 -0400 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 19Wxot-0006xq-00; Mon, 30 Jun 2003 08:31:43 -0400 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) id 19Wxo3-0007Yq-Ld; Mon, 30 Jun 2003 14:30:51 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Mon, 30 Jun 2003 14:30:49 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) id 19Wxo0-0004tC-KR; Mon, 30 Jun 2003 14:30:48 +0200 Received: from ft.ee.tu-berlin.de (ftsu34.tkn.TU-Berlin.DE [130.149.49.204]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h5UC5IB20801; Mon, 30 Jun 2003 14:05:18 +0200 Message-ID: <3F00297A.2070304@ft.ee.tu-berlin.de> Date: Mon, 30 Jun 2003 14:13:46 +0200 From: Heike Klemz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: klemz Content-Type: multipart/mixed; boundary="------------060701000109040508000805" X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Mon, 30 Jun 2003 14:30:48 +0200 Subject: [AVT] CfP: Frist European Workshop on Wireless Sensor Networks Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------060701000109040508000805 Content-Type: multipart/alternative; boundary="------------020902060703010007080804" --------------020902060703010007080804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > Dear Colleague, > > I would like to draw your attention to the " Frist European Workshop > on Wireless Sensor Networks" Berlin, January 2004 (see Attachement). > The submission deadline for EWSN has been extended to July 14th, 18:00 > middle European daylight savings time (corresponding to noon Eastern > Standard Time or 9 am Pacific time). Details of the Call, see > http://www.ewsn.org > > Best regards > Adam Wolisz > --------------020902060703010007080804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Dear Colleague,

I would like to draw your attention to the " Frist European Workshop
on Wireless Sensor Networks" Berlin, January 2004 (see Attachement).
The submission deadline for EWSN has been extended to July 14th, 18:00 middle European daylight savings time (corresponding to noon Eastern Standard Time or 9 am Pacific time). Details of the Call, see   http://www.ewsn.org

Best regards
Adam Wolisz

--------------020902060703010007080804-- --------------060701000109040508000805 Content-Type: application/pdf; name="1_EWSN-Call%20(2).pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="1_EWSN-Call%20(2).pdf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjEwMyAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gMTA5IA0v SCBbIDIwODggMjczIF0gDS9MIDEyMTIwNyANL0UgOTQwMjYgDS9OIDEgDS9UIDExOTAyOCAN Pj4gDWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4cmVmDTEwMyA1MCANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAxMzUx IDAwMDAwIG4NCjAwMDAwMDE3MDUgMDAwMDAgbg0KMDAwMDAwMTc0NCAwMDAwMCBuDQowMDAw MDAxODA1IDAwMDAwIG4NCjAwMDAwMDE5NTQgMDAwMDAgbg0KMDAwMDAwMjM2MSAwMDAwMCBu DQowMDAwMDAyODg2IDAwMDAwIG4NCjAwMDAwMDI5MTcgMDAwMDAgbg0KMDAwMDAwMzA3MSAw MDAwMCBuDQowMDAwMDAzMTY4IDAwMDAwIG4NCjAwMDAwMDMyNjUgMDAwMDAgbg0KMDAwMDAw MzM2MiAwMDAwMCBuDQowMDAwMDAzNDU5IDAwMDAwIG4NCjAwMDAwMDM4OTYgMDAwMDAgbg0K MDAwMDAwNDY3NCAwMDAwMCBuDQowMDAwMDA0ODk2IDAwMDAwIG4NCjAwMDAwMDUxMTIgMDAw MDAgbg0KMDAwMDAwNTU0OSAwMDAwMCBuDQowMDAwMDA1Nzc5IDAwMDAwIG4NCjAwMDAwMDU4 MDkgMDAwMDAgbg0KMDAwMDAwNTg2MSAwMDAwMCBuDQowMDAwMDA1OTAyIDAwMDAwIG4NCjAw MDAwMDU5MjUgMDAwMDAgbg0KMDAwMDAwODA4NyAwMDAwMCBuDQowMDAwMDA4MTEwIDAwMDAw IG4NCjAwMDAwMTAxNDggMDAwMDAgbg0KMDAwMDAxMDE3MSAwMDAwMCBuDQowMDAwMDEyMDA2 IDAwMDAwIG4NCjAwMDAwMTIwMjkgMDAwMDAgbg0KMDAwMDAxMzkwMCAwMDAwMCBuDQowMDAw MDEzOTIzIDAwMDAwIG4NCjAwMDAwMTU3ODAgMDAwMDAgbg0KMDAwMDAxNTgwMyAwMDAwMCBu DQowMDAwMDE3ODY1IDAwMDAwIG4NCjAwMDAwMTc4ODggMDAwMDAgbg0KMDAwMDAxOTc0NyAw MDAwMCBuDQowMDAwMDE5NzcwIDAwMDAwIG4NCjAwMDAwMjI0NDggMDAwMDAgbg0KMDAwMDAz NTE4MyAwMDAwMCBuDQowMDAwMDM1MjY3IDAwMDAwIG4NCjAwMDAwNTMzMjEgMDAwMDAgbg0K MDAwMDA4NTEwMyAwMDAwMCBuDQowMDAwMDg1NTM0IDAwMDAwIG4NCjAwMDAwODc0NTAgMDAw MDAgbg0KMDAwMDA4NzUyOSAwMDAwMCBuDQowMDAwMDg3NzM2IDAwMDAwIG4NCjAwMDAwOTA4 MDUgMDAwMDAgbg0KMDAwMDAwMjA4OCAwMDAwMCBuDQowMDAwMDAyMzM5IDAwMDAwIG4NCnRy YWlsZXINPDwNL1NpemUgMTUzDS9JbmZvIDEwMCAwIFIgDS9Sb290IDEwNCAwIFIgDS9QcmV2 IDExOTAxNyANL0lEWzw1NGU5NTNmYWExYjBhMTEwNTIwOWFjN2U5YWFkZjBjOT48NjZhMzQ1 NDQ1Y2Y4OGU0YzRkYjU5MzJiYWY4NWM1ZWM+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAg DTEwNCAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAxMDIgMCBSIA0vTWV0YWRh dGEgMTAxIDAgUiANL1RocmVhZHMgMTA1IDAgUiANL09wZW5BY3Rpb24gWyAxMDkgMCBSIC9Y WVogbnVsbCBudWxsIG51bGwgXSANL1BhZ2VNb2RlIC9Vc2VOb25lIA0vUGFnZUxhYmVscyA5 OSAwIFIgDS9TdHJ1Y3RUcmVlUm9vdCAxMDggMCBSIA0vUGllY2VJbmZvIDw8IC9NYXJrZWRQ REYgPDwgL0xhc3RNb2RpZmllZCAoRDoyMDAzMDQyNzEzMzIzNyk+PiA+PiANL0xhc3RNb2Rp ZmllZCAoRDoyMDAzMDQyNzEzMzIzNykNL01hcmtJbmZvIDw8IC9NYXJrZWQgdHJ1ZSAvTGV0 dGVyc3BhY2VGbGFncyAwID4+IA0+PiANZW5kb2JqDTEwNSAwIG9iag1bIA0xMDYgMCBSIDEw NyAwIFIgDV0NZW5kb2JqDTEwNiAwIG9iag08PCANL0kgPDwgL1RpdGxlIChTY29wZSk+PiAN L0YgMTEyIDAgUiANPj4gDWVuZG9iag0xMDcgMCBvYmoNPDwgDS9JIDw8IC9UaXRsZSAoU3Vi bWlzc2lvbnMgc2hvdWxkIG5vdCBleGNlZWQgMTYgcGFnZXM7IGZvcm1hdHRpbmcgZ3VpZGVs aW5lcyBhcmUgZGVzY3JpXA1iZWQgb24gdGhlIHdlYnBhZ2UuKT4+IA0vRiAxMTUgMCBSIA0+ PiANZW5kb2JqDTEwOCAwIG9iag08PCANL1R5cGUgL1N0cnVjdFRyZWVSb290IA0vUm9sZU1h cCAxIDAgUiANL0NsYXNzTWFwIDQgMCBSIA0vSyA4MSAwIFIgDS9QYXJlbnRUcmVlIDkxIDAg UiANL1BhcmVudFRyZWVOZXh0S2V5IDIgDT4+IA1lbmRvYmoNMTUxIDAgb2JqDTw8IC9TIDM2 IC9MIDE0NSAvQyAxNjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNTIgMCBSID4+ IA1zdHJlYW0NCkiJYmBgMGBg4NBgYGBgTPnIgA1wQGkBINaCYgYGcQZ+5jcMCiwSLAs4HYQa VBnnsT5jlmHjkHwg+YDxAF+DEAODYg4DQ+0HBsajDAzsFgwMMisYGOoLGBhPMzBwxScHMHwz rj/wwZjxpoMMww7xM7oVcAuTGBhPbgDSTEDsDXIYA2OuJJBOZGCImQ4WZ2tRAAgwALozHG4N ZW5kc3RyZWFtDWVuZG9iag0xNTIgMCBvYmoNMTUxIA1lbmRvYmoNMTA5IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAxMDIgMCBSIA0vUmVzb3VyY2VzIDw8IC9Db2xvclNwYWNl IDw8IC9DUzMgMTI0IDAgUiAvQ1M0IDEyMiAwIFIgL0NTNSAxMjMgMCBSID4+IC9FeHRHU3Rh dGUgPDwgL0dTMiAxNDcgMCBSIC9HUzMgMTQ4IDAgUiA+PiANL0ZvbnQgPDwgL1RUMyAxMjAg MCBSIC9UVDQgMTE2IDAgUiAvVFQ1IDExNyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMiAxNDkg MCBSIC9JbTMgMTUwIDAgUiA+PiANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0lt YWdlSSBdID4+IA0vQ29udGVudHMgWyAxMjYgMCBSIDEyOCAwIFIgMTMwIDAgUiAxMzIgMCBS IDEzNCAwIFIgMTM2IDAgUiAxMzggMCBSIDE0NiAwIFIgXSANL0IgWyAxMTIgMCBSIDExNCAw IFIgMTEzIDAgUiAxMTUgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vU3RydWN0UGFyZW50cyAwIA0vQW5u b3RzIDExMCAwIFIgDT4+IA1lbmRvYmoNMTEwIDAgb2JqDVsgDTExMSAwIFIgDV0NZW5kb2Jq DTExMSAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA1 MjIgMTE3LjQ3NjIgNTQ0Ljc4Njk5IDEyOS4zMDIwMiBdIA0vQm9yZGVyIFsgMCAwIDAgXSAN L0ggL0kgDS9BIDE0MiAwIFIgDS9TdHJ1Y3RQYXJlbnQgMSANPj4gDWVuZG9iag0xMTIgMCBv YmoNPDwgDS9UIDEwNiAwIFIgDS9QIDEwOSAwIFIgDS9SIFsgMzU5IDQ3NCA1OTUgNjc1IF0g DS9WIDExMyAwIFIgDS9OIDExNCAwIFIgDT4+IA1lbmRvYmoNMTEzIDAgb2JqDTw8IA0vUCAx MDkgMCBSIA0vUiBbIDM3OSAxNjIgNTk3IDQ1OSBdIA0vViAxMTQgMCBSIA0vTiAxMTIgMCBS IA0vVCAxMDYgMCBSIA0+PiANZW5kb2JqDTExNCAwIG9iag08PCANL1AgMTA5IDAgUiANL1Ig WyAxNjMgMTc1IDM3MCA0NTkgXSANL1YgMTEyIDAgUiANL04gMTEzIDAgUiANL1QgMTA2IDAg UiANPj4gDWVuZG9iag0xMTUgMCBvYmoNPDwgDS9UIDEwNyAwIFIgDS9QIDEwOSAwIFIgDS9S IFsgNDYwIDExNiA1OTEgMTc0IF0gDS9WIDExNSAwIFIgDS9OIDExNSAwIFIgDT4+IA1lbmRv YmoNMTE2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmly c3RDaGFyIDMyIA0vTGFzdENoYXIgMTIyIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAyNTAgMCAyNTAgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgDTAgMCAw IDAgMCAwIDAgNzIyIDcyMiAwIDYxMSAwIDAgMzg5IDAgMCAwIDAgMCA3NzggNjExIDAgMCA1 NTYgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgNDQ0IDAgNDQ0IDMzMyA1MDAg NTU2IDI3OCAwIDAgMjc4IA04MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyAwIDUwMCA3 MjIgMCAwIDQ0NCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9I TkhNQ0krVGltZXNOZXdSb21hbixCb2xkIA0vRm9udERlc2NyaXB0b3IgMTE4IDAgUiANPj4g DWVuZG9iag0xMTcgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUg DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTIgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAw IDc3OCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgMCAN NTAwIDUwMCAwIDAgMCAyNzggMjc4IDAgMCAwIDQ0NCAwIDcyMiA2NjcgNjY3IDcyMiA2MTEg NTU2IDcyMiA3MjIgDTMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYgMCA2NjcgNTU2 IDYxMSA3MjIgNzIyIDk0NCAwIDcyMiANNjExIDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUw MCA0NDQgMzMzIDUwMCA1MDAgMjc4IDAgNTAwIDI3OCA3NzggDTUwMCA1MDAgNTAwIDUwMCAz MzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCAwIDAgMCAwIDAgMCANMCAwIDAg NDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNDQ0IDAgMCAwIDAgMCAwIDAg MCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIA1dIA0vRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9ITkhNSUUrVGltZXNOZXdSb21hbiANL0ZvbnRE ZXNjcmlwdG9yIDEyMSAwIFIgDT4+IA1lbmRvYmoNMTE4IDAgb2JqDTw8IA0vVHlwZSAvRm9u dERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYg DS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTU1OCAtMzA3IDIwMzQgMTAyNiBdIA0vRm9udE5h bWUgL0hOSE1DSStUaW1lc05ld1JvbWFuLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYg MTYwIA0vRm9udEZpbGUyIDE0MyAwIFIgDT4+IA1lbmRvYmoNMTE5IDAgb2JqDTw8IA0vVHlw ZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODk1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50 IC0yMDMgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTUxIC0yMDMgMTA3NCA4OTYgXSANL0Zv bnROYW1lIC9ITkhLSUIrQmVybGluU2Fuc0ZCLVJlZyANL0l0YWxpY0FuZ2xlIDAgDS9TdGVt ViAwIA0vRm9udEZpbGUyIDE0MSAwIFIgDT4+IA1lbmRvYmoNMTIwIDAgb2JqDTw8IA0vVHlw ZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg MTIxIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAgMzUxIDM1MSAwIDAgMjE1IDM4NiAy MTUgMCA1OTcgMjgwIDQ4NSAwIDUwMCAwIDAgDTAgMCA1MTMgMCAwIDAgMCAwIDAgMCAwIDYx MSAwIDAgNTM4IDAgMCAwIDAgMjY3IDAgMCAwIDcxOCAwIDAgMCANMCA0NjcgMCAwIDAgODky IDAgMCAwIDAgMCAwIDAgMCAwIDU1NCAwIDAgMCA0ODIgMCAwIDUyMCAyMjAgMCA1NDcgDTIy MCAwIDUyMyA1MTEgNTY0IDAgMzMzIDI5OSAzNDIgNTUyIDAgNzI5IDAgNDc2IF0gDS9FbmNv ZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0hOSEtJQitCZXJsaW5TYW5zRkIt UmVnIA0vRm9udERlc2NyaXB0b3IgMTE5IDAgUiANPj4gDWVuZG9iag0xMjEgMCBvYmoNPDwg DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgNjU2IA0v RGVzY2VudCAtMjE2IA0vRmxhZ3MgMzQgDS9Gb250QkJveCBbIC01NjggLTMwNyAyMDI4IDEw MDcgXSANL0ZvbnROYW1lIC9ITkhNSUUrVGltZXNOZXdSb21hbiANL0l0YWxpY0FuZ2xlIDAg DS9TdGVtViA5NCANL1hIZWlnaHQgMCANL0ZvbnRGaWxlMiAxNDQgMCBSIA0+PiANZW5kb2Jq DTEyMiAwIG9iag0vRGV2aWNlR3JheSANZW5kb2JqDTEyMyAwIG9iag1bIA0vSW5kZXhlZCAx MjQgMCBSIDI1NSAxNDUgMCBSIA1dDWVuZG9iag0xMjQgMCBvYmoNWyANL0lDQ0Jhc2VkIDE0 MCAwIFIgDV0NZW5kb2JqDTEyNSAwIG9iag0yMDgyIA1lbmRvYmoNMTI2IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTI1IDAgUiA+PiANc3RyZWFtDQpIiXxXXW/b SBJ816+Yx13AHs/3B7BY4OIN7m6BBIeTgTzc3oMiUTF3bVJLSvFlf/3VULYkFhXCiEODxe6e nurq7rt/iZ9+uvtw/89fhBI///zul/vF3f3SinWPv8uP6NfNQotaLO7+XT2t9vXX6r59arv6 udp39Vp09eLu70sjvvSLdw+Lu4cHK7R42C6MGz7Hf9ZEmZyI1sngxMPz4gf948Pvi/cPi/cf 4G25WzWnGPRrDCNTSiplvXhYC+2lS4Pd45OFTR9EdF6GpPRgvN9fWj8fz3zPdPluLcqTxtOL uIjcwby5jFy8P3TtrkLEn9ruj/6x3Ym2EaJ4VIOVsQHjjdQ6ZxFVksbioRj5VHfVU/nkwpOy Mgarx8CKQDi0Sd6PQX0vllXTt534WO1fSlTitx/ef1p+/O1HcT0T9lombsepUJwKHaUqLkPS MtkcB9/vqu6pbm6EzvLWaCl+XTWHVfdNGKXcd5y7q9dwzl2Q6tXp8OSTkzkXv96eLuHCshbl 50jSYESITjrhnBa3RgU8dtViC449rnbVKYRgL5l+vxwO7Ea/xfL+I8gRvXgRWokP8PE7/v0q /vNfJTZi4TO8hCSeFzrq4elpseSj+lc3F4V0PLVj8mkjczjyeniyIUgkPfh05vVyDeJ9J6lh lFR/eaPhdKOh5FebVzdChyyRMOePnCyGL14mJYMy/vS+5vcWcbp8eg9GV2Bif2Ri88rE8Ucm a5ntxUcgKvm1Wklrwjmu5ccCOB7Fno5ix0exxhcZePsGxL89hSDardjXzdiNQ5pNUvH0yTd+ n0A+dTZ5Q+9Bdh3UOT1iddi3TfvcHnqxqb7W6zHeaxSNs2d7Fb+PUht3jqcXjLBK6qzOifnz UO921Ua81PtHccqReUuRuXrZVkujXvn0MrnS8rKw7hL1qlQXsGxxFJXHsIpBGeexdgwCP9bt M3HCGqm8jWMkg5yWbijvS9ChoRMYH2S05dYuYevVnmARhY2XIxSbgo6oYCkZkHqCJZzTQpFH sFux6irBxEbaVCTkSlBshckustsdRWcdTpASwdaF6itChiidM4mQBIpGRuPptjiyCD1OMc6m zcYsnefcfiVQ8ldAFaSa9MIpDA6GXVarbv0oyLFDRpRXxBCueheugASDcKWRQSvRHIiULqZy CRTd56or17CpucCRGBfJ6nZLKExKLmdCVV3V0GV4XwqCMyM6RiWYm+SPQAGTR+Lb6Csiko+F 6Yr4yw7RFVSeFOBRn4YBKxV9un17vKJQEEL3HZrq0ttTEahLUDttXFPQ8zPEYl/T0Q1GDJ+D HmP7G85jkR8Toh3jVgyCMWR7DGq+sEThSrwmU9ye4ExmaMsYxaZiURQGiS0HjwEqpuBns2ay krg3AhHhrVJIA/t7ZMXRmJk5Vx1jkvSWMBtWQjfFvLAzC0OKLrCja7YOMsIgsW+nWom7CSaM gbvdE3dzmw28WjfLB4zIyLundO1ryrzDwBOMpuiaXgpM8D2H6EAM5V2cza6LWirNoIpBmDBz 5KzQSV0ql5mJF48EAnmmII48e5mCmQ8cU0N2ZtaOV9iBMDTMKoVHUgGkm9xXLFfGQupLcxwV I4NQ19aTw78m4xkGuBAJtRGfWZGNtCqRx28MwvAZGERtygdMoIlBnCysEWADRYXRmKNPoYxr cbYgPVg/BZ2l3Z6l3V6Vdqy4YRhMy120TDWNGJIrLLrE0YF0icHqPAZ1DEKbz+gvI1BFvdaA SDaXoecSdXiicddAqoxzZIxuzECrsDUSSNTNvproP4S2lOZM/MZ7qUycTYQJ2JNUpuh50EVr D1GTJW6CUL3snabYOVvRy6wdJYs7jZ5iuLMlcNsShphgsGFYHfhsddtMWk2U1hpiw9O00VsL RhgdxsBe7Lkv+aKcYT711hflJKfcvIKZYuprR8ACEQbdGB2BSGjBaLQ5PUtCp+AzMAgbV9PX G1Z/TDR5kJgZHjrnyxTCdUQgpAztS8+mw/l4BVRa8Gc2hwkyxUD5ED3DchELQwZ33CoMDsmg ST8Z6tvNZsJrpFYxiC0VWUxMHh7cDeo/ZD2b09JyIBR2IieinUz4GhMsVwDftgcbU1bzqll6 RUI2pndUcIOum0Hi356mCu9B5qQQ95Cd9SN1Up3KCuHdGEex6uzKZpPGoK+VoGG06PLQu8dO WZctpm1Pkf2PQRnji9djEMWOiUNmG/0YxDG5oeopJlZJl66A2BIKJhTqjkCi2m45rhhL0VNc a0alUsmO8lA1PNeiYHxGUxnBvjEoSQvOjUE3NJ6ULQDSEMhjv6s4NuuAdFhSxxfJCugxqmlF 3JmAyj5n4nz8KAaMcwQSLyeWqxPLFbHcYuPig9f7R14XLfpXCCi3OZ5bzLoqWMo1TQtOOUwL litrukEgiWSp25TSrRqeeR1yZFMI835DWXAYxP0Gg4MJgahHPCi7iE0MKj3p8Lwr/VCsms1Z YfRb6vVVfcHOgltxx4pZcS/VWDGMxacjHA9gCnMzQXgiUkhRhsSN/VXNXop/cDFjVEvZzdvD zGfLGDYCNeuKi8aAX2qov0vgSqx5JsXCZaCkY1zbV8PE2a3WQ2Lb7ZnS+UTpPKU05uk8NsXF jHfOMqiruCvbsuMpTbhVx0vlcTuj8Hmp1OEKSGy79lls6u12wutosOrwpU2W3iijd3wTe/F5 tf5j2vKTNgT90rXcqjE9K0Idmk0v6v5Ma3TVt/ynq8Qu4+I5r38e6q7aSPG3zeY4M06WEnyV XVHXyw95KcHIHhWDbgD6vwADALYaTngNZW5kc3RyZWFtDWVuZG9iag0xMjcgMCBvYmoNMTk1 OCANZW5kb2JqDTEyOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEy NyAwIFIgPj4gDXN0cmVhbQ0KSImMl1trW0kWhd/1K+pxBpxK3S/QNEzcYToMaRqiIcyjLB9b 6siSOOfIIf3rZ5VkO6p1Sk4IOAZ/p2rvXfuy9kwbofAP/5mYZFQ6Ch+MNEo5MX+Y/UP8c/7X 7AxKWibD0GeCspXGOFNDnxjKMjuda+iPQSz6TnSPu83jentff2KjlyH/wEILN5Jm6K7fFUxJ pVQW86V48/zrV3H2bTYyBqXrbx/qC5zC35zxZMWwfthvOkJtlMY78lHcLgjzWnqX6NqRqaCk jtHSYWNPWFTSJUeH8VmIZAyBfNgShLeeQsN+Rzd6BMSZkF8332stlQ/s5HpHmLEyhUzPtxVb Cq13DtGwxI1fJ8aFIHUIlItfBjHujolzygNTUuL5t/OM0CHLclmSTil/SqXDdgmzt4vNhjLa aGl1CjX+jaEoVWSIq8ziqTND/Xq5ErfrYezXN4exuxUDZb5WMvvyXq/cb3WQEQGpoWHsHoYr riQPK3yyNdpJppIMyuaa4soNDknJkLwSN933R8gvj8BlmZyMppTl+ddLuiLDWmPI+wVDHn9z ZMdh6Mh1p4u9iQ9bjofFuOsHsd6KcdUhKZFwnL/wIFDKcE4aJ5Uh5guZ4K2V2mqiVovHrqTu TXeWvfYYuGbiWofHUeH0yIc9aheJI4/fvp/P3n+8nr39U/zyy9uP1x9+E1H8+uu7365n7+az t/O5F1rM736yQOB1Uioe75kjMvT+OiPrrMk1SKEz6CPJM7TYiN0dor0eBIr7y7DirxIMCDHU X+152PgGJNbHNnDTTyeNCwVjfvyZZPV4N/pwd98hXXquL0wbnY2r2b4beIqgc3r0O4pLv1w1 xg3qny7n+eBwmmFoEJiQD+gud3eEw8jkoq7xrjECjHOWqO0obngMWF1ewtfk8st9vztsb596 0CnE/iXEvplzKpa/xef5/iBWi/72K7dbj5BoohfTdpucDTXUd88z4oz0OC5nR8ft95v1kg9F P4IQ8jVaBsfw3cX44mKkLNJWejLoqtiz7LvF2InFRPVomVUZh1VUdv3hQXzldDIQXpFCsmIo NaAOMVlO0ynHYCl2DHmZLUO7YXizmQgTtMbkKGrfGMp4L4a4GBJK3nmKSI/WPbKUwNyEriVf 7xkqOoKhSWMvM0hrSo9xzTWAagFC4dheie3usduIn1CqpxJwRWgrlU4lvNscjuklqISNzhgC mnBuoyiUKdQzlE/VVEFi2FNEDUYW5hdxS64lKD2NJK+gNUMRMg/SuILYwaAxKhnikyBBfGkl r9qEsMaEEVQ7uOc4JOwJHtX2akQTFpHI0A13CdeAeI+wCt1AsVlFsbG+Mem0nlXg9raolals gyKz5ClF1gboJcfUYdp7ptB4oKAdVVxQ5ASbha6pJmeJW6YyipEpbgAKGq40gAp65D6nysiM r5+kPfoN59dmt39g0BXQJwr/dNubQiNUDu97qTjpKBSfP/3Br+ThacK+QK+0XXJ3gt4wli8u qwzvVqG0Mbp5sx7X3DlRUzFTXAYeET5GVIuhbsB3JiuVZW+3Py8HylBwxz5Zqqwri9LyMAyk drUo/8Sw3M50EiGW1xcaU/qNw7rVd7O7WRIfce5fogAaOfsEPP3907lgTk+CWR1NOZ560s7u pJ3PZnwxOcscjuTxl6MyEcg9jCnsNsXs69UxKjXnrLTOxJpcNzg8mnJ0Yn9B6ueW1K+FrdEX bS7jPJS1Azf8a2oJxluwibjbBhdliNgvK64VgSIua+qhQeGnQZZVnPg8BTEtoLp1De4aXMBP lEvFbdbD31diPqWhk1X2NfzfBpaLKqTLxbspqNVxhhLZNUBd1iYXa7DfrLcN1gSJBYFCfiFH tGomyevpbI8F89qpujr1rFJs/C534sUL0MSSejL8z3533y8auRCsDFm5mhbXUzBaNI1karCR CxGPERId2Lg4hdOk+BGHfVRN7m0UdY4ypUxuj2PXXYquuVTY+qWw9eXCLpumKf0Vt/y+29w3 qgyCIEZbo1htGxkcjHTZEdqqM2ytttTjObdcNR4Bwc2Y1fXdV+L3rpnrystovKvxfr1cvXkW 2OgWzzMlTWOCNga9ArvUM1Gi0vXj32+mt0FOYY2MNfzhtOuRFwopl4lsPD1SU0cdam5sRkV5 aMOKOzRSU2FRgyavz0P43nUXmgV2QJ2w7FZfXEo8e3GipJeJYi4lnk9FjZ5G1vu+MSocvtcx VmBrUkDyAamwjbhukAHRCJg95+S3BoYcCjFXWOOtINXwBPW9/XJ9Jf7XNZzRiGd0fOrY7Vtv AAOiru1sDQFsnkZjSp5zz4ukxvfPnRUuX0x0H8vE0xdnl8VPX2J2zjUSx5WdBvO/4taPjaKB UEho0xXY8K4sgUbTgX3zUeG7qblGCUK22qKXawObnUklTdzYSJMIj5MlA8WHZhHGYPUPLYTu xIvwzQ0uSls0SsU10j0XzeP9D58uh9NuUnE3rRTGEpPQiyuw0XW0womKIrNpcRmNoNREFcIL zcZdnHIvHV03OvpTswnlv1OJ/KdhcpGlCZvIOdeP4t9dK0OUTLa80xnbmFyljXgI6nNsaMrI 0qWV8RXZKEVUObpI7UtrBkM/WIex9J37vwADAM7HTnMNZW5kc3RyZWFtDWVuZG9iag0xMjkg MCBvYmoNMTc1NSANZW5kb2JqDTEzMCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDEyOSAwIFIgPj4gDXN0cmVhbQ0KSImEV19v00cQfPenuEcqheNu77+EeCAQSNtI iJoXxIsJhrqYgBxT2n76ztkh+Dbzw0KKjDzeu9udnZ2d3Vv+Mv9r1mzLxuHf7oN33pbqm0k5 2ZS9mX+a3dusV1cE6oFokgeo6bin89nTi9PZgxfm4cMHF6fnT4xP5tGjx09OZ4/nswfzeTJA v5/dd9a5lMz80vRPFZ++mfEQ6aFNStG66GV3xIu7Vwne+lbjiFsQXLI5tDLivq7vAmOwQXIb geb5XWAK+D4dPTgVG2sOI+7v1V0gUikt+BF49YGELM2mGtUVT+7iqljvYlVPeXUX2LxtMai3 kLq3bPEUFZA8pTVbYtJvZpSLNmddZcrNhqdkdfKGMVNszFnx4Zrc0fsGQFX53hKgIDvS1CX/ ZUCkJzZNnQ4Exz0K1tl+l+hBbMkOF4lik/i4+9n8G6Fmsi3JiFuSMqVkY5QyAsnLUrWyo/AQ kDBTbI69Soe4qXbPrN17j/vbbvfT3Y52xvdld8Lzz6SNi60ulRG4/kBzlVxTwOXG/LbYrE/M nDRLtFVCGH/AekWsE69w5jHXU8neqyswIO5aRd11SnmbjU7U6ROlKJPKCz3a12JXzYla9KP6 PNjRkSpvdX1cHOL+JLhsi4gfcaS0EeMn63ifCK5BoLtYHeKY8AbEi+od11Sgswsy4szvpFDF gSJ1BF6RvioV3CvqxdeXhHMQDNBZpZAoeYs2+KLeYrhAhxJG3DmjnMPYzPotnJsSsjr5PdVT b0PR9btifBdnS3DhKCM8iFjK8TsGZ3PT8aaaok7pEyh6o0+uTfaEK/iP7JX9fEEuE2pvehmR 5mKxIczLEIiigpIGyrnXKo44ZguQhqDjraF2RJxqh9QwYkmTg3jincKZ5T+MKdm6Foq65uV2 qhBtclDk20ExKU4RTE/5ptRnm9XyHREKCI9rMmIJH1MvA2o+4IjwYFxWWMMRR+qQA+IhEQOO UCVXNDWE7BiuIF6A6xpwoNR2u2QOyGFIJ5TsWFiPOsXi1Pkn5imhgRdMx9BUjp5/9zZO4hFv E2uCJZL9pvD6TSiROu9SMbIH7GZ1SVoiNSu1hRE6QTRxU0Rzt0STaaIh+0lk73lO2Xgr1kuL I3C12CwM2VaysxJhHgYwc1zwxVVU0O1mRUSyD5sWFXS9OjGvaM13ktPUbbkz96mqm1ILDxtd sL+NT9pcr6iVzjbkpI5nVhrmQioWywF4SzeI+HeFkJ9wDr4Vpc27376B0/2dck4ctGrALswf iy8rZgDQWi7mEc06Fp0l8PsD7j8iFTAAUXLRV5VAlBhDM2LRHaDMKuBF4M6IMy+5UIRa1eFs DEMokn4N0Ufvk/UYAyOQGQDM6ZRQxPGOE+3rp9o3S2fBzs8GQoOb/k0OnkD2gkWyALL47OKI I5WCi819Mg24d1/p1Em5q/oh0Lz4/GVJHADY7WpVUYlRBKGSdGk8xJHDq2Dz6zJ9iLtPcAne valXvyZkgsf36LEBRyqKqSBJwohbExzEwsfj8WA5bExJBWSKAtcRQlaZoYKGo5tONd2wIu5Y 6wgkjeY9Kh10RHNGZgQGhE1FhXzGZA+WpXTZG0J24J7m9diYhf1sOezn4RlbsqAOrdUR+JEw CduTVGyQA/B6qkdlqkcxGL73aEqTPSqgd8Zm1c/4lTVfwN9uaQ6B3Hzv9qkBx7Qv1r3NH4Bs h+z9BAUacG+Z5/O2xaICssEOzrimnkwGYMEy5Zp6MSEhBAQ0URc0r0jHY47GIkdTWGEnalYP If0EZQixd8khjviDrgxZX5B2POYbRtIIpP4W/Zm7Fh4Cr+lGipDNKeSW2Q1fUeeoskg3Uuxi EtUt3/OOD1kDfxiYeGtg8k+6GQrj4k3vnS7W5I0RwtIH6SGSXAc8LknByPNSQcKKwm3Y6tK/ 79bhELhamMWWLZtN4HqzCsunSK769I+cAi00FW9NnQYE1TcVkzFAPBLZE3oInJK7MLm6/tSY 3qgdbo9ZGfYr1HLzllQVwBoUdLnZmpdLug5VqI/vG+IhnozfirVix4ND3Ik5I6VIaG8ZgWyw oWsliwI+M+fES3TXF6So0y+mchynciy3OXaTOQ5wwRiXe2NJbD/WC2yxdcSR9goRVw5lxH0m DREjDJBXBxNCYvBUD7c64EilEi5Ykh9xWEsuPzIXiXUDkjiC2bDA375tjEHZnthQoarzyKYA Ts76ZLol9l2jqPdgS5zwX9jJjp7de7s5n0Yg84ggXulmagBSEejPFhXxh/3qWr1jnkcSJ1U7 oBtjDXvFP2UeLGLpwygegOv18gOhQQOtdsbmAMpsRbDFYdINOEOIjw0Wfd0Ogf8LMAAWuy7O DWVuZHN0cmVhbQ1lbmRvYmoNMTMxIDAgb2JqDTE3OTEgDWVuZG9iag0xMzIgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzEgMCBSID4+IA1zdHJlYW0NCkiJnJdt r1NFFIW/91fMR00uw7y/JMYEEAMqSqRI4rd6OWCl9prTIpFf75rTe/Hs6To0MSSXJn06L3uv vfea1Rc3X67/WFVdkzL4N33IWfvikvLF6lB8Ues/V1/sz7nitDeuSu414bBe6Ncj+1bX9vUX 96257dutpxr3eL16/OzR6v5z9dVX9589evqNclF9/fXDbx6tHq5X99frqKxav1kZbWxMan2t 7uGjMVGtPyi5iYsahM/4vvg4bbH+/fwsPunsrJUguVuwOidTJPcn4ar2zgXJbc656LEevhbc gXBZJ+Mkpl6ccylivf4eW8IVnYLr9n1HNOQRPpcvxiWXdr7uviPRkMVfWy7GpSQdJk3OuSvC FV2d69ZTRGsW+fCdDl6ec9YEBLAPNOOydqW/yEMC2gBl2i6CAwOLDqG/CgmhdVYX019mx8CA 5IXLYrAOlei6KiEFa73TLtDokIpNCxVrrG8Va05hWSrYWPDfbU/47vworupoi5Uc0aVHCGIu krsmDSB4XXE/CQ4kCKhYl0p3QvWCrYkopRqCREn8W5Hl2B1ytxvGK/XtS0VFhdM62628ICqf Wp3PwXG3XciuzbF2N1vIbmbZpZkMWRsEoS32bDMe2dbR6ZRTFaz6ZTgeBxz1Sj1+zgrQYWiU IH7z7Q8LBRhst3jjppmRTmI81yGigU4PhXlcwwU3/e4H0qqgHB9CkuD7A2v2SaPXd0vu9yRv UE61bczMyaVUFJaK00C0d5Xm7WKludagwqmWH5DkeIye3GbPHCT2ICBgplbJkf4VkjYoC8kN m4N6ReOQSyqS3e5227d0ZORcunNeqSckEdag4nzpLn84kAZiLSZR6ON0r4FThPNdhNGQlzVk m1hDnn5LxOxRpbVEyZGODvdhkwmS2xyPrKRalG2S6DCqp4TNaJK5dMsejtsjDXKpvrvRezpv i/VecmS92raOrjumogWfcfk2H+cozRim1OQrxd4HIlnrPK5TcxdQBmI4J9uFiPg+CyM5zeY5 t1S4dWlCmvpJVct1ayxm8G0/e0A0hZ46SXzOkRhM5V285Fiba7NfUtz3wo85ybHKTjCCrnmT OUiymRL+YhYJbrc9fLxSa/r0MDVKmLi8WrWbVCxOyQatwSj0PUkHrdMlIt8CXBi0DnMAA7bb novEm0UbdSeSZlsWROJKbRbwJMNnW2p8ko4FUhTosBvUrzQZpcYsWfYaQHJ9jJIbP2KU01dl RDIk+3L/N/fmKZZue5YMUyGD2t1pJM+q1t1dDt3urPE1112D70L6D89uSUFy6m5e+Et2w+El BZdST36GjgogVXIkBm0aO0mN42bcLMnMLsms+cCTzCyZcLcygzCiiyeb8jPtRZhbUXLECMOt o3sEyVHRBu0NPKgAN+NrKtoIX5C7zcnImtw6ngqCG0knbG9d2x3yAxF2xHqu25doEDpJ0XRB fLcwKjEZLgWx4jHnXXcPVnnNQvvS7/z0BSsTq3323Z3J0JkesfhacOoRf3KmVvVzkA3zVhe+ z/T4l17SsaM6Xii6W/XGCJ3Hz7dhL9YN/9VHM+fXarLbdrkP45HgQjw1g5/Gtxv+sPQ5W8mS /MLZWV8l9pHI3qCvm265zZE9Py1aBTyLIFlXh8FOTmLkHgVGoeDtIjimAXjEWku6uC8EjS4U JMe8l4na22Ivg9br0DzPpVBP4yH0QcSzdFiSSVic1vHO0rVPCyqB2E2JpyfGExIJeLVi2vyd gzvyFgpYz9QOhPv/fjPuqHEqQRcHkYsfMOeEr53tOO6crHbJ2u4IPGswIN1ZF5yTrTrgKSp3 X0hFXEzFJ3O9mAiH4oHVOLU5cpBmmgsSKUBirqcp3MI150ZqwkxpvX3ODZsDc86YUwUyl+x2 t9sSHbTnWsode6We0PdVwFlzkOzTpeim/9Fnmy0L6bNJy2xZtpit7Tl4e8r5ala1f+pwvV/h uYhKQFRtUvc8Bt04rN6I7crtdmZafvrRuVz8fw1+ckAYhiZMPzh9sgnPCViSqG+t/KtBDZNo zkgcOrlc5/D1zfuRsc5m7TAm5+zmLSVds9BokDNyUNc3+yOlY9C2GnGGcUtJjJBS0BRm5G/v +aIZzi36NEe3NzQGrhRdMeZm5IFyFS23FHF/9XqgrLeTdxPbX3MQpsxWkS0afY9O42wVd6dB 8g4mKlgR/N+2e5oocHg/eXF3RXVyUhS6XGnTZ9p8v7/5m2sqIE5J0hueJRg+1wy9XJku61pI S6qSHdSHm/Ed5YNBWptc57y62atXL37U9JauPf1C7S76YGx974bH2jYP2O3xhqOxDezuNJzE UC0h9+GmEfQej7pm+WRUeLKDDi52wR45G52uNndJPBw/PRtduutB1sfP9CC0bszI1hT/FWAA UN02eA1lbmRzdHJlYW0NZW5kb2JqDTEzMyAwIG9iag0xNzc3IA1lbmRvYmoNMTM0IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTMzIDAgUiA+PiANc3RyZWFtDQpI iZRXXW8bRwx816/YxxRw1vv9kRgGatlA8+AgQATkWZbOzbXOnSGfGrS/vrNybWkZrqIiQKIA I4pLDofD2Zt+WP2y+GOmtVROKPx5/qSTkcHFIJxRUuucxOLb7M0DD/Uyhhxr6HbdnQkOblSU 1vlUw+9YqDYyOu9IZB6apAkUOonlphPDOImH/hv7tahlsJl8rZ94bJTRplxju7WYxne7l94s Zje389n5J3FxcX47/3AtbBaXl1fX89nVYna+WHihxeJ+psRihaiL7+KHUoYsjXCokH+J34js FBtZKmVsCf8WH7U17R/Bo2XM2e9+5C3b1wgKAFJD2Z7q6KUPikT9jWeLlS4mAl3y0CRtRh0q 6Gb9nadVScGfENZoJV0KgYTtxP24EV8+f2S/E7RM0ZBUznioA6UolB+FgFHIhlS4k7+z4KSk V54UTvJQW4aBQN8JntbZgDXaknLwUEw65pcUeXjiwBZltlmTx626/i8WbRJGXZGmdCzUWhmC Ia/b7CpcBkC/8L98atIf+qZzDs9JjcOqe+RZBa6oktYhfno6EzwJjYYyBFvDeRaaIJVNuob+ yUKtls7GVEPZ2hgbpPUoSQXdPorNct0iq06ahO6bZC3lP0SODY2PUGPnM6nD0CAgNDjreMrz cpBBW5LEMCwF+zoLoY4umRMiW+MhdjXwqWcH0doknfeEE8PZnoBpz8B0hIL422fszd1v/c3r apJZO02wU8cuM+SCnV3IeogW/TB1vKIYB14VfT3E85OP8dQ+k0SWfD/BQZUMSaMfhwZXfKm8 yjX8cTPyxIKoqEBirzpWgUxycBrJkerxWYCEVhlPHjisxYpNpFDLJk+7OAkebb3MLtkafc9D 0cQQaRNfuGX26maOyZsP2FfZ7r7MkwVuJijta2hjDxvpjSVRh+39cjU1zBha6stKOfwCTyyd pY0q1dB+4AkL5Qe/dQ3mtzBIqLElaqi447XYoWY/JDFNvAYFJY0PmTyOnV+DZgBGEhZTt/rK kxDbxida6PFh5IUIZfZJkehsIoWuOeZ0QuWssbC5FCq6odvwWXiEzsadkgUQ8Du0HK+6aX5i jK1z6BPc+m7WVkvWSRTXGG2MNbprMEo5lBDHSAXm9x9c+Y4jh8hGVBwjoaj2IbRl5HXzRGgU AW7AFyk+FtS0rgPlX/WjfGxWGi/IPpufXgephv7kOjiEzlmlLN3DcJGwjXUXpco6nAAtx4HL VtfQ7dCvlhPfbAi2J/BxELxH9K64YpIyr3Ye1sHRSoxTY9eZAiZZrFqnqQ2apDA+8FvRy5Qy yYFfoNAjlcooHUJ5vcUVkVykdGjcMlZhQJKyNZq9ZSz+QRVcDX0nbn+di7KeXxdj2C/GcITY ameQn5XnoR9Yw60TQHDcNVo8LHmRV1iPtmzSQzS/O6AhztsauWnQqmxGXYxABebdmcUtUVbS IXS8a+3QnAq3q0rwjtJA2512JAeeK2UKsDtq6HvR8HFoRsg08Jb3k8/HRA3tB57bAYafJsFr NAgLZ01qtqPUtFmy0a1VMhka/emRt3wOLjhTDrHts7AfaefyD6HTfi/uNVsf0WyTrQw25Rf/ zKuKxrud17qGs6pSBNZGE2toQ1WgsFnDxVfYJ/HEG0SD5ZExpxW659uP0wO6UiGXd3wSzkgY P1+D+Ul0EQcNCSvuebL6LJVWJOyGvyOCL9JRQ798/ngmNt16y9MK3sw7S4qxXg4r3kSBWDg8 SFd4KwdiBU2he17lPa/yEV4l/Mf+V3h2lnTEqWJKOw+gPBInWS4jdIhkh6IYgeBMrpD8Hasz NkPwrs50wsUJ+j3y41mUDba/ft1m4ncb+o+LzFfYnVLwopkAVyTz8a5nKVtGPsaoK3A/8Z3H BrQ+1jmXJ/JiBS2Jtu7J48gLkMc/8JQVdnq/J4rdE8UeIUpAfjo9X6y7yvOdzQC7QPD87GO1 GpdqZMOd+3JH6hrasucozW5WD6Difjvw3sqCiGX/1OmCXTxXPMwgVnyF5q9OHJLBYWtXUF7Y AubXAXFCIUIhlEqnVBddi0j2lKjwoqns6wra8U4gGRAlk1aIhhmNJdt8Sgowo8iWpMD6N5OD xH1CGNaJhxF+n5dgsIfkwPfX2p0ro2BefbFpbXanUNJ6W6aVcvJ1AON+AOORASzkg3A+cw76 9MTqSNnrIapY44fV14ZXw7KOAcdTDW/tapMotP+Hn6tdkwiW749xDmaqrNUqLgS+oG8Ws5vb +ez8k7i4OL+df7gWQF5eXl3PZ1eL2fli4YUWi/uZKkVUR8qHhuWc3L72TGTHRv4fPYKJtDDg ux95y29TmKOYYw0Vn8ftZtWJ1bjuG7IGocoZ6l1/b2r4HyypUtA99l8BBgDVYTE4DWVuZHN0 cmVhbQ1lbmRvYmoNMTM1IDAgb2JqDTE5ODIgDWVuZG9iag0xMzYgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzUgMCBSID4+IA1zdHJlYW0NCkiJnJfJbhtHEIbv fIo+JoHU6n2xDR9sGYGD2IlBAT6PqJHMQJqhucTx2+fvoUhOFZt0EOggQvrYXVX91zb5afal +/nmr4nWUjmh8LP9ZIKXXukojFXS5uTFzdPkp3kdTTIYy9Cvm7YKJ4dzjaPwSlTZrKXz3lK2 WSyW/aLGW2OkSoGdvawabU2SMVnDzl5XWRtkVNyOVtz3Vdpb6ZLiVgweKqmU1uJmJi53H78J foAOWcIuHWXMKQzf/jz9eCFa+VCNkjbS4hbyBXkh1r1YVXl4Y4JmN2wWi35Zf10tc8qJ4mtx V4WjlXA7Uripo0lqbyw7t6krIZXXiprC95tV/W2Vl1YHRvfdy+rZRTVaaWbI3bwaPGudzNqy o0+oJkllPYtzNcbWaRmsZybUfXNORh8dRW83dSV6GVJmFqzbu4MWw0GL4YwWEVAVk9nm6rwq Q52gk5wihau1RacovU6Jos2jqGa1URZeOHZwXasqSqecpmg/q6cNYuIsY9vViZzRUkdrKVyv hlCIyd6xONRT13mki2GBGF7n3c3k3Ye3k6s/xatXVx/evr8WzovXr99cv528uZlc3dx4geJx P1HlAdXpp9PZSIdCd/bkUD25iMIe9GHPXBIzRJmGOy6rLx6NDFAgIavZqCP6TlCakNfz1br6 4DpHtB5NLag/i1LluSlZTxuDXyFGipasqevIGgnYErrvqiXBuCCTM4Gwy/6xyvosVcj0XNF0 dycKpEKrRA8e003d4KygZRrg9aZaoy1Sz2dKzvvulIzi/xJoiOgDSR8JFBbiR6xm3cTGBPln YYwXlyZHsWwn9xM3mIZmK7Rz4jKr7Z9HFmEU2FqkhmuHs440jlN2GjdDDcwDnJEWYbAPanCD ddPN7VMxcA+gjpkyF4yYbdvYE7n0wzwG2P8xWUDy5AQK5HKAGwN9R87wiGYyjlgqGIF6m4rs DsQXApTByRjiSL95JIiFFEzJ4AOyleKecEqaUlBHRNevCeI1hKSIIaKlREQXoZb8Q4CAemaJ szP6/4Chi4ac3hAxlXmXzgAO04OnnlIgyRQDcRSf903V+r2glKkICkGwKFzD9xYNeW1cjZRn zANFstSlZRCkpbK0UmUUdYKsXop7qiy4aUqhHVM9ReBoUpYiSxILZYqb7K4niqRS9NgpDRWo kan0bYKs1/Pugco0Sxu9p5igDKZbOM/is+FCDZAiReZ3LZdqSNh/CPQ47yiFLck4lVmoKYLR VZcMJkY3XHI5qHQu0DEWxJ15d18mMGOYevay/FGdQ1Ryzs96b7kso/YUoXWsDPPZMmRGVYkx 23tHkSVFfEE0RWg9RMlFb6bELbUWNRVTD3NI9FSTGBSDY+d0XJPKMI8ELWe67IWB2csqq8ay FZjX9NkMNGQSM1h849U3hRDOHWMj2kBiN93SAuO9kinzc2gCYWnAwmvPXYXRBF2YIVLcUN0D SuZscNC8URnOBgeyR2VgV+01jXwo00WRdK5I2ioJW7ffWVC9YhoMpbKNESpGGBd9zhTpuepR QtlFs7a9o3p0aBeZUXMqNoXUxYBPEPosCn2tbEEEoZVGZYjEsouYkHSSvszy1JjHR3FLxYSC XFrgmGJywyhbagy9jETZO8wMNmvKsFqcUK4zs4fa4k05hRKP8xWVEgpx0P6cwdCjj4H5xBq7 Q2/lLlEiFOWfsxaDePKROfSdIihzw35xdE+pzhrrzFbUGoo4FrVRZSLczstTKkfUGpsYwnTv JdYwT5ElFzUQdgorwugvDOgo4J8HhzFC5xhsIfyMlqeNSTqdMxXbHxDmjeCpFTC4msigNZWP RlyCTWfs8RpLkHH8nPEqNF003WH38KPdQ1d2j+Gt0fN369FoGKd3/P7xqBXEUpfGzFuK5BL+ mlZ2pr7vyigz/dIs2oPF4dniwQJdyjc2LowUZWjARDVsV2znC/E/bFjG76p0cXfkqcPYo3eu OKVruws6VohYDwnD2hGmZsuPWc5Z+iO3nU8UYpMaZgvjLEWkED8MXHoOwteJC7YErKy2pdLg ziAuMfkM0fv8i+gmV79OrXhYia8TJLr0Ybgc5dZEjE/DpGVESR+F55g94cInI677yafh+k9i gkjs5KQjPqJNOWGiEpdZbZ+o/Dnt/rr943T8Zv7km7mDMkuPeH608ukbgjLQ+KVRIXyZ+JN0 6jlK74eRf8Rg8VW+jE9jasEhpFQcVpAR1FPIKF+BlgzSGiXVMKPWHPJldWJQ0zHKYOKwJc/J UeK6WbcrhobS3xJz8gWHoCrNIcGghCIVfwBZJOMJaKfO0SPvNEmzcV9tjp8TyZi2rWi6uX2a r1bzvhN3bXNXBM+dQgeAVt34WzWX9FlkcIgjWv7GKFQzW+w8QJtHhrjSs+hB3xmCIuEsRS44 Eo8QyA9t7ESIcy3EQ/KouK94sR5tq6XalZiP/Xp+P5816xLx/l40s2Odaf6lWbtYH2kXPdNv Z6UxyaEssy8D/hhqX4jK6wTEg3J4nylubp9u2+XFuegEdTI6el9Z6rHRsZRfs21szVO7bC55 JpcGFx1FeU0wZbsok9gYgp4ZhsUi6jKkjrHvHArQe6aM+JtB2Jx8Toxq+VtiPkzFWWJ6Sbaj HMN2oSwzrPZI5gjS8o/Zuj/xRP8KMACv1zL1DWVuZHN0cmVhbQ1lbmRvYmoNMTM3IDAgb2Jq DTE3NzkgDWVuZG9iag0xMzggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCAxMzcgMCBSID4+IA1zdHJlYW0NCkiJnJdNTxtJEIbv/hV93JVM098fEeIARKsciCLFEpe9 DPaQzAY8aGyHzf76fXsSlulKDbFWOWApj8vVVW99ibOz0+vLd1ciaHF+fnF1ubhYLU5XKy+0 WN0tTpRUSlmxWovnT09CG6HwD390TNIHoZWVKpX/fFj8dvP76q/FBElZ5mBsDfUEyp6Bhi8n 3fbkceg/De1uJ3aH24dut+v67RuhvRTv+6/tw207LIVRqrbnNH5UZ1fbs6JQb1eLt9eXi9MP 4vnpLnFPL+/Vobz85Pkjnq6lct9/Zfxkk5f4Oeelc+NvnIyO/EQlGWJOU1D8aYy97jab+/ap 4b7knJba1V8aeNDJFHLlRgvrTrC0j9K6WJm963nDUUkdc6jcvvn4filaDvcqwg/jp7hkQa1k MKay+4kHg1QI0xEWk4ypBt+Iy3571/GGPdIWQsUfBjYNPmRpcq7QfdezaFIyxfpdWzYJP2Rj jUxO6RFsthvRbdk0aANr2tb8bs+zWUbvCdvcs6yJUGUINXvf8IYtJJwcgbs54SYVUo32fCQc MuGNJvDu8PjIhtgl2HbU9rBfsnDWyHIkwRD3fPKUkV5b6vUXXm5WOq91zR4eRX8nmq/sN1yW PlNXmo5NjA+oD+UdgXm0hC/W5C1vNTqpQvA1276mT4P61+hAY484bNdskJWTMZYETmlUCK9l g/wlm2ua738mFBmFGp1RcgaafY3y4sTjszXUXR7FULI+HmU1S+UTeRbbJZ2z6JKlmqfojkeT 1EmRRCwF29Kcz2AS8Zbv6wECsJnY7aHfdf/A1wb+RE2eN4Nm6aIjqThsu3Uz1zXRLBXht8tR luPctS8j2L4ygjF8/PPXNx0bT5uTxBwnMJ97vBjNwNYoH81SADa5GuVlMk7I8tgpenvgXUCp ZKtyDbcbwVcLFJidIab5aoECVSitfIryooICXXAkYnxn9lbmRNGBj0NpcOPkqRLxmVWUixhT uZThFOYLJhkk2JJUYKyKG16rAVo1BP/Id3xMh6xSjWITwoLK8hiXRkXCsy3RIx3RULTdP/UD P3zQx60l4Xili9sMfWY0x8JhmV7zbQl1G2KMNc5HGdMvZwySY1B0sIzTokJ5TUDuVmPPqtAt L0s0cYO41awoKxTvBnbe7FOoeb7qAv4kjLMKnd+PjY7EjYZ3Gbuht45Eoi0bw4bXJgZ79pnY nlunsQDT1zVL8ZnFMSxRrPoYyxZSi54EY+Abv0MxBeJvv+3+mVtbnLHuCF34gBPThXCMLnzE 05Im7MsoOe6as+giGgL//kP9pmUr3OmSfJwcFb5ut3teK0WyseRzindriHaum9qyJVT4Rmz4 5h8xKnIkxvcN73jC8prckX6POnQx/Ow3L1ssbcEa4slm4A9GhzEQiGm2gD1O3JzQ9I5BsQcl mhdeWt5IqxwJxYy0gpXGaeLBUoziertavL2+XJx+EGdnp9eX765weojz84ury8XFanG6WnmB bftuoYr+1CvKC+VKyPFFtj9b9oq1fPymZD326ohGW36EVYhNuPUiJkuF8iMGJxbOFV2jfzT7 9qn5xteBkjFoYpvv2ti/VUQR127se3HHlwy2Wh1djfOzxpfNPhP0b34whlAKt0Y34h1fh1gw cXXWMF/gqEJf2uWU3LfDlq+UcRo4EjV2gHmVZNTU8jgb+RaPtVtpIouO31Sw1PhUxm7tNF8w XpeSJTHmewzSEZUlLjf881CHwZQ6rPztt4I/LlLJNPWC1Q/ONxm8iYzqS0kZ8191lY+z1YVO ZSKkVb588/H93K4VTbA1LPigl7soF6aCUQS8AlEzCSOzpnnDDgtXDJEYnpOgQ+CdM+SFMztU gLYdfd/sdh+NJ17wVYsVKqHEanSzuW+f+EKAZU+9aIaWP6C8SbjNEnkfr1fMcp/KwjVF1/y2 5YzMmnrR8drG6FKKprpd8zWDMreB+LA/8A7HoiFHDfMoBJSJ2d3cmPP6f405i6Hh0SZfG3Nm bsyZly3OvLbF4fTA/mx+OeZijQr2/rMZx1ZZhKdouz4M3Z4fc1CTCWVsTL+wFK3krwMsz9k6 Yl/yKNpUdsTrN+KRXzsDFuGxvU/pbqYUMemUsoTdd19ZOqMasyWW2x0/nL1CS1CBPJBv2dpI ZJY8cBDN4+P8jUK9nqlbjOdR3JUTvNlSi7as1JXZju8dAYus0+R1s/MrBkvstmMVFE1rNcr7 +dOsuhFP63/MKLZBWORHm3ILTVE2LjZbNFZi9BsbFqegp4DttmL5KYD+iyZJUDblTmO2KIp+ 4hVt0HxN2bGmLH8WmYhLV8Ua5d+Flp6jItH6zM8hDE6XfTgiCaWucTSQ0M7VKlq6yaX9/zpg UFHSFJ0dxtnpCv1XgAEAquwqGQ1lbmRzdHJlYW0NZW5kb2JqDTEzOSAwIG9iag0xODM2IA1l bmRvYmoNMTQwIDAgb2JqDTw8IC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGgg MjU3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCV sMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw 6ug4tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJ AAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7 ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4 d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOl JNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHB Qn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+ Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo2 6rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4 Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WBy o75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAe bALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2Io EoqHUqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7 wb6wGI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiU IXqkFelGBpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ 1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8Tj xEvEu8RZEolkRfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m 3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl 0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyM a+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL 2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91ve BG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbd lgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+ YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxt HZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252Pev6 zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7B XmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8t EUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4 QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3Qin CFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6H xCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9Ooadk pwynfJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ 3Ozi7D3ZT3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWz i+MXb1o8XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fI N8sfKqIVA4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqv OqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrI upG65/V59Yca2A3ahguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp5 4vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHnd rej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB7 4PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCe rp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm2 8Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrR PNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHt nO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8 mP0p/br+S/7c/23//wIMAPeE8/sKZW5kc3RyZWFtDWVuZG9iag0xNDEgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjY0MyAvTGVuZ3RoMSAxODY4OCA+PiANc3Ry ZWFtDQpIidxWC1QTVxq+eQJJeTUBu13UC4gKhDABgwJiDSFAXF4mIVLbuk7CQEbzIjOAFBWI iqDVUov4pCJWQcX10fjYntala48PqhRfFVlbXalbrY/aFp+g7h1YRW3dPWfP2T17dubMmfz/ /f7/fvd/5B/AAgB4gXLAAdOTtOoUaeACM9JcA0A8IlMbGWXev6AXAD8fpNMbLbhdv692LwCq VABYp4xFNMzyj8fRugnJ1jx7vuXE3I1bAPDvBIBXmG8uyYu8uO0RACO+BWDoIhOB5x7ZvjMA gNTDyF+MCSm8p7ktAyAgC8kjTBZ61sZX0ruQTCP7FrPNiB+9dVoDQKIdAHanBZ9l59D8/ci+ GeGhFbcQtxS3PwcgZTzan7TbKBqdA10pAcy63UHYmyVNVQAEQWT/Z6Rj9d/MG4i90VsM+i+x G+YUc/geYZWplXc8WW7sBqeoB3OKbrJZLJkX9hLffWCFzeMBbDpfEM5ncVnOsWwWt0GDZWGS pzQBjcPKA8D4/jsTGAAFbMAMCECjZwJzY/BZf1yfHdhO+VDXFNXIRY2fFKSujG5wer+GOdmt 6Alli0XVruOLLjd9/qn80JolVW3D27T69zDPJ1xZXESp4gPZcGwon5PNFYj89YSD1JL5Vqhz FFI0zCDoYptjpmwI5scAhCKvxwAJVFuNUpkECxtYCB60JC0E1NK4xU5a86GWcBSRRgJqbDZa NgaLGkCHZ2TCNLUiUZ2m1r0OFUqlKkunSpLA0cbQ2LHw2T2wYUM8Y8diclkUNhZD11Qkxsqi omX/EP/3D1Cx7umYs3iAU7EExb2aXVEBTkrhTdNsSYS0ImAnf1eTcK+v55QubWdh95HosF2n bnu8MebnKzUPPV7q+Mtvp/7x2He3q3bWty4MuTonx4eaMeuLAr8HB3Nuh27NmVbHfRBh8M2p CGgrqD0dlBN5+qiYNz/m49otrvRJV27EB23Tr5obuNZc2TopZcUM16aY030eESddsWvYHFTU z5UEB/GK8127gDfhxJXy3tLTm3taSvp4fcsTCoI3h48+/46IqH4oWch6d+pqQ5tvU3nP3v3i vcf1q2a6G1QHGzd2yct4Qd84IriVvKbZHv7vi5U37/inf+W2dI2POeehQL6irXrdea59bdgc fOlnl4UFq5sP5RkSE5bXBkWtDKpedD/XfcStE/dR/R5DTwzbD3zqu7pLeT2wNzlnfnVbclVN yA3x9P+/Im6RjcJCBhwP++c0Hp9U+MKT/lsUH8dH8Iv4+GLezIKbyF1tpQmHlaCxivpflPRi lIWFTElvxa+7ti2pSak55/KdRp4TlBlq+LJj7Y+q3ks+o46rvXKK/1r9tsZZU6/d6zOqMvcJ rdgPjTFbIzzO/2gbtdVz8nSePLOsXZfZsVeS2CnsWLJv2qM95R3dda6yIHWij/nkyh0s/YYD X0rXxfWUNedsOhNEXHpn66y1n5xNSTS9ETHnwW42i/MrBW2Z3rvq9x+SH50stYcbgoclwcnb g/0O0ex76p9GvfpmS2WB3D389rvfXNhdd3lx0++6qcOpHvU7uhZ3+S1r41zyCNHzv8v4MGXj 8SnJp8bpbwUeOzAyPiIkqn3NxT9NTPm+05JSdKkV2+Bd3l7WGT+34d7yMFm43/3D4utf77iS rbAnR0jmYk6PTejxbuCwWWy2T0lenXXejo49rJet9a0uouBpxmxU0PivRP3FGYrGZAMJD3tS EUqbxUI4jCRuhlpbHl2MOwiYVWgwk5SJcFBQqegvyXHYGFkMhj0pSUaMipbHymOnYk7WW/9x ErJkLGnAKKG4uFhahAwpZCg12iyRaALbKJK2OUoilVlaZg+bwy6FhhKoIfKkEqaupWm6JKaW Y2QTsPEDfuRJZD5Jow3VSVBpxikKRsMImE4aHTYKURjkocfNZC5OkzYrLIqSCTEPxp4vYmdr ZSLMlxHcRYIpOGVCrUfbrDIfzGsgFG4aItdis+bKhmEBjIYj9ht0r0QcbY5+t4/XhS9YRwGG z3eRk+UJkN6d7WSxgKvmxMjm3L9d9TvwyFKqyBTcs4UVtEtf0W6KirlwyvRX+QP1y511fcSX WjHczz3y9q0jdkvttaMfbQ/DVkflzN6zeWZI/qrWi8Xf8y790F13Z5vwN5v+MH6+/eJd25uZ c2zeGtUivzPEuXjI605Yb14R5yUMEV0P/AIujX3bMI93JPjVPk19S31a3ZnxGTkJztIbHnL9 blNroqoxXraht3N5b/YhSfOGA6GZ7T3v3+QML/3RL27z3S1Z83gWw83FoqpxZ7sDvKjP+BM/ Hn3g6rFlBYf25+1arwv6Spg/++7CkuqWPMGWyfcfOAL7Kt862DPJ61oOHpzesTMu94Log2mH F1jS/LcnuKFG3uDkfY05eWf7szNUxGVjABMyP725XA6b14BVVDESi1tRjs0t9ymt+/a48oFp 5c/jjlrjfxI61xv/C43k5LFd6KsQC2SYcFmsR9whmBhjvvwGv+z8OWy3coCyjSACLh9D5PkT MSc35imMgDF1coORenhDaPkoE03bqbjIyH/RGOudnH0VTo5LZyIpaCQcNJlHGnGagGR/wzDF RlBM1ziIPMJBWI2EBOLWXEjSFCykEIyCFO0gjbS5REAVGmYQRhrSNgmkTQQcDMITv0y/ZDlw I80MRDSaaMJCWGk4GjEJFSCaFAOQSTG0SRFOmnGDmWHyrLfBA0CcjhO86KDxDGtVhAW5QTiI dohwEAWFBEVTE5/F2RwCBH0MfDanEhglj41GacTRhFQUEUiRbiu00jhipSeJYglKIYwdg42J FmRrFQhnL3GQ+SaaGZKy2NiY59xBqDCboYZBUOiPiEIzmciVQqVKo1OoMwRTFBqNIkOnVmlh klqrTFOo01VJUJGR9NQcTlOnq9EYlgoYdIY6IyUO6lJVMFurgpnJ6Kda2+9OnaxWKnQqiESt TqNW6tJeh9rsxEkqpQ7qMhkTgV71d+arPaipK41/Nw+IQStSUCq2nHgNQnkFRGAFNCG5IakB AgFNWLVJIDwsEsprRHYtsC7VKJXu2HF1rcK6Ptpx2otOW6DqVjuutuu262tQlhndLWqnPra6 ahWs7HdvEl62nf61szf3Jud7nt/3OOee5Orxj1fWGH19dhYx5qrUeXo1g3boIJPJykPY3BR6 kykf5yOq/Dxddi5ikXpBmrwREH2m0aD3YGbMxlzGZCKjUWESstSGfA3nZZQrRdyZTK5ah6Q3 yuxcotXnZXHmWhyriFGFGNX5BlUuMebnGrNNTBQ/yVK9wUCysvOk6QyfJAPDG6izs0xMTj6C 16sMUWiSpc/TL/HYeMFmY1S5RKPKVGUwphhiYhgpFyf3vuB8aBjUMpgw02onrv0KLJmzeGIv lpRV47bgKCIVzgqurYrLHEUm90JQ1eDKsNfiApI6VqM939x1tvJaB6kutWEfVDhriN1BCp0o KuKd2KqJrbCwtsq9AoudVav4NSOtc79uUAM7lUOgV8VIdyc2JvycZe7llztLnDElZcWKpve5 nYSImvYpGhWNPn7WFh3V8pChfCkKGeE+EtxVxGLcQafP+lH/mCSFfURToFiiCJo+YT9U4GGF mpnmZc6t5jNbNvomHtlTSHmZzR5DymtwLYw/XQJ/KaaP2elCRBKFD+52eE8493AntbcMf6zP 76tZtlF+fC/5trzrUIO2YeeuNT2v+uiCAhynl0c8zEnZ8GrnvcDk1X2b3/NrTGxbrtt6ApKl pj8rk4Zdz85dBRkJ3+kMMVV3/3Ju7fca5+zNZ36366stt64Pw2fHb1fNurRDWPHhscKG+NWa lJ2/dQ2ta0kKj7m+NzlpYc/j/zTTcc2iBNyDFRi6ovZ/8P74gcPgZB+JOykCsRjam44qnhvJ 0iRh3NgXiwjPGKOUX9yE144idNRQFBcg8rdRKezmGFlbYm8Ze+qK5TB2wKj65Lg8RW57eGMY pIMDqqAcyqACCJjAhr/VONKihPt2Il3TEdY4h+suT3Ot8h5y+O6qqa90llTZKkvrJx5yRM0U RH1+0BW6ubPoZELQpT/FCZX5c8qvpS1aeEx/eeAdeDP99KG0y3cPJ+8IevFfj+DMe/lrOhQn Kr9eSWzzSqbNKLgw9WPFZ62uj/bvX6LIXBYQ3trw6esByl1Du+3bFLfXryjtnp8AO8LvbFsr nLElnqn/5lFs/MnHQ93HivvFQSt3dw+uq73V42i4cnb/FtGswm69KD2SCZm/StLe0zbnzr6g ioyi1H79vx9vTWw5MNjb3GdsqHxZZH/Db0CVMtT6Wm+Vcfma7SmGpLOtlpVTzuvWVHyfd23T 82dLsmYllB17uy/0gO/SPdtS/zrp4oMsQ/XXvVGvfNVS/u71+1M+WG2k+ztfmxP3Rpi9/1FH M/V3POedHq2OT1wzdQRZ3VzbNXX93/+jFQTBkWnb+9S3ZENa87oNn2vXt8lvB1ontK5FETy2 c/1GCF8KG3dEIo6byv8ZSYpLiFckJMbHFTzVuEvPz/7NF//Ypt1v/27R+Y6jdyc2VVNjUVrA jmfZ9lPJe8T6oNILd7L6Qi8eKLkU/eCIqnWP6s7Si5Z99fJeS3VbR3DgR0lVBS1vXkmT/zJj T+uNF4ypv6/cWFy5oatjbcbl/rDGFwJW7PzyjjOx9kZEgGT9QMoXb/UeLj1w5hnx29HnJpuo iLrBmd8ejxaevdfkXx838FARshO+OYdnQGE21QZikIi3i+chKXf/CtuhWBAgEQie8REIxAKB 0Ac3RCGMubTpegJKIEMC38gnVjjqS1PtBB24peIGWIjPXFEnzBT2gBxg+Kr3eXJy+J74Q4An LIBg0fBdcT3MpFzDN0VHYCo8dQnvgexp7s+4jsJtOIvPJbgLT+ACnIKb8CXcgmsQBD4QAP9E nXMwgPxP8eE+12Am8p6npsMDaICr0IXag3ACPd2Ew7AVCmAGRCKaQfgD8vbCa6i9F3bAaihC nwBSSgY3oBeuUvHwLmyCfThrH/Ucej4D/fABnBE0CUVwhAoQ9FAvCd6BgyItvAJ1sFfwK6oM 8VSj30F4kUcvBRoxLIM0+DU+TogWVEArvEwFU7upC9TH1HGBmXqfWgFmqgZ9g3JBjjE7K9Ow +CW9LkPLaNTpKuWihWmpKQt+kZyUOD82JjoqPEw+h54dGhw4zX/qFD/pJImvjxjP9LixMbTW StgwKysKo3W6aI6mbciwjWFYWYIs7Xgdllh5NTJeU4maxRM0lW5N5Ygm5U9SITU6ijA0Yf+m oUkXVZBjxnGrhrYQ9hY/zuTHojCemIKETIYWhAku1RCWshKG1daVuhirBv11+knVtNohjY6C TqkfDv1wxIbTlZ1U+EKKHwjCmQWdApBM4aZlhXLGVsQac8yMJkQms/A8UPO+WB8168v7ImUc ZthIOqM+cW3q8ge7NXJyEV1kW2ZmhTY0cgkZl+t1dlokG0Fr2Ig1A8EYsoONojUMG0mjs8W5 IxNQrFjuTxPXfUDw9K2b4zk2D8dH7n8fuCEX4kiaUO4dA2JDhBifTMZh2dilBDsSbGOO2U0T sIccBGVspIUVWDnJJ15JUD4nafRKRsyttIwrFWP13HWlwWyjnURHYfb5W443ygkrDLPaC0u5 X5vDRWs07rzlmVklHr4xWZ5YmU5FLOrbrBhEGZeGHDMbS1eygXS6WwEZhKtBmcnMm3jM2EA1 C9ZCjxUby2g4XIRxWTVugJwvOsfcDfOGr3QmkJBD8yABLBwOdroaixLGuMxFxWyoNaQI+7OY mENkrNKC6bPQZoeFqxLtz0Zcwelk/Iy8FcY2QdurzEXuK5cQsyBEaOGqhQyixS86PRUF/lgu nuQqmp5KzFQIeNVwFo8GNxrnBwmhXK3jRELOVK0LkVlk7usnIIV4MInlrGSML39kjGByz/Oj 0NzaHKAIwjg0YwCOcyr2APR4+2GcAi4XnonRQsKVU+cVCeW4cpEnQDc8i6tiMGHBSMy0g7bQ 2ENKo5mLjcs1X9/FJnpxToGZr7anS/LGUW558ojMM/J+iEtCLza5OB3aIwLi0rOAzafEZZYc kODmanGfcrm0NNG6rC5b13CjnSb/Zb38g6K6rjh+7n3v7b6FFR647C4/d5cFFkJ1UcQdRdx1 YVHBKOIPFiKwIBpMY5CCGgbTJdFUq8akdaaxJqPWVkAnYxY741AnY9qJttPJGDuZkLRj88Mx jJNpdNJMYtCOvH7vCq1j82ff7od739377v3ec86976C5948EAvu3hSJCZBgGH9UvHMiMVR9s jGmRTrZQjO9e3rHfvSa8CGaYJc5pvO/i7z9Sx/Qjk/9Uj0y/Aacv9kOZaEDU+BTsGm3nW6la qaNSqZuWKzfIqzxPK1mEqvlV6uJX9Qn+N/JI5ZTLRvW7ko18bJSqeA255D+Rj1eQVbpOZuky 5WJsTbpKqXImVUl7KUk6QxrqZewoVbGj+j8wTpn0HAVQFkteypYnaIFSTSb5BnXKF1Hvpqfl ldQhV9EmZTPuL1AnG6dO7iajfBl93NRpqKdO5SK4QhXyJHXEyz9Qh/QWdWGuGcoy2iR/QxVG N9p/QQvkc+SWE8jDP6UoNIsyE309Ur/+JX+XyuQuKgY1kg/5QQ8VSdfQpwlrKMJ9EVWzd2g9 u6y/L0eoA/V2w3kKyV7yyzb8vptq5H7Y4AxV8A68Fd8iVX6KIrKZgsoY7NmHea6SW2ohB79A c9gdOobSIY2TU6w7vnasW6x5ek1x/Q80/Q9Co9D3MNBkZe/ox8FFcOQ/2h5F6HoIKUz5kptq +GXywR6lkp/KpddphRwGRN3y1yi/ppWKTEbYyQvc8OlmwzHyx21+h/KkasTBBVoBIkoVzZA0 2ip10C5+jdZJedAH2E39M+ksxj9La2UnlRs+xlqgB/6fJWIP7TuNR+mYlARbJtAZqZRmyQb4 xUDlShHiRuRvU7YS8xqfxxg3sJ4XyWvYQAsklUJgIRumOuCFpmppIeUIuwvf8259ELFziK+n MpAna/Cth2xSlEpFHOOZEjxfpF5G3At/CF9MlQLEn4ON6x+A34Av4j4S68c+mvbXNPDFBthp KcifQtjtL6AHLAQWcBIEZbc+CX99JOIWsZMmYlTEiYgRpVsfF7EYj13EuHyEOuP77zYVwsaZ yH8LDcFp9HvxGCtHjnsUz73O42Nzi/4R9K2Arauk2VQgj5LF0ANOkkVxUYo8DO0u2PMr/V9K Gc2VRilgFPtiDPPuJJsxivoEFfEi8sfbEA9YYwc0ucT9o/Ai6OjGHnyXmnAm2HAm5OBMyHnk TJghxhRnQjzubiNuPFQvD1K5fBYxeQ6aUrGXu6hN2kpP4AyokK8gz7xGrXyMHPBjmxShiOEA YsNFbeoYfg9Ts/JnlFFqlmpoNfZ+lnybGpSfUobxHClKBRXKX+KsiVC90YYzpVwfxxiJ8b6i PUwt4re4hu9BaIrreQgxt5jjYQz+eN+AbKcAYnmZtIpm879SitSJs+ELSsIeEfVy0f6wH4Vv vq+fiMGAPXDetlSL1cUisW0xOfpb1vrG22/wVW/iIP59QI/a06uj/WbHK4fMjtbDrOTgqtOt pyMHXz79ysHjp786oEaH3xx+e/jqsPzpr5k25BwqGQoM1Q0pXSeZdsp5KnBKSh70D7YORgfl /ZUpjp+APWA3eAHsC6Y49oJfBs2OHwc9jufALtCP+51B1bED9FZ6HD3gR5WqoztodWwDXeCZ oM/xFPpuQb2z0up4EmxGv02gA+0bQTtoAy3o0wQaQbiywNEA1oN1YC3GWQPqwWrweLDQsQJl LcapCezA3+VgGViK1moQAlWgcondEVyS4nAnhXLNIVdCyKmGHIZQjhzK5qEsChWoGapdtaoW NVXV1CTVrCaoqmpQZZWrpMLwGfhfhDEyMWToVFiIUyg1ReUBX7J/lNGIldWOGvX62pha90R4 hLFDjbHUWqpdG/wdHtJffCnIsmtj2WvCsUh2Y21sABXKHrFSsLEYGX/wnC2F7XPGclfvdz8b C9Q/O5Lg3Idkft2zI5wFY1KWy8WQiLorNzQFWW1deETFg5UbHpRWbdtipMjOWF5oY4wjA0ay 6xo1UGN7LLUynDnKKTIqU7t7uhJLLHY3xhKREiW4g+T324u1RcxrMMcMaDK6gz3F/8+rZ+qa qhbHkwzkG9KAoY0kMlJGIEGRTDKpRoaTwXvFe4Vpn1zBd05JaYorJd+V4hqQ6P4Ap0kytN09 PqC0IYfpmozxMeU8OagmMCecwWrwtTZZOWmb1R0qb1DZfJV5VKbuWmBjtiFnP57pzdZ6Nab1 zkwl/61mfJl2p3m8GdffL80pQcEsRoP4pFlsVvFJsxjcuZ68FM033ze/dK6Vjzl+vtSf58wv qlg1YFtkMqVPJkb3fWc3Ji5WzGmp9e3hV/dE+w7/quGZFUmJM0+Z7/G9LOfmtz3m14jpE1Dc Ele8PFDSkMOqc1hZDmtgrIqxMsa2JPcl88LkcDJP3oWz1tkP2b0ZWq+RGXvl/wr+8NIHt5qb 42qFYE2BwoKyeUKgb37ZPE+B+JTNg1qxAN4ymWA3mRbZBlYuLsp35vmrDzsWJxrt3+0d4BX3 ++6ZT81MTHp8a/jE4b7onlfD7fWpacmvmXu+vQm9d/V81s/MNJNyAokGkzmNWswWkyGVvB+n X2J27cP772mfpMNw+XGrCRmW+T6L0FI6l/W7re1bPKaVW+StDeXW25tXzX16xwYzf7nEuM2T ZRV5qY9d59f5Dcqk9EAiZWtZSScSd2ecsJH38/ufM+2P2ntzStgDfxgNnoLSXEzxYHBr6Vz8 5Z8xU7KUwH0F1U2Gxd9UZC5UbO597oo7FVb+vsld5fKbJM65zTX7Z0lKupixSr/NtrMyMpM1 YKJ+o3FGUkJUIu8tlpK6wHtLrET4+4H5rGx745IlP3hs/ZJg+HBwY2lJsLI1ImLXhzfqS3in JcOT687lqBkX9Amy6hOB2Tg3NpLLvlF1brH0WfhjFma3MMuTPjMzK5uzdmTx/Cz2b6rLPraJ +4zj99ydz2ef7buzz29JjN/txA5xYichR5L6QuIk5iXEEF6S4Ja3QFh4CSsLCiFp0zJexuiq rQGG2obRRlRa2ZtGl3VDWkeAIoVpLdJgpUJblYVqI9M0Te0fxZf9zpfQzX/Yd+efpd/v83y/ 3+exvQiKdteQQBqxZBZVMqu+o8LOcQ/RFmrQS5Ghuo9l+TpqUVn9PlWWifiyavLM2PiXX4yf PTv+xZfjY//IdI2Nda5t7/rBK8924F1P3rt+/VdffXX1g99dfXKhf2ho/+sXDo6Mfks5vw3N F9PkXSyKiZIH6yO3hQol3pgx9r3IA8+XLrXss4263UxoX4RkDCgYZhEVVAoFTnYmOp3IzaCK oL3xgtkqqOWwVPOVfvUSqe+pEBM+RX0wDXZyxVG320jpHbuddg1pW95AVC7VQIe71kSOa4xX 5R2b5Tc3h0mnFbrfgRV2j8FQbmBKGaPOsZwQK8wkQyo7N8z/k7iF+n4dtlFiz5VfLsePOOCW AO8JUD05/y/JW23qtYFtJ7YsDvFnAn3Fxj5Tvaegp0xT7FvOVffQ6Di5Gzdj08ncTYT6b3+a 5R5mp+ayZrFGtRKqvFXwxxFm0u+Lwf/4SQGvpSp8qrOslWoUKNkAlBaVIwlx4hblZe7+sUX+ a6udKmhuE04fv7IytaWzs76+kkYKBY2VbR8Z7Js8fEK+GO4oCE/laOuka3CJjaOEVw0GEz84 ce9Ad+0yv6PYD5oljqXdPM3Uh4Mbt/3i9/Klsg24AxTlcYjCA/JTrAZbhX1P6iosfD8IjiAE Xa49DaLQ0CCGxAHxuHhTJKVmMSP2CVIzn+H7mrdJFSWZkj6pgskwfRQmVbRXbK0gKtZsbYCa BmiodTUQwYqmXc59pM3GhoMaFoslb6Ci1w3POHJTZrsIsWyW+zR758ZMdCaam4miz+wJU1l0 mJuCbDbhiCm6WNQoIqNdFEQe56IoFrlRygK7VfEwWg2V4Txhra0W4uoy4oEtsMJB0ozTt/67 Nj4jX8vUWVKjP+osWs6xqVfcLOBQ0OOkcfk0peP1zJUrmtUll9cBThpp4CyAEygJzvhtJGVz XQrZ9UPb7Gvf+uxE6SZrJVOQuJMo6+8RMzRfdBB/lyZ9NuvnjxnN0NAb68sR46r5W8Q95G43 VortlhrTvk4ffpuF8+wkiysRfYolGLaQXcV2sySr9ezANFqtAyvrCUFox6ADaAc4lpbs4a1W ItBbpNH1Esjnc8k5RHN6Dikvi9zO/YEXYze4OV5UlIf0Bxzmzds9EVdVp4BciPWv/c8LefMT 9+Qu+Y6gLQ+dHU6tWIXc+I2jV+6PHLn79+H+R7UN/f95oWdXy1r8onxH7jIfLbJJ/pUdTTq9 dP/KxwPPT4y9cai9S5Z7jidE1IKxXgwjL2qGsABWiaWwHkkaDsM5J5zEYU8QNgchjdTVUthZ tacKr2rx1FLYAELUUlHbZG4ztLETzR4x3Z+AREJfkhbwFWk9vXjY7JyImuvMTG4KGY0X57JK 18o+bbJ+X2AhNcxVlbhycHJBG/mUWwKQP3JeK+hpwmPJ37tAuVMz8OKeAz+W5Hkpdi3mtFqd nbCr6+Ph8+2iy7V6i/xoZPWVdyj8M2go3Jf6/hPyxZE3U93ws58Mv0zR9v3w6/2H4KNDNrzt uQ9TYyELRXGRt2D2TIXL6T3ms291uOThI9GiwrcDrwX1+pJqJYF2zv+bLESkNmCtUqQuiG0q W9UkCc6Ms00SkMnahImNqfTy9ni8kA23R9KFeEd7e5pFPHKzydyMEqGzcwqR6Gw0V8c9nHra N9Wo96pGQTSIUAxCeR4BFYnKCh09H/5xVSN5MsoP8/FUrX67LB5EYAppHU4wGqu+aEiW0/In aa/TgOsACpvB0dwITGOMtNo2yJc3rYsSuqjBZmemXq9fb2WXGNbUTE2UFlPgce7c3wyNrHCb WxKiAykzaaZd/fBB/zdhWfu4yU7TrmMeu6V001i93g1anMYFzzGvWUuRRFjb8VpvgRUcaEhG 1LTzO+GaZhArxkolPoKtpZqkAnfG3WYuKPHi5sn5x79kuFazAYtNRZPIHdNKuihtX8AXckSl E37aWPhwpWoUdQaAa2hmqj5tobW6lpSOaXIELU4wGFyW1RbLSrNT07NdPry9/LexBycnD7BM e5LW0vpaV3lqC7jPPfvR7V0uikK7RC7QrNN8G2vBLksHTaZEoqqG6+VwrkqsWi1wgiBwz6wd EAHloJiSCCyDtRHpQQFqhFahVyCcqMenpFAkE2mTQv6Mvy000ZrADwgvCHi3ADEhKawViK1i v4h3iOARy0VJJDhRqCK9Ugw3eZFE6pJKyKoTXXJBJI/RNfcQ8chmZ5SoPWEaRlnLo6yNxxYA mRUFhPI+CuMQCvv+79HXYnqavWaw2asX/Kby06zjSCdbx3IrOLPzvpxuYvR6gW/mzS1mp1WH 0wDOhqAp7LXobLPwidWstQjmtBnRtWp6npfLD+2T1+zzUpQX/HjDZn3Jhdy5C+hW2A+/OTAI teveNrIABBriXPJU7tUCS+TsSzg9ilYo2jgw/5g4pXkZS2DfkbacKv1hKU6XwpFiWM/uYPEQ C9UsnAycD+AlgcEAHmgpQT8JoTmlyjXAANNcHKmJ4JGJykoewjysjgAT4QOktYzysOZWSrcS K8PdLT7wrbTqkAezU0nnDUfuZpRXQSuD/1x2CuXxzWx+nMayoA7UqiPj+fBR/wIsSnBRdx51 yl4MZ7uNOCX4mSJKD9eTk6N/to/+fPzzvTRponmCdexwQvXwjGbkyOFr7b0HRY3G5m10i7qW S12NB/ndP/3L6CFHKL2kTkeb9B9ub31Js+vd9/v3FrhK8lNPPYZRj1DmPAcmKT3QBB3GnUa8 0QiUEfYYYLMBtuj26vA1OtD9l+6yj2rqvOP4fZ7n5t685yY3uZeQQIJAQhIJIWEQQEg6ESFA ILxIBIMvQzfUuqoMIlTLZq2CrB4Vnc5uPZStsDfP2Wo3u7nj1qp1Hl/mus6z0+lOzyjWdfG0 Z6fr/iiXPTchyjxbDickN/88v+f7+35/n58MxCE4RIDORjBYB9bUgcFi8AManKLBHnqUhgMU 2B0CvSHQEQKh8wsfBmW9zn4n7HACp/gt2q3YphhWIAVDeygiFPJs/F6sWSoCcyRcFwZhT78T PKMBDKepcTq5QHONFCugqKnxcLjZa4zN3Ksb+j3AGVJ4ajjCFpYxbWUmSNMMbm1fUcDnE+9c bOv5WeYvifKqolgGM6vD/3XlOixGBiaL2fnY7MP0I8If88fEv5Qmojjpz4svoEcUolwA6/L4 A0x2fLqzDaJDWM5XmiY529LfkijNijuet0z3X47gS7CLqPtXV46p1OdYZejwqmMK9jWNatXY RbkR9762Rmtgr62kIFLa6xoRbWAb9fgZLwVogskDiHrqsk6KHa8LsQYkR8NSYd0x4Z7JdBYM nBcmTKajIBe8mN0KQq06itREhDciPmHzIUDxfW/923ig8qNKDZ5GgfnAlzmvMLy8lUQHwPGS VlAbwc+VIKtZuCKSoGvhPulF7+Nc9RONwZxlat5hd0BHhI4Rk+RURWlxbTEsbs+YKSdi+VRh p1VkZLnVTH+hU61XKOSY7a8nAjf8icAHWBdMJMLsXCLm9abwHt8bz4kRssi+S1cRfvGWOPTk TuJFdiMAZV81sXhJ9FT6mpvfPLDvuQN/Pr1Lm4cQxWlNodaF+qZ4vKWpqSX+teYQGiXVH7wq F+rVWapxu8dYcGbi8r2j39qqt6F9Gp3QMhxd39M1tGdtbP1aXLF94T56HT0gsgknsS5YXkrV UtAO89da+ix7LMjSzhBTy8n89ij/FT7OI37GZe8nLf0jEECoXxY10SN4CZNG9QocBnuvxDIW IeVdcSbHMKQIyWWgXIQxfAMSLlVUmTcbpAKAeMxiYrxiJBFR7PWga/43qvaWdd99nmGkklrm +NyHwj+eP3ztwr7hh/tb1x3Jm7hZAY0hI+OKVlduUanIgxJK+xIw3L95+uWxF/a3jUysM2RL Ra/XLgjoluRF7PmyoEYeqZwKeFxsZFm3ebracx4vl0qPJlpCO2J5hMSI9fMFZgOJG/6kq1Zc ZoTk8ppULL2IJcXRLj7T4kmQFjFtDn4pkHPolsGyz2Kk6R+WrV1vsDxr4VVQA5XaDYZ2VqWR +iKbnr6w2ofI3HyY43mz2P2ronNllcXzZ7OgCfxtAIwMPlCSWpLSsD3CwR4euKqqnmn9meXr lqAg9usaAoKtEgchJ/KJkqDFPhVU412kWx0xEj1k0GiOmLuN0zbperghm9KL7SmkYOmPCQav Gw/FvkztEdimaHH2Ydc/xsdFHNg6ethV4PdHaJbSvWWgeYOugWUbWC354+HhsrxltcIvm4Tf heuFu3UGxypgqA0Df1grl+MT9i58TlZJjuJpVE0MB+v2VoG+KtBVBVZ7gUKl6oISPYQS6JeU tBNTwZYgcAb9toitm/Enjx7wdyz3wMp+lUTBMFxpp4fOi2UDmksrhZutvNyXKGfuJuuavzTr uoRdl7ikLV/co9IjCDC0Xlf8aOhogOGRhDANQakE0+p9pemexGIbUjas+uRq7xdzVuuKNitv 2DnrXivHsjkr1YV5nFouy/DMnJro2fLJG2M/iezub90CzwqfR33CpxoJym45rUPgMws21Y4h MDekg3hwU5KM0j+VCoJBb/9GY9vFI+dPaJaXid26Cb/14smUSdiDvHkqCUXdKBJUYxTuVk+b WEImqpjUcH4uKSANtf9PtS8BTspc1JEGg65Oh7lNJ9mmEsaFTweF/AGeHwDvDW4HP92mT7Ja APvkDnqHqCA8wUx5xD+1wjVpiORNWqcr9YXaaDFtc1ASU/LefYHE3d8uzp3/YZDF/EpbRDxU 0iLVIBl0S92hQ3f0OftzdBTMKdjuXdvDWkesBkkhUtF3JBSU6Eo6+jZdWIXdoedgVvFVb8HL BbuK/P5K9/yMEfLNYEXLu+dkpJwEuUx1wFEVfLrlNcuIdaXwLyKZbA/Qx+ivhAbvnPXBYqaN yMlok85YZXoQ0o/poR/zZWenclAJlTRlBqvMB8ywzAzMnVEyTkISJ5qIMDtT72KcM/cSqSBf Gtz0E3mNPh4dv/X78dHRb966OT72TkM4Hm9uaGwZGGxuAPdvT5w+dfz27eMnTx77w9Ca7q7O oXg0FouKpw0Jb5Nh9B5RiJOqIWjuc4MKd8gN3e19WJypQKlNHsmc5KarvVGbOHTUNidtjZkp jbqiUyqe9UYigA2BR09SmMs4ulIAlj6vXdwAkT519LQki1rwjzLryWrI8MgLbz8bczopCAD/ bTNPZkO5rX6TUitBkKJl40euHNr/94bmgf5QTW3T4K5wHXj/2onvNNkLkIraKsxZScSPQGLk o5tKUoGgTLeiwC6VkvIjZ05ciXdv7O2KD3Vt3NwjMtmCAF9B14kioiLIEsW23MmgQhPRdCsi WZPGaY9NzGqFje50U7kxSyrL5gKJ66mknnXNXmaupItNVpBaaZ9oQVxlrjc1gZIFw1c0SGvo 4PblGmQ8jmle4oaq/JXbpYxcBZHDUVhkrwqjH+3o4mWrXYd2+Gf9JmiMgNrWz05KSaWElOoH YGamSaUUvVu48E9YgRVcTuwPRqddv3BBo8lhgk4emHiQDwEPQY0LbHENuGCHC1TyDTzMYduI KbfGDYrcC274czv4vh3Y2xTGmUKZ0WiE9Szws4AljHaSzI1m0dooSRQlcOqJrC225N5LGVjk 2E5sw72XUjy3E6RRLt2nycJ5Lte7lK9T8zclNM/BisHtZ1ZItQqdKsMCft12UN+2c8tLalU+ G3yqKRK3toKSE12tSOrgogYViRDqL3OHtKt3n2xvyDykViCZ1PAf9qs2tqkqDL/n3n7cfq23 XXd327Vb2Uc/1nbt2m7sy3atbl0ZDLovhqPAYiYQlmXyDQkiREmIP5QMDIQ/TDDTxGiJwWDA D0IXY0BJEH5oJDEREjSZMQYTf9jN9/beFqIY8If+4jw597w9Obfted73nPd5o76Gpyv7BB6Y xXvUtJyBbhjqbNTY3Y7R9gE9NOojA9pR+6itzK9fqV+vp/Wziea0oXXYU5uurvAoutLxEUVa jZF8J3c7GvruDpsL3hZExNXs7X33+Hn2VhZT1lxjoKUu/8dFASW6VjqOS4NFPSrdL+1E1KSF SMiHhSS1qGmZnBBKpu/P/MS462rLZLTNzDfIraoPynUVvxiUlNX1pouRyVm+t2q3TXuec/hL jDKl0nljiAwNuWkiX2Gz83JCOV1n3MkqutSb8dq02iadPqIv1bQmXjo2XB2uEBjZgDlQRmcg COMfocS82xkx1ZNZB9npIKsd5EIp0TXgNe/EvEAT+nQYwoQNrwpPhenKmdqUeaZsNhQwK1wj PTqiY3Vqg3AJX21Jz0dDyA+yJfgfq9kcRkDe9S2FKrZ4GIRAMIhZXshxBceLB8EQRppkMq2q lLmslavk6tnTtxLeOhVv224z6UoIbfYcjQ6P0nL3Wzb61eTCN8swzydNCuoN1ZFTzxFyd8ZJ cc7RMVdHz/sdE5FYRy+Za8Rdhxb/kJ+hL0I//Ng5vX+QbBgk0cGVgxQ7SEa4TRyV5EhLGakr IYc1JzSUR0N4GYFBog4oqFgsQFEpSC3riiYIJNgElQiaeDbi9fKRChSc2kAk0vZUKtAEQTZ4 KkgHLa4aR8rC81bL2wNangq4uiJK0/KWSkU2Rs7FyM4YiQ2p1Vkv2eE956W8Q2z+BgmF8PSE /MIREqsp5HMu5Gdz2RDWTtkQjn6heEobUGcIFZRQUqWD2dxcyFCssyTS75+6grSni9b9Y8cV i6QC+/mALcap8YFJqSCQnymz7j5YwfQ0MlXXWtvWWZi2dqbqxV3mcrXcVLm7slSmVh010rT+ oFHLGD9lFdqMjtbvV6u0psqdlZycob68GIjP3VRSFENWrVt/FA3l15/HOzLTzZysilvDvdcT /YLnPu4KzFYfWsJZ7AfsZ5cu5PhLseYDjteq9DKTE71Zs3CBztDvYl30emfcQZOKetKCqoIy G0nCSII+fwrcRmLEOpYTagM43eZvI2wbcVbXpXiO45kZDZZNlM9J2w/Vk/p8Dqsf5uxGozJs V+iGlXqIzkezxtZ9SCs/35IW3XHjjkF0SDrN/hz0pwXaW7G0zQWzoq6TKgsQmG4gAmsoNAo3 XbMkhiTOkV3jg+TSGbVuweN1fWvRNzVNNRmTR04YSygexR2rYBRf8YYPFYyWRT4qqfPv1Phy SXet5pCOs2u2myrOXw67TzpOODmmzDpl3dvhWLhO3DXBl20vWM0qENqSh2IvXBdAKNJO1iEu UDx1kjpJrygi+1fI1uRxrwB5QoSCKmJahPLU38GYJRzO43dVEvG92oY4pL6lSSM+0ca1V3Td uu4SH2LuCZ7gnwCCViX5+DYBLVjEgl0Bj2y0NGpQLOlZA5SayqBcmLAWVtQBuITRh71RMJqx txW/4BnsPQC9y6FvJaT6B2BoePUIPAtrH/3b/0uTwWf4rAc7Wmp8uqEBM34YWiEOXbAM+mAA VsMYjMNmmIAp2AG7YM/iIr5jx317IfDQtZtgC0zCVnHt4g+PB8lDj9voR65g4HnpO+m804i0 43KEaCvQahAiQqbCGQfuQrQpKMEdiDaNK/ZItgztWclWoH2zp6+nNxn3xMe3TmyeHBib3NYd 9/WPb/x30xggfdh7IYlEerCPI3UTSPgkEjqGz20oS+MoScZhIzpgAue2PuY7Pumt/3K1yCzZ AgdBCceQIwpYrIj6ce64fEf+vBFxzbVLhoX1+o7fwMLk6c+88utSYTx7ZfvaxeMLG5jjSg9+ FPjPtz8HAJiuaqMKZW5kc3RyZWFtDWVuZG9iag0xNDIgMCBvYmoNPDwgDS9TIC9VUkkgDS9V UkkgKGh0dHA6Ly93d3cuc3ByaW5nZXIuZGUvY29tL2xuY3MvaW5kZXguaHRtbCkNPj4gDWVu ZG9iag0xNDMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNzk2MiAv TGVuZ3RoMSAzMjI3MiA+PiANc3RyZWFtDQpIiVxVCVBV1xn+/nPufQ9RcEEE94cPEAWCCypu AeSBiIrYmoioIwgoLihRxj0uqImiNqQaosG0GtGmIVOedUOtS9RGm+AWq3XUUVxi3Yi2ExNj 5N1+YKdJev+5M2f5z3++f/sOBIAPlkIjbcSvo3pMHJpeBry5iqup2flZBdpWFQ4saALI7uw5 hY4s33t3uHcN8PKaVDA5/19+zwo55pqZPHn6/EkrB67iPNoFdC/Ky83KORX+ww7au8wzvfO4 4Dek+XbAN4Lz4Lz8wnkVRuQUztOAlv2mz8zOQm2LB0DuKc5d+VnzCny6yzqez6O+Y0ZWfu6y iTOJeGEN8bxdMHN2IXHzW3i0fr9gVm7BqGfH6oBOa4Hme8zfoKM5rOFvpzegLWDd5E+s1j1P ivXCnAanZ6pVo/1oLfjl/98vBCsQjHsoxRGMx5dKI1FeQToMCURrKOmLodIMATDFG2FwYijS 4I8UfC0+qER3PJAkLJMQjMBmdEIqWiEe72KLDLbuYxkuyBRU8PTHEofOGCbJ1g2MRJq1j3cA /fE+PhBfdOSOtzit67QwG2/jAC7BQgY2mltoJQ2/wgxrH8bhvGTIWKsdhmAGFmMjtuIQ7sgq OWqYViZ6YSJmiV38JEwXWR8jxrzcaI91wjqHZtTfSquPVLiRZH2DONwzxMpjRP3QkzIDH2Ev rkmg9NIJ8EU07xqPRajUYcSYjNX07YAslErta5XTmz7IxhLUyDw5qoLMy+YTawFa0L9oIi1G OT7DcTyktSQZpfM9sVYqBF4IRyJvWoG38CdG7hjlhDSVIBlCy5/JdbmpZ+i7tPwH1OI7PJMw mSKLVawqMnvULbP2IJQextHGEIzGdHwqoRInY3l2s5qrFqsleq++ZoQZj60Y6zhsiKJuET6h X2dwAf9gvpJkuFxSi/Uu8y1rIfFGIY9erMB27MdTMaWRNJGW4pCe0oeeLZSjclO1V06Vrifq SnOtNd9ahyDWynjk8uRULMdK7MNZ3MJD1EobnoziyVhJk3XyjpxQZ/VoPU6XGnFGqVFhHDNe mM3NY57znhpGvd5ONwynjMckLGCsqyjHcUW0tJUOtDRQUmhpgkySRVIi78k22SF75aSck/vy WH5QgWqt2qAOqr+qs+qcbq+7apf+va42gowrxo/2rLr2niOex1ZjK9zqaZVYm62rVm1DFtqx 4mORwOqaRi5YgRK8hw8Z8904jYusuxsNcgdPmIMfxcZqak1EncQpnSWC3o2WdJkrxbJeyuVz uSl35IWCaqI6Ubqq3ipFjVNF6pF6ob21U8frefp9/ZV+bsw3e1AqzD3mE9sde4hX9Yuyuuse eKZ4Sj1lVi/Woo2V58eei8Yg1lwKs5yDNyizMAdzGaMFjPhmVk4l/oyDOIVqxv4srpKh6vHW y31m4lvUwSOK+TTFi/ISezdmJoHVkim5zO1LWShFslo2Usrkd7KV8T0vX8kFuSG35Sl9gopU 8WowPUpTY9V4ygSVrZapNWo35Yy6pK6qW+q5bqab6466s07Uk/UqXazderf+u75ohBrxRrIx zThpnKfnyeYQc4KZba4xt5rbzGPmF+Yd07Ktt31kq7Lds3vbe9vT7KPsq+1/tB+0X7NbXp1Z T8OJvgt++tbLWCNKlYilquj3YVWov1QbpOJnGjCLiSAHE1SVPqQ+XFSib+lPVRFguBq2B5LF qvEXVJsXDH/zHk6qNviGfLhBZ6nDapMKlN66v7HSqCbrzCfObeqGsqtKajxkNibgNWmNfxuv 4zHjf9YsZkyT1HWpUJ+rFFbyZZSrg9iELciVPkSXgz14jndlv3bIXtbdEpzDI9T8hNaIqhuk Ym2Bao6tHzO0X0ZaJ1UX6yG7/qasxFX9nLX/uqRKFHbgNrN+UaKlo+Ex2uI8ma8Dyli1/8Qu 9uAXRjA76Cn262hkGDXMeVTd3zwus1Avl+9UPNMZ0MDcI+rZmBy8kVxVz6O+qGQlkEUaOvoh TksnRvGC7Qo+wDs4oP0RorerpcrSpwwHfosaPYy3vkl+aifRtJQPvmqGw7rrKaeFqYhBjEyU DLi4k4wOVj6R7yAXxVnjrE3mGDMcZ2SY+OMI2SuQUSw1G3lqqbmbfXgVybIGuzw5OMp3JVBC pAerqdacY5aYn5i7zcPmaVt3zGPXljGLt/AtXw2HZDMWD/A9a30QuyeC/RNPFMl8w6arMfoQ EqQNCsiBYeTtQYxBBjM5m1aKsJb9tJ1vyBk8kWYyDodxmZ0TwD7P5v1etDMUrzHrs7GD7Lhc dnElBx3QlXF6Lr4Sowp5Xz3PlpJnjxLTNdwlc1gNuCKkv7iYvWx8X9/LvKE30mQnkqy9rIRU uHQ1vkYwX9dB7NFynstkbfiiPfqat0UhwpNqxagp+pC04mvoy6oaxZd9oLxBFE3pRx38ZQR6 eQajL9/YpUgzt8fFxcW+OnBA/359Y/r0iu7Zo3u3qFciI8K7dgnrHBoS7OwU5OjYoX27tm1a Bwa08m/p16J5s6a+Pk0aezfysttMQytBRKIzKdPhDs10G6HO5OTI+rkziwtZP1vIdDu4lPRL Hbcjs0HN8UvNOGpO+j/NuJeacf/TlGaOARgQGeFIdDrcp11OR5VkjEzneJ3LOcbhrm0YD28Y lzSMfTgOCuIBR2JgnsvhlkxHojtpTl5xYqaL5nY29k5wJuR6R0Zgp3djDhtz5A5wFuyUgFel YaACEvvtVPDyISh3G6cr0d3a6apH4NYhiVk57rSR6YmutkFBYyL/w3q1B0dVXvFzn7uhC9kE wyMJssslCcluAHmYVymBJAtJeCUE3KW03TxAIEOBZqClVIwWBC6hVpwqKoOMU/sIrVzQ0dih TBw72v7B9I9OGKuVOBU7oIDa0U6nHXP7O9/eu+wuaaGdZvLL+c53vsf5zvf7zrkJW1Jdp9Fh kbHYyg6JIVQntrH0Ossjtgls5tPQ4cCZ8KDZN+CnjnjI12V0ta+PWkp7jPfICWHfemvidy9P uqli8dy66IFUa4FiNkzaHGDVNA8ErJMt0VRrkP/GYlgDc+WiSNyMYOs+BLF5dQC7yftjUUva jy0DfBI+VeJ8G4wG7olvCVhZxmJjk7kljqvJNy1q3R08m59f+6r9HuU3BMy2qBG0FhYYsfb6 wjN3kdm6+8XJtYHJ6Zby8Bl/TiKwZ8ZlOw3f2NTGhqRNtMRwbjW3JiMrsUdGIwhhBToD8CRq 4EyV/GdDJZmdlRiGn5iEWVYXbmSzlVUXN/3V3M/zLa3IbwTMzwkMMK5fS+9pd3r0Iv/nxE3m SZJqsLttKxSyysqYIp463Cl8/IrQ55eHdw3Izxrb/QEIhI9WIbbtsepZCH8wyBd8eKCWOqBY vS3RhB6gjoKzVDsrFLPkOFsGXUveGrb0upbk9LgBJr9E/P9JnuUtTv5m+yeMb9hUbUkT/oN5 Q8LevNpoblkXDTSYcSe2zW1pWsJembQ5LWt8XVQpkJ2WXKAIK0i5PjmYlajPUovwqwtSdw14 vGCl6JECEcsfX5r4GxsTDN7hpAH7E54lxM1pjptWdShdr0nT09zzmQocVovl5rZ1pjkmzRZB BjLNiBGImHGzfcDu7TACfsN8FV8rJeb2hrh7owP2rw4XWJG+GA6xSaou52B7giMNdJ+f/nlo pNXfIMKf+p0xVq+SCrklu+in0+oOslSiGcBKL9EP9H5qlauoT2bZT5PR/y31UZqB8Yuhz4Fc B7uM/ibgADAHCAJzgQZgmSOXAgt5D+AY1ijldYTEP42eHbRee5P82loKQbYABWiXqu/TTL2K VgMhZYoYOwHtmbAVe45QKcZNgb4K4+axhF6s9tAW2JvQns1r4hy5kOOAXPQHsf9F9hmyTv0J Pa6SfR3tYqy9HnNDyhFaAbkSciX6F6N/OfQI5pTJ/fabaNejHUJslnG/OHsPlQArMKcZfraI 9XpoIWzjsW8O5CwgB/Y8pYSel16nZyG/qpaST5wbY8S51948E+QS4dMoYB/Zv1SwT3KV/Snw LvC+41vjLWC/UkHUqcylGshewOD15Qs4cytJsFdr/6AahpfsL3Cuy8AEtYuyoV+Fny3aSzSf dWCcAH8XHodPn9EK2EL6EzQT/fPke8CxjTRT/jFV6kWUhfOtw9h6oEdwj7nQRW24DxtyrPoB 5cM2HSjGHZ524uTn2EDn+8X57I/hxzWMaQFWM7cEv7rIj/055nz3OdLaEXDTvgrb14Bv4Fw1 wL2wfxMcjok5mI91axweliYlwNxLwQz2wQXfk4sERygPuMtBCfA6sA94DNgObOQxWLcM45kn 3VizAfo05gdzA2vxPTQ53MkBv0sFxxJv5mnEsQmYBGTreFsOxmJsHr8X5qx4L3gLzEfmFnPG lcxvwftT0it8Tr7zFFmgXaLV7IM4O7iVIouZZyyVQSoTsoxmMGeZb64UbzLhfzG/CVcm/cH7 5DfCUg1REb9V5mJS4p1yLJJyIpVizeX6c/D923SfWkJNSjctUtdRo2Ih/4zwfvZ1dYhekH9L Ic+g4AzOSE9lSL7nY54haYs2SC8jlkXqBXoK0lCH5GnqkKRpp+yr2il5bwJuO1VmQhpM2Fgy Um3/bf//Avmidoo2ov2hNoS3M0RHcVbyfCTNBgKuRP9ZoBco84akY95uacCzBu+J6DNgm1qL t15LFeogckIe1SJORehfo/8InOumEqz9hVxLb6D9FnJfhUJ4n9hLvoh8AfD6kMtTeJTGuVG4 JKTL11FkyOGSkMxn5LW3HfmOI29AhsHJEq4NnJ+5PnCOBpYm+erysoTCkM0uPzN56vBzhcPP W3l5U86FrHNqC+fuXH6n2MvjvNn1nB85x3GO5DzHOc4dnymT8/vpSZzhLZGHL2Bu4l1PBUJA GPbdTh5BHrb3iXzYZe/0ROydarm9U6+yD+ofQW6yd8l77K3JmqrSPU4uC7q1VNTRc5Tl1lGt m3qcnMZ1d55Wg9qUqKOifuoL4McmUd/C0CfwOxRv8DDlynsQ1xIao1bQRuU8KcoK1E30q+XI yWzbQdOVG1SoHkKue9y+pjxGC0TdXEoblDhV8VzlLGVrD1FQ+yNq2R77E7Ee1ytI7mP/9Y20 iHOBtlXU3i1OPg7z3Xt18nlVKhFjLiA3DVMun0XEoImmiTjw3Ifw9YO1PFdpqlol4hBgiDl/ Ix/Hg2OUFotEbW4Saw6LfDZOrD2MPX9Haxn6VGryvIOcyXttpXiWzHnRvuLU7EbU00blOXwH +YgE/y+QT6mgAtTKiIMl6gOIeQ/GHne+K1gi74t6fwO5ChzRDlGr+J5g2/fx3fMaLWGo/TRd X4j8WIPcv5MK9SmIURsZgtfLEnujv1F8n3Cd4u8Efi8LyKfHMR/vQvjA9YbXLhWxbQRHF3nH oLZ0ULbcL0ngXqH49uvHvfdL/B31aAp+6PQVJqQUlK+I+sq2G/J5+bR83u4W9b6CwsovUB8/ Ro5/BXyYTAvkTqqUTapUs/Bt9mW0v0eVys+Bo4jBHntYnYgcXo/+Z4ADmPcHxDMbtk8x5mfg wT7MvRvtd6lOeZkqtYehF4Grb0AOA3/HvC9Rn/IC9el+2i932kfF+ow9I39l8Ho8D5jlSvbV xag+/5R8o/pbf9PPpI+j+Mdr8LpiHo+psIeJ7D8BRQk50iIfoVPASfltzB2kvdITRBLuSfoA OO7gl7RUyDNAC+5wr3QQWAWo6l46AVkO+SEwBBwHzgE31PmIxRF6DfJFHf8qMOTzFGUJ+/PA r4FLri0VvNdo/alQ/0JpujaHHmTIYXwThunW8Sdonvod5NrZ+JYElF20iqGPo20eL22T/4z+ tZiXoWsz6El1G919O39uB+n3NFvEMIHaOznjnYK/0bg+/7/Wu1Pgfh8E7hfxP0kzBYeuIP4e ypLO0del92iRcpyWMRw9LuJ5gma794T+g6I/4/7AlXuVVqrN7Ef7YYarZ97r7XSsezoVLg9c eObQIwz1EsYDmbq3lx5h6MyxsNAfYLh6ct9/hzaahzhFIElwLENHDtnJkLdDP0bM862MpN6G 76q2BD8ZiO1mBmJIDPTdz0DsiIGx+xgpcY1yXLEnzyX3flyeZ94P+6X+BuMu0zS08zNlkt9O vkjjfEuC7//ivlpjozrO6DyWtdfr613bPG1gNrvLZrlgdnNtHrEa+y6PhKZZMBVq1YZiN4q2 ykPYSfoQlGQXqiqtFAWrVCJ2VOzEaaEhCvbcFJY4DitVJS9FdqNKNo9iWkBJCIld2oTysOmZ WUNaBEortX+q1Tnnm5lvvvlm7ty9M9fK6r/k9HU+n78Tn78beFduFvP/CXh33gbeAA79r8ei +H9Q/xF+9T+hzqgbcFZdj/fiXVJPyFiakEsHCbmMXTF2GToA7cQ3ogL6GyCGOnwdxpZBpwO/ R9t5fEdwZB9PuSrIjolzJdrGV8PvaSCbjzM+FXYV4n8EdAE/Rf1pIAUEAOV39wQeRfuxfN/x H0B/gvJF6PeBd1CHHX35cdgvAetgfwL8HdgJxPLxLsHv0n51HrnBPfS/qze5f/y7mr9vEPOq Xn+H+I90wxfr9XeOq8//i/TqXeIGqtdh4t70wT/dfW52x/kXxf7x5H+EHLiSc3FnxQrLzkLn LdAqo3Mt3SArZlp9Ls7ayK1EoILKqZW6hcilSyeMRUvyhmNWWcMJddAfAZiLuCiJ5ns50QXW 6EGUKR8nPkpVLb/s+CdjND7m+MotO+HnF/AluEAY6eY9JAcw0sw/JWmAwX2vrLpNDcT3OkUl lh/+IyQAZABOOsFUl21A+Y845VNV+Pelr1T3G5bxmrzh+KdbDYnJ/BjyeYu/R0JE8D9DZ0Pf gM6CHuJvEkPn+YLj81sZjNcF9y6+kcxF8y/5JmJBd/MnSKV2OyxL8uMcllHTShTxXXyzdnmM P0JqoA/zh6QlAr38BWRq87OOx6vyOyv9U6w+/iEuYJPhdQpe04Svj28gMUDNJOt4DKs1Ucyz mGYWyyKQIyUdmm3+nkQgjPdrniFT0dbPt5Ap0Bf5VjlF5Hr5ee32mYqC8Z6XhdVKHKPEyiU8 uEtQrPg5rPg5PdrfnMgSiyQi/CkSBxgW9SSsk7D8uLjEgQagGUgDHQD+f/jHaPkYPjF+nLTw o6QV6IDtQsiNEit4QBvhqHWAP843YyX8vVg7itonHE+JymyzLCvXbpud4hKrvo8P4lUdREyb DznTplvNvfxpPZVWZ3ql6vAH6SnG0v0w/yzQcZN6Bn08w7fqldiiV6D7dRQp8fEf6c5XnOJS K42nvxbFZvA2YAAYAVxwW4s5rCWNAId7g1Pis3y9/Ju685dlSbXo4ysx9ZV6tVbKKUGd810O jDW9/CvYJKv5Knm/QIJrJDqr1lXOklor3stX6QmvkiKUr5blM7Rxp/TkN88yp6hUDbdcO86T hSW6et7Ee8dNZ/I0S2Az1uopVavvC66eASAOZFCjVtxy/GXY4vdzS6dtkSagE+gGXHiQFtwt PEiLnNA1Pr4Ic1qED8siTLsFPAow1N9G6oFtwEHgBDBJ1zYBDPVxjNAEbgUYIsZQ9oNtoAnI AJ1ADhgFCkg/r8I4VfCOgzNANzAMuPBA5iOP+Wgr4wEyhi+nwBm0za6laZKmaZbmaVd6Utqf Li20F86Zb9kPKlqgKApa3ORp8WQ8PO6xPQ0e7vcEPCx7JScLaqshdpm7tvpI8kzyYpKXLW51 txaw/kQxLSXDwAjAST/1o+RHyW8/yfvrhutG6nh/cjg5kuT9x4ePjxzn/VXDVSNV3E5W1lqL G2kzTdNt1CVojNbT1dTVyJt5mm/jLsFjvB57wdXkbfFmvDzutb0NXu73Brys1dvp7fbmvAPe Sd3unHvAfcI96p7U4G5yt7gz7lZ3p9stCmIF9QW22zWaWMaOYlE7wd0AIxlwq7b8uiUHHtDl Vl1uArfosg1u0FYIHFcWENJXT4o4R9DjiPZT5RA4rspACH/hh1HXAm4FGDtszwzGw3aY+cOB MCNhOhqmA+ETYdYdzoVZLlHLhnSWQ8hySGc5hJ5DeuwhxIUFhJDtoPYbhN+g9huEn7JuVNcE btGWDW7QVggcVxYblKHFvsQM9iwiNoI7gGGAkxi4HmjWJR9YAIw9C7ZZu3PrfCuTZe0ygj9D SDAvs/MyU4szo8JqTPhYO8K2I2y7DtSOQO0IjdKVHGuTy5Vvm7wjL7XVw4nb8blU6bThptOG dFeDO7QVA9dra6/28V0rd4NPaKsF3HmtX6O2lJ8ArvZ3sXb82mD52CbUbrK9jEzFeY+UlRaW Zdmr8oEykWWvyKgf4uRFKkmUM45nYNBPNL+suUPzzzV/XbPP9oaMCyHjdyFjV8hIFLG7SRjV o5o/1PygXRI2Pggbh8JGV9h4Pmz00pMkiIZb7IqgcTpo/DFo7A8aLwaN7UFjXdBYEzTuCapQ URIgBpulmK7XPNOeFjAuB4w/BYx3AsabAeO5gPGNgFEbgDs9h4+ngduI4h2aF+6vMUSNMavG eJVhbei90kc8vYzRe4nBi6RZJ7Lco4XdIpNzIDNlMgGplMmvQipk8lFIuUxuFwkP89EenEwE K6E9hUqLpbkFzd68FEpzPWSSNG8XWTouzRDkkkzNglyUqdmQz2SqBvKpktfoX0mKIQz9i0zt RHh6hkRVWPo+ibA90KxM1sN7f350+gqpo3NQLYmtsqAvSRPJ0d3SjEJ2STMM+VVeuqQpIM/J 1ALITpnaDvmFTJ2CtMvowypeG4nqOM+QiNbHZLISzY/IpIrQIpMxSLNMLoQ8JOvehTwg606p rt+hPRS7m6aIqTP9tkyZaG6cmMi3SFQ3ryMLdeS7ZFItyZ0qSMKgKyYmspwuUwc8upT26Ci2 NONwq5NmBHJHfuW+JFPzIEtkFGtMF8voTqzcookB5qrn8xoNIw0VKCTNPXASMjUXMlumVkAq VU8kVT4xahmp00mVSlN5+aUZEK9TL0npiEUkQtv3iTHEvVSXpV+T4qKdLaRSnI9C9omzyfvE R8ksjrfiDF7jPfvEMFyP18G0veKYeUocTQXF2yY87ErxlrlA/DayUWSjvcJJzhY9SKw7dZ/Y m9IRXo6gmxS7o1lG0bszdY94xpwndkSyKoefwflJNQYC/djcKLZGtojvYSt8N/kP4qs1po3s Ct87Y8+Mx8YePzGYwcbGg8MYQgBDIsA2ftAlrkmANLEpToAsBEKUhvDYJupuQdukZaM01bbq blbb7p9uk1ZKY5fNrkmyCkqirap0tfxopPZPxErtVpWK1KqUqt0Eeu6YhqyUX/3Ta99z7z3n u3Me9zFn5p2T1aLzlO+w87iPKCp2jlX3OEfBkWMwZ3jkmHOw+vvOgYBi8eHqj529AcWHxIji UWdQEbww0uPsAAtAECICsKAF9mU9TK0N3CIxQjU4uvCx8yvNtyl4G+NZqKfDteyH7CvsEHuA jcB7p4r1shVsOWvhTJzA6Tkdx3Mcx3AqjuLga5ay5DdXwjKCG8zCCKRhVISqlL5AEQqE5CYU 5ii0F2XNdIJK9EayzXIiz272ZHfLiSy7/6upHMbfTeNEdukoSgy5suu9njzmu/uyak8EZ00J lDgQsQM4S30nj9GBVB5vkhnnHFlTNLWIMPafu+ggbce5i+k0ss2E7CFT0LinI/YcMrBF4zF5 u9hl+QsjMfvDRG8q+3Mxna0nnU0xncju6HX1pxapE9TxeGyRGidNOrWIR6kT8R7Cx6OxNMBa FBgKUuMAQ0nSAIzqR0ECA37/MzCcA3YsFwwWQPtwjoDg0OxTQH0FUPRZEH0BRxVQlL6ggH5c UFgNdoDCMGkApj6BqhWF1eoTCsxOYDlJgieNSASSq5cAkJPqFXH3tthXEF8riK8RcR7jbXlA KljrQ5KiQaJ8gJH/j2U48j9MwgttMydT8WFPfMATH4Y6kL0wM2rPzg65XLmTM0TgytLSwNDR UdIODmdnPMOx7ElPzJVrSz1HnCLiNk8sh1LxA6lcKjwc+2VbuC3uGYylF7rmdk98Qdf8U127 557zsDnysN1EV9fEc8QTRNxFdE0QXRNEV1e4S9GV6IngxP5UjkORdLS/0C5QWh5Oy4CjIh2x CaeCytFpqbC/4ripQvgq0srprM4TyRZBJaKa9pp2IoIjTUR6YBu2RPZXWiocN/HVLZEAbKMn gqbs8bEY/CehTE1NQ4EYT04WYm0vCKbkuCIHwBT0ppQCSOiTOqlwt+RTaHq7yHIBiyblaCqX TMbtYzEHJPMLJP+W05NIlgsKZRmBTvBaSfhtSsKvZWwND5N/TP4jSS8pmf4y1BUl01+CLH8Z 6gpk+uX0UnA5uBKkl5LLyRXAPlp+tPKIXqpZrlmpoZu3LCCq0hgs3P5Ny5PThC1jxVvFbxhO yZMycfm/MYCRTLgkKlAKfGWeDE+Rn86VtzuTBeG0MqXAnXy6f+FuhZsViBp+4AuLIu9R+B7D 5mkubEZq1T0a8azqHkYlHKO+R9G3cTvSYC8+iOyysN76pLVLWGtNPmlFIegLj4HsqqswVhi9 QOAeR49d9NLjsBp9jlyqJXKRRzYu4w9xAypGzWHjvyjMalT4LvqNqVPHqxJWyALCWtzgNGBD u/3aRdCxlll7sopCq2ur2Lhnz646nDEHmpoCjVWSx80yHrcUaGxqqLdZLczI1BjLsoxOlFsO vfilg2evbVz217/Ta9RwrLE/GHnx3NSlR8SCvs0/4Su4EWmR+z3UyWjpPDaHtS5NnYbSlOi+ Nm+Xu4THmSRRCuqURxfUYNQxOBSPDw7iRqWJx4eUF9Tmp1RIPQ7RawqL8AYJUbSFguSYxpjS 0tdRqRpfp/yq23HizWqXsE4e3Rpq/ba6Vn5ZuA86sAdToY3oLL6jHv/3jPo1RPJ6sPIxfRes LEb1i6gE9mCJydzIdCJW12nSGuhOjf+OFVtL7L/7hFi8lkmukWVYVayWn7Xb/KwPBxXDBwdj W77QdwcLvgw+Of2sV92bn6oPgVeVWFxEts3ZBQ3fWJYvtMxWWwRtOA0dXanG0WROlp63XSi9 5Jgv48aN46YzxjOmeeMV5mrRu8W/Kn7g4BkbkqK29rJZ27ni845vlX2gulXO75RGnS8xM0Uz jvPmmwa2WW80VYqojxIxzmMLBLSv4mdGk159XKT1x60afGSnERtLT0lYMnlPLuJ6RJyPpsIa A+/kKT5ZUrKW/HPGsVDoraa7hMx6JvkHJTCwgf4C+0iAzYSEX++qS/SeydVz0TPhSlsZU6ST ir2chtVQjEMqsvFexJQB0dr1XqQpVXsxnE04MdWyPDeHMxMoM4GVN4DRI8FWZFjGajHZGuqb mq0MxLqSCjSaKhvqixWW+lCV/69vfvO3u0L999+efThz+p/v/n7j+gcPcPrupXf6S1w7WfX4 RnX+/uszbyy+v/Hw8qn56ZfGf4E78ndx/1KwcmcD2REOOKUT6i9DK2NtuL90FgLvIUQgRCbk mHnUfsz71o68T33MOAaDN4xv2n5iZo7qWZeI3G7OJerdnrJag55yBxwOxJlqygyiU6TEIFfH 4v0sZl/2t90o7KcJONeZ1iQJroAkQaKkJLIIljoLbWmCkEKQ35eSdRasjFbTsKeF1VDrqiwX AnuYBHavRxZKTWajmWJ8VTuqqqtoZntEMTZrsdVuLbGqmEqvLEheXE2IpxRIlbmMEBl4stfq 9iJZaC2sgFxNytwcyuAMGTYESIibAsZGWAhPoAJibrJa9BTcDrTRYiMr0NxkFKqkKslR0xIy aGzRPTXUkb//4Mat/tfvvNb2ap9gdjRcSX29p33kBa/XZR2jvzHaWOWNdG/kP7n0tx8dKdWp Nj9/dEDiDaffgq8S9dtn/U44IbUIqX4K6+GHD9Ukq9Lwftqt3atVM2qGh2DRkkriJa2k20d3 8Pu0I/wMf57Xn93xvdobqhv8R6qP+M9Un/Hr6nWe17tEi9sjukSr2y11+/15yhc+XiVKBg5z 3TrdA43IQW7NdlPUA0Zky11ipdvDsaxE6fYVQb4n3fFib2m2FtciXGTQO/WUPigaID+nULC8 XCypsVj9vkrKh326oqJKi17cQxhe5PNWUlaupvY2plAFasMsnCUZhWANhVWhda31P2SXf2wT 5xnH73396/zzzhc7d/7ts3NOnEviJGcnOWyc42eBkhK2USjDDWxdYCBCnLWBgbpSNWyFbd0Y gsCCyoRGNH5MtF2bpbCNdoOWSdVA2x/JpK2L2ohOHaFMC4xpxNnznjMEmy2/9753Z1v3fp/n 83wfN6emclP6AumYZ6cKLIRELqcnFaxvsDf0m2TIqZsUe6fwP0cSCyRXisgNGrW0KnqyxEGV SkXxihmizEPKkavAdaxUr+9b5YjHK05vq+ZBrJlsfbbK77IT4Yy7kq6vbc+dNJZm/tCyd/vM 2nf3lDYRuSSvKyZ0l6Ur7dk/EGBAoyQkzi3QKEId0OpFrTXYbouGcCzmj4a4WCwQDaFY3B4N uWNxzo2hxfAzgUgAB/J2Gyn6wtJ4+4QNNdo0W6/tHZuxCwZs80VFcjEQCKUnRNQrviPiRlET u8S94muwMM/vh/wpFPtI7YJRzyId+CRYCZul/39yLylmgBB9Z/Cthx8YXyFzxg4bIT3ykOX5 /QGYg9KdwOvbwGsnFUZnNWULu6XiqG2MG/ON+8eDY6FPOKtFsIR5LDh4Px+sZqsrqj01fluY YIMng3cO6sxDcCdHmkD+GUJ9chciAzeIjuBj5mP0EcegcxgPO943vW99LzSGxpxObLTQZqvZ xiMe8w7eWRmydvu6g7tMOx39vv7QIDMijITGArdp+5MuV4YyVGYsVs7ui/Ss06nTAbTxUQEW ROjQDMjgT0XbozjKcBEOc8AcEnlFwh6NeeQGrmOqfImASK+BhEGrCYNyKMxKoYQnYZVMCZ9f 8GMz4+Qk2KeAhLw0zHgzzNwOl4ScQQwjqrBVSpTfCIMs5+Bdxo7umID9VLEA5vBN2sypptHZ ac3OqVjgVAd88OjsX99wq47R2ZtwMJGVU7XC6nWnSv3XdD2FHrQPxQKqotysBYvR6oSbpUwQ Bm62jCwuwwJFeCDO4cGrpUOlH1x9FQ2htgubVu1ec2zzknVfembI1OUo9ZR+XypdLt2/dxk5 UQM6tPJXx0t/Kp0afrZZQ76P4Jy9h1SPNNDqFGSCn6qirr1NRWfvveFQo6Oz97QNdnVVAg0K d/m70X/FjLV0kEKOaMgSi6FoyByLO0muxAMNHNUQDJorOAArzYpI/HBj5d7KE5WGygMpqMYB BkUQRvVOysE6cKdjowM7npcSj7DlielC31xRIUV5qqCnBQAEGAO7YWBNObCPIFk4Evf4Bd7H Y3PcI6ZQxA9DzFuVQlE+nKIovRDMlQCy0NMGsgoYU06pjBglnsdiNrhJAc6kgSrJwJINM6ue XhQILC4ANatKP/7+pk9E9+6BgZdwd+nlHjUmSfG2HkMvmV0/PvCLmICPzozgg0cHv0Mc0dbZ CaMIGaYipKlC49rkTtFgdiErY5HNjQLDy/WMzCbdqVhUrqprqW2RNyf3J/fXnk6P1l5IV6gP TM1yzUutZ1oiLbjldFMoFF4fDUWiERQZRbu0peH1lJ/1Y/9pb1Jm6ARjZ5igPcgY+5n+5BBz yv6W/TJjlpOM3Rg3ZZoM8YzXugp1oR3oBfQ9ZEJry4V6FFoRF+fPanZnOsvQERrTcOrNSFOD b94oUl+fy7XJKcgnGfxoYbJQNki8CrYGkK6qFHuzMD1VmDNLZK5PmxqJ8SmgirLr8Xr4yvLb 6zGCw6zWrVDcrVTObXuiugHrDp3Xz7Qafm1Phj4e6N7pDWmpM7c+/7nSPz/Q+p5sjPjncZJU 9++DvfuULQNvn1x7662F+dS3Av6wE6xR7sy17Y/Vx1MN4hee27Llm2fu+Ks8NUlMjX+8e3Xj +tULvrj31a6Tk6xjQXQ+ifUNs/8wfGj4DdVE5XBW85pZVjVGWbVZyy1OfztzyDKUMeQJwjc9 nhlR0Tcsw/Xncj+vf69+XByrH8/cqLdmLEssKypW8Msz6/hu+jA1lDmFRtAI7VAsaG/+mPGH 9cebjFS+M//lyo35Pv6I9zw6Ne8Smsjb6MrO/LNZwzIaezkvzpJ/ucyrn2VRs0JDIyLX1ch1 klyXzClnlYuKwajMVzqU55XvKieUnyq/VH6n/FmZUuy9ClKyHlqkv0I/RxsxnaVX0rvp/fQJ epi+Sv+RttrpAN1LGzwcbRCciYgMv5jsTmWX4eZBqpBKYUFLymlGiAhdwg7hhHBeuCRY/iLc FO4LBkHQXGxawBELtjN1kbpUXXudsW5xchEjRSQsfUpRKWu79QXrJasxCgdMWVlojEbRRY3V 8nvzWMtvzOP8T6D1CJCnq+msaZ8NoIBMtbKtuLXZpMWl9A4oRbjRpJk6TRtNRpNvftsaYRQ1 7Sv7SrljqjhdlN8tsIXidAGQAKbiLonAdk6VU3CdzUGjBLZjZnqSLcdkH0cG8O96cLK/pdmc K5ejCjLq04HR3DYvGLexBiMDpBcle0JNuMLuMOWIWsNQ4ucZWsMUG3SGkS0GQ5sxGyYQAYqw uTkUvwgv1FcsUPBBRZkqwjlprmmSSCCTCk3C/UErRdpOWOrsaW7lietPVLvN5buUZrz87Mud W0dRhtdqFtT6g4nl2fY1fR/07BviXTaP0x8IN29b3Lne9vVsteirbz4w+NVV286+8vTW1mSI E7wRuaZpyUpl2UtLiwtrB0uHNZGVhBWLHj+M1MdWt7Q2xANApCdmJw1dEOdx6u/a9jtmVGVF T1mHw1fwlfg4+hR9hC02GtXhWs/aSLd1c6Tf2m/rCw9WnKs45xnFFzwj4QvxK+FrkptC3grK 4ApepyYge66jCYSNyAM0Fyu8gk+4DR3X34SE3SIuM9oZF3LJCJT/WbOvHelGyOpOMwj9CL0G 3/Cflz6DKGKCkSAONlvm7iPHkRo5fR1cLPmK1eFKW3xVba/oHJLBxndM6aUdxJc7Jvt0GE0V 2Rwo7gblVQIlXiU9m15+QShJ33BgSyvRoSxKtc4fIoDu+lsMWmThlR0XJ7r3jB88u6Qt22E1 /4fs6o9t4rrj9+7s86+z73znn/lxZ58vdhz7fE5yjkns2I+EpC6EQMWgNMUd45fawsrCRili WwtdW7pOCxua+gebSLdJTJMmIsKY6f5IpqnVmCYRNomx8gdIQ9WoBAOtrSZ1Cfu+symrZune 992787Pf530/38/nhcNKXjW/9HhxXe/W+5FvHkZt7y/84OwPpwbXTO6qRqP9609/534pkyNV ZAOgWwd0g1QMFfBWVlwXqAf2B54N7o4cDji63Gfo9+lL/iv0Feaa91rwX8y/ve6Xg0jFUtDc wuxh9quHmJfVV5nXfR95/xF09TgfhJDT5cpQTsEZczLOuj0WotB4qIG6z7cnJYe9geR5zuMK EYA8AFoIR1Uz9BxFsINbYmcJnB6fSVnm1F+g2gy1qn5Z/adqU2PppgD3CS3MrSiLzZjMmyRi DoBfEpAQjbewt05QIMm3CPqZDOEmWB4L/4+Xy4SI9VtIuDTdlGW/3NnVlOUOUZGptkBIRrK/ XUbhIDQtWSYWKUM2aRrFm/vQJEcKSCPCXjnMh9sUZOrLD1xTY18p71ilTjQOL+3dsvzL71+5 m+gKJsx4CX3y7r5No0+GTh2dPbrwEQre/uk7Lyli/1OnEgDFCEUxI6DGOsrgbdhArKRoNM9S DoUVHLaeDIVQ2i94OU6kvL6MwHOa4nhPRZrCvpcgJr/azpyFstWXPBZEuu/VLLwC1HUbOOyr 8oZi3DAYIxxuQxECWz7abkbktIohqifSxgc3dKRfpah0C/QebolH/NUl4MZVr1dMcwRzmIhE bKT7zBi3xNFQjbg89wp3gpvlWGKTtlvdJe4e5+CiMSNv0Dnjj/F30S7EErs0PWkdIIAQZeHW 9K1pKJNW70Ph08zHv4PdG9u95kOAmpioMviqMnCGEEiA0iiUyw4SWy2qE+EG3fZDbSqCU6rQ BX+i0F9ImY/oQ7hUMC0JD4aD/UF0IxDbsvy3aiFw/Dj6y/kjh9YOm8OsjRPCnSn6u8zY8qFn Il2MpqH2/AT95o4x48TitlX6yEDc1eHng24+Xzh7aAdsE7V+ZZy5DkzKU8PUBPo5fqJL8PDV bNcbruP6yfSvbRdd59IXcve0T9a43f2uAjvIlmKTdmdXpCvtSiurlJryPedrPadcZ/Qzox5c 00bi3nREoJghhxaopL0GZ6l5GyR7BYuDFZxMmRXwkNAEI2a+gsjjeTFiVhqMDQcDAULRQGfx bY7rNGgGG70m02A6MAcZ3Pu24RhLdvI1i2pilUTshn8bq6FaLTLUeLCEg8Au7xAa6osccNDo gOJABqlrDIvT2RE4DVSh4avGCOJHlBF6pBYXyKBgDQqIFxSBFhqMHQeSZh6mok3Em4pJmzie zGTJ7ykwmsXdaTNLxJTP7s/OZJmN2aUsnT20HqQ0I1iFMnOrTPZbuFMHFrfa5fr0fyBH7ljD mUyTyOXlTNlPbDbR1zsZi/MZIqRwoVYkl3/QyhIQwQyCI6nl6izmEqMX6i/2hZumGnKFCGCx 2SQtf+dovtNnZRDTLMKtuyT9E1Sa75Ui+xfWsgf04WLlV3/eMP3s5qO/+PbS1Ngzx57/+usv 3Zyrrx3auGGgvFGPHdwTH3zxZ2+d5tu/yvz4hd7ugdKuk5vspbSWo3P4tc1vxXt7n8znHo/i A2PH8r2zz715qXKw8aP9L5yeX53/7L5fKfRvWjsa9csh4trH4dyzCs49WXTjIsU+uHfOM5iz WLmuYNrHaXpjbilHO+x2NsQmWRvvpVQqq3gFVciy4lnfgo9uR5SkKb4GfR371ZSmqAnVpSne RKJDU+IN+gO8M9GtKdlEArXDV6nIHptDjcd9Pq/bqbiQqycg4fjqqoTHHjMlPFyQ8Chcg0Nw k++FJtUNTUaHRtWggayVsOA3L0uIl1BMuizRgoQkYr/ExRxScnM52sh9jSBRKZCFzMNUVoTZ rAgTWhFmsmI2Z0Xsg6TPUU1h7ulOWUPwx+6lkJFaTC2lGDI0XxwyrQicsCL8KetVV2fcTEX1 yaNNxYYPZJ51lhNaBgpKFZg5Uq8+/5ThMVQnUBEoTVUi5tYwQ0oSqo9u23qRihNmeqpx6zcC XNWHobHupJAX7qCI+nCUh6ZdqPpg/Fw8UH04/1OkrKH6AcjZDKSs37JkliMLQ4kbKLYOg3Ai IWXvf8ZSBfT79a+Mbf1Wunt4JdkXFcVMe/dElpdKK8lS1J+q2CeW//7E6K43ZldO7i04NM0R b9uN3vlGKV4cW/HsiqpOTWNjob3MhedNZxd4hR4wDAn7PspDdVDXcUh+xR+u8n5KpDoUvyAK HWxYU8QGunte9WqKn3QSEU3p+C26C+aNhdX6zQHzLItYTCGugxX9bhfBoANGm/4bM2mO472K l/b2RMIYpg8TMIYKJMzHEqYVpbAVsaHnzbkwmgkjKiyE6fARLG+UaUXeLs/Kc7LNkKvyDHQW 5Zsy2zm5CAUFNu7TulVUmtsGBrylLNU7Vr2woM6gR1oxIH0RZ8A0uXrqaYynpv6UG11xVORA bsS+zxrA+OmV0nL7zqJN02g1vJNWodsF7MwAbhqwU6BgsSJBbbuI5kTE2ymWEhS7AGc31gOi bWEH6m23sAMxF6CDQwn4Jmt3Uw9l2EOQ8TSRIWFeN01PCyEScQIgmvOgGQ+iPIKH9hxRxFlx TmQMsSrOiIviTdEukvd7TZPEC3rO9FsAkQT/AkIWOA+BgXH0f3DMP4Jh4rMXP18884cdZPGw +gmKYg+CLo7Tk1h5jEaiqGC3XHTyElWmxhUJiDPOooFiVFPAsP/1vKprSjd0cEBdrSnlhMpr ipRI4BRSNSXVoK/9JoFLqKgpJejjnsSIpownEg5VH4g7kE0u9+2xyXvcbpuDGmfLpe5UQHLX MGiNJXKbZdWkarO1udpizVYD6+PjeYWn+Z62KJStKKlRp6ML0ctRBkdnonT0dlztyenwSLce 6Qv6ZZ3B+oxO67cpvqjAYfC/hJd/bBtnGcfvPdt3ju/su1zOv+07n8++i3N1HbfnNqEJPpNu SRvyAyihWQlpmcqAFUi6IdEWcMYKAzStpWxFVYU2lYmpk1BHva5hQiJSRcf4ZxEbnQZ/UEEQ g9USsKoCpLk873uXtlAkquoe3+W51757n+f7+T59H2gQMGfz9t7G1Qb9TOOFxkrDV4HDasPX SI6OLdMfaWlYVCzX6xBFIXAbem89zg1NYqOziGk2hP/hFz8B42EbzwSYX3gT8P/b2kLsaqFS TWe5cIDpNzJGNbBRQQyb5VIK4sMVZpOC0rzimlYYAskciGdAaseuQ46k5oJduaBiBtQuzaRy WpBFWMVAZR55ZGS3U9g7dnWMZvgCb/PO2BUuMBWYCk52TXErY4EBeoqZ4v/F+LHfWjw4S2Ru DEoqliUvuiVG68zyzX+0QOhIBPkDn/jXW7E77F6HSM4Fzj0XvL+L3n0Q8fmPuUHqtuSCAZ+F L4660+n/F0TsA73hlr2rgF+deHTyvsPa9Hen9z1UNt/fyQ6mJdnKWrvL3fFGJ2OWBbmS7tUq NfibQnTT99yRXSO7Zu6bnv3Wyc4jB2zQyYCZ3odOfGW7Vq93QvtTRdwFevXD6ETTKUTV8U7o /jpD1PQALRI1dZm9FfrCov2Y2W9f4Aa7GFTGtTQwXpsuowDwusj43qKv+H6d8kWZGpDcdwX9 Lk1LQoTSKEuNiJponRN+JgRROiMXVMHltwHM1vMh4Dnhdw7zO6oD1S1d13I5QYiEkp8K+Pxs ehnNt1YRggn3gjOTqKFDFGUxIUL0aFTGSJeh9gUZ5eTXZFrGeJcB7TJGu+zUtsABiCzj3pAx 5GXMdxnzXcZ8F2UkY6gLavmFMl0pL0DbANHLHtFJhEXKHtnLHsnLHuHLHuHJOxGA7OWMQKkY RKZp3EK7gSrGirFq+AwP7YaHdsNFesE2khtuI50QXbwD6XDFHRDXz6AdRY/p161FQPpQ28X7 XVzPuVzPrXNdwFzPrXNdIFMW5rqAuS78N9fBhh7E8+PcQRgkrfVq/h+FfHfNXho7+sE9X5JF KEmzFhclKzWz06x1TK88D02O7h8fPNN58gDBejF5P3rmoSHtSIf7zAD7H2UIL3PnzTXfRajD MKWhXU7ilRQyeSR9LBgxwohi4wbbFeSyjp+8b5BRv2NYtuBH/pSOH2i8RsKoG+oktAaHbRyd Qq9lr+irOk3pjr5Xxx8Djv60TuuCpEq05KxyiIAL1iURlsbxJT5ic8k8rLH0olkbWMTK6W7e RHtuUlz3XzdgqybalLtBQ20ih9uRJhbpoqrkFJqRe6I9NMMY6Uwqk8z4GCEsmfCUWQXFuiSF SrBZE3XzERMpvoiCekJxhcoE4iblaYxl9Vl9faCYIIbVXjSIdqAd4iE+sMA0+aa4kFxijvHH xKXkL+jLaqjJLoQXhGbiGLsUXhKOJYJojppbnIU5A2F1kvFAQddsKZ5nYGqIx2Bu2AobivfT QJ3Dv/rc/sNvvr7259c274hHuLGNZcUMy0Yx5bv01be//co3zqDeS68ia3TiD798cG50ZzI/ PI+055vZKN5Bs7PTD4lg6ivoYScpVYICQ7FUt8qIrNjN9FR08FsFlcVmgsP+gvm57jk0J62X j8bZbgncGFM0VI5hI2IJlZx0Sqq6+4tDa9uwjaPTD104XV2t0v1VpzpdXaj6q5JnS8ISzJb9 vMNP8yv8Kh/gk/2Ti+4UR5qFh2WSGlbzlVYiR+L5uIrbYZbgT5zDu0pSq25q1Uut3pF6AyoA m5K269pwQ0ZEzEsPhzljQ0JJFi0ja5jFDYmSiQwFDn2psol6M0WToryttVzIbSs49VFbx4dm oqk0jeYG/8NyM7mQ/bK+YDatr8uP6yfl7yVOKafypws/lM/mny+8JP+0IG2PIgr2FqZIa7YI DRrbfGeHalH4SLDkzpaGSfYbD4rQz+hcvP/e994hrgl9s7p5x8wDZ3fv+dFnJ0Y2bZ355Bbd HjSc/Y35zrNjdqJYpLX4Xt9vsZc8MparfO2PR59450g+9ezhwV3X/j677QT2WOMU5fs8VEAJ mU6IM7hBTuZFt6VAkCH+qZVWbcvzfBCXzqs1cppV3MuCSKJjyjFbtNBJ7rhFc8lwty1kKYUq qVlREUsMisbicSp/RlWIVY1fVrPEquoFtYSrKauHNgmOMgSKl9laFx7AkKFKjJINCXNU6GU0 T/nR/MXj7Cp7lfVBPb7scFRJiKvg3vv0vFtveUID2yYxnSPRkaWYvZJHC3lE5cU8nf9N3+RH SW25XhUK6Pr1uXZbXHPdPKiBZeHiYElx4NqA0cnztWCxrHW5dX2+6VoDJhqN484kWos30jSI QZh7vDEw0thYm2RD4WyqFM0hlq8MdNhhKxgy+n3PvfGd+XvqIzu3+5lYvr7vi28ODIrppA9M weBhOjAdy6QCmPcfurlGvwF7tIl+zPk41x8V634xXJLFbMnPyDH5cvGy8Zb4F/GfIlsSi30D 4pa+x7in9KcKZ7kf6MvcizoX4APhYCnKj3LjPONwDk9Lm1TqNK0ihLmDHE6qP41hju5xeqjT UgUu2JV3rYSaPJ1WUyksrJByPIVSy+hBR0+ejr0rSQHDYiXFkDivjx0paqM9EqWJGk1GVI4T bPcsj0dTZyOItRpBkZRgo4o9Zc/bX7Cb9jmbsSUhqAbpoAM3uJ/yqVIv/la4Q+hFvQSTIO29 yc1Y07GkL1oTazB6YYW4EMwBJYM4KQ43BB1ZqweHojocYkU4hZ/ugRMT4MZBkH7vRi0Hjw+/ 9arTBSton4C78S9vwQIkwhokwjI4nr+1kjW7RlZwksjpTcAbzHTDQUzDIRKHQzjmJs5S9Tb+ IkVRhLqyfPP3LV52I2TgeB7SSSLJ+wkVAD8lQW5AgcSAAlkBeT1FvIanTiS2r7cp8RoWPEeo OKHuesXpEuAAz4LTcJKbhb+5WIafBn282nIjPCr4imIZHAacve50wYdiGUxHcfnm31qglRDX LmKZzYCQ3rbOs9QitALWLRAu1KMTn4xx5L+lVNAKum8z5hPIFbSGadRsaJU4vrCVflLIDz/a KL1PziFjbvKJmZEFhdNimpgvf//e/uGhT58q/5v9ao+Nozjj38zsrW9v77G7t763d9dx7o7k zneuc07s1O0tSTAJTmwnBINBThM5ThNw3jiQQEoFRmmANkilEaX9I60qkPijFCdyT0VVEyl9 pKpUVKkqqhC1RAoUlJRSB0LN+frN3jmBgprSSkiVbla/mW9mZ2dnv/nt91jxra+vvTGuaqEI OzN35hvbly2MRxf98tHBvuMDi+V2MjAx8fnFbT033tm5YWTsuWQggM4JUpW/0+NCGaLwpO0/ Jh/zUqeSvRAtkSk8HkHXWeNDlIiW3CbbMpP3SaN+mbIS8dtNLnnKG4sTQYCAy3RR1+JgqPGg rgdtVH6Q80nB3CwfPB18MciC0Ri3HMg9VC8GgjNOrIfBXZ+CrgW7UCyfHy5iYsZDvpluopzD zHcv7CXqksYWx863LwtXjUaH2oJ2YhkpvfJKIKVcv9xYPzV0n+o59JXnVwjluWdHyj9bn28a CZ0e+cKC4+T9lqGzB7mtDmK8dZE9AwkyYcc0CpRooBGhzRgKD0UGjB97p423jQaD22hfh8G3 n0qYhWKoPzQosga/22wQwiQcj5hhEBWRisRliiGl0QyVKkftOwOQsOKJRE9A0QMBhQBsCvhR 8if8BARRsZAiCv9d2hRboUo8HIgrAT9xJdDsNTSIYgLk+HvKwbaAHRgIsMCw/01i4yOOgbHI CUK5kfgtYWSA7+xkd3/B2WG8JV0wbF+goBibjRPGtCEoBvkRfgdtQk/BTjafQZ1nqnHbzF7U fDk6MzwTueBYax5a13LcLryF4pFcxn9YOXvElYs4QiYCygWinK7Wwx9t8HhwaR6Q240G36zB N0sVNVEkvEKjNT2pdzlNI28uT8qBIpn/IVyEcxwdNnoA/BGCQYf12BfFBkLemvt5lxVuJX/L q5HsU/d1tHaR9mxn59yvEvT3D7XEpGRSDRnJbXPfI/kHl5ppmkyKSyfKC/g5q5Xzrkk85yy9 9ZQGKsnim+1nNL0ADAQ5JIcVUJgiNOT1fCgfLurFUDHcr/eH+sO3uW7TBo2drm2erfJ27a7Q XeGtxjbzgHJIOxy6P7zfOGjdmz6WezLzkvgGvOZ/M3sZLnkuye/6Z7Mp0SPKol9QXKpg2LmB 3OacRAjVNDUYBI8imx4MjsyIkCbpzHVmGiRFopLgNqVw0MKdBUNmOGUlzZRdqhw4qTKKucx+ e4cJWSuTzfaYlm6aVhAkEE0Km0wDu4bAJEbYJlXRVVVB/wG0R9VQ1hSBUUHKGkGNgKjKFnnL mrWolUmbGcvEUVURiCebTkXCHknMMgpyjnM+25Fz8rjOgtNazU5rR6KxQs6W/QXAb6LP5Ugu HI6lxy2zRFqn7M3qHpWqL5BWsEDC2Y3c40gPSBWJtUm2NCAxKdqaK9FBh4klkn0YM4oZjAdi 0XXl4VikHIuWI303jK56bbiaWvCkgocRWK5Qcy9KKpJzXS7jRlK6jiA79/o/LjmMzcQ+zNnM J1K3Wh9R3N3ubm5khocxEXT8h1GZPoleSildaS+jh+gKufWuMILMU5e1sHn2VsnrRCycux+j MjtfgdnC+53p6BLyUttC6+iEx2jNkz91Gk0T98ZSy0hjbmlm7h8J+sPyBvr0d/KWP5lMaOot c98kOyO9i9zJJIuGQ73YHVgdSy8UkOkd95ejnOmYhLAxZLpG/oxeGliI/YXNMsFXqrxhSy3J ArNiTQXeO2lYvH3bXhuNF5bTm+h29gAb9z5CH2PHfbPsss/Ty3q8q3x3sEHvC+zXrIEq+Pi4 9x1K8+68ZKmWNuj9g/d173tet0wFb5zqXkHj9OhSPUW3pGoqvt7r07b67vZN+J7w/cB3yvcL 33nfuz7Jt4kynVJGCfOB5NVl6iesR5ZKLGX7ZA9oCiakGvGIGh+5ztcDdAqIR7eRSqATnXNP R87J7ilJ8txB2Li8SMuA4170LrDx9ylCBehuVEiJJid944Tf83AmYlAWDeol0lszhH0zGPeU Of8yMzPc6SgX+hTOPoyHkHnohy5cLGpd+WGl+6JyAcnHCcg5qHHTuM+hiA+pgXGFj1ME/Ry2 P+FUcfpKY7UNOOPTk/7gfOh05PBZvpZyTjkHGYwEePxM9jlxMRl21mX4HMYhXn5MEppPGsEK V7n4fLiLR84kM9Tc3EEwbBAbWtTmRsLDgiVs5Qe/o/T4lo2FRAsLzlH79LOZRIhtbFk3QpT4 B6d2YZpSK2P/Ay5WQb6IeOI/B9WvDfY0gGtpFeIfr6Lh7CdDOg8gp67C++J/h0CpCjVUhXYK QN8MEHoZILoCIHboKuL3AhiPAzRHABbg3ha+XEXqqwCLvguw+GtVZPcA5G+/is89WEcdddRR Rx111FFHHXXUUUcdddRRRx3/HwAKBHjRgXGJxBAiXLOwD8kBULWrvaZ5IZWGRQBZR25fArD0 Iwusgh5Yveam3rUA/QPrN9wMtwzeCkO3Awxf++WfRRHgBNYLwEKJYp2FPCx3dr0GBuBm2AIj sAP2wN1wDxyqVHAun5PDOSudOf21OaMwBvvgAJ9TefXfX7WTuFZh15zhhm21tRhEsSa1L4ri VZVFlNr5iQsSjrRDb02m4IfDNZnh+KM1WUD5pzVZRPmvq/tWr1u5JrNxx87R/X2j92zYvXPL ruyK3WNbP/0NWA19iHWouDWQgY2o1p2otv04OorK3QC7sb8FdqF6V6A8BltxbBS+DOMob0Hl fvrnP4snuKZdCrwD3TjZhZpVkEHXAzQ8gmxh2EelksfxjltAiffmW9hG8X8iV8q/Hm8RC9jI t0Nuvsxv3B1sf+2U6befWvh6PvClQPcld9TtzP7+qx09vJ3snRZnj5YfU25wd2CXn7uz8j8H AIJoyZYKZW5kc3RyZWFtDWVuZG9iag0xNDQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAzMTY5MCAvTGVuZ3RoMSA0ODkwOCA+PiANc3RyZWFtDQpIiVxVCXSOVxp+ 3nu/7/9Jal+SYuRPfllIIolaY0slf4RYYhfTkj8iiSX8CMVoUbUcsbTGeg7KOGm0OvzRobZq OHSqqvZ11DKlliljVI05+O88yXTmtPM95/vOe+997/c+973vfS4EQA3MhkZW3wEJrXIzhz4B DrzD3j4ji7y+8st5C4F9iYAcHjm12PVj78tzOHYFcB7O9xUUtZtSlgBU2wjYkwvGTc9v2vmA F0haDEwZXjjKm/dl0F/pfuAsP20L2VGveZ1SoGZ9tpsVFhVP++fKpO1stwfqJ4+bMNKr2ix7 DHzwA9tpRd5pvuBi+T3n59HfNd5bNCr6aN/VwGecL1m+CZOLyZvP/seV475Jo3yn82NpRxQD tULtpWTVC2F8m+gVaAyYG3xv8r0T6Gme22PhDowx13U9zv7jzy8QiVV4H83wUJJwCBXoiQ/w KrKwAt1xAttRE9PlGCy4kYYtiJQwKKQjRGysxSW8hkm4heuIQSauSl3+xwMfGqKDuctvJhaa PfQKQiq2Ya+MkwFIoJ2h4iSWkZeZCoQgxhw3F9laj1vSzJQjg9b3qINozMJ7qIsx+Mo8r8wg clEmM+UuwpGDEqu1tciMRUfsxDnJpNUb0+2L1XdiHGdtlhCpMNfMbRywBKP4p7exkIx3oEK1 1Kn2RrgQhc7oAy9Hf4dLUk+SdIqJNt3MWvaW4ZGKVV9oJ3nEogdGYAk2MRvncRM/SbC0kfWy lTglD+yL5JaJKZjBulrP7JXhY+yRJElSISqE2QpBcwzi2DKUMv4nOCmZki0VclCX2omBrqa+ aWBuG4MWGEqG7+MgYzyWRPowgo7QxVZTq9hu9WIOV5iHdTiJU+RxlXn/CU+lBXFDvaVmmSFm i7lFLtUQhvboh2GYgKl4A3/grh7CYfxDnqnq9DxhHbFn2A/NcuY2Ct3IvS+9B/DfJdylHdhN nOcq64iLq2gvfaS/FMgyWSW75ZJcUg4Vriaqe9qvj+krVlvbNsn8U0M0ZVw3hqCQO/AWs72c 692CIzgqDSRK4rmi85z/RHVUacRmdUJd1fP0Muu5PT9wPfC3wDOzCE5WWXfmYQo+Yhb+Lg3J obmMkcnyHZm/q/6ka+ra2q3b6Ff1QJ2tF+oV+kv9jTXJ2mpdtnvYXnur0xsYHzhlMk3lqRY4 yCsacWiNdqyffFbTWPLzEZMwE3OwCEtZL8uxEVu57s9xFOfwLX7gDkDCyXk0oxex6ubJUmKt fCwH5YgclRvypBIqgohRbVVXlarSVYGaR6xQJ9V5dUc30SP1LD2b2KB36UsWLMsydisiwy6x yxzHnDHODGduta+f33/R4kX2i6sBBBoFfhtYFTgYuG0Gm+nkH4l4tCTTBWS5ljVYSnzEStyF L/A1LlRxfSRKbFZ8qLhZDXHcta7SXXoQvaUfMYgYIsMIr+RKITFLZsvbMlfekSWysgpruLZS +VB2EZ/KXuKcXJPv5Z48UixipVnNkSpaJagOXGmq6q76qv5EgZpA+NQkNZU7VKY+UXvUeV1P R+p47dUT9Vq9TR/SZ/W/LGXFWQlWJ2uwVWDNtU5Yp6yL1jM7zPbYhfYG+5CjsaO1Y5BjjGON Y7vjjuO50+HMcuY6ZzrPOk21SKrVn7nunfjlk+A4IZPt+tY0dY3nIlT77AUyiBlzqIF6nF6q T9v58lC75LIs0qP1WLNZp6uneoIMVp9LhA6zk3U+FsPIVnVDPVa3rQYyUN2VGOs9+VRN0KnK URnEPmM1sObadwB1AcnqTalQR/RcPdd8hmR7g1yzN6hTcFnXVT1c46leoKjY+EaNViUYarW2 n2E08/6hPY357qIWSgt91tqAW9qtfpSHsoqqcVx6Ws3UcNVBtlJxX0hT3JeJ8MlKpMg++VZ2 Q2SLLpNe6iXull/VkHa8xo7rcDmrg5BdyVGiVAPJUg/VIL3fcVK3EaFKnMYM0ZLI2vnvE8B4 noAVKpqa5qGanJFWCMVq6v3jwP5KxbYv2iWss006Dv2RiNfVMSTzbNwihmI+WmEva3AhEtUa zDSzJY+635v6qbBbxiBBgqmWIeQ2i/dFQxVBLRzBqE+p/19R9TPlAd4QF09WBWKsypHFlofK lEP9LSHy8Dpb67DcsdM+g74SAliuwAZW+RUM553zHeM3QifyG4ZNVhxZu6jMEzljXSADKcR8 HBOFN8m5C895lpVB5V1lxnCFo3lH9eKdeBSjzWqkcu/6m7mmBCPMJvMaCjDAbKH+TjU70BYL 7Gw12I61WlNjj8ph3kd/kRLqdgYuU48iJRT3iG1k1MXeh0XWBWpnV7PYnEMD5iOCGcrlLXoT RXjAvGXoCrwS6KPKTbr28Ya6hn6mzIRJEArNOCrvfpQ6bWrPbDS1S1NSUrp26dypY3KH9u3a tmn9SqukxISW8XGxLZrHREdFNnNHhLvCmv6mSeNGL4eGNKxfr26d2rVq1ngpOKh6NafDtrQS xHnc6Tkuf1SO34pyZ2TEV7bdXnZ4f9GR43exK/3XPn5XTpWb69eeKfTM/z/PlP94pvzPU2q7 OqFTfJzL43b5j6e5XbtlWL+htJekubNd/vtVdu8q+90quwbt8HBOcHlCC9NcfslxefzpUwsX eXLS+Lvy4KBUd+qooPg4lAcF0wym5Q9x+8olpItUGSrEk1yuUK0GSfkbudM8/pfdaZUM/DrS 483zZ/Ub6klrHB6eHR/nl9SR7lw/3N38tWKrXJBaFcb/b9arBTaq44re9+bt2w2x8dr8bUN2 vayRf5hPbVhTYBN7NwbTEH8wu67TrsFEGDcJFZ+UNgpGiaF5QBvSNiKIIITaFOE2PANpTSsh owqhtAJaVQbl0zYloS1tAhGCShDVr+fO27esF1JoVctn78zc+dy5c+7ceXqt6ZbL+Lp4N7Td 118+aOwY8NKKRFlWZ6Czoz1mio44r5FbhnXrzAnf/Gji7Somz6uNbUvXFggjMrHLx1XD2OYz 9zfG0rV+/o3HMYepBqMJI4qFd8CFDc0+rKX2xmOm0osFfbwP3pO9u1WBCLck1vjMBwKPBFYb axI4mHzDpKZN/iP5+eHj1geUH/EZLbGA31xYEIh31BX2jyWjadPRSWHfpJGaivJ+b67t1v7R OclCVnZ6YVVKJ0uyO5camlJ+VdiiwCLQwfSt9MGSWAB7mss/q+aSsXIuuuEvrmCU2Ynz6DIf qE0Y3hq0e3m86Qp6Az7jBuH8A598PLKlI9miB703iIvMkhTRoHfKZlmZWVrKBHHX4kRh4wJZ r6oo3zigmoG1Xh8E3EePw7cd8ZpKON/v5+PdPhCmFaiYPY0xu+6jFQVHKFxZFjfVBGsGHc24 ZazpcTSp4YkAeHyM+MtinOkpTv3neMePiayuMZXx/0G9ytY3NAcaGttivoiRSPq2oWVEzdbP TemSJcVWwOGmFoSnFgVAvaa2GDfg3xWMBiJdiXqEGmw0x9TGRIEat0tqgZBTgb/tqZm5Esvi ubSgLvnfOeD2gMCyRfFFTW+i3v6Nj/L773PQgPUpj5Li9rDknsyaspH1eSPqI8zLMgQM1orV hpY2wxg1QhfFZWUY0YAvaiSMjgGrZ0XA5w0Yx0VMxIy1kYRz/APWL7YXmNEdcWxitVJTwW9E cvuHI7TcS5+tH27y1sjDSvtzZeshpZBLqgO8TkUd9Wr4fgK+ph+iej2EDPd1aoSuBZiO9l3a CxRE/6dRb4bcpYZIoH0x8ClQDjQDPmAFEAOWAM8BjehrAt/hORyIndTu/gp1uE6T19VKRcBi lAPah1SqrSM/yvVcx3qzxWQqRbkIuhL3ZPQ9bV1iPfoVyX6tGLeOeqBfgPqDQJ57JxVA5gBj 0J6PeQ6yzZAN4iTv1bqK8kbYsQjlzyCjsLUOcgnal6I8H8jGmC+qIWslyrkoz4dvclHOAiIY d5PHoH82bOyEfizqKvfFutmQBdwXc5aIC0qBsgfvkQvUr7XQWOhHS2DfvGdnT2w/2/Q5iLJ9 6bDtk2Bb1du23QE1A6vEbHlWW5J73aueobViv3UN5YA+liIM9wWagv19DIS0Tprknmz9DTYu ch2jKtQ9wEQJnnMvbRXXKQxdmf4qeNNJC9SZUFRZt9Rv0WQ9SI9iv/A3TYPtceYeuDAV/Zrl +E6aol2ifJTDDA/RX1J+gm9w9g2QtfD7FQ9Zn2COWgbmOQ6cxPgJWL+SfcDnrrQO96HvZeie BdaBI5OACdBvlxzGGB6PdR7mNexzIK/kIMDcA2Y5SJ6PgwcdSP8fkhgPTADmALzuq8AvgceA 73MfzDse/afAjueZM8xN5gdzQ/IffJKc5XNcB98wx+yY+ZH6JH0bGAuU40G/NYlS9JXxwufI NnMs8NzMLeaMI6EvtnmvXOV9MqfSZMBVLteWMcjcSpMlzH2WIiz3UKIOUjVz1va1I6UNEY5H jglHOvZwfMoYgRTdNIZ9x+fuSMcXKbmfgtAtcb1Dj2ozabk4Bf63o/w45Bz4Z5+MwavaD+gj tZdU9yCV4yw5dl/LkLsZ7iFlDeYbhC+LtTP0mpRDapE2pLhcfdZlV5/6vA2nnC4zoQzaOpaM dN1/2/6/QD3v6qMnUf67a8iytCF6BXsl9z+UGYDPkWg/AvQApZ4yZbenWxlwLyMveHMdeEYL 49svTHO0QVqojZNxF0T7MsxdqXXTPIwT+Mp5SSyjA3offUEM4RyxlnqeXmDw/JBrUzzK5Nyd XJLS4etdJMdAtiNlTIWsP8q4Cll/kjEZsoZtSSHODXw/y/xA8m7Odfia4uXrVCxupPEzg6dp /JyHcd5MXqbJ0SyTuSXbiVOMGc+5hvcv78dWGU/ynoPuiNM/U6bGH6IB9ZD1nryHz1CbE9fA TCAI/a+S9wjuYZw358ydVrv+rNUuFlvt2OfP9G2Q16yj6jSrP5VTgzQreZflO7mU/eQ6Q4Wp PBqkpcn7LMj5VDuIHG7n0TEyf/6VJrquybttlrSX45BjsBL33jTk8X9at7Q8elq8RCQQl9wO jjSyTvPQOPFn3LmLab3YZ/1e7JJ3UEQMU1yUIYYxFj6b6FKp0FVHDRhDcj7uA8ltbL+ugZ98 F9SjjrNy7mU+e/0WZQPTXFdwH7WizyG516C8x3fTVPaDHLsBeQVzucsoT1OpLNknKMc8hfeC 9AfuwDRfJHPzAp5Tb5KczZFjZlu3PHkUYrjeoGqsH5Rr1VONJ0TFrlbrinxX5NFj4jTNEPX0 EMr5kvfbkKNKkC/rkR8B8SEwDG567brM1VJaN2W+3yzzeZarkpbL9wTrdJqil9B0hhaALkEV 4g3M8wx4dQvlNy1Lvg/+QLm8NtqjyfcJvxNUGS+/w7i3qYJjjG2Q+Ybt2QO+naOHOCe6D8CH ozgGFQX+LkzmwTzUVcjvpuHlZFuhLRW/+g61Sl0LfaCeUA+rJ6xufgeKd+mr4oc4v8PkF23I 36eQG+chhy+Gr35LMXEW5SK07wM24u23nnK0HOoUF9FvFnRrMe4M5jgAPWMrxrwP+SbNF7+m LjGI98FFfiOQX9sA+QRQR7XKT6hbvUndejVy8jzrdTk/Y731ZYkDyJsXk2OTkLY6uJvNm/C2 u4u90tZ0O9nGu9jHc/C8chz6aBrlEFnvA0FbDjeqO6kP2K++i75fok3KQTzz91JUuQTsTeKn VC9lP9CIGKtSngOma1X0c2ALyuWQJ4DDdp32AO8BvZj7JORRHZ8KDPUR8BkSbfuA3cBvHF06 eK27tafDVUAj629RD0O5bv2Lkdlf20LVWK9am0/EEJfpZYa+mdrcG6lN4H7QpmDOjDrWmaW9 RWvuZc+9oJyjGdKHNsL3s8f7Bccu5+f/13z3C5zvZuAJacMV3Mc2h0Yr56kIshWyVWygbzBQ r0A97vhTuQ6uMQ7S92R76vzsdnCFBOfsjPbMeua53quuHsVbNw0OD1J8eIVeZGgL0R/IrHve phcZ+inoTt1Z1358D7ThjbJH2kSSYxl1fSk9xVCnwtZ8OWYHI1U/h28NgPvK8dm0kyFjF1CP URcjpa+i7Yw0v1azX7Gm1Dvn45xL5vnAvrB2FmjDe/YszYBshnzYkSl+J++LEZxvtPmeqvNd cimjz+2YuB0biJXPm/Pf3FdtbFPXGT7nHufaxtzYpIECITlObgwOMU0w68KHW18HB5Y4atLC IMmmOh+kVBSUMBjVumSh2uhgbZdsMKCwkrRr2NQky801UKewEXVaq1bVyKRJmyYEYePffixt N6Zugew5xw4fWqq1Uvdntp7nOed93/O+5x4f33vu/xPw33kPeAd4+39di+L+IO4RHkCeUdeR CvVBnD23ELyu3nyfkKls6H14LuCfNzWB9u/QbgaK0X4DtuPQg1CkmboF+zSeI9hKt07ZFuP8 TshBADlutafG3rwBPJ3KcfM8If/6Qxp7U+OnXgA2wIddOHUGwO6d+jkQxZiZPD9Afzf0V+hv TOWaQvvmNeC7QAw4ltKp7wHC70SN34vzyCzvoZ+rftL7x6fV9HtGaEb/4x3is+i6T6X3vHPM /P7/TWfeJWZRuQ7p+at3zeeT3nHuUewfZ+pLyOj0GLuWqKgIGklo8QNSLX9RUDqsxUuCv2DX lEGyjHAYrloLcqTnilVenm58cXWqkVi+Ing1ModdIX8FFHaFXSX+1KiE/4HgZESDgbJvETel hJM+nGRNQCEG+2OicGmw9yJ7H/732Ltkmxz2rqXNCyLhO+wNkoUT7zl2Nu05m8icFySRPVgE SsbA48AEMAnYSBv7KekCuoFhAEcwMAdKgBphYQNsAPPsx3g3uARoA7oBG9nMXof9KcHsZ2wH KcDYF9gRMh/6PDss9TXoYuirsOdBX0FfaG+6fxIq/CfS9pfQXwA9ntZjsOdAj6Iv9Efp/j48 FMS4vWntY3usPO6J5MHvBUoBhtYRtI5g6Y6IpzWYsm+znbLSCDQI3ZVSLFenla/L36gzcf+i YB+WtBNL34mV68TKdRIbXB0zMR2pmBWsAzEdiOlATAdWpZTtQb09YvuAPYAXYFj3PVh3YTfB Y8C4tH8H3AP0iR57GutYhFkdYjssP8cm255YYwTD59kTWGqDPZFYlBvsvtNzzhEbEZqZVreI bZXe1oRzrrC2JhbnphRRT0UyWQv5JqCQbHAh8AUgCthYi1VYwt9kj5BdDmJk8i6li3XZujJs pVGadZEFSS3urZxksRUkhIAiHg/RskZnu3O/k3mcXmep03DWOjPaWBfrZoyzEhZmNSzOMpLT Y5Z97SqIsVFdu6rH1ecyXWOucVeGqY6p4+qEOqlmeNVS1VBr1Ua1Xd2v9qh9qrNH7bErja52 134X87i8rlKX4ap1ZXA77YscYM3iqQH2AO1AD2DDGsdh97LHgTh+jTiW4nFxBgUT9DzAONoT 0Az03IhzI84NqxtWN6wELDy1QCPQnvaqtz0zY0T8pPAA4riSCWsm1nYCPClaQBV6Gnoaehqi xpUpzNAD9gK1AJO2CQC7BjzjK037GwFV+idlzIzPEGOVKaNp2VgRNYtoXxHtKaJGKBwJGgWg rKysuB73xf3xflub3uZr87f122r0Gl+Nv6bfFtbDvrA/3G8r0Ut8Jf6SfhvXuY/7eb+tu3q4 +mL1pWpbvLqtuqualeGnS1jFpUGpBT6hZ61Fi4Nl7shDeDekJA7uBa4CjLjBHCgBwkAbkKEM S+sQrEOwDpEaIA5kYNSQuMWAedon7L3SJ1rCr9zjZ7j4QWvtqppINW67caAXYMg9CP+gjE61 hqXdBE9Ie006vk/aRRQHZsaJm2CDvN014G/YQMJAHGgHMsgltpVcBZAdzIF2YBiwsQZ8t7Kt yhC+g8ogCxjayvmcLFiAI03WPIcn4lHmYi9oOAYLPi75kOSw5EIjs0q7UaX9skp7rkpbhobi JxE4jkjON1wR7UxEq4loRREN2e4n+URT5ktWBdO/SH5EcsDIztc+ztc+ytc+yNdeztd252sP 5YtxS/Af1pRsyS7B9KjkKslLDRfX3ubaVq6VcS2i0VMU1Um55DzJOYLph2fcUTdxnqcfkigy UStUxJMKkUKnrVAEcssKbYTctEKnIP+0Qof5BfoxlY82esMqvM4j8+nfaKVN9D9K6we0kgxA J6HboadJiPqgr1mhZ0X8TzD+BPqvkgKHiH+F1MpxvbRS2l9Oj/uxFWhG1ZNW4BuoeoIEZNVj VuA6rIetwCHID63ATki35RMT3GGFlvPIPLqdFCoitoX4FDGT6nTFLyHzTujG1OAKKyBGRUWB JF1v6Sshy8QsL1Cd1Mpy3NLlReYSXaZYQnQ56Rzik5pJ3XLyGimQ6rD0Z5FFPeO7zv8ROi8u nPyduq1T/M8XcH1b0P0TrbQG+G9HxXJZ/FIgSX3n+G/08/zXhUm6xeJjgaQDjouBpELP8hEs solYhZ7jw4HtfEiX3n4dXvzUvaEV/KTewF/yoW/xZwMXxDTILlzxFrjrAw/z6tAA3+BLUriN EIoZc/ha/Wt8Dcyrk7QyMcBXFibFVEqRY+AcX46KS3U5lS+Xvak8SOz060bAvtfebN9if9S+ zr7KvsLutefal9izHVkOjyPTMdcxx+FwqA6bQ3EQR3ZyesLAsZ6SbNUjRLUJtsm2RxEMEnd/ hToU/HfM+1hMiW0qp2ZWjMQ2l5tlxbGkffoxc3VxzHTUfqVuhNLv16NnKgeTlGyuwwYVpgM5 Ztb6ulFCacmBF3OEdhx4sb6exsyxFhJr9po3NuE65jzaYGbo5QvJgn3hheGsh+et2RCdhRrT XHzns7D47s/CXPNobFOd+XpuvRkUjenc+pi5cZP3q3Wjym6lrSI6qrQLqa8bpc8ouyseE3b6 TLT+dhgpUNoRhjN5eyosQQpEGCmgCRlWLcOwTQsqoiMFBamgt2ilCML2eUsGbU/lKkQJ5KoV gjAljxTKXIVKngjDfkglc9+dbC6hbpnMPZfIZEtE0IjPh5CAT4SMlPkQMOIrk+6BO27dl5pO PfHJOj5aL+tQeifGn4rBLkjHKA7EFH+en9byzxBME02Xt7VUtOoVjXpFK9BoPr/vyYXm/mav d2TbZeHwmmxpY3PLk0KbWs3LemvU3KZHvSNNLbO4W4S7SY+OkJaKzXUjLUZr1Goymir0pmh9 4nTX+tg9tQ7drrW+a5ZkXSLZelHrdGwWd0y4T4taMVEr9m+yqwe2qeOM393ze86LE//3+xOH xHZiR4lJsJ3YkOAkzyHhT0wySlgbp5iYjP+oCcH2OiCQUFpYo7aBbQW2Zk22MdoOtiRAqRW2 0jEYpdVEta6TWk0q29iE1lplG4W1ELPvnKjStKf7fd/57nz33ffn7ju61knlZHat8OomHF7V OZWDmiJL1s7ys0STC/EQs9ojTYJ+R0M2OBbbpX3WaRWCa0vjjkzmlTRN5gNoV2WoMkS7IDpp lxaadXNd0r7Fdus0fnWuSw/NhpIm5EZSy9bmr0o8Hk9QJJNuoImklG1LQNDaO8KTSx/p6pwM TgZbJpVYcwRTcyTnviWdiv5i8HqQ9AUHgyPBseBEkE0mI9BsvOi47iDdjj7HoGPEMeaYcHC0 Y23neSU45vjMwSTBm3ACvpbm7JpJ4FDoz0QyTj8EC8QBs8u5k+4lnSEH+gZkvRgy9EpkApQA qgEdABb9Buj7gL8C/g1QoQNAvwv4CeAsbWEqmcoWaWszXTHipoeOxPjOevy+RSng6zfN8o6u Wd7SPsuDIZ8E/ExjdW5IBwk4RtNA3wF8BPgH4EsAy/gYX3by5KzXRuIo7sYgPoIfCUri7gR2 QwVTdSfibjeioA4OFoChbvy/fo9wPIlAFWAQYDAo2xqnf0tS/tU4uCcRaIDmzEiN2qYIvkDe hGRVTS6eQawqRd48x6BcNa28jpGcw7EXoZ8gBpcjHm/H65Dk1t8NzgTb9XeCbTNB1Ah1/QMg Xo/dYDc4gcDRjx7YmLceKCy6j2yqt2Ct8MM/s/fZ7ciL6tEKHFFcKHwjTPRhzGl5q8YmaK02 OcQtq+izQtJb3de028qpfDhM81ezUEO5Ml9rrClXqss84SVlPepYYaw85ttYv8OXqP/IlpeX 7zZxDb5QeWFePqnguBReqTgaCs0NDYWMan5VpWeBGlcXVnDz3Q2mEM97jyNyHC78FPPIuUVL Sxg+RQYVjX7ZdUHQa7ygpRT2nEUtLu5XkK404KtIRuXkt28UNhaHRbEgP4UPKCa52IVd+2N+ 7L+weKqveEcxgUSgUrE2B7vlPnlQHpHH5An5onxd/lj+TM6V5VY4Ow+cta/pgnum/U60LX0n SstO/Ux7y8bmv7fp76RpuQsKpXrVp/XpxvSdLDeKtRhwSFvl3qu/jA3GWihZ6K95PTgKlu2P 4ujOfmy3cBxRC0K1L7BQ5LgSh6ssS/01gYUuoAsD1T7BYubUghjw15S5ypwB4K4SB2cxCyYX HQ0V+LfKgk881jHZG3luWUvM7HSeeGL1axsGrvb/9NIvbi9w7OvZ++TRI6nB4ckioTzz1MCe SNNjEcfvnt5U/61dw8nGJLPVqW7MXBre0hFeYX3+YGRb79cnd+/65/4tz9Sf6lr6/OZt491/ +eXvD1eVWlnN4qNrl6/bVefdNSOfO7mn5eT67T/20XRhTaaVDLAvIBOqU0qOGl4xkIN5zxpI 7nHegI5jE3hyLv+q1rGKw9yQec066pjR9Ewwqz3QnNeDQCXY4ipzEb8eLaSKsZjFIkIGjm08 PIp9d/e83G4vaN2b6XOu3HQED/8BB/DD3ormTzNHr/xxYviVH4AMVSDDo1kZapXSclVFznKW gcUNIIQJ8g8+FwSwcR5O4RhuyNJ54v+FwFGTXxAFo0WP1P5AwAhKryJVxzeOjGau39sz1maX wwPshorwpu9knvwg804G9zpbPsHbr3wwOXySStCbOQWPj7eRiDqUsgiJiJcFhhdj8nsyw2Ok Vql0OUZ03qjkaVR1OkuxZcjCWFK4ApJBXbeO6GRpFISCaI22zUTTINNNYy34j1hLJcP9Jn8g 6wYlDvWcl8y6R+/mfl6t1jiNZm9dONC0eSRzar5jZJUpnzfzddXepfHuzVPURh14iHTC04ZB jYqNsEPzNgQGWUwTvkmGQUSPV+EYPozH8XuYg6CqeR0NqWgAgJdHqY4WpIFmPdhkt9g7CDtz n4jH6MxHHt7EfegS0iC3UogUTsMovFLn55VGfzePx/gJnvDP5G3bTefq3+l20715Pc6s9LM7 wWiBEqqqCoUuZWnVAoXOyzy8SRrAogxarfCIfbd4cwAMmWLKlHzCmAkBsSH+NSiFixWzjfEw MWYHM87cYDjmAv45eVeVwn1TH9NVafBCnDYGD7HZsPR63BiXYNKQsazCn7AvfPko+zOYC7U+ vMW8wW5BelSKps+sz7HBe+EMy1ooy88vSGGdYuQLkEtxEcUVc427brhULgNt1najPjSIRtA4 nNiycxoXgWrnrJlu10f777al59xsyS5lJS4tKXWUEo5gBhNO7Sy0zrMWWRnO5NI5NS5JFmXC 2VWGHlTMFfRgsxZqQh7USrGtB1tzgBj1lh4k5wLJZlOUVGRRUbHfVGOkh4coGMwENFzmWqgX s8dMwEDPkawLkdbnEl2x0YGXvv1+z6X9T1xuqe0PJIqqPKW15XXN/uU15OVb+GurQ2NXMhOf Zs6/+Ldf38vcmnpx/c7TuPbWS3GPvb4jMwo2ug3XEwcaE9AxxaxIMWlcuiGpkKRI5JvoICLa kAlvhVctj8eRA+4mWs+BegkY+D9Ih7ciAVoQ/pcC7zUd4Qlm+Zw8wqBpfA+Gr1CMWq1OMfg9 ukHdYd24TqWTxWlSim/OKdcdbNOnb2ZP4caggQZMLfo8/QB/7nZnT5X+qMlZbTALgmix+xuI nyqA7v82brWbgmszJLZIyFU7C5xNqqs/un9o56Ii4nSSed7d5E/fq7AVFVM/nA97PAV7LMJL lafUkqZWlArrayQFiEyJrkgQytVB9Qr1a2pOsT2u6sp5XOyStuckDAnjqOaH2u8bTmtOa6+x 18S3pQ/FD6Ubti9UX4gWeLuqZNZqkQVZnCepeVEjaebVyMvkZ8URm1qSCREL5Dz5v3SXDWxT 1xmGzznX9vV1bN/j3Djx77VvHDs/TmxDTEjaCE7SlvIfKGIBhpsQ0JI1UDATDGhZkonKhJ82 bVdKlw2iQmhL0ZRgJXVCt3YTYm2HxjRtU6euImMpg7bRKo11DW3CvnsdaLZqjnPv1YliHX/f 977vcwwWzkn0BkcB6IWXdBBpbUwQWJ55YaeAhQxXycxU73rGidUQI85RrhIKdzSNiVnO4KPM ggzXGqQmabvUIemkDOaZxOBLuZCf+Tv9XLO/z0/8zgt4EnRmwYzlNZHtpIM8Q94iV8hV8g9i JE7fKH7663ker81OdGIFyIqqwpqYSiRrF04lw+OqX2ltgMAj1Fqbovr9F60gOJzcmYB+qGQT xpwyD6FslvGBqqyR8Qae8Mrcqqr53OtNX43hTdh/4vEtJ0NB55Xe/g9jS89MLsAtWxsXubB+ +ssgrsfHX+s6sys5cukPPa2tLw9Nf1ZN56gguQY0/C3o1ly8fASZ7oydN9cIKpTUmmvqhIdM i3KWFequCLi0tLqUxZvjV+Jj8X+beBTHdUJHYF/kbNFI0Wjk3cjVwNXgB5GPC28GzUuMpRl8 JF1SQlGGjKd/F8OxDBcf4vQ0H+dn8MkhLwtH494MfiBNLaUlF3AbykMC+RvLWQUVJj1ahaFP 6QEzNmdwD6xXdFaQnoq+ClIB60NNfAd89wz5iJlYHPfF346TOLjagjeY9JZEJGelaic37pVf q/1EInlLvYwD3YGxhCd2LpxITOTWRLMOUxWJyiGTqDMUKgGlSAkqOoM+aA2FTGAdUV1FC5ZF eFJyiluwSYgYYi3YZ/GqXkJrZ4i1rAtemoJ2omQ4LFVpjgJ9yteapcxEUAFIS/UWjVBAWgFV ZWpn+bb7Bg+caqwf3d+547npT7o3RxWny7anIFj2nRcDLl/42Ep/w8nFXc29bbql3S881rDh RyfmDD8x0PXqg8XecqN+oSHnxNaGZdXekjrZ9OiBhtaOM6oWW6C7e/XLkYIN7IHTOpy7Xv6u 3KHvMHR4j+iOevl5ZJ6yllvrb1TaPbv1ez0pcsh1yHOKe1XoC4wFRBTAIrXlSvb8AmMepAiX wR5m8ysQHzq/4nJ7ON6h08PqybTfr0ijoAoHJzGzxYKvIXJNUQCYR/EC5MYPD3XyfWrX8L+g awHMAs0BEoBxmBympE/BivohTPAz2kcJdRaO4hfwTa2F4wmwLJpQaVFr5Pg9gtTaBw6miihl jIT1EFVohgCSoB44bLGcdt323C3yDv0Orz6xHsCAV3id2heDYRYXzLQEOlKMub0rp9vWY6H3 qcYDq7+3d9/2SMBVHF22YtfgicPb3sQ6/fKzw8UnDmbahzuL56+Z6wlTJT7Y8cQf76vgiaim 4jqo+SAoyoFK0AQr2yXsNn3f+kPhz8GbQYOBw/u5fbp9+U8V6GqNJQY9F3CWOA2cv8mIjaCI YT+gd0gEoDiadiC9Gqhp0QKnLczUXrDcHBcqY2WElTWX9ZWNlenKnNn6wp+QRCW/FJOY1CP1 SbzkLP06Vr8CSBqfyVVNAGBCUD1gdBXAszUDGZR7gkKu1yN7iMEWtISCQgAGnbpbkGKFpyJT qAV7cv0tqNAMF3Q3SNXZ1yYf260cf9ee1CC1xXOLqiqxCt53Swwexh078Mqp9qKeZw9fbn3y 8uFNv3gOi1+0T13OfXhR5ZLG7oP7Q436tqCl4eVfd28eGzh75OzGNPYO48XT66YeTK1p/mt9 9PTx12/71VoPAEv1cAPAUgWofpBzZnCQeS2tVT3OPkAChngzlExkdkCseI+9z07sb+IgdOb3 wNga0d7SHHmGZ8N4FmRJs4FLUTELfsujdfXqnRvIklekbkqqzz7Vq/t5Gpg2ww3CfgJoM3Mr wV/aWqsuiRcLidniluxUMA87zOq+8jLcSuaTmQPoTxR8gHxVbnqfqPiUToVT3nE7i1QABANT 4ZZqPDYFu4zScS0r4K0O+X9tmPs/xItdM5t/9H/Rlxtk2b2z27e/CcEEbbzzEXc/nG0LUQTd GBKMYoyQzJ0xVh2bF4/GFsYaYk2xJ4XDQr+533XKLYSMZouVo/mcXvHpsGiVTAa9jqM84RQu VN4hYYjT4SHTIieHoEiPMHeAleaA+6NQOT941YtFL/amQnRb/vXyWAZveyPE/OWxclJ+gVhQ FMXw/LTyE/WI+Xli6rp2pEwmJ2yqB0BtPq8FP0jgbJ4W1CDtFDl7tF0FHqPZHcxxWLxIcPFe bC4webHRAxeUneOuLnUCkhgSdv6so+O9+mb9HGzDwM8ejUul/JwVtUWplsYttRGl7KFfnfnt psV13362zj4zK5j9oP/55N4FHcceiQW3eormrFma/Nmede1Lftx2uvtWXVQj+Dp1eihC+gGo twf58DnmNlpF0UJNsuBbpRjsokRdNpfb7XF4DQok9PngPPWWjq2La/dwRLufL80u+0PZZZec XS7Qls/btRt7kUpxi5gDH14jLhUX0SVyg7JebKRr89bJj4mttE3eTTt1KeshMUVTud3yQV+v 2EtfsvXKI+II/blrRP6N+B59x/ue/IH4Pv1EvEFvyJPiF3TSOymXC+IyN/GB9fhkgryy7BGs JreQ7ylw5xsJ7zbabXlu+x5ZpH4qezyFNppn22HDNiparRnyLrMRGU4rss/bj9AO3IkJuOEQ MxupyNnz841GwejJ4NtMEOF/SL+V2TIklm6QsZwhnzKrn1lXWT+zctZX/O2HNIk7XSAhh0vN DxW+KPzA9RYkylRtypqNjVTCGnGEUwBfYQeiE5i+/c1riu6/WMvXwlvLl/DdF96ZwAqveRxA M8zOfFyJswStCTKHcK9N/XNj4f0t02vXOisX4A8D+P2axJqpm6trSh6//im+9KeGYl+UDwZF R+x53cYvjx9crQ8GdRGlvAlbSNHUXwCoQYNIdx2SXEZhVE3Ws9gGtEHuRgfl7sqXXD8tPuc6 V3zT9XHx36PmarTvP1RXfWwT5xm/9+58d3Zi+3zx99l3Pt+dfY7t2MnZBlyPXCjfLCTrkhTY IsLCx7YyESc0QLsu2dQRQK0StQIBUzMqisQqV2VNoQFW1jJpE+22DsEYsD9gGjAQZO1WBlOp 3b2vQ2gnJe9zec+Wouf3PL+P6DZ9f9M+/ZDyun7RfzF6UbOQ+Un8HxP2Dbk8GopAOIOq8XeX J6MbUgIePiHTZMgaPPhgZr4yX93pvwQuKJf16ypNKkC1NrGEi+L9TsGtuDVXuqFpgbI08yRY 4VsV3YM7WIzNd4JVSk++Lz+cP5Bn/Gl/UzsGt9+vCJovRVI4IXiENn2Hsl+5pNOhvJFvz/fi vUSPqYfqoXvSg9SAf4DvEzYrA9FntOep7fx2YVQfzn+Qupy6rXym+FYydpE3S2FW5N2SrCsY QSawbFxUiHBsdkInGsJaNmt2xzSPx403aGhQxqCaoqnPZ6tlHirDE80tGfTnxOMLq9Vwwvuv rw4Ai5AO4IFOMi7OTjSiF+yCLGeQB0gcg8dVkiDRpcXqyGAkCJGAnARnjyXCrH18Tv5X4Cwm YWuAF8pKfPndQivy+PHu4uMrjmONRPIWXy1TK6FhLKDh65+qzk5/1cyg3yqRPWQvxzRvoUwG masllZE1rwBoP+/jcYqKKCqu6hHNG9FBim7UgSxEdCIDGnUiysd0kDY16JgaDOuY0ERkdegA oEktPBLrGa8Kuougv78f6y9i8YcvMRQ53NPuSJayetOsXDUBQpcqIecK71U30vFpdqQdDzW9 GkyIt15cuGb4yvXysN6peoLRVh1f+lrvnvEflp9VV8956eXlp0+sbd9cPHqq6/To3BU8/rYw 79s/XXe8U83J/cTGH0kJ1au8s2X9q3aabv5J65bD7geb+INb217qIE3IyS794m8mO+RGBXtg zDMLKZDCU0RK3GPfJxy0H+SO2d/hahgB/vfQYD3r2up+kdjlfoXY4y8RJwlzLWEj8eBiYiVh SjGsQ+FhXDAdxXkATmCTxLJjof0mLUCASfzKUUf8CAvYSaLl6Kj151bcOkmkjJjTjJcwAEAT W3rTAURHswN3+A04XOZCyAvsXtGLe5eoa3unI0d/Kwp89/qL0GsVkTjB6HH3RvPUnbuQRqag cJ2p4hpy8VQtrfojNRG3SvHmJFbrggfjMyWBxWNNYtgjyCBa0ND2Q4dVJ1e7jbucHGr+LA9F yqEoFCJOQfqEIJtFnhXFuTdeHbn83ODU3uc/2Caur3xysvLm8V3HQPO7L4/Wc7zTX2N6qqJ/ dGxn5fyVycq/x4qHnUcPf3bi8w9Bx8nF7jo+DdVIhmqEsoMbDvZHxrdq+JrgdnY3+2fWNMgO OkfYvXX7XGf4M8HzLON1cM6gQNAuMOLfIeAaQ4k8JoVpkbdKskfyiZrNZsV9mtuNMYFCGwcw juVCXJozOBO3REZr5W/OwlgQkkGfjKIHIUse6GPGw2umm1poLRdaoX/th+oP+/vl2syZWZOA X7C7WNUZEeyBLuB3wSPoELsAX+frmukk8qlw6ruL+v8Pd4jkXCwMaVHYQAxyGZxtWe9S3AE0 xRpIg6+9X3q/8vRfh7pugqbKHz9ZNaDOkgaIjUOhhLqrcupc5fqp898JgIXAA3xgfhDNaz3k 67dh93TsY6PTyG4IbAn8LP0Lbyl9Mn01y3T5+qg+eogZMg9Tw/QoM2o2KyIflMKqyMclmZFs NtHMM7SE4yLF0wGWx4EM7UBQxw7FG7Akm8STk/g5Y3EiEYezcCjI3wwEgoy5xDBUqZkeonGM Zuk2mqAHG0qJuJhMwS9s9JdCvMFf4Qn+m+3ZvuyBLJHF2LCqjGeuHgcjVUNcKBfg6HZP3e2+ Vr7X3T1VYKu9vgO1EpZKVTQhU8GPIR/KTt3B2P+A6YJwgPwBTZiEplB3yNWEKzmckDPQrMI7 YppVvuw8mmf4BEqgfnM0Q6mqzcY90Vm5wGqzbwx8Nz23RXv6we10Oh7y+JWONOmyR116k7bO hJdvyg2bK1pvQNYqLauinlBq7nOVkuphjV6i+GNBUyt/eardZYdISBAJESKRBNgvtdQkEIxZ 6tqcmTRbjqSIvfET8d/GLxHn4rfIW5YH5AOLGWZFaghiM2wapkYhNgxtMdfjtFRbOwkihpXh 6aDIe6QwBcFBNzETT9mqmiSIfESS4wnNwtSSJhxCVmu1epKYHME0VsM1hJgajUZwt4eJxrUS FgNYLB0zYn0xMjZGUSIN2mjwaxrQyPFYMFtYCI43fGUD7sIFKEBLUyxfg6hAQP7Z/QgPCAf8 QajAYa8iUp6pEBdIHVCPgAPhAJFpwGXZ4fSgVKa7vsL0M6DA9+Dg/c42q6qC6IL5960WaMUb yyfSHRGv1SJCpIl/WWX/gnXfh0jcXrapkm1bqla6Nkg+zquqjaFniI3Tz5ULq1dqaB8WQ/5+ HfJ3Bia0Dgu5sAH3Rf0aznpZHx7KGbme3Famz9vn21o/5h3zHfEe8dUkU4M1IzWEN9fgb8/1 5V4g3yCv5shaYnvNezliMQO77f00zCEs5EyV0SeqjA4moF9aZsQb9yc8Xm+Y0hKETQubQVwU wg5HOzfG4XaujcMRBw1xX3Akx03i/zVYS6E9AuwRMYJHlmTX7prh8vK9VLXr5cK1alBE3WZn qPwh92RCcZplVC0ai9ZHCaoWSrRdcjwGQiLroOOWJGaV4cGGbI9h5iiVBDWqLYlNiy6yo0iS pzk+Xl0gJMqI6SEaIWQsp6negYQ2K7lQvnM5oEJXeR9uFcp5nupHyFsQvo5tpyrlkeKeT4eX vdAitjyBW33Lg86BqzsrW36/r2v9W7s/XLpt0+y6Op6AGtBx4BtP/+GNj09X3tsdUcGO9c1S JJJRf1BZMzf/+bv3J177zfee9MZcsg4RRHrwCtyjBdjvjGLfogOL/rTo6iKybtF4wMi1w0cc QlEjhcP/I7xqYJs4z/D3fuefsxM757Px3eUC92Mc2/nzF8cJOHHIhRDSDTYiQUsD9SBqtrGW qknEf9Qt2tYy0m1UWlvGfjLE1qpoaKVhpIF2kEldJdROy6SN0g2JTIIOwdAYot1W4mTfd04I Qapm+/x93519uu993+d5n0dTywwzrak1htmuqSsME2uq14gENVU1IpTfqo1IvaY2GxF6y8jS peqK5uaiIi+uqa4uK1N5MWhiy4TLJugmMXvNI+aEOWm6zDGsW6VCx9aO8Q5O74CO9qhZ35ne msbp4dXdl+TKLwh3+hlEhL5+GyX57LzWp+8CRuYEEBXw1OpR2T5f83ZYaVwfBIXx2TCZ/Qu8 gndRfFQSglfZTEUBUkVI/m2yvlzJD9mXavNvzUKHXsHttaSSSoYP4NvbCoCRhNaeqZfm0QM/ nX78Piw9ed/PGJbqqFncQzOhoQErZ1jxesXoDvQ08JqKDVPWVNEwFU0FI+LR1IAREQOUinhZ MT29/CA/yXMzPBC+k9/Kc1v4cX6C5/huvdcYNCYNjhidxlaDGzcmDMzC+kUaSwqDvj47uDbp FAJYWRn9jIjMxRDveWDTNBx2MKILGILNp16053bfnPkbF6B7i6ARq6ldhC3BLSHcI/VKzxb/ smQ86hRlIFErikv5wnYX2xsNy2VCWMGAScgK4c4QhMY4rxVV4j7P4jLT4yG8xR/kf8a/zjvP 8Zf5Gbrl0uhlKvQml0bHcO1JY/Io0+1XcoxcqdBgW715M9fXkrW1+D2RIZSq3uLS4rImKPKq RUoTohSbtaHbT7VzX3A+BBSfpg3POXDOhel9OxJy2y92fGm7YlTpdTFpqZq0A+OM2dHIf+3w 2e/lsrWKVrG5YeUGbrgQHGAe0HmRxqYNW9a/Bvxn/Xg7gm+gnXjAv4vsrd/XcM57xsc/hUB0 tNfQgmjAD+Mv40F8wHoBH7ZO+n7tP1N3pu3Pvg9SPrEIOD92YWfqebQ/NYyOwxH/H1N8EVW5 CDuLNc8SXwWKQtLT4lnn+S56N/0hup0u8RQpRQTqcZ210upsfxV+jl+xRvGo98TK36NLaAL+ hC9wN9ANuAUfe28V3/bJ4bpwOp0i6Q1wGL3oezn1Utrj8rlVF+Nuw0xqatwws63NatbpcKjO EpvLNU2NGZGmdKPaBAiZfl+IisdWhMbweWsDSYcISSPwpVud7QS1ph2NPsDFRV6P2+3v9Z/z Y3+52+F2h8PKcTnb1BSPx5obGxOJ8uMxWZJcLmcMO/nsDxx+QpKOQSf0OsE5hpdbxZav04cH fXDCB74x/N83kyWmtmR4VfvbkLWNnTJn7PJZWiL91N3ZvCLQptAiFKb5rDD/Lixo6eSS1MrR D9Bjv7+m8hnhHTrIbJSRQNvIOG0CbFiwoAxFZSrq62971PIk66pbkyur2xy5rlxl22OPWt4G Oexr8eqhTGpsZnJUyFiCPwNjM9dG/BlEz4zYq/ERga3G36BDgfdov+liToKqAQiHJQpg27/F 4P+SXKBhGVpm2z52zo/dLjfugTsDv9qYH2isC9ZPV9kVXJM/ex/kV9YkqzQ5tBMSK9SKlAa3 qx7atjZ8Ct+aLhnoolovJsvlafjD9JoFusGUC1xn9Ux3B7eDsDm+RIpQHRJuWR06TVGQoHru TYoCHT1nqQISQEc6WOZG/FW8Gw/ph/Vj+mm9GMwx+L5V5+9peBg/tgRTJuQMM7xMDTSbXk0V jIiu6YggC3Ho72UBAZdFMMdTGGzHY/gdqygsUdbwDhvduVnxRRN65w7Twsx2XMkxRmBtpJ+1 EYkzFvqJReWzrcQWvg2Ol40ddz+qeyS6yDYUX9m+UReKU996/Cdf3wa73dMvRJfrO7gnmZmI QoW1d+r4em1RqGZnAfGu23SvBH5rXSuRwY94ya/44iWJkgoHcYvN0Jzskp+GbfJTyb3yIfhR 8j35L/I1uCH7fDJ1kS6ymnANcgPpkLkwicnlhHPJTiJJXCVK0FUTapQycr1ST1pS61Lb0D60 S96r7CBD6ID8LDmMDpFj6FVyJHUi9b50Xh5PXZI+lCdSN6Xr8nVlMvUJ+lT6N4k+BJ+TVic3 QZf0SPIJaY/yrvw7ckG+QK7KV4mfYtpjmLqmlhpmjY13Kgd4IyLYitmwsc5kGoIQkhUEiiwz oK8gyRCRJZKUk5Ckzy6VKoqEPTyPECGxOE820x6oJGtMXTeOGCcM1rAmDZcxbKUgBTSH50eF kuFau4Xdc4+f5NiEUnpymiZyFqkFfUDxGcjs52sqnQyfPMUnm8jzcoG2wD6KxxyDn5oUQsUt UPgSMrIcyMiCmEG8nJHGZiZOSRmJhDLMcaLC0QW0Oxg2yhZijAk6gPv65n2XgVudv6NGO8l0 nFAvGvKvWQ+D8A+4AoPJjdSbRjuT+XGyMRLOf+zYObXrGa0iGk3r/dyuTfHFsejdvzrs5dTQ vQtDd5+nHXbm6sx1qsTXohgMWWuGRBAPAmBrXf1BDOJiDDFcHVwe3BP8Ib6MZ7A7aJqiwASc aTABZ3Isn5EQy2dEFAOAsSmaIVE0Kd6OWiWx4+D1eACrpbzo4VgeLL+4PhDQBSJYAicMJygh WUJLvZUAPQFHEpMJnAiG7N8ZBjFh3ARTiXcfLcjvQi+mqevrr2TZEz5inbmlkLSbN/cX8oWo 78nYuXILWWZCGWvGPaIiJqAFZcR16PPiFrRJfBo9Ie4TfwzH4C04Jb4Hn4L4TwxMcnchao76 aG5PIzzz2sklYgumz3mSkqxIWXWUVodVlmHTkdlBtYdRJUOFFZtetErEjBgWM1hYRA8lE6Tn Rooy9DYTheE/p0IZbAXmqJhxsf1i5YFyHK2O9AIRFXmwXMoZI6vQyzWz1MNFVhRLp76plq+j FcIqoqm5aXGTc+2Um/PP5fzuAceqqd/cq4DX26uCHgoc243toW6sGKnoDav2kPia+5j3mODY DXvd++E7bkcb74sjblHc9T++yzw2iusA4/Pe7O7seo+ZPWzv7uzO7OwcO7vjnR17D7OLY0+E OBwDhsoiYNk1ERFxBImPGFqgCCgkhjRKQo5C/UcABagrqLhKMBTVTlKi0lKFpJVKoCpEqqJG qQuVUA+1Xvre2KAeUv/YN2/21L73ve/7fa5wC0/mSEiQDJkgDdIk7WR7HG9itK2YiJtxGPe3 MK6EC9Iu3gVd7bGn1z2sTtPLmCG0bWhiNSeLoJoAS8tuJaoEFZ/HnyVYEM6CEIVmdXY0Y2q8 WRCBaAg4a7NEva3WKkqPVkvbhY4icnw/Qwh4bC7Vo9XyMxixAn4mpcBp4AS7q1urX1X/UN39 28m/vvf8vlefOzf5933Po7ozUP119RfVfvAqaAELrp1pHx2vXq7+6NxekAGPg54Te/HaIM+1 aRZdN4DlFwkd/dU3K8Wcvik8wo7EvqUO6m/HqC3hC9Il9RZ7K3ZTckRSjK4qZbmcmq8aenfq 2dSgvlN3f0SAaCwd64j9JnKLtY+r4OfSZ/U3pc9SN9SvJEfMFOOq04fNMAl4lhJEZJW1gkjE Ew2ZuNomdopQFKnajFpXVwudlDNARJmoETWjg1F7tF2f2wJCB6Z+WoeH9Cn9uk7qDSBJ+97J 6hPgG+eEp9Y9gpaHZ2jZAqRxhcx+yVqX6TUW0zPTiFRyvajclgOzyYa2Kial62NhWVXS9Uoe SDE0pCKZPJBZ1AfntmTXLqK9C3Exh+xBnG9Lcon5aGN4Ali9ltB2WbgxjCptL65c/+uAWPFN 6B+GMC+n6ixSxkU3SYGjMWVZYebHKDdDLMpN8Of3Pn391s8ahx8vfi3ef2DJnq78Critumkn j3JzHj9CbsSzjrNbj1/3La6pObJz9YGOINpP3Fv70X6qRAFMmhOjSRB4UbkiXsmS7dL3szDM 1+vrJdIFXLIiLyZWgwE4IG0D2+AL/AuJzclvyi+D0cTB7AlwQr6gXM4+kGodiT3gFWlPakw6 Bo7C49Kp7GT2hnE3+yDrDRB1IAoDKtqnxopeMdZLz+ZqMk4Yi4FanqWFJCGrLIGaiw91Fp6N CaIJG2RJSkIQQiVNOgkTkMqkj1EMtYJaS5GvU4cpSBHsyVhhAuw36SY1Ho9B2udDmO4MCJjx VhfxxRQ6i4RwSoCdKA6hcJ4pAbM0WLpeIksFZ7Ku9p3iUxcthp1LQ6Z3GLmrpmE15GbVkJtT w1woTk8zSA69wzlMspEoM/2QWkGgHA3PYao2yti3/7TRCGO5ZBs5kZezYi4PGjk06MmGPCFK RqIpDwgNyQFYggHDSBLDVpJeJGQEqx4Mq/fOhsoqhtmQZZ9oeu88UzYYGhkmmPVJlKKCACyd /D8dURhtQdOckpCQ7P3V71aL+YSXY2LK0qKlKIvEwJ9u/PK1d0+A8NqXB/75WDDm+uDKod2V dXArBKC6+T911faDTdsnlOq2l1Z74Ftg/Ns7DgURn+188LnNjnx0HnzSjATebgA0oKGbJGib SqTtWifohC5/ZQIsMq+X5pWiJGvrC/dF+qJ9rMPutfuIzFTFNuIe8Y74NtOD3CA/mBs09jlf co96R3176FFt3DaeZwLevLfgLcbz8UK8iHAIZm0JLsGn09l8K2iFbTYjYnAGbwiPFR4rLvEu yXS5V3mfZFalV2lxHvCQzfNFttQV7op0Rdc09eR7Cj3FnlJ3s490u9NBN5sW3YnK/LRRGQ4M B/dJB6mDue8Z47kp9f3MR9pU5V4ltNw5jyUGIHsKfAwg2AEAuERMkB2mtzjWGGPjAzzLcZfi +JlCZCyU0bQWjy/k8fg0T8ZnU1zWxSGCGUSzaiMpqiEXPAlMLlkAgFeAMgFEk8n5J/3wth8k /Kf8t/2kfwKOXuBPchqDTiZ+A39IB5P6Xf0BMjlzcdHUP0Y3JKEndANZn02/DBYRZbAIhGdF 3turDaHgGb4/PYPr2nA5p82mkOV1GPfm+phvtoj98T7S8zQifDzrBcwQmlsuWJIMKqgq7gZX nkjT2AiDaKAMdFuT9eQJt6dBSzHIFmlfOiMHkDU6cw4seM2yQGuYTS8kfST8Xtzo1rnXe59h 1mm40QHky8QQYZGlxx2myzaDLucN2iKFNcAv6lBMOmpxQ+Og5ZOYG5MOSvTnOTir8pQiKUqx UMo34SAsNZMn5EDvyZ7+vVrrlz/5Tsfdy/ML/IfRSJyS5ejq8xu372+upKpH31x654cbt8yr jwo1KBu10cNf37GyNd+xff1zb60cu+2yt3E58Mkb+9fu6W5a38B9OPJK1xu/Kkb4HKJIohWl 5GkrJa+alW7QDbvj3dwGsAFuiG/gnDmhTegUDtoPsOP24ywFQZyrw60r6cIuKFJhkeAhQzuF CThlBl1AI8x6X1uARl+3gjhF2IgJqF5wupL1dbzGYXvz4ZcJjuH6uMOcjbsEVaIOTp1LPI36 GfOX+73Yxzjkhu4ifvtZN11Aa6f9nmlBtc1accJ0F9Hj4fNfWLE304JijLnKXMWEjxIqKCp4 bcX/shcMZGi5g7YjtOIO8s90TSLoys28jwns3T618ASlMPal1Q+6pErzP+4/pC2bxxfc2ANa 8Wq5H9yxn0GrpYPwRcJAZJnJFQxMmAnJuppddbGC6qg4ljq20DZZlFNNYlNqobgwdSxFpVPl FFxhjLi30WOpydTfFEeLD0UIFJI8z0aEZIZngSAGeTYsiKg+oRyBsup1ZdKYqgMul9P0lJ0m ojWn4YTOqPV7ibYiY4BB47Bx2rhj2Aw+kQwEdgTBQBAEI7n7c/jda+H3coQOiBzQqcZ3+BBZ GTHbjDpWbjnT7ETnRBHUGn8SVTrooOWULPkSWYLxK550FrhrBEbOEqpbxjAHrFOBPpzBBwIJ nxjC5wM8It+Qw/J4Bfn6vwNxyBL7nNuTn4A7+RVa7crpa7/7wkgsXJaHTxS6pEh86Wv9L366 DLm7PSXLC/ihmZvXPj8y9i+6qz62ifMO33tf73049sXn88edY5+TnO8SO7kzsdNcMPWtfJSQ AC6wkYAS0g4KFFZCYAjGQq0VSAPVlK1dVzptnVZVkIx10FBqyqTyx6T9sU3qP5vYf1RiFKlC ijSGxoKdvWeHFe3DJ7+/u9eW7Lvf8/ye5/ne0N9x/8QGTcu1jlcub/zD+LrDH93EtVfUtNsd P3LDH7hYBr9yGjkfHcf9QgIEGd6eCYKayIZrIjvXlcvWatqsVefHakv2b/6F+HyC+CR0LXxd vpR4CKmZyEX5N9RV+hpEOes8PQNnpfNB6idw2jftfyc4naD2SjtDh8ljXClBbQtuDRUTu+i9 kNoOh5jt3Ih3SKKcRBHbQmylNtOUmsiSPdIarM9LaXQbNBhDMoIU8lgJKzGKQi+FUUDBfJKg +LxMg+KNh2JKvLw46TQGIa0yECLxDyBdpGjahUMuGEJXobgPeQgMhzS7EAKhL6ygE5wOzgfJ 4F1LcqSidEmalyhVGpXGpJJESmX8y6tq4q3EvjNI+BEsIveHbw9j4aUclp+k6mMU1XDtJIUG qmsP/ntFRDs4/NWrJuzIF467w4/lwn7b5/ht0o1Wgs0wog1RjLoq2pwhurs3L/vsx0kAuQEg 0RDJfQtwWasjoNDumASgPhH1HPXBWi3XVtW1KqkLkb6n8faRnk4wBByzdzXloQa0hkRm18IJ 8gfbAvEWStPYztZlLz36K9F4uKMpxyMWIWwoi5/DCYQNG7/gRFi6AXoYjoUcZ9E29HvDou1B b8UFBcNmUS25NYqqs4hOutmcuY4dIgfZ8yydpFNMmjc8hmjIbUq7oWe6aVvOWs/Sq2A/v1bZ Qg/CQWaIG/QMyoPWlsxeeifcz++R9yj7uo6QR+gj8Ah3lD/uOS4fVSaiR9Vvm6fI15kz0dfM 16ypzA/hOf4N8Y3wOflt5U3jR+ab1gVmlp3lZ+ULykx0tum8OQfnmI+5snzF+p31kHnIP2p6 qK7bY+6y9mSmWLJH2R87EH+5g9wFdzF7WKKfHYivNfpNckjZaj5nEUVYZLbxBAkxDvmGaNBs j7bFM9DmWTYaZViWiyInEIsxGI3wKMoBxZFEw2xTDL+nUfHrsaSi25kexS4vjs0pPKeWFw84 AYuBqofnmxX0fUWORmMsx7kwlZQo2oiaTQzTbJkByzIzNITuJ1Ergy4zol83DBRWMJznOIaB 7PKf0e9n0GP/0MllXMb21oqT7LCyVqaUmc4QGzM7MqOZsdrFrcx8hsncZb5gN/HKRzL/Ca5i MvinwzueouczD+E537u8jL80V0f8g+F7tyPC7bBQuV8zzanKnX/75FqpU2DSO1GnwFcnzMQT pPj/rHhyhYI3z6ADCnlXlZZeaEq6iQuB32VKwDCCDYWYu6gWWuJhP1+oR7IaLZqXeLFEjfoM rXFD1PVk/Xhic4kwLTk4kXsmFkhVTxvV31f/2Fr9VocnsHo5eBDO9aQB/7mhSnKDGImIbbjQ 2pPtACTA003B5ApEpWS25eTCdeKbj35KvngilNQ0zWpuOVGB+OT49mVJscHP0GirreuVShz/ 8rtWyGC8mjt7RZTOZmrK+NYVCgP+mjpdKOQcayQ8EilaZDp0PHQseUw/G5rS6QgVoXHMkqBk qFbRoigK3akh4WQCU0ErNPRWQ+u0rDXAsZ4Dg3BbbNAoWofoQ/CQcah9zCqBEn0SnjRK7SXr 3fb3wHv4z63fNv2p6ZalnqIn4aRBAIgroG5V4klViWNGp4LVTUss3KTEWpPhUAgZsAB6jpBh XES26Qa6MsLJkGlAizGgngxTcQFgWDwec01OKNjsMOxFVXdvzd+QU3VLd/SiPqaX9Gkd6mX8 7TnTBVoESW5KruTlsCuzS8N1yazatvueJJcmLbkEKhTGllCVegJDqcezdnj44EHXW4JxkKrl LWrxluNFiAGGixh3CaNhiyIYrBf0H+9e9tSsJ1gasjWYIDj9hykCyf8BIiTMn4G/yPLOTfnq tWhyU7pywzVJ1defMdcFkviqmLlxBVAAl2/q7kag6fzG85VK9eJjxwS+hvfsXNbCaVo63TpS 7Qe/GOmMpiMIJTJym7MIJY0Av+J3kEdxH+ULopzt8fUIq6h1vtPkVMPH7DXfNYHVwAZsNdjA 7SRfgKPiYXIcjomnyVdhSZzBZrj3Gz7FyuBTrtwQ8AkIPRRB0I0UzWMANLNcAM0xVmA4gKFd N3gQjtPFcHxLYyOGfFULajnLqLRFO/S7NEnLplgQN4qE2LhMFYDwfSbiF48l9iFPmtpwfz0S SWSd7gwLbjPXV9x+VvLCHX89e6B2TnamUAsx1NfazhNGNOUK4hVMQJ0oL85/GLC58uI/Lgfs ek9AAln8EJHIgURz3Zi+8+gUni5N5RLOwiXixeqG/c93SckoNbBAj/2Srp7TyD+bQ98BmzEc 61u8R0wRv8aWYSvwrzsH+OiZLty/uRv41bhdKlxgr3KEP+WfwCa6TmNn+bM5uskf7BUKpQLJ RgeoAXq1urp5oNcpTDUxnBeqWHMf6Of6+L5c/1Mre/tWbOV386fYk9xJ3rcl+GoQjxd2FPBR pgvL5jvbOrLXkTZ4MM/ijaus7TF42+P2Ue7NCWjs4u7sHfUQaq0c8ZCePMLmTaeNtzeGd4QP hAkz/EoYD59A3BK0GLTyTh7Pp8mxjlIH3pFrS1tlYo3TSPKdNzpAx6iGdTV4PNls13WwG2vF NPRDAa+NaXGtpE1rpKPNa3hJA9p1fCUGMQlJRtyWymC3E1NMOwMdr63CIixBQoBgHoIiBHDl 0ytfrhvjg+PjqfUoIaYEN12mUJCoy4DwYBg1+37l9rBw72Dh3jj6NNVou19JpUyUO2skrsXK Z3PLoy2U+FRPdw9OswzH4PS/qK762CbOO/y+9+3v89k+2/HFPsex49hOnDR24gumMdglWQZN NiAEqBsLEN2mosZuiwrrhCnNUKAtXqexgkoDG2UbSCMLCU2qbU1XUWjLH9mHNlqtIpOyr9JI qUarSSzNfneO1u6k935+L7Lie5/f8/yex18n1xFM0qDIyFprk5Bgs/hMEq4LrKEVCaW4hIyT CYMg8RI218Gtk0lLKlGrCXPVVUciYKsPA9+B95AsIVYOTnQJOA9MjiKtq1rh1ZqnV+YneK1c NSsdMrxslf9Q5jMGg+KSDYoTFjiZpUyNAQyYQekIq1UPVQ9VB1WnCcWXr+0oHwRJBv+eTHS0 t3eAJmju3WmvPtMSqlMENy+Kqo50ODSvb4XvgIrAI6L7+fr2tUPf9ja+9/G2zV3BEBEPBePj YwcfXCMJeqeFNzrSw3tbO/EPY325gdTGZ/dZ3c98K9uae2qgfnRvXV2ss/m+RNNApdG3Pjry +TtH1thZUzp1Mvd9nE+7YwWlZwghYuXeygI5Q7+AROiMpcwBPoTPM1eZKfYjH0WHsqZ8uxx6 ktxPfZc8Sl0gL3FsN4s7OXuDaZ3Na8+5nEZEeUQEGcG/nWA9QZ3B2+qjKzRRoMv0ZZqk7xhF hFz1RiNv6jcNmyomqgy3cROJTLxJNrXAx1nTnIk1Qfu/lk6aCsHffFVrrCi0ipayoJWW86VF NWwtlrqsTuXTxf/gT7XOCbtl0sCGZNIr4xq9S0Jul8EocbDzUX4Zuw0eCdUyHhlVRXw1qh0+ DP0ALaCOAgABQgFbPXlVtOvYhmCb1apC0r6KGF4zcvr53/3o+KX+VwcsskuKmLGtqW2fsvPM mT3JZJj4bOaT3979Qbmzk5x6uaeGDwwvh5f/fF/bjTfGf+Wxg2JvgBPuBZ3x42cmOQoLAZXp j0eaEiignq/TtI0mJNsWajOEnC3soGdQYh+h99NlVPZPeq7Jc/I8+iut68DdeMC1VRoKFFwF ab+rJB0TXrBVrBXXBXyeuBy4gt/E19nr7n9yC9JH8l3sYoheYZtw3HdcLgeWAqxVxr9cmUcy LB90PKpFqka0AHIFf9lPID8PQaofgtSwv+I/6x/3z0Kkmvcv+U3+vbW3LdhyXQzq2FqQIdBg tWRSglLbShr8N31G3Gc8YSSMcR61oAwqoGFUQeNoFs0jnfqAQBcfrzlSQ/TX4LEaXDONjRlh icGI4ZnqBKGZbF12hvge0qAvFTct5kvF5WJ+oagBH412LS4WNbFZEEA0UqkUTkF6UiFEJc0I woRwqeFjCSISzfMKVp0vr5J49hd8lZsY5kURM4A1kUwgDXj43KANb5WY9ioNyd7grSMv/wPj yaM/b42t8VoNgcD9e9Z+7dzorgc7Evihqbcwc/sWNp/YFIqHHPt93t5d587fyzYfADah3MoC RQObfKgJN8+gOISh7u5EXEV8fbQ5UYg/TT1NH6PK8cvx2TibiZfjBIqLEUd0K72V2xI9ybI9 LJbjHfpu/YD+JeonkbNxdja+FCVkGcn+1wE8A6jSA2m5T35Y3qt/VD4oj6Ex+SI7w74dMYQ4 W4NxneC15Ry1DeI6yVub88HXDFTMgSDTsb4YjsV8pMGHDH6jrCq84CiIZfGySPog9RLincZ+ Rg1w4eaEWl/rTjLZ5uyhKiFB5pdLeRB49YI5DmxcVPnIa4RE/Be8rAlFKa4hGOIaZRSl4BZm gzKO0DGNibjKwXxKhRFALOJSMR+NBpmqLgqgi8kvqFhVRycdSFqbif/hRFzPlntPzv/7rQN9 QMmaqAlbmyx+0dNk+HypmUnvjg8+sHP80Z2PbFh779o13L3pZ2c0Zt778Fy3ZA0U38G3csNK 3zduvPsnFbWNwNDN5Diyo1oim3ELQ668u4AK9j+StFuWQP0lRcxIik+FUZ/tTXA+lbg+7aTC Ce3xzkhzwsO4dYO2h8Uh5w7XzhoWkzqG1XFG2vEVZpR4jjlqPMaP1P6YuOSasv2BeN/yAX+X +BdpE2DmcjzLcwW2wA3DmB3VvcnesCyxRgqzpmcJUqfCzgDs2XbdBqJb1+fbQmzR7SJKxKht 1H3Kdl53Xj/NTenG9deJvxPzxrt6OzfHYsTOsYTMVtiz7DhLsd+h7KhFdKi/1SYowpDjkGPM cdtBORye31OYml6ZA15T6uizqeVWpkdQqFaD4SEP9gStLHuTE8MexSLix8RD4gmRFO/a7WUO t3AVjmjhTnC3OZLnMhy8AjfOzXMMd9HsoNAonO40GcsILeaMud9MIjNvls3kkhmb1V+ig8M0 Z73ZVckHL7FpuajqfTEPZREsA6/yv6RKQLRkVeLqDH/MATNcMxqqICiaT0ylUDGPs4OTDMIE Udyu2Qz10gb9DGLhnxkCijHTpJhgcao6hFWnrxa11Sc81Z2n+rfVnb6601d3Om2XMesUB+9W 3LJVMcHSOvr/hv92G+NU50eHc1VsBFVsgn4tgNYxH+A9e47uGGnyOd596dU7n1w9/fbyUfxT mnfvbt98hFhz84kndj9lH/0Lxu/fwex7FzsH61OZwzBH+hAiD9LPoSiuzdx/XD7lOBUic2TO 2OMeIUeM9GkKx5sO+StMhR3jxnSv8K9Yx5t0PMOzxFBkKEpInHnSy71Yhye97DTJZXwB75j3 DS/htdYHnTjaD1ayJdIoWBmO1fMA+jT++pUTYB+nic8mcCQ6jfmMKdyIBYuVf9FiwfUqgFcK hYRWOzurtaurWutbtZoRJX+iYsYq7EPmYfOsec7MmN2x10mGZKtin68itWkR4NSMYxrK3/IL JS32pdPLpXTXMhjHeDSqaYsQbLCLoaAjFBTDEmqw10t4VVFUGUGwvhzP2iGeBZJt4LY0u6Up flXwwWQ52hz4ghS8f/Pyh43h9e6JicGp4jcHOxNeZ1uvzxdqzkgfkxuXL5TrYvX14dwuYkdP evTXT+aaUt6kf5/N9l+qqzW2besK85IiZVG0SOphkrIkUhb1jig5lmTRj4i2ZSeVY1tJHLuO 5sRLAxTrHpYNJCtSbHOabdkDiIUV6ZBkqA0M64DtR5M0yLxhWb0gKFBgW4wB2zD0Rzus6xZk Rg0sC4Y1UXcvpaSZJPKIl5eGdc75vvN93c//cXgfRmCDjTHiXTjf+7FnsDn8b8bLzo7K9yMX 8wSW4qr4qcSpQziWoDTq4HcVS7F3qrrYezJSq65aVsmzwtfF1dx39pwdXR3/5tQF4YJ4cWrD 8nPyunBdfCf7zvhmdav6fnWn2ulVPD1czp2Xq+SP28r5YifWQeSD5U5MGnHyHOtoZ+y0zeZy uW1tUMg7w6gEbqaIomGHznYt/Eb4rTAR3gCvGY5nkytB4FwLvhF8K0gEW1vNCHcG0RZnvQzK BlwtG3CpXHED9wZou9GWoy6OgJENottgpDKdlkBFWpFw6Sb+e4zCbMQENgBv0ZRVOgAO7NrF TvyKyEBBEIBnHZsgMobIZcBiZjWzliEyOV0jVqbBdFiOgRj6P/2CN7saA1OxWmwzthWzxE4q 1UzVqK7DJJBVs5nsTLbqWH11DIx1Kx2A7ah13IFEtIHfNFwXi6DYnSEqBF4hoGXlCJxAv0jy Z1G8AZ8kPnek+gvwIpRh9NVvQ1v6IIkkpmlMtpc/4JJLDyDdLEOZ8QHsyW1uu8U8jz5EPFTk tpe5+/CAD0EugjR0/U7wvSA+P7d8fxsOL3Qdfi+MrlEPt1wtOgCKj63O6fHZvlE15/MLIiAj 4d3dPd3ZboIaikxFtHAiMhOe9gFff8CHjecmFGwYFBVskCz6sEpqwocdTE4roCSO+cDh6KwP zMz6+zrh9s5+bH93WQHj5VzewEcUyBR7LAM+MJk+4MMOxQ8o2Kgw4jMlcNMZfXoygfPklYAY OmM6pnlEpksmdRq0xsEeyHFOZJF2rjpNLTUHIi0HA5lNMBU0FQq1BJVpXwTz3dLWUdMCwbf5 FOiCG4SmwI5GAPX0FbzOTR/57frZhVtJB0GRBJv8cuH2j0p7d8nBjK/2u8H5xRd+8PGvvzFu 53PWY9mkDjzlE6VsZf/x0Z7Gf9KZvhM3r/+0J3vpL2Ay/srct24bJGUTvDRJ7aut3HBHdDev WC0EaWuvHVx67nuzu/OiGB62PSd3y6Gj+LlTp1+bHV4+vXZk+OGZnmfDGXXP1/ZlOzoscKhg 7ZB9/wWVXR77r5EuGIkcXViAIoANs5GVQr1guVLYLGwViCQFKoWFQg0tGQWgtInxAL9BsAbf lYoHouUuOh7gyqFgPBDZIByGFspFtaFsIFcCSjSPYf5dFiucEjzP0ZKo2uo0uEIDlq7Ra/Qd 2kKjVg+nsKCqyalKaiFVS1lWUvUUfiUFINmkNlNbKUtqofd1qNi4B/PIQT0ypymKkE9R2aFm G+D1polCVTf70u31kW1UuDPiIyUfsLZ5rX5Eqy27BJaWodKG6EgCHvFo07XC6rY4theSrCnY KKsp1+AqFNKPF6GKAxOLLw9N1jpdDjpjNPZ4jN00IZcy3S+UPfpYo28w5BZZ2etJO4CTPP/o +OnRmc8YP2n8chaaLVWNRrhJUHr1aDo71fAd1WRVddGFGWKwqeigvhiAEs4KK2PHurB3Damu ggW1ptbVdXVHJRW1ouIGOqmID3bvzpqx0NeMqUwzhsJmNDTJm4UVc5W72uMBJ6xTVBpSAsES IzGuOgUoHcO6GKvLSddtwKYjark2kkPBYIs54vMM0y61q6KR1EW05s33ZesiqIhgQayJdXFd 3BFJ8Vro2g/N+iCRso2KArX1dnPeQcaBfMG1qgOljYlMmHtkVluOBWHI9STRZp6jjxMdT/T3 JxID/V+VuocaIyNap80a8PpiDuAmz6MbA4lEfyP4SJnRYWa9A4fBZy/sUiRWrcEO5zHMwsA8 9uL9xiesLuu4k+IA/Lxiu0DX7XXmMnuJv+y8JK/pb9K0LuneY9wx/pj8BW6RX5Qv47Z7gW0Z X7GdcbxNvM3exe+y2/xHzrYiXxSLckEp6mPsMn2SbUvjCU4JK5G0Dl0cZ/Vwh8FBblqxhLhZ MMt+yP2bI5/h98m3bLfov9KkYOvgZL8sj+LDLGXnWVe7l/GzAYdMHSIOWw6Rc9w0P+2iJNbv D8iHcAvHApx3ulycJHsDkgYxF+2icVuARpCLhvLR9FAukC9haczu4jhVkd0KwBWZ5eBswt0A 4AA6LdlgXcASxVma40S6F8OEDfBPY7/I/MZupymYbUkSaXuGWWHwHQZsMe8zeI3ZZHAmLQhr IhC9sg50iFJMTacxjdOuaJvalkZWNLCi1TVcWyjoG+DFN4OvfwkOosn7S9BWTaCJM8ktP0Bf 789D8D5B7AC6VRyQYGek0TARdIjMgXMOTUw6vsLdPtfW+oLBDWKrd7htwG02z+fQvdtWK+ym 5eUlqJHml8G8+cKWsCVTHnOf/MNwQ5qXY3BgwcNvwPrHWB1HDW7X7SjwOtsMtmZgYLjK62aH NuUvgHMBqi/E9NDARXNBD0VZrS5zEqBezSOKB6hzhSZF9D7NEVN3y0xbMALOH/zi0L17x7sy qrSnMRLpjDX+LmkTDW0s5LGzDsXrSfCAI88/rP2h5GQYtx9XFFzr/3PjTy8F0w5aVYHHJfSA 5xtbcwURqCpvF4IHiOG1vZ18CHX5IGQLFna5B7v8s7qwKewIhGAq17Esikaf3p8FwrX2E/mK AAyhIiwINaEurMONViYesJa7QDxARUPuaPuQK+AueTDMStEYUNuZ1p9hTOjn+rN1BlQYsMDU mDqzzuwwJHOt4ynoNzm5OPAp2OHQNcUsxPr/4/txjl6SsnsbxaLmdciiN8YDnjz/8dBMwW9i mTAu7zUpsYllKgM16SwoGb6sdWvuow5iZQ7wc2hmJdtBfQ6OJiUeEDfwh9e7euOB/zFe9rFt nHUcv+fu7LPPL3d+t8/2+Zzz2T7fOfFL7MRJtlyaNGniuPHWNY3TN6+EFdZCk1R9pW2sbu3W MUjE0MrUqS1ihWloS4YmSBEdYSuwqmMtCIbKH/xVFaI1QkKTUDXm8pztpgGBhHV+7rnn/rGf 7/P7fT/fJJwohqZhkR0YarKIrAu60zu8JLKJRcz0Dt8jsv1wojzKb44Uep5gN/fpxLaCkhOj OoQQBka3EF2yRpCNpIHQ4hpioD+ZcLvIksvF0JZQMMGBSW6BQ7lFkFGoNrFZCrUn2sBk20Ib 2qauOQtbekLDw4FCsYBWCnMFFCnQBbSgkpvd2Vooj5UW0XFYLjPuRTBxSi0Zld1goaghUHW3 2/Vb18b1X+y7g6i5oUtND/Aq1GpHBTKVxJBV33vgfE0hI2US+HDIGPQBM9VkFtY6HzQ+CcDm C49qzfj+i/01jnEtUxCE66Fwq8vEGl/8t3adBsUJa/xL6dFjjt3fzA9OBZ0mMvtItcvWGXSR uDcymtkzjKKOjv5qcjhn0ATlkWxmU9yTzFc7u1NMrbVHKGCX0LsTVDg2sfNwPr+541j14Cjn hDbponlLEbww2axkNhikar7mnbAgHodrScUvt1Ud41lvKOTt3Ax2nJWDNRuAZ8cISecf8Oyk gU7pyEDS0WXUU5PIFDPlzGRmLqOJ40CpzSvwaSGjXcjczKALGVCGC0sZzK9ziixVhx5RZEND TTqRNQ/xfpHl69CTjMR6Emyyz4fwqTTByCgR4nmKMpMuZ4iY04EFHaB0k7oLuhs6XKdCj1dM +0OxgFgUy+KkiFfEOXFBxBCRFlFRLTc9PCZiubUOPtL/Dz5WtwfT4oIHc/mARuvWMA/Eh9pv n4IXBB9YquB/Ug/Uce3iw1pNg/x3v5XfyznNhuS6aqdNSZN4T+HQQYNZlc/en4TE01Bv5b38 aNex6pEtAU+Nd6gRcOj41Mmqf7vTD/UZmABPXNrA1NRBkfX3b2OXoToU4gdjynprxQF+4Pyx 85fgmv6q/5Zea/0LCTbo1zu3OE6BF/VnqFteIqCkMnigF2p4IQB+5bjGoEoADOpoASFcgs5g xdUdlGD7H4G64uCmOhbxMj6Jz+ELuBa/a1RjoGK8AA2ul+3Nu6WN9KfTUmFFJUwpvxDdlF8o Pjb+tpEdfDuADz4+PnYFMd5fQnD4Ddxfam9vL/WO/QxhsBSCI3YstUwve9c8wgItwajVvVJT JAv8VsEcRgVfmBS0YQtl5+A/ZTjg1MOZm4Azm4nmgBeDg8Pg4hCPBg51/1n9wMoFao+FEoLe McVyAD2gPUoeNR+1HnYecB/w6baXoA+q+Ubvoy05L/w61HhjaMSblBpqtI3oks26mtSUYm2E FBS5eWLPwRszN47uPv7hpsyedRdOPnniywPY/Pnn5r/2z8qlr7954t6hnu7zxz6o/vni+5++ WIa63b9XHcJ+CnWLIDmAKyfITlWPHD1Ib6XPWPDTMuiUuzvz8lb5acvT8n7dEcsR+VndJWJZ d09vSnSOpUute1txpRO06LCoaLXB3u053WSDHTzCI5HgSIRF+lCrFMXwZjoLsiUtgRLNgtng cZtTyQA5R6JlskLOkxj5CYfaFsFuxctxxeBkEK0EARKkgwvBpeDNoCZY7ngv37CoLrpWRNMr qk2tdKts6lplU8xMq022phnXkiFMOqE1bAwnhAyR4kCLCQ5pfZYDSUMzp4bPhji1NKHmSwkT 0g61nbpWQ2LkQZdMO9fEB029vlJttb1XuykKmPDA7MgL26aen3xjKBtNuXL5Kudpi9gcNM+6 BdCqN39l08Sjj21TxhItISw3/fGRJ/c++/uVczMOKl5d3pFmBQE4DckJbFcp4TbPVN/Yx3eM bXzq8u+mNrqtapX1VYdwBKrlR+APV95iKIYdpTEQr9kn544U46gSr8Rfi16M4wkmEeyOtUsj tMIowZHYBmmMKjIlthgcj+2U9tG7mF3BfbFj9BQzw04FZ6RTzDekV6mXmVfZl4PfiZ2XXnd+ n/mh703psvNd6TfSn6S70mdSjIvvF/ZHZ21nbWftS3Fikw006cwQPyIN/PC6KTaA8YwIxJLV wAt+N0FozV4vEgiYVXV5JADmAFoGFTAPMPBJOEk7ig70544bjr85MEev3DtTK+Op6cIKlBi2 SZUuazyy0v25KrQ11+iR7lDU5gq5whwStcFBcPIciNhFri6qapKwlKCq7RLykFvS9QSorecV pOadbVgjJjrsUM8stsedHqqmbO1+u3vr84Onfgvs7+fK4Y7MM5GJ7smL39vfuQ2b/+ypsZRP EGhDDtrW3pG/X18GAsf5Qp+3gLdg13z3F5eX0tCzTFC0n0C9oshryj4IGlQKTVEKqlAncUKJ gZ0xEFBLpUY2p/lIhOsJs5E+hDTELHaOBri7ouY52giMJQxDCMguO7VAgYGvORADMcQSCgQC HKhwcxyKcDRkmSXuJqfhyqJK8HAbV2lk+vZUPcnRK9Mr2y116sghaxLdtOopDtVQ6mmuwQcN D/lPKh7ef6RtQ2uI3+KwOuIJm2ndo1Wpv8lDakw8E4iQwIHNf/RRrxzJrreLO6qDwxFoGCFn zfm/cPERXz3ZTdy/jf4B7k4S0yuiXvbIqNXarBhyctSQc9tLxvHwOfrbIQ1JkFFSLKcn05W0 lkovAk55Dp7366br5quhq8If+Y9Dt+Q7+B3+TmhZNli75e3yV+PH5Vkwi85iFUeFqXgrvjPx 2WYTBSiUxPRGrY+UP2i6xut8mNNu9Tn9HtErv6J/hTzHvcS/FDJYJVNUHpJH0jvTh8XD8mnz 6/x8+q/YHZ9R1CVZ5ArKggBogZlsEUg/Qq40LwJGscTcrOeKl2UCDKAZjkEZ9aXnilN92WS1 hniTAacitZuGBb9GmltiSQTRCDGCOQFz2yLWr9idLaxgNaAfWsG/+K762LjNMu7Xvg/bdxfb 57uc7fuy4/PZJpdLluSSOooWlzZN2i00DFgbIKRbqUQnkJKg0T9oxe0PlkQMlo1KkBa4qhJ0 CMHStE2vjUbTCVAl0FoJWm0I0f0RUCd6o0NZNalNwvP6kqkIxJ1eP69fv7ZPzz2/jwdFr2u3 tX9qlFalYm5onEMHuHFulqO4KupyZVORi1ka0YWKiQ6Y42bZpFSzzSTNy9AntiP17BNb//9Q bXLV8xxrozv2L2xoaHTEaQWFWdhAMAUOra3AdZA57EZW+NqmJU04oE8s2J9cJBSLRELQ1nnN 3IhE8HdXa9Cr8bXVWn3uTT1Mpiw7q/JCIJgVwLYGbDoFZZlJEUHLn0JbwMQeBh7OPAje5+8L Dyzf6AgYWig/WJQrqEJWqEroRGQ2PqvMJmdTc00/0CstYVBGsLwEiCdsC7XqrbnvFE7mThb8 oyNYLwVLlR3Gkh3ksg4JI4nbQdZRsImQWacISwVvME6Yz0T7GlR8AHFdSDpekJ1cdePOgujo 9QD90p1F0SlIYv1Z0fqzOGhF3Si8IuoU1Ci+557LcbCNcyg+Au+J4Afcc6MReE8E9sCQBG8Q zf/vA7kZAQgK+iYXQXuaqGPRkxdd6MByg1vYnKf+WKKw3yNntfyRL+56Ws2Ovfr7N57/7Fe1 eCKiaamfPNu/75n1v7a0nPxm11CHwEfD1Ovr177/3J6WbZZdHDh4+thchlXQwEvf+7TT/6XZ HmffxA8TXIOEvXZs4wOy13eVSBK3LhGRjTvu9rAzhsZIsi89J8zJV+JXGqvyHTlYSaMZBe0N 742MhcciH0rgVeOSKVGNcUlWKIQPseQpRMXbfFWUdFOIaiNJFAiX6AIXarwev+2x/qFY8g9E qIruugUVqK7Ymp5Pk2kCIZ/Pn4sNi6gsIkLkxXlxWbwhvisGxAOpX8xsuYE1z0bzo6uj4Nig 5MFYr61gouNrcGkFAdkRnm481gb67sn8ZDMSOuK64PF9d4enBvmSoJe6gOW60Z5btzos7XHB 1Ms7i/s/8Ur311sStu/q+h93rf1q5HHbevZgx9hB8ita4+HB/CHIFgned406ThjEX9wSMrEY qyZG5bzp6wx1Z3vUweyg6ldocS/2RdrejGHqtIm2BzP0TjVkpOkq6ndFljAMIIJAutDQwIbY UEhTsWQ2EPMIcWgcVdB15EO47TCispKLRofFWZEsw2FepHB+1M0MQX7yb37rPwUACAAyBYnC bUet3npgsH/ceXj45ZMpTkhxSorghSSfThFe1/HCC1CXgD5PRNu7E369tJUyEIRgSdtMJJyZ JeogpzVmzYb191u+cbR/aKKQ6h5E20f6mr/2hPN56vjazcpAStAn3ix/cuSlMprb3p5ExtrJ 8nDXk2TwU92kAfkUIJ81yKdK9rhM9DPsfukLMiVXN95eCJWaMAafiZdickzRmSZWE9RoTlJl VelhHLYn6kgluUfZQ+9mdrL9Ur+8WzlM/4ieY36snEhWmn5OvEb/lDktn1ZeS/6avsAssovS RfmyspRcbrop3WfvSw+UlgqD8FvOtR/o9GLzY/WYsetxYKAeTbMedb0eBcGLriunOrmmo+A6 Jslx/1H1Bf+3hZebmB66k+2UnOTvAsva20pwmp2RpmSqOzookaIUy4hEUs0QUVbIRKsbL7oF RpFVSZbbGDbGMGxSUXIMDTM6GPD7fDQokBgFlSACihySqijtRsdYxLM5tsIusn9i/ewxJomr h3cDrafoS/RbNEUfY+TnlSWUJFSCgd/LRTsZ/LvltBcX2ks4XAyXCGaZIZkqurLIN6FyUz0b sAvHRU7s1DD4ZB7amMnVUUxdypr0dxmKTVpVajhOSrW62fCKDCNwqq4eU/6i5E2aQUZqiF9+ 9AgmZBRaty0+9GquGU0Cu19g1cZIHw2EfBEikwN7UN14FziaheCyokOrQNIwPDdPeFQqavE6 jYqi59DzekmLB8DTIB3l89jVo9dTph2/eStBh5o6UXNnTE+tL9nrlxqtrNBOHTfyqt62HiAj 29INDBcyDJ+Q2fXwfcrf1cozNGbJyMaK/zzUaYFqOhst4r8+1VdqNMGICYapFseKh5nx4nvG e9ZHxkdWGG9YEEvevmvJbKdWLNpf7krLcjap80Ufm0/nC3kn/7nEmcQZ6UyeDhnduW5zL/Ek Ggrupgdyu8wha8ieDpb5svBdY9qatsvFE/xxvNlY4i8Zl6wrxWvGNesd4x3rRjFL+H3BQNyX YIygyVgBu5TYwe8Qhv1PBZ+WnrJnQi/z09KMPKNPG9P5cjExxbyYmMpTEWYEHeGPCD6oNMiS YbAoCLXGJ4QMr+paRiXsQobg2IYMl5UzmSyU6jnaMtXqxjHXlYycSgdpJpizrZhtW5Blw2yj mRhNM6ALcjzHGjGWNfRcrk2SY5Ik23ldBlMLVc0SlraE7kJpZtDdc1nECfiMJxpAFViO43kw uipB4kVEFGALlL60hJ4D0qXRz1zOcuHH5nJWSH3IHWLBmJ09v0wcsvUqot24m2wdltEpGb0h X5dvA5e8mmsF0CQvqpyBeAMZuMBD4U5jCfFEnogDbsIu2zqWR26+nCfzIE3nmWNmK30ZwEOD kLHQdKCydc8iLbj1AtxqnQp63euwjco2ImzeVm3XnreX7Rt20D7Q8rFe1VabRydkpba2As5p YhMxsKTAAlyWVhQQMTwwhDCAFKxk0P5A6N381ue1ulkDTNWx1QDYordARj+60vy/4PbfxyBP 99K9HgwnEG6eJrEtGW3GCMzzsXAfNjvnIIoYfWkn8UiI4XBvIeEYOMS9s7PxOiDxB+MxUIej idFXB+MWPDfPkU7V0RlBZVCV3/y2UzIbe9H5wUyMvnE1ZjpI22evv2X/bf1DY/3P6W29gFJf JpUtrH2AfjnVm2igDINK8HosvvYv9KBLFTOkYUQOP/wH+W/CqzW2jeMI794dRd77jiLveKRe FN88vsSXdLRknhPb8YuyktiJ44S1C9u1XRu1pdpNUlSQ0FZR0gBRgSJtUARVihZN3cBxErWy Av9JG/3Ijwbwj9QwgqLODzVJiwg1CtUoCovqLCnHcpGgJGdnd3hH3s7ON9/MztXLNLWzIELw BBCiPwHUDtDH7DX3Ng7PiDPSjDodnS5e46/pH8Y+LLByJspF+LAwxp3nP847OyoZ+WCZyVQd VaWqDkSrcauYq+zk9yp71e1dO6N74ruLduUR45HISOW8c4KfUCbUCW1Cf9E5q8yqr/quRLsk h6zIqpzqVrrV7lSCS+jZCqdU9rMHyyMVJgpYgE4rViyWOF4QCj6OdTqNaLFULJQi7hktq2K1 JIiiJnSOGyNduCsbOROaCFGhmRAOGZFMxiqk/5lIxAojsMHxEi45HM6I4XSGSxFPqRQRtFgs VxA8hYIAvvaxgl6IRQx+IGsnoz6OForOktyBO7q7U9lspl2hBoCIVJWwS4ZJ43S6q6uTE6BG +d0ZDWuZyAKW5noMbJBMJigl23jD+Mi4aTDEQFjFuEKVUQE58fG3SpkYIHAOFXDhCvV7ZKEK VZsLvg9gMG/VoWtQVs26OboMtVsr2ut3WANqleagDNZJq9os4kiwQxsyLY23QptMsM9tjWd9 nylLdbgsu0QGkHq2DhaluVS+8xnMnC5lUBqclpTB8cVFohZdi05QLrBCyI/V64RxRtEoRPvb iIcg5ix+Ye3fl1lLJ60CzD+dA+0FbbMdalW0A0rVR6ywINpu16Wqw3bzVacPhjKZVQijgk7E ZfJrN+dlK9IjE966/pZsOQlyZCsPal6EL8SmhbQY0R4iKthUch9UPk2ugyakqdQW8wVES4H9 qyA69COKIlsqSMr2Wu0tGGot5Sbc4yUNzE273WuVXV4rnvNYCRDVpVls88c0K2GrIF4rTwT+ WSf/DkJuf1O9C+Z7X//b1uB7viDAv9PO9BOo3+FhZ7um6d5gKU+ssRhJBs01KcH7CV8H8KVE MMRrW3bv6I3icl+4b//40r4dVmMkbbTbz/xoazrd+FM4ED34zuu7HhyCVNCh+/JK74kTR/ze TkgEvt6xVxsLT/fR4bBH0vX64uLjqi9GhcMOT+eTa7dP9xMOFxrb6RXIBnl82n6NVeCoJPPF BNVezGhHy99zTLVRLOtwuwyXnzU9/igbdof9UXMAl92lwAPuE+wJ7qTxNf+RwInUU66nuaeN J/3nAk+lnuOeM15CL7E/8f/YvIKuFv/aFgJCNc1UMsnhZvFmkIovlV+v+KKuHsPvzyU5D1yQ Ms1mrWcm4Zakn2U4Vwq0ATTpCq1XfTGCPQmeNpYNWZ1yUdf9BqG6wAyHb3A3Oeowd5b7B0dz 41V2L3uIpdlxaDIku9O8JvdguWe2h+qZOZTC2VQ1RaWMQvFC8FfQMZjDULzVluqjS6sr0FDV R1eHtx3b+jGq1laXzBYyAYS4iUTXBtoBTVD6pSxzl1nwKIGZ+cXVWbM8a7YWG/rbfhxtMoaA X/Om08Eb76tOV6+Jk5G4jzUaz5cvPbhpT38uaMW5rgfCWxqX5aCh6AUIh1hnbFsjj/+TiLtZ XoT6zReUqre/MfXs1lSyoMmbH5ul5rozIUERIA4SwAqnIQ68+JA94HYxPmaWmRVnpQvMAuOc 1bGonxf7yiPogDzipQOMLrXLX2Eekm8wV2UnuqUoW7xdpIUN23mH47dcF89IshymGQ9NMzRP MTIWJF2kZUpiRhzYkROFNuWQjOUcpjj5CrUZSYihNtspGmdm4WkyIyLOibZ4VqRFf1av6nt1 WhcyfAlRmDI0/eetFDq8MlpbWRpW6rfg1FbqSwq8IY+ujg02BwuOpJk8ocsDgRp8enzRh5Vl KKz+ta5I6kNjJtTazbwnrV21WchydA4GhgSZCBPZJquwZskLa3+e1ywm7iHT6/MeiznrJtMf zrstxucl00/nvTCVm9M35XuTBmSExzAdLOFgLznrUH/Qi4N5gnj6Cf72depw44OvDrYHmHgb jVZ/iodP7tYVHhuNT8J00gjldzUitz8IpXqOo7U1REGXuOoYoKLoAADZiV5AF8DaY6sUfieL J7M427Vph4kpKvU2dRHOF/JSvV4CDyKLOUyNOSzEIx3tBJ8b+2JHy4I94cZuZE+04TYD4ETb V9mPoA2aku1D3jNeyrvPt++gzxyG9qa2equ+DoxsvbacrS+DF02c17ye9dgNbphTbelqNZ22 7cYfM1U7lbarDstOr9vWNYKnup8+Tj/sOIU0lEbfteMYSYxPjwS6470ulY/bvfO6avPzSKcR nYXnkyPdkckIDWSctOVA5RXY3ruy1C1NSrREbCxTueTBHiOTXcDn5oLk2Qm6a8urEC0wrAO7 WoNKEz6tMMHroWLBhlrlGoFgYcNuIl9sxtsP7OFYUUy5E0O7+u8/PUU9fszmeYFPaYmh2sB9 X3/GcSqRObopJEryUCq37dz+oxej0coTmzskSdlk9u0Y23/yIjnVdS9gGi0ixPwCwZ7P9k32 UQhTSZocYr3pq8Yi/TB6D84vi563h14OvJy5kF3Ivpf9W7bt29J5/QfSlM74jI4YwowcdCUF 33zSDvNo3m0LfF+1ozKSxnK6Oz2ZptNNB74Sw7F3mYrs7fZOemkv2OZkI9e30XW11foynHt9 bBkwtrwEH+KojR4brbeXys10Fup1fp7FiJMcX2L/5rEqx4ucpmnJwVr/faem8ZFHaxwniJqu giPLW09PNRaTVn0I3ORyDZq5HWOPnnw9nEwf2xSSRJdrs5nbfh5ciT5/fev/C/WbltAZkDfu CjMM8muEHHCZYwyhtl8i5HwWIbaMEO9piQBrceVekb6PkPzQvaL8oSXuvyDkBdFHEPK9gJDf h1DgZwh1Hkao6+//Zb/sYZqKojj+a19pHsFARTRgABvFUj7kU6qUIqBWWrAVoYJ8iKmhGFSK oRASNhM1Dg4mkhgJk4OzEePmQoyTJg7GODgQWZwcSJzE1PPoEz+iASMDwz0vv/P+9/T03Jtz bofCnhfg/AD7PkLRGyh2I/8woTQA5bkpKiagOg41c3DQC55uqH+aouE9NLr+TrPUapF9j02D vwpa30JQaoUiEP4EHZ4UXfkQsUL3EeiRmr0z0H8UBpZh0AFR6deFdzAk5xt+DZduQlxyrsqZ xsNbjFv/TqJw6zFRJLT9H5ODCoVCoVAoFAqFQqFQKBSKn8GKBcNy0Axl2S3YWde0VZ9OxjbI cmzP3pGzcxe5eRIrKBS3l6L9rmJ3SWlZ+YGKyqrqmlrqPIcO13vxNaYKHPefaA0E29pPEj7V cbqzK3Kmu+dsb1//wLm1PZ7/uuX8k/WPtSl2zXA2Hol34RRlF++ihFo8NNBEBz30McI015lh xZnvLHAWJpOSb+S5KacOr+S10EkvUS5L3t0fecmlPz8040zeWLwnz0NzKhsxbd0MnWGzniZz xtQ20TmmtotyGzfAli4RNz5TW8lkyNSaxMdNbRM9a2q76IVAOBAK+ssiI6OxRDg21Tk2Go1v NEaAsBAiiJ8yItLZUWIkJBpjSno4JusocVExLjLJFVmNb/hbm50nHUtzsCw9GiNNOuSgUiZN 2iu5AZqspTmWO/KJbhNlrL6/GbZmS/PX7PcxNYkZd4AV3SjzUs/UEua0rPdnbXPPfOezfJ/1 PH01+8FSwYLxfty+mPFl4utth1fPxPhJWlIz/SbAAAMMNfwKZW5kc3RyZWFtDWVuZG9iag0x NDUgMCBvYmoNPDwgL0xlbmd0aCAzNTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSInawMh0KY3j+sqVP+5FTJq0euvWM08fv7jTxZPPxDQjg5WRtfn1Nr5HUziXTsv+8Pz5 jRvPjFmY//z+Hair48/EmJXVb2yQs6Kvz8tr5qPbtxYyM1+7dH1PeflmLa1T7W1XTp48lpLi 61NxxJyNmdn/84ePXUFBhcbGRzckPD17durUA9uXLSstXdBant6pq/tw9+63r9+d3b+/Ii5u uyDb5tCQZcv2trgwnzu5dWub4OuFDOwcmR93Mvz+8jkycsnZRexbJCVz2K0Ob9r0bh//jPp6 KYma799+fLx5c25q6tt1DL1lpaH6TDMkJX5+ucvAYB1r51CVaLdr80pFRsZJGSYn1jRkS0o8 X81zZ4vuzSqOmKg6aenQfkPWfSwMJyNMnaSlns5mVlGqn9iQKSBQu9XGeuXCCY9OhF+dMWOJ DMvzpXznM002zZ376cH2LSws////ZxgFQxkABBgA03KfJAplbmRzdHJlYW0NZW5kb2JqDTE0 NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEzOSAwIFIgPj4gDXN0 cmVhbQ0KSImcV8luG0cQvfMr+hQ4gNzsfXEMB94SKIgNByLgM02NLAbUkCaHVpyvz2tSFKdL NZQQ6+AR9Lq6upZXr0bPlrOfJ3+PtJbKCYWf/ZeLUZrgs7AqSOuzFZOb0bMlC01GxuRTDV3w UA9oDDV0w0Kzklp5W0PPeKiRKXhTQ8WmYV/mVZZeJfKyLQvVXipDoWsemmR0mbjbsFBjZYiK WBU8FAhE4Qnx8lbJYKgDP3hoYJ7FW3VKWhdIwjoeaqULKT4lAi5JmxVJ2A0L9UHGrAMTLCWV 0l5MZuL54fNW0PMWFWcE4iKDxYt3LrVf2SpS+M87V4PnPNRJHQOBtk3DloZDvrXLgRge8MJG mNa2Bovdg99PRu8/vB2NP4mXL8cf3p6/QybFq1dv3r0dvZmMxpOJF1pMrkaqxESdiEbCLzYf I8kYdqxhhBl1e4h4+Ry8IyDFGtVQLnnOvdSmhDbIqYaybWCzlj4oXUNfr1aL+WzKhzxIF3Wu D7Bl6wzoILsayWfdGiA9cXjZbgRPi6hcrTPx4YqHZplsJlETny8+nrHxKITnQ/Y1vpFsRXnl ZQDh1WDJQ5N0mkJfiHb5fYhywGMkds1CsDnxLmCiaIJGDllwAO8YSzI+kG0f0WDa6ydk20c4 YaN9Qrp9zIDmh9m+55505J50ohM8Zp5OaXd+2l6K7prNqTbS+Rrd8HVoEJtoCXYtePJBjlDi iRjmoR4MWxLUh37b8k64LJ21xIeG5XDMDzzNmKf4EHV5W66hbbfh+yAFmX0gj9tsZ2yEvQK1 WkPeJ6YbwU8eRM7kJ/jsETejMaIq6OV8Nm/5iQZltevHxy0Hg2FAPT47VuCRi/UpLnZG5pzc 3fRje3k3/YINNXh4+hW9V0HXy5ZPvonShpCoF52YLdn4FDLEGHb1AZ67EZ+Af8SToRo0IeQa yhM3ajAmCl0MUHEqVRLp87oZS7Aue5miJW/7RfDZh+LxxhE//lnxKqNIRW3LjHw0gR4jz0CF 0pTwctk56XX0BMxDCydkUnAbccvXtgPYpKf4GyKgjqS5u+a1wr7k0bw2J39HS+zYwN+hmEvf 9sH83oLuiJBmNZSVNQ7j1hhLrLIhcLoIQ+rAcr24FNOBuQgalbFUW//EnN/gMEJR8MT6dKCR UhFBltg9TDtGH/r/JTx1hJhP4aTyDEPKEwV7YLvyOXgJEqBiMo8qz1xDxefraSdW04ExaqSB BqhO8KHENHAqEz/4HnCQRCpFXWMH561Kifi8WPCkhBGTdSTufr7g2Q59mMok72M/8lwHiaI0 eRq7N5bJvNPfVRBWPCc6cCKNLV/96Njd2lFBeU2ojEzKEF9/DKleox44O2/FAHGUgR8ztb2Y /zskewEJJMf89ldkbzKGJAOKkefbGCVagUTuqA7iUR3E4X7RWCZcTHZ3mNUGNiuwA5ikgrJl arG1xsKpFXQzH96SjEMvQmdVB/gtyUCIl7BXULH9wveLkSorT3z+th1e1QJ9YMd7jGkUsiYe bzfQM7wAylnqAG6t8KttN1QDRTB5T5wRP/GVCCYr60yNPVQAYnXPmOZEBWDTiX4vLoceUTRf rqE8EGuMz1A4feS2xebWDfAaBpoxNX7ZCixKPFvhnaDXCi5e8xRUtkLwyuM+Zw2hBenUR36Z F416zkZdZ5mDrqPBa32DYZB0bblrFvzOayF8c0l8Dzzna8SlMg1qKARc82t/quJa/IjNrB1h QdWY8aWHsTg+TxrcNrrqz13o3f3cVbt7dqeGhrvZu1IWulI+HgpxP9MvtqvVct01l2LflPdA 5CL4CvqDACAddQUorCf+qFFal1kBcdXDLQnEqAeQOTJZUKUT9E5FKHnQEOQtTskYUArl2Pn7 2rQN2GRKqfZBBOMsxo5LJzFeS20iuUycv65RWFiw+sUadVFjokU34CEVZkwwoXhE7Hx6kB5v qB3iNYZADtTOnwSDssT6dNJnDSqJDwyNKQgz+YGlc1oNZi+fTrmt0awgDHfap7I8GeLSfcnc Kc+e8CRFg9P5cOr3Zn1D0g3KCtHVsGkr3pI8ISypkFAfdk3yBPcSMbTqSA5AOdoTOw0NL5pE U5/WlSQ/bxfztrm4nq6ae5KI6o4kxr9fWPF1I76NSnyTVXZvekcx+6BAk+Cm2Q0s3Vjxbjn6 i0p9ZO7emoG1x/lGYxktHLaz3U/Twz0imGqPcMc9AtPjMBX32XT35Lr70lBsKZX+c3ti/W25 FvucUiT6Jnp8HLFLFofeQYxiD7duIDCvODD6EMqlcoA1WlY10L/pG2W9RB/J7HzfSwzjZXsm VouGO4BsSpNt34Mpi9NKGm/7hjfNQXsoQ7c1etroksvjWfF9vpl3L8R1x14WVXlF/7ndigUi KVbpvvcvxuPb21sO7FD/FlvVESt5GMasS/0EspEryx8Iyfdwt5uWNxmMDA6ysJfm9dd+Mf8n wADUURb4DWVuZHN0cmVhbQ1lbmRvYmoNMTQ3IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRl IA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTE0OCAw IG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vT1AgZmFsc2UgDS9vcCBm YWxzZSANL09QTSAwIA0vQkcyIC9EZWZhdWx0IA0vVUNSMiAvRGVmYXVsdCANL1RSMiAvRGVm YXVsdCANL0hUIC9EZWZhdWx0IA0vQ0EgMSANL2NhIDEgDS9TTWFzayAvTm9uZSANL0FJUyBm YWxzZSANL0JNIC9Ob3JtYWwgDS9USyB0cnVlIA0+PiANZW5kb2JqDTE0OSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE1MCAvSGVpZ2h0IDQzIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyMyAwIFIgL0xlbmd0aCAyODk5IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvJdtb9rYEsftvMCnglo2lpBNgMhy EIrCgx21RaBrYcRTUrn11izSao0qtimXMt//A9z/HBtC9lare9/UUmJ8PD7n55k5M38fj7/g CILAXUfFsVfDTVR28xubKFILG7cSRWU1+BU8Zyq1XN4zmKa6fBHlywfqOqoECjOpGm7v3V9M td6r6h7L8rWrlTf58uGmjCEwbfblffnX+urI7tm6rhZtXeUoXVQpQuhW9ir7ab3XVIRTc38l FVJp78IxlTCnKp/TCU7c7svlCiLrbn9xYhVUL76KtCKEAIyi7QYJpWD4FFl5KIry/y8ln/kf HmQTuElzAzVaS6oj9tsWXgtCd7OX2zIIcsR95TLfw/Cn8/3TYkEoN8/lgz9HvHluKAXV+lQR 1PXWDUJVMkVR5ZRNbgVmSLZ8tpv5VfjfMyrBPwW5Oe89OcpVL3ReoH5ir+w8unK+c/B40SKd XG29UTdcKiogW5+oEONo46oVeeE0ye46r16XY/o8f3CUc5yU4lRYOFdEB+HMS22h5IPKrtdp OC9zFI8+PbdiUVBpUZ43AX5FKAT7jRtiG2qnsAUunAfWfIVrslMhV2405PIc0tCja+FwoAIO MM5hqChhoyFXYyoQzUtV4RzDBu4oNzS7hfuURoMdD0sZXSfNDNHYrPd/hgHnPGeTWpFuUplG QbVSCyxJhRtnqiq/cqNH9MzzXun0jGU9/el63HNu9M5TY9678ZrOzZxMWEiqPq0su5QJ53lM 3rVzQ0QzRPVmTPOdo9zo5O0cwHX0hej8+PYRo+66zNWpso/K2HpqkZOBupd1Cnhbhtq6l1RK OKfJgBaiMaeZXasR2YMUwRXX5KVdzxzTddecHWy6BhaoDmY9a5Uyq0mlg0kPuxJRvSYeqDUh vAWZd4cu3jDUaSp0ONakwR9atF6DZ13ZcMk8U3E24VQpy+QvqkNOhaSnVpLRRDxTqWoYmU5+ YtSobizIy9oelfzsjqaJT3UEDVT3d+RPSlk6ht2BJpZPs2pidcw4sam9IDtLLFA96XCpTp+z v6j/6YPsz9wMkVkvWw++U11OflRTba298hUWat2vzJZlY23DSJnKOlA9YaqqR6sks+ngH8x+ KphqFdMEVDF5VaC2jFumSk2vdm+TH8Nx8YnK0Ok+uScvBtWaM1z2mu2pkLN0WO8lE3D3xUY9 USGrcLSkkyyB6XxDHOC/gspPUk9aeJl8halRN+ulzKd+NbktqIyuKU1WyWpGeveCyvgK+nfr s4dkMwxOP3ONw9eosC/Zni80qMZx1ShRzRBOTvUsfdWXVEY6pyksYkMa15IVUg++MqsI8kBS WV3T82GSGUZ1QDXhnKke3+JtUu2lOLkFIasYhirqA2fZiaq/Wtw8YfXYyDLjjjy/Gzo63bWR 6bP4rqCyBLgzo5ohMpIqK4Eqw17MJnSAv2iaihYgsqqRdo17qll/oxJYUg2UopJykqPCa7wB yvvz+Do6VVEc5q1V69OMFlY6QRiuBDYhiTa2j+0hgmOm6uLODHtKZnvNsKa8L/w+2VQHyIBo YLVbZFInXZCOsZxqanh0n70lM0M53Z/UChen8oaZypqqXoyrBVXX5yOzrKq/8lMhrPh+1cb/ lY+h6SqLfcO6xX1H3oGFw89ULSF83LGqq5qfJUKk/iq2LANztEW6mPIYnHoLQzz8+NtXH2nC vaZY3kWSo8Kj9yB2nE7uqe/kvcGxEhxYxDL4hMWTxMBVYlhyKD/jhsOX/OOIX9IQF0IYbIGb Bj8lr+RURvrEhvnD6Zt3j49CCbVCRBV6ochxRUr4Yk8WdJiQD8fp3i7aOMnr039R3MOfouSX qKKKIwpD5zSmyHPj4bZd2Kcd86EwEeK7+uHDm+8KKz7I80CWJ9leiloKzbc+7cliPyi8gBM+ Y+d34Ah5rSj5f3lLnpWTZf5jFzCc82qMuw9P4fDYTjZwJX8YyyKj8yTXcg2z1jYnKc/pNDrv yePLoQSoV/UJ7+azUsjFwOVFIRygEOY64nN8GZWnJpmD1p18MaA0J9y7Cwv2EnZ/kU1RNEQ5 DdXtWRQjtqMNnKhWRpdU19jZnBKO0tixMIBECHcNXJ0vpH4MpUiE9awLhXDc8SiPNAI0vQ7d oS1wTYe4kHLB4UnkBK727ffNpoJvmW9oweq//+Tp1ErlhAVnLbEZl6MLKnZVXeb1E2uAZ8fp 6c0OjW+a+HPQ+a/naLpQBBBRV2aDFQJBIUBZYGA3vmrqeIGnDk3kblCac3P80PJuBRQHT9CY z5s6ffwddeDHR/r4LxWBgbQA1rbYk0j40Wg0HC6Hmwuqho66yPsMzbnG2qrDlYrMWZ366RNf 9OkZVVXvih51b23EaiqadJhQT+xQxfpdVHxUvkFbzkH1wa0OAfJgelN71u3qZNZn9OWD9gM/ 3r/5Qnd3/JZoglvVLSrCKIpGmnop3ZWdie7F4eM2WIMOHKCQ+0RxVqd2yk6IUckXqJtWj2JU bi9L2mg0mWe228jrTFaOVZ+11m6MdmxUMRNsp2jMq5TfeUqf330hPTYeP43rmWETXIn0H2pq yF+qQ/hq+frbS2l4KMLIzQdzFkMDeNUJcgStPzMGIOtgUqPfr/pMhQEpb9D6PNsGOKhiqVsc C2rH7F5TyUgsVh1o9bqtg5llg0+fH99z5lm/mTPbhhvwDL4DR8MNMw21TWWoXbrqyDnRMkRB dftCVT1TWfrfqCz0lUFr0KqymcVFwnEso0U+PJrlqgM09cGg5aNlSqrsPX1GjUVcWzigdfiD azlaLpdDKbu2y1dYCkQLdzin24c6QASzAajQcatZS1IdkrZpZyztjI6kYoWACHJbAFXM5eAY OiKts7oyfctp8Ewt3thJUmVfLTAjxB9Mn0wbwtLAFj2Fbshfqkj+4VK7rFdOG7Ho9JoC+RRD 3iWgMi6ovOkgd97gDgx8p7WA7cSfriyOIAv/oDe/6sBPkIderbnLM3RWu69ZTGUw1SeT7C9N MaH3X9++ffyDmZbD7XC45SxX0BzhtUsqEQ+gFTpWu45NP8iS1msq1t5QwBOoPkQQwoKgiqvS VnQLKtQr1qCJEWN8tiiBKjvMiMYptMcKvvpsWPdoIHbKLiD7zYftaDmEBAWctnGha9z/kF4F q43DQLQlByeuC0uMFkov3iXbiy8+LG4CZmF1EDnIEGxiaG1ZUNhD//8H9s1IctxuWQwdCHnS PE0m0tjzRBs3r3eUhC7Q4NO+oH6f/iigTnb6C0BPdaV/IykSBtse+gHAcQu9XTc70gOkPnYF LV2n0BkaH/AgREhekOZodlsa52N9bLZFXteb6nBwFzB6pw+o+QTbpt48hXe+3TsNQG1/7UQB Oj5VO78f2emBlwZMTfk+FjQFe1PWGTxFQYnmxv1xAwXRH4+U1flbuLmqRxil9vourfVFA0x6 wLV/FFoa5MRMUcy4V5cIV4E2rQjReNz83FRVuYFF6jDQJZX7HyX1mJyvr5/eGXKbfV2m7+6/ 0lP89Mb5IXcavX6AwgR6NF6YA9VThDNDJudoGHBLjCKMk19Ljc5tMXmBNafq5qCiM2ygl5Xb pednVJZS8VLb77/vF5OXmNGnsqram7ZtOSdUVBKVZUTVbj3HBhBfwP/RJ2geWqHrsmqV36rJ lLLFCMtB7AiMnY1tzijD33FIxLFgkMs4zhgVoHWeZmUenMY7rV8Ap48rkAz/1GiApjmJxE7l 8Af7VJa0UWRJYh9WsBchDYPVg5HihdGtlBmDVS5l7lAm5a2jTQtGG2hwdisXzdjRxTATTRof t5PCzyEuMuTETrXWQjAiaIFFJuicGRkgwSZpi9nshOCUDExYMKPFHnEMGZyeRodmsn8QnSYS g1k26eBfAQYAd9z0mwplbmRzdHJlYW0NZW5kb2JqDTE1MCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDQwIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDEyNCAwIFIgL0xlbmd0aCAyNzY1IC9GaWx0ZXIgL0RD VERlY29kZSA+PiANc3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwR CwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1MzMzNTs7Ozs7Ozs7OzsB DQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMeHh4jICgoJSUoKDIyMDIy Ozs7Ozs7Ozs7O//AABEIACgA+gMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAAAAAAAAADAAEC BAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwz AQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNU ZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eX p7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi 4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1 xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APRsXAwDiUk41RJraSSx v7o8lI4GB/3Gp/7bb/cpUWMrwanvcGsbU0ucdAAGhZHS/rTi9R6hfhwKw0xju3SXgc7h2Ph/ eniMiCRem6CQKHd0zgYA/wC01X+Y3+5QODg/9xqv8xv9yH1Xq2H0nF+15rnNp3BktaXGXcaD 4KhnfW3o2DcynIfYH2VttaG1l3teJbwnRhI7AlEpRG5AdA4WD/3Hq/zG/wByG7Cwv+49X+Y3 +5UavrX0e/EyMxj7PRxdvqk1kEbzAgHlVmfXPoVtjK2PtLnkNb+jdEkwE8Y5/ulHHHuHUOHh /wDcer/Mb/coOxMP/QV/5jf7ln5n1r6NiZNmLc+z1qTteG1kgH4hWsDqeL1LHORilxrDiz3N LTI8ilwSAsgo4onQFk7ExOPQr/zG/wByicXE/wBBX/mj+5LIy6cdzG2naHhx3dhtEmUA9Twh JNgDRHu15O7SOZG0pykhxcX/AENf+aP7lE42L/oa/wDNH9yh+0MdzHPYS5rLG1GB+c4gCJ7a oL+q44qstAc4V2ekeBr+9JMbfNJSY42N/oWf5o/uUDj43+iZ/mj+5Cu6lTWGktcd4aQPaI3B zgCXEDhqD+18d26GuIY3eTLQY2h/0SZ4KKmycfH/ANEz/NCiaMf/AETP80KN2ZXVfXS4Eut1 B0jUx3OvyQLep0VmC1x1gHQA6uHLiP3CipOaMf8A0bP80KJoo/0bP80IdedXZf6AaQ6A6TEa jd4/ijEpwCEZoo/0bfuCiaaf9G37giEqJRpDA00/6Nv3BRNNP+jb9wVfqeXfjVA47Q58Fzt3 Aa3n8qNTcLqK7R/hGh33hNEomRj1AtAkCSOoUaqf3G/cExqq/cb9wUyqN2ZYx73Dbsrdt9P8 93mEsmSMADJmw4J5iYwqx38dA2TXUPzG/cFE11/uN+4KhdlXPYA6C1xa4EaQZ4nujU5Fz7Qy za0mTtjw8DKjjzMJS4aOtVp3Z8nIZYQ4yY6WSL6BOa6/3R9wUSyv90fcpiCYKbQgEFSSywjO OM3xSBltpQawxSlAzFVEiO/UsCxn7o+5RLGfuj7kQgDkqMA8H8E/jjV9O9Fbwy2rX6MC1n7o +5LYz90JzATJ2lXS3V2PrX+2PsWOa9x6Z6VXqNq0fOm+Tr+b9FcveWRhfYd2+HfYg0EODfWd u3nk/NeoUNY/CqY8BzXVNDmnggtCx+nfVnHwOoW5jXB4LpoYW6sadTJnUz3/AIqviyiMaI1G 3j5pnjJNg7/g4v1q/aX/ADPZ+0iDf9oZt/e2e7bv/leKoZn2/wD5zYP7ODHZX2KrYLQC3+bM zJHZdp1jpWL1fE+yZe70twf7DBlvGvzWdnfVTpeZezIsdc2yuttTSx+32sEDsnY8kQNf63TT VEsZJ08Pwc7rH7Y/5r5/7XZUy2Wen6IAG3c3mCe6F0D/AJzfZcHbXjnp8N9xDfU9P/O5Wqz6 s9Prw8jD9S99WVt9TfYXEbTI2k8KvV9Uum0vY6u3JHpkFrfVO3QzwiJw4SNN7+X+1RjKwfDu 4bP2r/zp6p+y21Ptk7xaARtlvEkd11HTjn/ZG/tFrG5MncKgA2J9vEqnl/VfpuRl25bn3Muv O55Y/aNfgFbwMCnp9Bopc97S4umx290nzKU5RkBXYdOyoRIJvx6tTN+zOzXB9b7G+1lr/U2t Y54EFrT3gA6KAPRR+k9UuJLiXEuJJAducdPCw6q7fgYt9nqWNJJguaHENcW/R3NHMITemYbG FjWmC1zeT9F0SPwTF6BtnShTZW2x3ptc17h7pBaQ0EaTy3VRro6U5xpx3Fji0T6ZIkNEzPBM O1R7em4lk7mnUkmHEcncfxSrxMektNbSCyY1J5DWn8GhFTRY/FYyt7sZzMfez0Xk7gRBY0xq eOylaemOfYXWuHqtDntBcGkOAYCBHmOFYbg4zSC0H2kFoLiQ2JgNE6DVAf0vFj2bmO9vuBJg NLTp/mooROs6a936S57hXtMuc4g/nD/NhEGPhX61ucTUQ3c0kQW7u/8AaKk7p2IfzXdvzjzr r85RWVsqbtYIEl0ebjJRAUiGJU21tsuc9vG5xImNs/cipEqJKchBlZQoc0Ebtwcf80fxOirH qZFRtNcRULQJmSTG3hXjB+SiYTDGROkqHalpEuhpzsW9/Ua8iyyv0xs9JgPeQSVDpuQW9J3f nVbmD4zp+Vaax8Jr68i7CLTt9X1JjTaNefPRRyjKEoEmzISiZeJ1DGQYmOtkgi/F02BzWBpO 4t0k6koBxGeo6zcQ4uLpEaT8kcANBjvqqubmCgemGh7n8gzoP7JCdlMYY+LIL4Ng3eTjllkG PEeEz0Pk1ywDIBc1woedrbSBq74wrVePXUSWySfGP7lVpsqyGxdsqrY5vsBLfa1r+Jk8lWcL IpyQBZ+h2j3RLp8OVU5TLAyPFHUkyiR+IdP4jgyjGOCR4YgY8g6eB/ikHIT9pUZ1T7h4hL4j ilLJjkKIjGVx2sWDX12anI5IxhMHQmQqQ6aHX6KOrfGfBOZaABHzKYkRAICYOEakFVxD0A+2 eETnL2if3hvw1WjMZeoj3PUYRj7gH7vS99WFnOohRlPYSTMg/BQlaHDP7lw2OLgrrw+V7tLi j97ujw8d9L862e+xr6fstM2M/m2fnD90KRvp/wBIz/OC+ZUkwMer9LOvp/0jf84KDr6v9I3/ ADgvmxJOFKfo919X+kb/AJwUHXVfvt/zgvnNJEIL9EG2r99v3hRNtf77fvC+eUk5T9Bm2v8A fb94UTbX++37wvn5JEIffjbX++37woGyv95v3heCJIqfeTYz94feFE2M/eH3heEJJyH3U2M/ eH3hQNjP3h94XhqSKH3EvZ+8PvCiXs/eH3heIJIqfbS9n7w+8KJe394fevFEklPtRe394feo 72/vD714ukkp9mL2+I+9RLmdyPwXjaSKtej7CSzxH4Jpb4hePpIj6K18X1/cPEfeolw8QvIk kdfBD64XDxCjI8QvJUkfsQ+slw8QmkeK8nSSU//ZCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9i ag08PCANL1RleHRCb3ggL0RpdiANL0ZyYW1lIC9EaXYgDS9Gb290bm90ZSAvTm90ZSANL0Vu ZG5vdGUgL05vdGUgDS9TaGFwZSAvRmlndXJlIA0vSW5saW5lU2hhcGUgL0ZpZ3VyZSANL1RP QSAvVE9DIA0vVE9BSSAvVE9DSSANL1RPRiAvVE9DIA0vVE9GSSAvVE9DSSANL1N1cGVyc2Ny aXB0IC9TcGFuIA0vU3Vic2NyaXB0IC9TcGFuIA0vU3RyaWtlb3V0IC9TcGFuIA0vVW5kZXJs aW5lIC9TcGFuIA0vRHJvcENhcCAvRmlndXJlIA0vTm9ybWFsIC9QIA0vUGMtZW50cnkgL1Ag DT4+IA1lbmRvYmoNMiAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAzIDAgUiBdIA0vQyAv Tm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgWyAwIDYgMCBSIDIgXSANL1AgODEgMCBSIA0+PiAN ZW5kb2JqDTMgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCA5IA0vVGV4dEFs aWduIC9FbmQgDT4+IA1lbmRvYmoNNCAwIG9iag08PCANL05vcm1hbCA1IDAgUiANL1BjLWVu dHJ5IDE3IDAgUiANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vV3JpdGlu Z01vZGUgL0xyVGIgDS9TdGFydEluZGVudCAwIA0vRW5kSW5kZW50IDAgDS9UZXh0QWxpZ24g L1N0YXJ0IA0vU3BhY2VCZWZvcmUgMCANL1NwYWNlQWZ0ZXIgMCANL1RleHRJbmRlbnQgMCAN Pj4gDWVuZG9iag02IDAgb2JqDTw8IA0vUyAvU3VwZXJzY3JpcHQgDS9QIDIgMCBSIA0vQSA5 MyAwIFIgDS9QZyAxMDkgMCBSIA0vSyAxIA0+PiANZW5kb2JqDTcgMCBvYmoNPDwgDS9TIC9O b3JtYWwgDS9BIFsgOCAwIFIgXSANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDMgDS9Q IDgxIDAgUiANPj4gDWVuZG9iag04IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWdu IC9FbmQgDT4+IA1lbmRvYmoNOSAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMCAwIFIg XSANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQgDS9QIDgxIDAgUiANPj4gDWVuZG9i ag0xMCAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGlnbiAvRW5kIA0+PiANZW5kb2Jq DTExIDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sg OCANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZElu ZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9O b3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA5IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0xMyAwIG9i ag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDEwIA0vUCA4 MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQz OSA+PiANPj4gDWVuZG9iag0xNCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDEwOSAwIFIgDS9LIDExIA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0 SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0xNSAwIG9iag08PCAN L1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAxMiANL1AgODMg MCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0Mzkg Pj4gDT4+IA1lbmRvYmoNMTYgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5 IA0vUGcgMTA5IDAgUiANL0sgMTMgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3Rh cnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTE3IDAgb2JqDTw8 IA0vTyAvTGF5b3V0IA0vV3JpdGluZ01vZGUgL0xyVGIgDS9TdGFydEluZGVudCA3LjIgDS9F bmRJbmRlbnQgMCANL1RleHRBbGlnbiAvU3RhcnQgDS9TcGFjZUJlZm9yZSAwIA0vU3BhY2VB ZnRlciAwIA0vVGV4dEluZGVudCAtNy4xOTk5OCANPj4gDWVuZG9iag0xOCAwIG9iag08PCAN L1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAxNCANL1AgODMg MCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0Mzkg Pj4gDT4+IA1lbmRvYmoNMTkgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5 IA0vUGcgMTA5IDAgUiANL0sgMTUgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3Rh cnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTIwIDAgb2JqDTw8 IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDE2IA0vUCA4 MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQz OSA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08PCANL1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50 cnkgDS9QZyAxMDkgMCBSIA0vSyAxNyANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9T dGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMjIgMCBvYmoN PDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAgUiANL0sgMTggDS9Q IDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQg NDM5ID4+IA0+PiANZW5kb2JqDTIzIDAgb2JqDTw8IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1l bnRyeSANL1BnIDEwOSAwIFIgDS9LIDE5IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0yNCAwIG9i ag08PCANL1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAyMCAN L1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVu dCA0MzkgPj4gDT4+IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1Bj LWVudHJ5IA0vUGcgMTA5IDAgUiANL0sgMjEgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91 dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTI2IDAg b2JqDTw8IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDIy IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5k ZW50IDQzOSA+PiANPj4gDWVuZG9iag0yNyAwIG9iag08PCANL1MgL1BjLWVudHJ5IA0vQyAv UGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAyMyANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5 b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMjgg MCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAgUiANL0sg MjQgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJ bmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vUyAvUGMtZW50cnkgDS9D IC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDI1IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9M YXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0z MCAwIG9iag08PCANL1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0v SyAyNiANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0Vu ZEluZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMzEgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSAN L0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAgUiANL0sgMjcgDS9QIDgzIDAgUiANL0EgPDwgL08g L0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2Jq DTMyIDAgb2JqDTw8IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIg DS9LIDI4IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAv RW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0zMyAwIG9iag08PCANL1MgL1BjLWVudHJ5 IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAyOSANL1AgODMgMCBSIA0vQSA8PCAv TyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzkgPj4gDT4+IA1lbmRv YmoNMzQgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAg UiANL0sgMzAgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1 IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTM1IDAgb2JqDTw8IA0vUyAvUGMtZW50 cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDMxIA0vUCA4MyAwIFIgDS9BIDw8 IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVu ZG9iag0zNiAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIg DS9LIDMyIA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAv RW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0zNyAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDMzIA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9M YXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0z OCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDM0 IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5k ZW50IDQzOSA+PiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05v cm1hbCANL1BnIDEwOSAwIFIgDS9LIDM1IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag00MCAwIG9i ag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDM2IA0vUCA4 MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQz OSA+PiANPj4gDWVuZG9iag00MSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDEwOSAwIFIgDS9LIDM3IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0 SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag00MiAwIG9iag08PCAN L1MgL05vcm1hbCANL0EgWyA0MyAwIFIgXSANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9L IDUgDS9QIDgyIDAgUiANPj4gDWVuZG9iag00MyAwIG9iag08PCANL08gL0xheW91dCANL1Rl eHRBbGlnbiAvQ2VudGVyIA0vU3RhcnRJbmRlbnQgNzkgDS9FbmRJbmRlbnQgLTEyIA0+PiAN ZW5kb2JqDTQ0IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAg UiANL0sgNiANL1AgODIgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA3OSAv RW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag00NSAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDcgDS9QIDgyIDAgUiANL0EgPDwgL08gL0xh eW91dCAvU3RhcnRJbmRlbnQgNzkgL0VuZEluZGVudCAtMTIgPj4gDT4+IA1lbmRvYmoNNDYg MCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyAzOCAN L1AgODQgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA3OSAvRW5kSW5kZW50 IDIxNCA+PiANPj4gDWVuZG9iag00NyAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1h bCANL1BnIDEwOSAwIFIgDS9LIDM5IA0vUCA4NCAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0 YXJ0SW5kZW50IDc5IC9FbmRJbmRlbnQgMjE0ID4+IA0+PiANZW5kb2JqDTQ4IDAgb2JqDTw8 IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNDAgDS9QIDg0IDAg UiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgNzkgL0VuZEluZGVudCAyMTQgPj4g DT4+IA1lbmRvYmoNNDkgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAx MDkgMCBSIA0vSyA0MSANL1AgODQgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVu dCA3OSAvRW5kSW5kZW50IDIxNCA+PiANPj4gDWVuZG9iag01MCAwIG9iag08PCANL1MgL05v cm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQyIA0vUCA4NCAwIFIgDS9BIDw8 IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDc5IC9FbmRJbmRlbnQgMjE0ID4+IA0+PiANZW5k b2JqDTUxIDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiAN L0sgNDMgDS9QIDg0IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgNzkgL0Vu ZEluZGVudCAyMTQgPj4gDT4+IA1lbmRvYmoNNTIgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9D IC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA0NCANL1AgODQgMCBSIA0vQSA8PCAvTyAvTGF5 b3V0IC9TdGFydEluZGVudCA3OSAvRW5kSW5kZW50IDIxNCA+PiANPj4gDWVuZG9iag01MyAw IG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQ1IA0v UCA4NCAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDc5IC9FbmRJbmRlbnQg MjE0ID4+IA0+PiANZW5kb2JqDTU0IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFs IA0vUGcgMTA5IDAgUiANL0sgNDYgDS9QIDg0IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3Rh cnRJbmRlbnQgNzkgL0VuZEluZGVudCAyMTQgPj4gDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwg DS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA0NyANL1AgODQgMCBS IA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA3OSAvRW5kSW5kZW50IDIxNCA+PiAN Pj4gDWVuZG9iag01NiAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEw OSAwIFIgDS9LIDQ4IA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50 IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag01NyAwIG9iag08PCANL1MgL05v cm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQ5IA0vUCA4NSAwIFIgDS9BIDw8 IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVu ZG9iag01OCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIg DS9LIDUwIA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAv RW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag01OSAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDUxIA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9M YXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag02 MCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDUy IA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5k ZW50IC0xMiA+PiANPj4gDWVuZG9iag02MSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05v cm1hbCANL1BnIDEwOSAwIFIgDS9LIDUzIA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag02MiAwIG9i ag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDU0IA0vUCA4 NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0x MiA+PiANPj4gDWVuZG9iag02MyAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDEwOSAwIFIgDS9LIDU1IA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0 SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag02NCAwIG9iag08PCAN L1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDU2IA0vUCA4NSAwIFIg DS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiAN Pj4gDWVuZG9iag02NSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEw OSAwIFIgDS9LIDU3IA0vUCA4NiAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50 IDg4IC9FbmRJbmRlbnQgMTU3ID4+IA0+PiANZW5kb2JqDTY2IDAgb2JqDTw8IA0vUyAvTm9y bWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNTggDS9QIDg2IDAgUiANL0EgPDwg L08gL0xheW91dCAvU3RhcnRJbmRlbnQgODggL0VuZEluZGVudCAxNTcgPj4gDT4+IA1lbmRv YmoNNjcgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0v SyA1OSANL1AgODYgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA4OCAvRW5k SW5kZW50IDE1NyA+PiANPj4gDWVuZG9iag02OCAwIG9iag08PCANL1MgL05vcm1hbCANL0Mg L05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDYwIA0vUCA4NiAwIFIgDS9BIDw8IC9PIC9MYXlv dXQgL1N0YXJ0SW5kZW50IDg4IC9FbmRJbmRlbnQgMTU3ID4+IA0+PiANZW5kb2JqDTY5IDAg b2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNjEgDS9Q IDg2IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgODggL0VuZEluZGVudCAx NTcgPj4gDT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9BIFsgNzEgMCBS IF0gDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA2MiANL1AgODcgMCBSIA0+PiANZW5k b2JqDTcxIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDS9TdGFy dEluZGVudCA1NiANL0VuZEluZGVudCA5OSANPj4gDWVuZG9iag03MiAwIG9iag08PCANL1Mg L05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIFsgNjQgNzMgMCBSIDY3IF0g DS9QIDg5IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgMzc2IC9FbmRJbmRl bnQgLTcgPj4gDT4+IA1lbmRvYmoNNzMgMCBvYmoNPDwgDS9TIC9MaW5rIA0vUCA3MiAwIFIg DS9LIFsgNzQgMCBSIDw8IC9UeXBlIC9PQkpSIC9QZyAxMDkgMCBSIC9PYmogMTExIDAgUiA+ PiBdIA0+PiANZW5kb2JqDTc0IDAgb2JqDTw8IA0vUyAvVW5kZXJsaW5lIA0vUCA3MyAwIFIg DS9BIDk0IDAgUiANL1BnIDEwOSAwIFIgDS9LIDY1IA0+PiANZW5kb2JqDTc1IDAgb2JqDTw8 IA0vUyAvTm9ybWFsIA0vQSBbIDc2IDAgUiBdIA0vQyAvTm9ybWFsIA0vSyA3NyAwIFIgDS9Q IDg5IDAgUiANPj4gDWVuZG9iag03NiAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGln biAvQ2VudGVyIA0vU3RhcnRJbmRlbnQgMzc2IA0vRW5kSW5kZW50IC03IA0+PiANZW5kb2Jq DTc3IDAgb2JqDTw8IA0vUyAvSW5saW5lU2hhcGUgDS9QZyAxMDkgMCBSIA0vUCA3NSAwIFIg DS9LIFsgNjYgNjggXSANL0FsdCAoKQ0vQSBbIDk1IDAgUiBdIA0+PiANZW5kb2JqDTc4IDAg b2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNjkgDS9Q IDkwIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQg NDM4ID4+IA0+PiANZW5kb2JqDTc5IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFs IA0vUGcgMTA5IDAgUiANL0sgWyA4MCAwIFIgNzEgXSANL1AgOTAgMCBSIA0vQSA8PCAvTyAv TGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzggPj4gDT4+IA1lbmRvYmoN ODAgMCBvYmoNPDwgDS9TIC9JbmxpbmVTaGFwZSANL1BnIDEwOSAwIFIgDS9LIDcwIA0vUCA3 OSAwIFIgDS9BbHQgKCkNL0EgWyA5NiAwIFIgXSANPj4gDWVuZG9iag04MSAwIG9iag08PCAN L1MgL1NlY3QgDS9QIDEwOCAwIFIgDS9MYW5nIChFTi1HQikNL0sgWyAyIDAgUiA3IDAgUiA5 IDAgUiA4OCAwIFIgODMgMCBSIDgyIDAgUiA4NCAwIFIgODUgMCBSIDg2IDAgUiA4NyAwIFIg DTg5IDAgUiA5MCAwIFIgXSANPj4gDWVuZG9iag04MiAwIG9iag08PCANL1MgL1RleHRCb3gg DS9BbHQgKFRleHQgQm94OiBTY29wZVxyXG5XaXJlbGVzcyBzZW5zb3IgbmV0d29ya3MgXChX U05cKSAtIG5ldHdvcmtzIG9mIHRpbnksIFwNYXV0b25vbW91cyBkZXZpY2VzIGVxdWlwcGVk IHdpdGggd2lyZWxlc3MgY29tbXVuaWNhdGlvbiAtIGFyZSBhIHRvcGljIG9mXA0gYWN0aXZl IHJlc2VhcmNoIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCByZXNlYXJjaCBjb21tdW5pdGll cywgcmFuZ2luZyBcDWZyb20gaGFyZHdhcmUgdG8gYXBwbGljYXRpb25zLiBXU05zIGFyZSBj aGFyYWN0ZXJpemVkIGJ5IGEgbmVlZCB0byBjYXJlZlwNdWxseSBpbnRlZ3JhdGUgZnVuY3Rp b25hbGl0aWVzIHRyYWRpdGlvbmFsbHkgY29uc2lkZXJlZCB0byBiZSBzZXBhcmF0ZSBpXA1u IG9yZGVyIHRvIGFjaGlldmUgbWF4aW11bSBlZmZpY2llbmN5LCBlc3BlY2lhbGx5IHdpdGgg cmVnYXJkIHRvIGVuZXJneSBcDWNvbnN1bXB0aW9uIGFuZCBtYW5hZ2VtZW50LiBIZW5jZSwg YSBjbG9zZSBpbnRlcmFjdGlvbiBvZiByZXNlYXJjaCBmcm9tIFwNZGlmZmVyZW50IGJhY2tn cm91bmRzIGlzIHJlcXVpcmVkLiBBZGRpdGlvbmFsbHksIFdTTnMgYXJlIGV2b2x2aW5nIGZy b20gXA1zaW1wbGUgZGF0YSB0cmFuc3BvcnRhdGlvbiBuZXR3b3JrcyB0byBmdW5jdGlvbmFs bHkgcmljaCBkaXN0cmlidXRlZCBzeXNcDXRlbXMsIGUuZy4sIGJlY2F1c2UgYWN0dWF0b3Jz IGluIHRoZSBuZXR3b3JrIGhhdmUgdG8gYmUgc3VwcG9ydGVkLlxyXG5UaFwNZSBnb2FsIG9m IHRoaXMgd29ya3Nob3AgaXMgdG8gYnJpbmcgdG9nZXRoZXIgcmVzZWFyY2hlcnMgZnJvbSBk aWZmZXJlbnQgXA1iYWNrZ3JvdW5kcywgZnJvbSBoYXJkd2FyZSB0byBhcHBsaWNhdGlvbnMs IHRvIGNyZWF0ZSBhIGZvcnVtIHdoZXJlIGNyb3NcDXMtbGF5ZXIgaW50ZWdyYXRpb24sIG5v dmVsIHNvbHV0aW9ucyBmb3Igc3BlY2lmaWMgcHJvYmxlbXMsIGFuZCB0aGUgZnV0dVwNcmUg ZGV2ZWxvcG1lbnQgb2YgV1NOIGZ1bmN0aW9uYWxpdGllcyBjYW4gYmUgZGlzY3Vzc2VkLlxy XG5cMDAwKQ0vUCA4MSAwIFIgDS9LIFsgNDIgMCBSIDQ0IDAgUiA0NSAwIFIgXSANPj4gDWVu ZG9iag04MyAwIG9iag08PCANL1MgL1RleHRCb3ggDS9BbHQgKFwzNzZcMzc3XDAwMFRcMDAw ZVwwMDB4XDAwMHRcMDAwIFwwMDBCXDAwMG9cMDAweFwwMDA6XDAwMCBcMDAwQ1wwMDBoXDAw MFwNYVwwMDBpXDAwMHJcMDAwXHJcMDAwXG5cMDAwQVwwMDBkXDAwMGFcMDAwbVwwMDAgXDAw MFdcMDAwb1wwMDBsXDAwMGlcMDAwXA1zXDAwMHpcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDAg XDAwMEJcMDAwZVwwMDByXDAwMGxcMDAwaVwwMDBuXDAwMFxyXDAwMFxuXA1cMDAwXHJcMDAw XG5cMDAwUFwwMDByXDAwMG9cMDAwZ1wwMDByXDAwMGFcMDAwbVwwMDAgXDAwMENcMDAwb1ww MDBtXDAwMG1cDVwwMDBpXDAwMHRcMDAwdFwwMDBlXDAwMGVcMDAwXHJcMDAwXG5cMDAwSFww MDBvXDAwMGxcMDAwZ1wwMDBlXDAwMHJcMDAwIFwNXDAwMEJcMDAwb1wwMDBjXDAwMGhcMDAw ZVwwMDAsXDAwMCBcMDAwSFwwMDBlXDAwMGlcMDAwblwwMDByXDAwMGlcMDAwY1wwMDBcDWhc MDAwLVwwMDBIXDAwMGVcMDAwclwwMDB0XDAwMHpcMDAwLVwwMDBJXDAwMG5cMDAwc1wwMDBp XDAwMHRcMDAwdVwwMDB0XDAwMFwNZVwwMDAsXDAwMCBcMDAwQlwwMDBlXDAwMHJcMDAwbFww MDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwRVwwMDByXDAwMGRcMDAwXA1hXDAwMGxcMDAwIFww MDBDXDAwMGFcMDAweVwwMDBpXDAwMHJcMDAwY1wwMDBpXDAwMCxcMDAwIFwwMDBZXDAwMGVc MDAwZFwwMDBcDWlcMDAwdFwwMDBlXDAwMHBcMDAwZVwwMDAgXDAwMFVcMDAwblwwMDBpXDAw MHZcMDAwZVwwMDByXDAwMHNcMDAwaVwwMDB0XDAwMFwNeVwwMDAgXDAwMElcMDAwc1wwMDB0 XDAwMGFcMDAwblwwMDBiXDAwMHVcMDAwbFwwMDBcclwwMDBcblwwMDBLXDAwMHVcMDAwXA1y XDAwMHRcMDAwIFwwMDBHXDAwMGVcMDAwaVwwMDBoXDAwMHNcMDAwLFwwMDAgXDAwMFRcMDAw VVwwMDAgXDAwMEJcMDAwZVwwMDBcDXJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAw UFwwMDBhXDAwMHVcMDAwbFwwMDAgXDAwMEhcMDAwYVwwMDB2XDAwMFwNaVwwMDBuXDAwMGdc MDAwYVwwMDAsXDAwMCBcMDAwVVwwMDBuXDAwMGlcMDAwdlwwMDBlXDAwMHJcMDAwc1wwMDBp XDAwMHRcMDAwXA15XDAwMCBcMDAwVFwwMDB3XDAwMGVcMDAwblwwMDB0XDAwMGVcMDAwXHJc MDAwXG5cMDAwSFwwMDBvXDAwMGxcMDAwZ1wwMDBcDWVcMDAwclwwMDAgXDAwMEtcMDAwYVww MDByXDAwMGxcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDAgXDAwMEJcMDAwZVwwMDByXDAwMFwN bFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwVFwwMDBoXDAwMG9cMDAwbVwwMDBhXDAwMHNc MDAwIFwwMDBMXDAwMGVcMDAwXA1uXDAwMHRcMDAwc1wwMDBjXDAwMGhcMDAwLFwwMDAgXDAw MElcMDAwblwwMDBmXDAwMGlcMDAwblwwMDBlXDAwMG9cMDAwblwwMDBcDVxyXDAwMFxuXDAw MElcMDAwYVwwMDBuXDAwMCBcMDAwTVwwMDBhXDAwMHJcMDAwc1wwMDBoXDAwMGFcMDAwbFww MDBsXDAwMFwNLFwwMDAgXDAwMEJcMDAwVFwwMDAgXDAwMGVcMDAweFwwMDBhXDAwMGNcMDAw dFwwMDBcclwwMDBcblwwMDBGXDAwMHJcMDAwXA1pXDAwMGVcMDAwZFwwMDBlXDAwMG1cMDAw YVwwMDBuXDAwMG5cMDAwIFwwMDBNXDAwMGFcMDAwdFwwMDB0XDAwMGVcMDAwclwwMDBcDW5c MDAwLFwwMDAgXDAwMEVcMDAwVFwwMDBIXDAwMCBcMDAwWlwwMDBcMzc0XDAwMHJcMDAwaVww MDBjXDAwMGhcMDAwXHJcMDAwXA1cblwwMDBDXDAwMGhcMDAwaVwwMDBhXDAwMHJcMDAwYVww MDAgXDAwMFBcMDAwZVwwMDB0XDAwMHJcMDAwaVwwMDBvXDAwMGxcDVwwMDBpXDAwMCxcMDAw IFwwMDBVXDAwMG5cMDAwaVwwMDB2XDAwMGVcMDAwclwwMDBzXDAwMGlcMDAwdFwwMDB5XDAw MCAgXDAzNlwNXDAwMExcMDAwYVwwMDAgXDAwMFNcMDAwYVwwMDBwXDAwMGlcMDAwZVwwMDBu XDAwMHpcMDAwYSBcMDM0XDAwMCxcMDAwIFwwMDBcDVJcMDAwb1wwMDBtXDAwMGVcMDAwXHJc MDAwXG5cMDAwUlwwMDBhXDAwMGRcMDAwdVwwMDAgXDAwMFBcMDAwb1wwMDBwXDAwMFwNZVww MDBzXDAwMGNcMDAwdVwwMDAtXDAwMFpcMDAwZVwwMDBsXDAwMGVcMDAwdFwwMDBpXDAwMG5c MDAwLFwwMDAgXDAwMEZcMDAwXA1oXDAwMEdcMDAwIFwwMDBGXDAwMG9cMDAwa1wwMDB1XDAw MHNcMDAwXHJcMDAwXG5cMDAwSlwwMDBhXDAwMG5cMDAwIFwwMDBcDVJcMDAwYVwwMDBiXDAw MGFcMDAwZVwwMDB5XDAwMCxcMDAwIFwwMDBVXDAwMG5cMDAwaVwwMDB2XDAwMGVcMDAwclww MDBzXDAwMFwNaVwwMDB0XDAwMHlcMDAwIFwwMDBvXDAwMGZcMDAwIFwwMDBDXDAwMGFcMDAw bFwwMDBpXDAwMGZcMDAwb1wwMDByXDAwMG5cMDAwXA1pXDAwMGFcMDAwIFwwMDBhXDAwMHRc MDAwIFwwMDBCXDAwMGVcMDAwclwwMDBrXDAwMGVcMDAwbFwwMDBlXDAwMHlcMDAwXHJcDVww MDBcblwwMDBIXDAwMGVcMDAwclwwMDBiXDAwMGVcMDAwclwwMDB0XDAwMCBcMDAwUlwwMDBl XDAwMGlcMDAwY1wwMDBoXDAwMFwNbFwwMDAsXDAwMCBcMDAwRlwwMDBoXDAwMEdcMDAwIFww MDBJXDAwMFpcMDAwTVwwMDBcclwwMDBcblwwMDBMXDAwMGlcMDAwXA1vXDAwMG5cMDAwZVww MDBsXDAwMCBcMDAwU1wwMDBhXDAwMGNcMDAwa1wwMDBzXDAwMCxcMDAwIFwwMDBVXDAwMG5c MDAwaVwwMDBcDXZcMDAwZVwwMDByXDAwMHNcMDAwaVwwMDB0XDAwMHlcMDAwIFwwMDBDXDAw MG9cMDAwbFwwMDBsXDAwMGVcMDAwZ1wwMDBlXDAwMFwNIFwwMDBMXDAwMG9cMDAwblwwMDBk XDAwMG9cMDAwblwwMDBcclwwMDBcblwwMDBUXDAwMGhcMDAwb1wwMDBtXDAwMGFcMDAwXA1z XDAwMCBcMDAwU1wwMDBpXDAwMGtcMDAwb1wwMDByXDAwMGFcMDAwLFwwMDAgXDAwMFRcMDAw VVwwMDAgXDAwMEJcMDAwZVwwMDBcDXJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAw SlwwMDBvXDAwMGNcMDAwaFwwMDBlXDAwMG5cMDAwIFwwMDBTXDAwMFwNY1wwMDBoXDAwMGlc MDAwbFwwMDBsXDAwMGVcMDAwclwwMDAsXDAwMCBcMDAwRlwwMDBVXDAwMCBcMDAwQlwwMDBl XDAwMHJcMDAwXA1sXDAwMGlcMDAwblwwMDBcclwwMDBcblwwMDBNXDAwMGFcMDAwclwwMDB0 XDAwMGlcMDAwblwwMDAgXDAwMFZcMDAwZVwwMDBcDXRcMDAwdFwwMDBlXDAwMHJcMDAwbFww MDBpXDAwMCxcMDAwIFwwMDBFXDAwMFBcMDAwRlwwMDBMXDAwMCBcMDAwTFwwMDBhXDAwMFwN dVwwMDBzXDAwMGFcMDAwblwwMDBuXDAwMGVcMDAwXHJcMDAwXG5cMDAwQVwwMDBuXDAwMGRc MDAwclwwMDBlXDAwMGFcMDAwXA1zXDAwMCBcMDAwV1wwMDBpXDAwMGxcMDAwbFwwMDBpXDAw MGdcMDAwLFwwMDAgXDAwMEhcMDAwYVwwMDBzXDAwMHNcMDAwb1wwMDBcDS1cMDAwUFwwMDBs XDAwMGFcMDAwdFwwMDB0XDAwMG5cMDAwZVwwMDByXDAwMCBcMDAwSVwwMDBuXDAwMHNcMDAw dFwwMDBpXDAwMFwNdFwwMDB1XDAwMHRcMDAwZVwwMDAgXDAwMFBcMDAwb1wwMDB0XDAwMHNc MDAwZFwwMDBhXDAwMG1cMDAwXHJcMDAwXG5cMDAwXA1BXDAwMGRcMDAwYVwwMDBtXDAwMCBc MDAwV1wwMDBvXDAwMGxcMDAwaVwwMDBzXDAwMHpcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDBc DSBcMDAwQlwwMDBlXDAwMHJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwTVwwMDBp XDAwMGNcMDAwaFwwMDBlXDAwMFwNbFwwMDBlXDAwMCBcMDAwWlwwMDBvXDAwMHJcMDAwelww MDBpXDAwMCxcMDAwIFwwMDBVXDAwMG5cMDAwdlwwMDBlXDAwMHJcMDAwXA1zXDAwMGlcMDAw dFwwMDB5XDAwMCBcMDAwRlwwMDBlXDAwMHJcMDAwclwwMDBhXDAwMHJcMDAwYVwwMDBcclww MDBcblwwMDBcDVJcMDAwaVwwMDBjXDAwMGhcMDAwYVwwMDByXDAwMGRcMDAwIFwwMDBaXDAw MHVcMDAwclwwMDBhXDAwMHdcMDAwc1wwMDBrXDAwMFwNaVwwMDAsXDAwMCBcMDAwSVwwMDBT XDAwMEFcMDAwIFwwMDBDXDAwMG9cMDAwclwwMDBwXDAwMC5cMDAwXHJcMDAwXG5cMDAwXA1c clwwMDBcblwwMDBPXDAwMHJcMDAwZ1wwMDBhXDAwMG5cMDAwaVwwMDB6XDAwMGFcMDAwdFww MDBpXDAwMG9cMDAwblwwMDBcDSBcMDAwQ1wwMDBvXDAwMG1cMDAwbVwwMDBpXDAwMHRcMDAw dFwwMDBlXDAwMGVcMDAwXHJcMDAwXG5cMDAwSFwwMDBvXDAwMFwNbFwwMDBnXDAwMGVcMDAw clwwMDAgXDAwMEtcMDAwYVwwMDByXDAwMGxcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDAgXDAw MEJcMDAwXA1lXDAwMHJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwQVwwMDBuXDAw MGRcMDAwclwwMDBlXDAwMGFcMDAwc1wwMDBcDSBcMDAwV1wwMDBpXDAwMGxcMDAwbFwwMDBp XDAwMGdcMDAwLFwwMDAgXDAwMEhcMDAwUFwwMDBJXDAwMFxyXDAwMFxuXDAwMFwNXHJcMDAw XG5cMDAwXHJcMDAwXG5cMDAwXDAwMCkNL1AgODEgMCBSIA0vSyBbIDExIDAgUiAxMiAwIFIg MTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDE4IDAgUiAxOSAwIFIgMjAgMCBSIDIxIDAg UiANMjIgMCBSIDIzIDAgUiAyNCAwIFIgMjUgMCBSIDI2IDAgUiAyNyAwIFIgMjggMCBSIDI5 IDAgUiAzMCAwIFIgMzEgMCBSIA0zMiAwIFIgMzMgMCBSIDM0IDAgUiAzNSAwIFIgMzYgMCBS IDM3IDAgUiAzOCAwIFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIgDV0gDT4+IA1lbmRvYmoNODQg MCBvYmoNPDwgDS9TIC9UZXh0Qm94IA0vQWx0IChUZXh0IEJveDogV2UgZW5jb3VyYWdlIGNv bnRyaWJ1dGlvbnMgZGVzY3JpYmluZyBpbm5vdmF0aXZlIHdvcmsgb24gV1NOLiBcDUFyZWFz IG9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86XHJcblxyXG4t IEhhcmR3YXJlIGZvclwNIFdTTiwgZS5nLjogdHJhbnNjZWl2ZXIgY29uY2VwdHMsIHdha2V1 cCByYWRpbywgYW50ZW5uYSBkZXNpZ24sIHN5c3RlbSBpXA1udGVncmF0aW9uLCBwcm9jZXNz IGFuZCBjb3N0IG9mIG1hbnVmYWN0dXJpbmcsIGJhdHRlcnkgdGVjaG5vbG9neSwgZW5lcmdc DXkgc2NhdmVuZ2luZ1xyXG5cclxuLSBDb21tdW5pY2F0aW9uIHByb3RvY29scywgZS5nLjog TUFDIGFuZCBsaW5rIGxheWVyIFwNcHJvYmxlbXM7IHJvdXRpbmcgYW5kIHRyYW5zcG9ydCBw cm90b2NvbHMgc3VpdGFibGUgZm9yIFdTTiwgcmVkdW5kYW5jeSwgXA1hZ2dyZWdhdGlvbiBz dXBwb3J0LCBhbmQgbW9iaWxpdHkgc3VwcG9ydDsgc3VwcG9ydGluZyBmdW5jdGlvbmFsaXRp ZXMgbGlcDWtlIGxvY2F0aW9uaW5nIGFuZCBzeW5jaHJvbml6YXRpb25cclxuXHJcbi0gU291 cmNlIGNvZGluZyB0ZWNobmlxdWVzIGFwcFwNcm9wcmlhdGUgZm9yIFdTTiwgZS5nLiwgdG8g c3VwcG9ydCBkYXRhIGZ1c2lvbjsgZGlzdHJpYnV0ZWQgc2lnbmFsIHByb2NlXA1zc2luZ1xy XG5cclxuLSBEaXN0cmlidXRlZCBjb250cm9sIGFuZCBhY3R1YXRpb25cclxuXHJcblwwMDAp DS9QIDgxIDAgUiANL0sgWyA0NiAwIFIgNDcgMCBSIDQ4IDAgUiA0OSAwIFIgNTAgMCBSIDUx IDAgUiA1MiAwIFIgNTMgMCBSIDU0IDAgUiA1NSAwIFIgDV0gDT4+IA1lbmRvYmoNODUgMCBv YmoNPDwgDS9TIC9UZXh0Qm94IA0vQWx0IChcMzc2XDM3N1wwMDBUXDAwMGVcMDAweFwwMDB0 XDAwMCBcMDAwQlwwMDBvXDAwMHhcMDAwOlwwMDAgXDAwMC1cMDAwICBcMDM0XA1cMDAwTVww MDBpXDAwMGRcMDAwZFwwMDBsXDAwMGVcMDAwd1wwMDBhXDAwMHJcMDAwZSBcMDM1XDAwMCBc MDAwZlwwMDBvXDAwMFwNclwwMDAgXDAwMFdcMDAwU1wwMDBOXDAwMCxcMDAwIFwwMDBlXDAw MC5cMDAwZ1wwMDAuXDAwMDpcMDAwIFwwMDBDXDAwMG9cMDAwXA1uXDAwMGZcMDAwaVwwMDBn XDAwMHVcMDAwclwwMDBhXDAwMHRcMDAwaVwwMDBvXDAwMG5cMDAwIFwwMDBhXDAwMG5cMDAw ZFwwMDBcDSBcMDAwaVwwMDBuXDAwMHNcMDAwdFwwMDBhXDAwMGxcMDAwbFwwMDBhXDAwMHRc MDAwaVwwMDBvXDAwMG5cMDAwIFwwMDBzXDAwMFwNdVwwMDBwXDAwMHBcMDAwb1wwMDByXDAw MHRcMDAwLFwwMDAgXDAwMGxcMDAwb1wwMDBvXDAwMGtcMDAwdVwwMDBwXDAwMCBcMDAwXA1v XDAwMGZcMDAwIFwwMDBhXDAwMHZcMDAwYVwwMDBpXDAwMGxcMDAwYVwwMDBiXDAwMGxcMDAw ZVwwMDAgXDAwMGZcMDAwdVwwMDBcDW5cMDAwY1wwMDB0XDAwMGlcMDAwb1wwMDBuXDAwMGFc MDAwbFwwMDBpXDAwMHRcMDAwaVwwMDBlXDAwMHNcMDAwLFwwMDAgXDAwMFwNZ1wwMDByXDAw MG9cMDAwdVwwMDBwXDAwMCBcMDAwY1wwMDBvXDAwMG1cMDAwbVwwMDB1XDAwMG5cMDAwaVww MDBjXDAwMGFcMDAwXA10XDAwMGlcMDAwb1wwMDBuXDAwMCxcMDAwIFwwMDBkXDAwMGlcMDAw c1wwMDB0XDAwMHJcMDAwaVwwMDBiXDAwMHVcMDAwdFwwMDBcDWVcMDAwZFwwMDAgXDAwMGFc MDAwbFwwMDBnXDAwMG9cMDAwclwwMDBpXDAwMHRcMDAwaFwwMDBtXDAwMHNcMDAwIFwwMDBp XDAwMFwNblwwMDAgXDAwMFdcMDAwU1wwMDBOXDAwMCxcMDAwIFwwMDBpXDAwMG5cMDAwLVww MDBuXDAwMGVcMDAwdFwwMDB3XDAwMG9cMDAwXA1yXDAwMGtcMDAwIFwwMDBwXDAwMHJcMDAw b1wwMDBjXDAwMGVcMDAwc1wwMDBzXDAwMGlcMDAwblwwMDBnXDAwMCBcMDAwYVwwMDBcDW5c MDAwZFwwMDAgXDAwMHNcMDAwdFwwMDBvXDAwMHJcMDAwYVwwMDBnXDAwMGVcMDAwIFwwMDBv XDAwMGZcMDAwIFwwMDBkXDAwMFwNYVwwMDB0XDAwMGFcMDAwLFwwMDAgXDAwMGhcMDAwYVww MDByXDAwMG1cMDAwb1wwMDBuXDAwMGlcMDAwelwwMDBpXDAwMG5cMDAwXA1nXDAwMCBcMDAw blwwMDBvXDAwMGRcMDAwZVwwMDAtXDAwMGNcMDAwZVwwMDBuXDAwMHRcMDAwclwwMDBpXDAw MGNcMDAwIFwwMDBcDWFcMDAwblwwMDBkXDAwMCBcMDAwZFwwMDBhXDAwMHRcMDAwYVwwMDAt XDAwMGNcMDAwZVwwMDBuXDAwMHRcMDAwclwwMDBpXDAwMFwNY1wwMDAgXDAwMGFcMDAwZFww MDBkXDAwMHJcMDAwZVwwMDBzXDAwMHNcMDAwaVwwMDBuXDAwMGdcMDAwLFwwMDAgXDAwMFxy XA1cMDAwXG5cMDAwXHJcMDAwXG5cMDAwLVwwMDAgXDAwMEdcMDAwYVwwMDB0XDAwMGVcMDAw d1wwMDBhXDAwMHlcMDAwc1wwMDBcDSBcMDAwdFwwMDBvXDAwMCBcMDAwZlwwMDBpXDAwMHhc MDAwZVwwMDBkXDAwMCBcMDAwSVwwMDBuXDAwMHRcMDAwZVwwMDByXDAwMFwNblwwMDBlXDAw MHRcMDAwIFwwMDBhXDAwMG5cMDAwZFwwMDAgXDAwMGlcMDAwblwwMDB0XDAwMGVcMDAwZ1ww MDByXDAwMGFcMDAwXA10XDAwMGlcMDAwb1wwMDBuXDAwMCBcMDAwb1wwMDBmXDAwMCBcMDAw V1wwMDBTXDAwME5cMDAwIFwwMDBpXDAwMG5cMDAwdFwwMDBcDW9cMDAwIFwwMDBJXDAwMG5c MDAwdFwwMDBlXDAwMHJcMDAwblwwMDBlXDAwMHRcMDAwIFwwMDBtXDAwMGlcMDAwZFwwMDBk XDAwMFwNbFwwMDBlXDAwMHdcMDAwYVwwMDByXDAwMGVcMDAwIFwwMDBhXDAwMHJcMDAwY1ww MDBoXDAwMGlcMDAwdFwwMDBlXDAwMGNcMDAwXA10XDAwMHVcMDAwclwwMDBlXDAwMHNcMDAw IFwwMDBcclwwMDBcblwwMDBcclwwMDBcblwwMDAtXDAwMCBcMDAwU1wwMDBlXDAwMFwNY1ww MDB1XDAwMHJcMDAwaVwwMDB0XDAwMHlcMDAwLFwwMDAgXDAwMGVcMDAwLlwwMDBnXDAwMC5c MDAwOlwwMDAgXDAwMHBcMDAwXA1yXDAwMGlcMDAwbVwwMDBpXDAwMHRcMDAwaVwwMDB2XDAw MGVcMDAwc1wwMDAgXDAwMGZcMDAwb1wwMDByXDAwMCBcMDAwYVwwMDBcDXBcMDAwcFwwMDBy XDAwMG9cMDAwcFwwMDByXDAwMGlcMDAwYVwwMDB0XDAwMGVcMDAwIFwwMDBjXDAwMHJcMDAw eVwwMDBwXDAwMFwNdFwwMDBvXDAwMGdcMDAwclwwMDBhXDAwMHBcMDAwaFwwMDBpXDAwMGNc MDAwIFwwMDBwXDAwMHJcMDAwb1wwMDB0XDAwMG9cMDAwXA1jXDAwMG9cMDAwbFwwMDBzXDAw MCxcMDAwIFwwMDBzXDAwMGVcMDAwY1wwMDB1XDAwMHJcMDAwZVwwMDAgXDAwMHNcMDAweVww MDBcDXNcMDAwdFwwMDBlXDAwMG1cMDAwIFwwMDBlXDAwMG5cMDAwZ1wwMDBpXDAwMG5cMDAw ZVwwMDBlXDAwMHJcMDAwaVwwMDBuXDAwMFwNZ1wwMDAgXDAwMFxyXDAwMFxuXDAwMFxyXDAw MFxuXDAwMC1cMDAwIFwwMDBBXDAwMHBcMDAwcFwwMDBsXDAwMGlcMDAwY1wwMDBcDWFcMDAw dFwwMDBpXDAwMG9cMDAwblwwMDBzXDAwMCBcMDAwb1wwMDBmXDAwMCBcMDAwV1wwMDBTXDAw ME5cMDAwLFwwMDAgXDAwMFwNZVwwMDAuXDAwMGdcMDAwLlwwMDA6XDAwMCBcMDAwblwwMDBv XDAwMHZcMDAwZVwwMDBsXDAwMCBcMDAwYVwwMDBwXDAwMHBcMDAwXA1sXDAwMGlcMDAwY1ww MDBhXDAwMHRcMDAwaVwwMDBvXDAwMG5cMDAwc1wwMDAgXDAwMGFcMDAwblwwMDBkXDAwMCBc MDAwdFwwMDBcDWhcMDAwZVwwMDBpXDAwMHJcMDAwIFwwMDByXDAwMGVcMDAwcVwwMDB1XDAw MGlcMDAwclwwMDBlXDAwMG1cMDAwZVwwMDBuXDAwMFwNdFwwMDBzXDAwMCBcMDAwc1wwMDB1 XDAwMGNcMDAwaFwwMDAgXDAwMGFcMDAwc1wwMDAgXDAwMG1cMDAwZVwwMDBkXDAwMGlcMDAw XA1jXDAwMGlcMDAwblwwMDBlXDAwMCxcMDAwIFwwMDBlXDAwMG5cMDAwdlwwMDBpXDAwMHJc MDAwb1wwMDBuXDAwMG1cMDAwZVwwMDBcDW5cMDAwdFwwMDAgXDAwMGNcMDAwb1wwMDBuXDAw MHRcMDAwclwwMDBvXDAwMGxcMDAwLFwwMDAgXDAwMGVcMDAwdFwwMDBjXDAwMFwNLlwwMDA7 XDAwMCBcMDAwZVwwMDB4XDAwMHBcMDAwZVwwMDByXDAwMGlcMDAwZVwwMDBuXDAwMGNcMDAw ZVwwMDBzXDAwMCBcMDAwXA13XDAwMGlcMDAwdFwwMDBoXDAwMCBcMDAwclwwMDBlXDAwMGFc MDAwbFwwMDAtXDAwMHdcMDAwb1wwMDByXDAwMGxcMDAwZFwwMDBcDSBcMDAwYVwwMDBwXDAw MHBcMDAwbFwwMDBpXDAwMGNcMDAwYVwwMDB0XDAwMGlcMDAwb1wwMDBuXDAwMHNcMDAwXHJc MDAwXG5cDVwwMDBcclwwMDBcblwwMDAtXDAwMCBcMDAwV1wwMDBoXDAwMGFcMDAwdFwwMDAg XDAwMHBcMDAwYVwwMDByXDAwMHRcMDAwIFwNXDAwMHdcMDAwaVwwMDBsXDAwMGxcMDAwIFww MDBXXDAwMFNcMDAwTlwwMDBzXDAwMCBcMDAwcFwwMDBsXDAwMGFcMDAweVwwMDBcDSBcMDAw aVwwMDBuXDAwMCBcMDAwclwwMDBlXDAwMGFcMDAwbFwwMDBpXDAwMHpcMDAwaVwwMDBuXDAw MGdcMDAwIFwwMDB0XDAwMFwNaFwwMDBlXDAwMCBcMDAwdlwwMDBpXDAwMHNcMDAwaVwwMDBv XDAwMG5cMDAwc1wwMDAgXDAwMG9cMDAwZlwwMDAgXDAwMHVcMDAwXA1iXDAwMGlcMDAwcVww MDB1XDAwMGlcMDAwdFwwMDBvXDAwMHVcMDAwc1wwMDAgXDAwMGNcMDAwb1wwMDBtXDAwMHBc MDAwdVwwMDBcDXRcMDAwaVwwMDBuXDAwMGdcMDAwIFwwMDAmXDAwMCBcMDAwY1wwMDBvXDAw MG1cMDAwbVwwMDB1XDAwMG5cMDAwaVwwMDBjXDAwMFwNYVwwMDB0XDAwMGlcMDAwb1wwMDBu XDAwMCBcMDAwYVwwMDBuXDAwMGRcMDAwIFwwMDBBXDAwMG1cMDAwYlwwMDBpXDAwMGVcMDAw XA1uXDAwMHRcMDAwIFwwMDBJXDAwMG5cMDAwdFwwMDBlXDAwMGxcMDAwbFwwMDBpXDAwMGdc MDAwZVwwMDBuXDAwMGNcMDAwZVwwMDBcDT9cMDAwXHJcMDAwXG5cMDAwXHJcMDAwXG5cMDAw LVwwMDAgXDAwMFBcMDAwclwwMDBvXDAwMHRcMDAwb1wwMDB0XDAwMHlcMDAwXA1wXDAwMGVc MDAwc1wwMDAsXDAwMCBcMDAwZlwwMDBpXDAwMGVcMDAwbFwwMDBkXDAwMCBcMDAwc1wwMDB0 XDAwMHVcMDAwZFwwMDBcDWlcMDAwZVwwMDBzXDAwMCxcMDAwIFwwMDBhXDAwMG5cMDAwZFww MDAgXDAwMHRcMDAwZVwwMDBzXDAwMHRcMDAwYlwwMDBlXDAwMFwNZFwwMDBzXDAwMCxcMDAw IFwwMDBlXDAwMC5cMDAwZ1wwMDAuXDAwMDpcMDAwIFwwMDAgXDAwMG5cMDAwb1wwMDB2XDAw MGVcMDAwXA1sXDAwMCBcMDAwc1wwMDBlXDAwMG5cMDAwc1wwMDBvXDAwMHJcMDAwIFwwMDBu XDAwMG9cMDAwZFwwMDBlXDAwMCBcMDAwcFwwMDBcDXJcMDAwb1wwMDB0XDAwMG9cMDAwdFww MDB5XDAwMHBcMDAwZVwwMDBzXDAwMCxcMDAwIFwwMDBtXDAwMGVcMDAwYVwwMDBzXDAwMFwN dVwwMDByXDAwMGVcMDAwbVwwMDBlXDAwMG5cMDAwdFwwMDBzXDAwMCBcMDAwd1wwMDBpXDAw MHRcMDAwaFwwMDBpXDAwMG5cMDAwXA0gXDAwMHNcMDAwZVwwMDBuXDAwMHNcMDAwb1wwMDBy XDAwMCBcMDAwblwwMDBlXDAwMHRcMDAwd1wwMDBvXDAwMHJcMDAwa1wwMDBcDSBcMDAwdFww MDBlXDAwMHNcMDAwdFwwMDBiXDAwMGVcMDAwZFwwMDBzXDAwMFxyXDAwMFxuXDAwMFxyXDAw MFxuXDAwMC1cMDAwXA0gXDAwME1cMDAwb1wwMDBkXDAwMGVcMDAwbFwwMDBpXDAwMG5cMDAw Z1wwMDAgXDAwMG9cMDAwZlwwMDAgXDAwMFdcMDAwU1wwMDBcDU5cMDAwLFwwMDAgXDAwMGVc MDAwLlwwMDBnXDAwMC5cMDAwOlwwMDAgXDAwMG1cMDAwb1wwMDBkXDAwMGVcMDAwbFwwMDBz XDAwMFwNIFwwMDBmXDAwMG9cMDAwclwwMDAgXDAwMFdcMDAwU1wwMDBOXDAwMC1cMDAwIFww MDBsXDAwMG9cMDAwYVwwMDBkXDAwMC9cMDAwXA1hXDAwMHBcMDAwcFwwMDBsXDAwMGlcMDAw Y1wwMDBhXDAwMHRcMDAwaVwwMDBvXDAwMG5cMDAwc1wwMDAsXDAwMCBcMDAwbVwwMDBcDW9c MDAwYlwwMDBpXDAwMGxcMDAwaVwwMDB0XDAwMHlcMDAwIFwwMDBvXDAwMHJcMDAwIFwwMDBj XDAwMGhcMDAwYVwwMDBuXDAwMFwNblwwMDBlXDAwMGxcMDAwIFwwMDBtXDAwMG9cMDAwZFww MDBlXDAwMGxcMDAwc1wwMDBcclwwMDBcblwwMDBcclwwMDBcblwwMDBcDVwwMDApDS9QIDgx IDAgUiANL0sgWyA1NiAwIFIgNTcgMCBSIDU4IDAgUiA1OSAwIFIgNjAgMCBSIDYxIDAgUiA2 MiAwIFIgNjMgMCBSIDY0IDAgUiBdIA0+PiANZW5kb2JqDTg2IDAgb2JqDTw8IA0vUyAvVGV4 dEJveCANL0FsdCAoVGV4dCBCb3g6IEltcG9ydGFudCBEYXRlczpcdFx0XHJcblN1Ym1pc3Np b24gZGVhZGxpbmU6XHRcdCAxLkp1bHksIDIwMDNcclwNXG5Ob3RpZmljYXRpb24gb2YgYWNj ZXB0YW5jZTogXHQgMS5TZXB0ZW1iZXIsIDIwMDNcclxuQ2FtZXJhLXJlYWR5IHZlcnNpXA1v bjpcdCAxLk9jdG9iZXIsIDIwMDNcclxuV29yay1pbi1wcm9ncmVzcyBzdWJtaXNzaW9uOiAx NS4gTm92ZW1iZXIsIDIwMDNcDVxyXG5cMDAwKQ0vUCA4MSAwIFIgDS9LIFsgNjUgMCBSIDY2 IDAgUiA2NyAwIFIgNjggMCBSIDY5IDAgUiBdIA0+PiANZW5kb2JqDTg3IDAgb2JqDTw8IA0v UyAvVGV4dEJveCANL0FsdCAoVGV4dCBCb3g6IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVh c2UgdmlzaXQ6IGh0dHA6Ly93d3cuZXdzbi5vcmdcMDAwKQ0vUCA4MSAwIFIgDS9LIDcwIDAg UiANPj4gDWVuZG9iag04OCAwIG9iag08PCANL1MgL1NoYXBlIA0vQWx0ICgpDS9QZyAxMDkg MCBSIA0vSyA2MyANL1AgODEgMCBSIA0vQSA5NyAwIFIgDT4+IA1lbmRvYmoNODkgMCBvYmoN PDwgDS9TIC9UZXh0Qm94IA0vQWx0IChUZXh0IEJveDogU3VibWlzc2lvbnMgc2hvdWxkIG5v dCBleGNlZWQgMTYgcGFnZXM7IGZvcm1hdHRpbmcgZ3VpZGVsaW5lcyBcDWFyZSBkZXNjcmli ZWQgb24gdGhlIHdlYnBhZ2UuIFRoZSBwcm9jZWVkaW5ncyB3aWxsIGJlIHB1Ymxpc2hlZCBi eSBTcHJpblwNZ2VyIGluIHRoZSBMTkNTIHNlcmllcy4gXHJcbiBcclxuXDAwMCkNL1AgODEg MCBSIA0vSyBbIDcyIDAgUiA3NSAwIFIgXSANPj4gDWVuZG9iag05MCAwIG9iag08PCANL1Mg L1RleHRCb3ggDS9BbHQgKFRleHQgQm94OiBTdXBwb3J0ZWQgYnkgdGhlIEpvaW50IElFRUUg SUFTL1BFTFMvSUVTIEdlcm1hbiBDaGFwdGVyXHJcbiBcclwNXG5cMDAwKQ0vUCA4MSAwIFIg DS9LIFsgNzggMCBSIDc5IDAgUiBdIA0+PiANZW5kb2JqDTkxIDAgb2JqDTw8IA0vTnVtcyBb IDAgOTIgMCBSIDEgNzMgMCBSIF0gDT4+IA1lbmRvYmoNOTIgMCBvYmoNWyANMiAwIFIgNiAw IFIgMiAwIFIgNyAwIFIgOSAwIFIgNDIgMCBSIDQ0IDAgUiA0NSAwIFIgMTEgMCBSIDEyIDAg UiANMTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDE4IDAgUiAxOSAwIFIgMjAgMCBSIDIx IDAgUiAyMiAwIFIgMjMgMCBSIA0yNCAwIFIgMjUgMCBSIDI2IDAgUiAyNyAwIFIgMjggMCBS IDI5IDAgUiAzMCAwIFIgMzEgMCBSIDMyIDAgUiAzMyAwIFIgDTM0IDAgUiAzNSAwIFIgMzYg MCBSIDM3IDAgUiAzOCAwIFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIgNDYgMCBSIDQ3IDAgUiAN NDggMCBSIDQ5IDAgUiA1MCAwIFIgNTEgMCBSIDUyIDAgUiA1MyAwIFIgNTQgMCBSIDU1IDAg UiA1NiAwIFIgNTcgMCBSIA01OCAwIFIgNTkgMCBSIDYwIDAgUiA2MSAwIFIgNjIgMCBSIDYz IDAgUiA2NCAwIFIgNjUgMCBSIDY2IDAgUiA2NyAwIFIgDTY4IDAgUiA2OSAwIFIgNzAgMCBS IDg4IDAgUiA3MiAwIFIgNzQgMCBSIDc3IDAgUiA3MiAwIFIgNzcgMCBSIDc4IDAgUiANODAg MCBSIDc5IDAgUiANXQ1lbmRvYmoNOTMgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9CYXNlbGlu ZVNoaWZ0IDEyIA0+PiANZW5kb2JqDTk0IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dERl Y29yYXRpb25UeXBlIC9VbmRlcmxpbmUgDT4+IA1lbmRvYmoNOTUgMCBvYmoNPDwgDS9PIC9M YXlvdXQgDS9CQm94IFsgNDc0IDg1IDU4NyAxMTkgXSANL1BsYWNlbWVudCAvSW5saW5lIA0+ PiANZW5kb2JqDTk2IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vQkJveCBbIDI1IDEwNSAxNDUg MTI0IF0gDS9QbGFjZW1lbnQgL0lubGluZSANPj4gDWVuZG9iag05NyAwIG9iag08PCANL08g L0xheW91dCANL0JCb3ggWyAxNjkgNDY2IDU5NSA0NjkgXSANL1BsYWNlbWVudCAvQmxvY2sg DS9TdGFydEluZGVudCA3OSANL0VuZEluZGVudCAtMTAgDT4+IA1lbmRvYmoNOTggMCBvYmoN PDwgDS9TIC9EIA0+PiANZW5kb2JqDTk5IDAgb2JqDTw8IA0vTnVtcyBbIDAgOTggMCBSIF0g DT4+IA1lbmRvYmoNMTAwIDAgb2JqDTw8IA0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVy IDUuMC41IFwoV2luZG93c1wpKQ0vQXV0aG9yIChIb2xnZXIgS2FybCkNL0NyZWF0b3IgKEFj cm9iYXQgUERGTWFrZXIgNS4wIGZvciBXb3JkKQ0vTW9kRGF0ZSAoRDoyMDAzMDQyNzEzMzIz NyswMycwMCcpDS9UaXRsZSAoMXN0IEludGVybmF0aW9uYWwgQW5udWFsIEJlcmxpbikNL0Ny ZWF0aW9uRGF0ZSAoRDoyMDAzMDQyNzEzMzEzMyswMicwMCcpDT4+IA1lbmRvYmoNMTAxIDAg b2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGggMTA5NiA+PiAN c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5 ZCcgYnl0ZXM9JzEwOTUnPz48cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUu Y29tL2lYLzEuMC8nPjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9u cy5hZG9iZS5jb20vcGRmLzEuMy8nIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9w ZGYvMS4zLycgcGRmOkNyZWF0aW9uRGF0ZT0nMjAwMy0wNC0yN1QxMTozMTozM1onIHBkZjpN b2REYXRlPScyMDAzLTA0LTI3VDExOjMxOjMzWicgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERp c3RpbGxlciA1LjAuNSAoV2luZG93cyknIHBkZjpBdXRob3I9J0hvbGdlciBLYXJsJyBwZGY6 Q3JlYXRvcj0nQWNyb2JhdCBQREZNYWtlciA1LjAgZm9yIFdvcmQnIHBkZjpUaXRsZT0nMXN0 IEludGVybmF0aW9uYWwgQW5udWFsIEJlcmxpbicvPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0 PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4bWxuczp4YXA9J2h0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpDcmVhdGVEYXRlPScyMDAzLTA0LTI3 VDExOjMxOjMzWicgeGFwOk1vZGlmeURhdGU9JzIwMDMtMDQtMjdUMTE6MzE6MzNaJyB4YXA6 QXV0aG9yPSdIb2xnZXIgS2FybCcgeGFwOk1ldGFkYXRhRGF0ZT0nMjAwMy0wNC0yN1QxMToz MTozM1onPjx4YXA6VGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0 Jz4xc3QgSW50ZXJuYXRpb25hbCBBbm51YWwgQmVybGluPC9yZGY6bGk+PC9yZGY6QWx0Pjwv eGFwOlRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScn IHhtbG5zPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpjcmVhdG9yPSdIb2xnZXIgS2Fy bCcgZGM6dGl0bGU9JzFzdCBJbnRlcm5hdGlvbmFsIEFubnVhbCBCZXJsaW4nLz4KPC9yZGY6 UkRGPjw/eHBhY2tldCBlbmQ9J3InPz4KZW5kc3RyZWFtDWVuZG9iag0xMDIgMCBvYmoNPDwg DS9UeXBlIC9QYWdlcyANL0tpZHMgWyAxMDkgMCBSIF0gDS9Db3VudCAxIA0+PiANZW5kb2Jq DXhyZWYNMCAxMDMgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA5MzczOCAwMDAwMCBuDQow MDAwMDk0MDI2IDAwMDAwIG4NCjAwMDAwOTQxMjkgMDAwMDAgbg0KMDAwMDA5NDE5NyAwMDAw MCBuDQowMDAwMDk0MjUzIDAwMDAwIG4NCjAwMDAwOTQ0MDMgMDAwMDAgbg0KMDAwMDA5NDQ4 MyAwMDAwMCBuDQowMDAwMDk0NTc0IDAwMDAwIG4NCjAwMDAwOTQ2MjYgMDAwMDAgbg0KMDAw MDA5NDcxOCAwMDAwMCBuDQowMDAwMDk0NzcxIDAwMDAwIG4NCjAwMDAwOTQ5MDIgMDAwMDAg bg0KMDAwMDA5NTAzMyAwMDAwMCBuDQowMDAwMDk1MTY1IDAwMDAwIG4NCjAwMDAwOTUyOTcg MDAwMDAgbg0KMDAwMDA5NTQzMyAwMDAwMCBuDQowMDAwMDk1NTY5IDAwMDAwIG4NCjAwMDAw OTU3MjkgMDAwMDAgbg0KMDAwMDA5NTg2NSAwMDAwMCBuDQowMDAwMDk2MDAxIDAwMDAwIG4N CjAwMDAwOTYxMzcgMDAwMDAgbg0KMDAwMDA5NjI3MyAwMDAwMCBuDQowMDAwMDk2NDA5IDAw MDAwIG4NCjAwMDAwOTY1NDUgMDAwMDAgbg0KMDAwMDA5NjY4MSAwMDAwMCBuDQowMDAwMDk2 ODE3IDAwMDAwIG4NCjAwMDAwOTY5NTMgMDAwMDAgbg0KMDAwMDA5NzA4OSAwMDAwMCBuDQow MDAwMDk3MjI1IDAwMDAwIG4NCjAwMDAwOTczNjEgMDAwMDAgbg0KMDAwMDA5NzQ5NyAwMDAw MCBuDQowMDAwMDk3NjMzIDAwMDAwIG4NCjAwMDAwOTc3NjkgMDAwMDAgbg0KMDAwMDA5Nzkw NSAwMDAwMCBuDQowMDAwMDk4MDQxIDAwMDAwIG4NCjAwMDAwOTgxNzcgMDAwMDAgbg0KMDAw MDA5ODMwOSAwMDAwMCBuDQowMDAwMDk4NDQxIDAwMDAwIG4NCjAwMDAwOTg1NzMgMDAwMDAg bg0KMDAwMDA5ODcwNSAwMDAwMCBuDQowMDAwMDk4ODM3IDAwMDAwIG4NCjAwMDAwOTg5Njkg MDAwMDAgbg0KMDAwMDA5OTA2MiAwMDAwMCBuDQowMDAwMDk5MTUxIDAwMDAwIG4NCjAwMDAw OTkyODEgMDAwMDAgbg0KMDAwMDA5OTQxMSAwMDAwMCBuDQowMDAwMDk5NTQyIDAwMDAwIG4N CjAwMDAwOTk2NzMgMDAwMDAgbg0KMDAwMDA5OTgwNCAwMDAwMCBuDQowMDAwMDk5OTM1IDAw MDAwIG4NCjAwMDAxMDAwNjYgMDAwMDAgbg0KMDAwMDEwMDE5NyAwMDAwMCBuDQowMDAwMTAw MzI4IDAwMDAwIG4NCjAwMDAxMDA0NTkgMDAwMDAgbg0KMDAwMDEwMDU5MCAwMDAwMCBuDQow MDAwMTAwNzIxIDAwMDAwIG4NCjAwMDAxMDA4NTMgMDAwMDAgbg0KMDAwMDEwMDk4NSAwMDAw MCBuDQowMDAwMTAxMTE3IDAwMDAwIG4NCjAwMDAxMDEyNDkgMDAwMDAgbg0KMDAwMDEwMTM4 MSAwMDAwMCBuDQowMDAwMTAxNTEzIDAwMDAwIG4NCjAwMDAxMDE2NDUgMDAwMDAgbg0KMDAw MDEwMTc3NyAwMDAwMCBuDQowMDAwMTAxOTA5IDAwMDAwIG4NCjAwMDAxMDIwNDAgMDAwMDAg bg0KMDAwMDEwMjE3MSAwMDAwMCBuDQowMDAwMTAyMzAyIDAwMDAwIG4NCjAwMDAxMDI0MzMg MDAwMDAgbg0KMDAwMDEwMjU2NCAwMDAwMCBuDQowMDAwMTAyNjU4IDAwMDAwIG4NCjAwMDAx MDI3NDYgMDAwMDAgbg0KMDAwMDEwMjg5MSAwMDAwMCBuDQowMDAwMTAyOTk0IDAwMDAwIG4N CjAwMDAxMDMwNzUgMDAwMDAgbg0KMDAwMDEwMzE2MCAwMDAwMCBuDQowMDAwMTAzMjQ5IDAw MDAwIG4NCjAwMDAxMDMzNTEgMDAwMDAgbg0KMDAwMDEwMzQ4MyAwMDAwMCBuDQowMDAwMTAz NjI2IDAwMDAwIG4NCjAwMDAxMDM3MjEgMDAwMDAgbg0KMDAwMDEwMzg3MSAwMDAwMCBuDQow MDAwMTA0OTgxIDAwMDAwIG4NCjAwMDAxMDk1MDkgMDAwMDAgbg0KMDAwMDExMDM3MCAwMDAw MCBuDQowMDAwMTE1NDg2IDAwMDAwIG4NCjAwMDAxMTU4MTYgMDAwMDAgbg0KMDAwMDExNTk1 MiAwMDAwMCBuDQowMDAwMTE2MDM3IDAwMDAwIG4NCjAwMDAxMTYzMDAgMDAwMDAgbg0KMDAw MDExNjQ1OCAwMDAwMCBuDQowMDAwMTE2NTExIDAwMDAwIG4NCjAwMDAxMTcwMzkgMDAwMDAg bg0KMDAwMDExNzA5NCAwMDAwMCBuDQowMDAwMTE3MTYyIDAwMDAwIG4NCjAwMDAxMTcyNDQg MDAwMDAgbg0KMDAwMDExNzMyNiAwMDAwMCBuDQowMDAwMTE3NDQxIDAwMDAwIG4NCjAwMDAx MTc0NzIgMDAwMDAgbg0KMDAwMDExNzUxNiAwMDAwMCBuDQowMDAwMTE3NzY4IDAwMDAwIG4N CjAwMDAxMTg5NDkgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxMDMNL0lEWzw1NGU5NTNm YWExYjBhMTEwNTIwOWFjN2U5YWFkZjBjOT48NjZhMzQ1NDQ1Y2Y4OGU0YzRkYjU5MzJiYWY4 NWM1ZWM+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== --------------060701000109040508000805-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 06:47:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05702 for ; Tue, 1 Jul 2003 06:47:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61Al6w18590 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 06:47:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XIf8-0004nq-4C; Tue, 01 Jul 2003 06:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3CZ-0007f7-JG for avt@optimus.ietf.org; Mon, 30 Jun 2003 14:16:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09366 for ; Mon, 30 Jun 2003 14:16:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3CW-0003HB-00 for avt@ietf.org; Mon, 30 Jun 2003 14:16:28 -0400 Received: from fmr04.intel.com ([143.183.121.6] helo=caduceus.sc.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19X3CL-0003Gl-00 for avt@ietf.org; Mon, 30 Jun 2003 14:16:17 -0400 Received: from petasus.sc.intel.com (petasus.sc.intel.com [10.3.253.4]) by caduceus.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5UGxjQ04602 for ; Mon, 30 Jun 2003 16:59:45 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5UGxeg02960 for ; Mon, 30 Jun 2003 16:59:40 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003063010052801915 for ; Mon, 30 Jun 2003 10:05:29 -0700 Received: from cssmsx401.amr.corp.intel.com ([10.15.24.6]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Jun 2003 10:00:59 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Mon, 30 Jun 2003 11:00:58 -0600 Message-ID: Thread-Topic: Updated RFC 2833 Draft? Thread-Index: AcM/KSwD/Ca5sQsoSueJ4mCwDhkRng== From: "Konopelski, Peter J" To: X-OriginalArrivalTime: 30 Jun 2003 17:00:59.0368 (UTC) FILETIME=[2DF3FE80:01C33F29] Content-Transfer-Encoding: quoted-printable Subject: [AVT] Updated RFC 2833 Draft? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable A colleague of mine was informed that the updated version of RFC 2833 = draft would be available last week. Can you tell me the status of it? Thank You, Pete=20 Peter J. Konopelski Customer Engineering Intel Corporation peter.j.konopelski@intel.com 303-665-2286 x152 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 07:22:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06869 for ; Tue, 1 Jul 2003 07:22:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61BM2526337 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 07:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJCz-0006pv-8M; Tue, 01 Jul 2003 07:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJCA-0006ox-BH for avt@optimus.ietf.org; Tue, 01 Jul 2003 07:21:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06531; Tue, 1 Jul 2003 07:21:06 -0400 (EDT) Message-Id: <200307011121.HAA06531@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 01 Jul 2003 07:21:06 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for JPEG 2000 Video Streams Author(s) : E. Edwards et al. Filename : draft-ietf-avt-rtp-jpeg2000-03.txt Pages : 20 Date : 2003-6-30 This document describes a payload format for transporting JPEG 2000 video streams using RTP (Real-time Transport Protocol). JPEG 2000 video streams are formed as a continuous series of JPEG 2000 still images. This payload format will allow for scalability and robustness of JPEG 2000's potential to be maximized in streaming applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-jpeg2000-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-30150956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-jpeg2000-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30150956.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 09:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24630 for ; Tue, 1 Jul 2003 09:25:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61DP7s11545 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 09:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XL86-0002zI-Vs; Tue, 01 Jul 2003 09:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XL7F-0002XU-SZ for avt@optimus.ietf.org; Tue, 01 Jul 2003 09:24:14 -0400 Received: from marionberry.cc.columbia.edu (IDENT:cu41754@marionberry.cc.columbia.edu [128.59.59.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24248 for ; Tue, 1 Jul 2003 09:24:10 -0400 (EDT) Received: from cs.columbia.edu (dyn-wireless-246-119.dyn.columbia.edu [160.39.246.119]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h61DOAf9024640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 09:24:11 -0400 (EDT) Message-ID: <3F018B6F.7000509@cs.columbia.edu> Date: Tue, 01 Jul 2003 09:23:59 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Konopelski, Peter J" CC: avt@ietf.org Subject: Re: [AVT] Updated RFC 2833 Draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It was submitted just before the deadline on Sunday. It should appear shortly. Konopelski, Peter J wrote: > A colleague of mine was informed that the updated version of RFC 2833 draft would be available last week. > > Can you tell me the status of it? > > Thank You, > Pete > > Peter J. Konopelski > Customer Engineering > Intel Corporation > peter.j.konopelski@intel.com > 303-665-2286 x152 > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 11:55:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05358 for ; Tue, 1 Jul 2003 11:55:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61Ft7W13878 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 11:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNTB-0003bG-L2; Tue, 01 Jul 2003 11:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XNSf-0003ae-5m for avt@optimus.ietf.org; Tue, 01 Jul 2003 11:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05337 for ; Tue, 1 Jul 2003 11:54:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XNSc-0005tw-00 for avt@ietf.org; Tue, 01 Jul 2003 11:54:26 -0400 Received: from web13309.mail.yahoo.com ([216.136.175.192]) by ietf-mx with smtp (Exim 4.12) id 19XNSQ-0005te-00 for avt@ietf.org; Tue, 01 Jul 2003 11:54:15 -0400 Message-ID: <20030701155326.97026.qmail@web13309.mail.yahoo.com> Received: from [61.11.60.240] by web13309.mail.yahoo.com via HTTP; Tue, 01 Jul 2003 08:53:26 PDT Date: Tue, 1 Jul 2003 08:53:26 -0700 (PDT) From: Muni Chandra Subject: RE: [AVT] RFC 2190 : Clarification To: Gary Sullivan , avt@ietf.org In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE24602A346F2@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1895192754-1057074806=:96099" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --0-1895192754-1057074806=:96099 Content-Type: text/plain; charset=us-ascii Hi Thanks a lot for the reponse. One more clarification. 1) At MODE-A packet without GOB header at start of it, it not possible to decode, becasue no way of finding out where this GOB belongs in the encoded frame in the case of packet loss case. This is since i feel MODE-A H.263 payload header will not give this information. 2) so based on above point, in MODE-A packet first GOB has header then solves the problem. Rest GOBs headers in MODE-A packet are redundant. It is waste of network bandwidth. Please clarify this. Best Regards Muni Chandra Reddy Gary Sullivan wrote: A few comments in response: - RFC 2190 should only be used for H.263 that pre-date 1998 in syntax design (i.e., no use of PLUSPTYPE header format). - RFC 2429 is a better design than 2190, and 2429 can be used for both old and newer versions of H.263 syntax. Regarding the questions: 1) I don't think RFC 2190 any prohibition against having additional GOB headers within Mode A packets. The RFC says it "allows fragmentation at GOB boundaries", but I don't see anywhere where it says it *requires* such fragmentation or prohibits GOB headers within packets. 2) As far as the H.263 standard (and within RFC 2190, I believe) is concerned, it is up to the discretion of the encoder when to send GOB headers and when not to. Even within a single coded picture, some GOBs can have headers while others do not. In some particular system environments (e.g. in some H.32x environments), there are ways to indicate that GOB headers should be sent or do not need to be sent for all GOBs - but this is outside the scope of H.263 itself. There is nothing in the H.263 video spec itself that requires any particular behavior for whether GOB headers are present or not. 3) Given the above statements about item 1, I don't think item 3 is especially relevant anymore. Best Regards, Gary Sullivan -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Muni Chandra Sent: Saturday, June 28, 2003 5:07 AM To: avt@ietf.org Subject: [AVT] RFC 2190 : Clarification Hello I am working on the implementation part of RFC 2190 for H.263 video packtization. I have a clarification. 1) As per RFC 2190, In MODE A, beginning of Packet should contain GOB with its Header. So, this means only first GOB (or part of it) in each packet should contain GOB header, rest GOBs will not have GOB header in the same MODE-A packet. 2) But H.263 standard says ( this with respective to my discussion with H.263 developers) whether all GOB's should have headers and all should not have GOB headers in a paerticular frame. 3) So to acheive above point 1 with respective above point 2, we need to calculate header for all GOB's and transmit GOB header only for first GOB of each MODE - A packet. Please clarify above point 3 is correct or we can calculate GOB headers for only first GOB of each MODE -A packet. So that we can save time of GOB header computation at rest of GOBs. Thanking you in Advance Muni Chanra Reddy --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-1895192754-1057074806=:96099 Content-Type: text/html; charset=us-ascii
Hi
 
 Thanks a lot for the reponse.
 
 One more clarification.
 
1) At  MODE-A packet without GOB header at start of it, it not possible to decode, becasue no way of finding out where this GOB belongs in the encoded frame in the case of packet loss case. This is since i feel MODE-A H.263 payload header will not give this information.
 
2) so based on above point, in MODE-A packet first GOB has header then solves the problem. Rest GOBs headers in MODE-A  packet are redundant. It is waste of network bandwidth.
 
Please clarify this.
 
Best Regards
Muni Chandra Reddy

Gary Sullivan <garysull@windows.microsoft.com> wrote:
A few comments in response:
 
- RFC 2190 should only be used for H.263 that pre-date 1998 in syntax design (i.e., no use of PLUSPTYPE header format).
 
- RFC 2429 is a better design than 2190, and 2429 can be used for both old and newer versions of H.263 syntax.
 
Regarding the questions:
 
1) I don't think RFC 2190 any prohibition against having additional GOB headers within Mode A packets.  The RFC says it "allows fragmentation at GOB boundaries", but I don't see anywhere where it says it *requires* such fragmentation or prohibits GOB headers within packets.
 
2) As far as the H.263 standard (and within RFC 2190, I believe) is concerned, it is up to the discretion of the encoder when to send GOB headers and when not to.  Even within a single coded picture, some GOBs can have headers while others do not.  In some particular system environments (e.g. in some H.32x environments), there are ways to indicate that GOB headers should be sent or do not need to be sent for all GOBs - but this is outside the scope of H.263 itself.  There is nothing in the H.263 video spec itself that requires any particular behavior for whether GOB headers are present or not.
 
3) Given the above statements about item 1, I don't think item 3 is especially relevant anymore.
 
Best Regards,
 
Gary Sullivan
 
 -----Original Message-----
From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Muni Chandra
Sent: Saturday, June 28, 2003 5:07 AM
To: avt@ietf.org
Subject: [AVT] RFC 2190 : Clarification

Hello
 
I am working on the implementation part of RFC 2190
for H.263 video packtization.
 
I have a clarification.
 
1) As per RFC 2190, In MODE A,   beginning of Packet should contain GOB with its Header. So, this means only first GOB (or part of it) in  each packet should contain GOB header, rest GOBs will not have GOB header in the same MODE-A packet.
 
2) But H.263 standard says ( this with respective to my discussion with H.263 developers) whether all GOB's should have headers and all should not have GOB headers in a paerticular frame.
 
3) So to acheive above point 1 with respective above point 2, we need to  calculate header for all GOB's and transmit GOB header only for first GOB of each MODE - A packet.
 
Please clarify above point 3 is correct or we can calculate GOB headers for only first GOB of each MODE -A packet. So that we can save time of GOB header computation at  rest of GOBs.
 
Thanking you in Advance
 
Muni Chanra Reddy

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-1895192754-1057074806=:96099-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 13:47:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08059 for ; Tue, 1 Jul 2003 13:47:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIMuh21310 for avt-archive@odin.ietf.org; Fri, 27 Jun 2003 14:22:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrK-0004ik-OA; Fri, 27 Jun 2003 14:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VnLt-00006b-FC for avt@optimus.ietf.org; Fri, 27 Jun 2003 03:09:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19697 for ; Fri, 27 Jun 2003 03:08:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VnLp-0001vZ-00 for avt@ietf.org; Fri, 27 Jun 2003 03:08:53 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19VnLe-0001vC-00 for avt@ietf.org; Fri, 27 Jun 2003 03:08:42 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h5R77bFl055740; Fri, 27 Jun 2003 00:07:37 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 27 Jun 2003 00:10:33 -0700 (PDT) From: Stephen Casner To: Oren Peleg cc: avt@ietf.org In-Reply-To: Message-ID: <20030627000758.R92361-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: Q about draft-ietf-avt-rtp-new Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Thu, 26 Jun 2003, Oren Peleg wrote: > Is this draft a potential RFC? or its like the avt-profile & > avt-profile-new which one is the update of the other that is subject > to future updates as well & therefore will never become an RFC. Both draft-ietf-avt-rtp-new and draft-ietf-avt-profile-new are in the final stage of editing with the RFC Editor (actually the "authors's 48 hours", i.e., the ball is in my court) and will be published as RFC's soon. I'm not sure where you got the idea that profile-new would never become an RFC, other than the fact that the process has taken quite a long time. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 13:48:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08459 for ; Tue, 1 Jul 2003 13:48:20 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIdGU16461 for avt-archive@odin.ietf.org; Fri, 27 Jun 2003 14:39:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7w-0004HO-0C; Fri, 27 Jun 2003 14:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vwnr-0002BB-6n for avt@optimus.ietf.org; Fri, 27 Jun 2003 13:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07835 for ; Fri, 27 Jun 2003 13:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vwnp-0004m2-00 for avt@ietf.org; Fri, 27 Jun 2003 13:14:25 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Vwne-0004kF-00 for avt@ietf.org; Fri, 27 Jun 2003 13:14:14 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5RH9Mw2024414; Fri, 27 Jun 2003 19:09:22 +0200 (MEST) Received: from era.ericsson.se (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW47W9HB; Fri, 27 Jun 2003 19:11:19 +0200 Message-ID: <3EFC7A44.8060808@era.ericsson.se> Date: Fri, 27 Jun 2003 19:09:24 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Mcgrew CC: Colin Perkins , Allison Mankin , mbaugher@cisco.com, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , "Karl Norrman (EAB)" , oran@cisco.com, avt@ietf.org Subject: Re: Fwd: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments References: <4.3.2.7.2.20030627081442.01ecd5a0@mira-sjcm-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, David Mcgrew wrote: > Mats, Colin, and others, > > I belatedly realized that there is another advantage to using the RTP > padding over other schemes: compactness. If someone implements CBC without > using the RTP padding, then the plaintext needs to be turned into a > prefix-free code so that the receiver can unambiguously remove any padding > that may be present. Because of this, AES CBC ciphertext will expand by an > extra 16-octet block on messages for which no padding is needed, if the > conventional method is used (see Appendix A of > http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf for more > detail). OTOH, if the RTP padding is used, then the padding bit indicates > the presence of padding, and there is never need to further expand the > ciphertext. Also, the NIST document cited above makes it clear that any > suitable padding method is considered acceptable. So this makes me think > that we should recommend RTP padding for use with modes that require padding. Will someone concerned with compactness use a mode that requires padding in the first place? Won't they rely on the pre-defined modes? I honestly don't see how we can recommend a padding that we *know* is "flawed", in particular when the flaw occurs in the absence of integrity---something we had to fight allow at all! I am fine with keeping the RTP padding as a sort of "default", be honest about its pros and cons, but I would not go as far as to *recommend* it. > > As a side note, I would still prefer a CBC variant that doesn't use padding Agreed, but that is for a future extension of SRTP. > as I'd mentioned before, but at any rate the compactness benefit of using > RTP padding deserves to be mentioned. Absolutely, but so does the security problems. /M _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 13:49:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09083 for ; Tue, 1 Jul 2003 13:49:11 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIdEt16343 for avt-archive@odin.ietf.org; Fri, 27 Jun 2003 14:39:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7u-0004Dn-2W; Fri, 27 Jun 2003 14:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VwX8-0001N8-Tk for avt@optimus.ietf.org; Fri, 27 Jun 2003 12:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07357 for ; Fri, 27 Jun 2003 12:57:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VwX7-0004fM-00 for avt@ietf.org; Fri, 27 Jun 2003 12:57:09 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19VwWw-0004f9-00 for avt@ietf.org; Fri, 27 Jun 2003 12:56:58 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2003 09:57:51 -0800 Received: from MCGREW-W2K.cisco.com (stealth-10-34-251-99.cisco.com [10.34.251.99]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h5RGtxRK001739; Fri, 27 Jun 2003 09:56:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20030627081442.01ecd5a0@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Jun 2003 09:55:58 -0700 To: Mats =?iso-8859-1?Q?N=E4slund?= , Colin Perkins From: David Mcgrew Subject: Fwd: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments Cc: Allison Mankin , mbaugher@cisco.com, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , "Karl Norrman (EAB)" , oran@cisco.com, avt@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Mats, Colin, and others, I belatedly realized that there is another advantage to using the RTP=20 padding over other schemes: compactness. If someone implements CBC without= =20 using the RTP padding, then the plaintext needs to be turned into a=20 prefix-free code so that the receiver can unambiguously remove any padding= =20 that may be present. Because of this, AES CBC ciphertext will expand by an= =20 extra 16-octet block on messages for which no padding is needed, if the=20 conventional method is used (see Appendix A of=20 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf for more=20 detail). OTOH, if the RTP padding is used, then the padding bit indicates= =20 the presence of padding, and there is never need to further expand the=20 ciphertext. Also, the NIST document cited above makes it clear that any=20 suitable padding method is considered acceptable. So this makes me think= =20 that we should recommend RTP padding for use with modes that require= padding. As a side note, I would still prefer a CBC variant that doesn't use padding= =20 as I'd mentioned before, but at any rate the compactness benefit of using=20 RTP padding deserves to be mentioned. David >Date: Tue, 24 Jun 2003 09:05:00 -0700 >To: Mats N=E4slund , Colin Perkins=20 > >From: David Mcgrew >Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of= =20 >comments >Cc: Allison Mankin , mbaugher@cisco.com, "Rolf Blom (EAB)"= =20 >, "Elisabetta Carrara (EAB)"=20 >, "Karl Norrman (EAB)"=20 >, oran@cisco.com, avt@ietf.org > >Mats, Colin, > >The RTP padding is simple, and I can definitely see the value of using a=20 >standard mechanism. However, it is not clear to me that we actually need= =20 >a padding method. AFAICT CBC is the only interesting mode that needs=20 >padding. The other 'NIST standard' encryption modes (OFB, CFB, ECB, and= =20 >counter) and the new and interesting OCB mode don't. Also, there is a CBC= =20 >encryption variant that avoids padding by switching to CFB mode to encrypt= =20 >the last block; it's been proven secure, though unfortunately NIST hasn't= =20 >included it in a standard, at least not explicitly. If we used this CBC= =20 >variant - it would be the variant that would make the most sense for voice= =20 >traffic - then AFAICT we don't need a padding method at all. > >I think that a brief discussion of the security details would be=20 >useful. If we allow chosen-plaintext attacks (e.g., the attacker can=20 >manipulate the plaintexts directly or indirectly, causing the encryption=20 >of data of her choice), then the padding method can affect=20 >confidentiality. Otherwise, I believe that it only affects message=20 >authentication. If message authentication is used (before decryption, as= =20 >required in SRTP), it defeats Vaudenay's attacks against CBC padding [1],= =20 >and likely defeats all similar attacks. The threat is that when message=20 >authentication isn't used, there are attacks that can violate=20 >confidentiality. Using the RTP padding method with CBC would provide the= =20 >same level of security as does the ESP padding: it's perfectly good unless= =20 >there's no authentication, in which case there are some=20 >confidentiality-violating attacks. At present, the two ciphers defined=20 >for SRTP don't require padding, and aren't vulnerable to any=20 >confidentiality-violating attacks even when message authentication is not= =20 >used, as you (Mats) point out. > >One of the complicating factors is algorithms that provide message=20 >authentication. Block cipher modes of operation that provide that=20 >service (CBC MAC, XCBC MAC, OCB [2]) use their own padding schemes. In= =20 >each of these modes, the padding method that is used is vital to security,= =20 >or at least is used in the security proof. XCBC is widely regarded as=20 >the 'right' way to do CBC MAC, and is expected to be adopted by the=20 >industry, and it is closely tied to its particular padding scheme. So if= =20 >we mandate the RTP padding method for SRTP, we need to make clear that it= =20 >is just for encryption modes (that need padding), and not for=20 >authentication modes. Perhaps it would make more sense to state that=20 >encryption modes that need a padding scheme SHOULD use the RTP padding=20 >method, unless they need to use another method for security=20 >reasons. OTOH, I personally would rather see the pad-less variant of CBC,= =20 >though crypto hardware vendors with existing products might choose= otherwise. > >On a side note, the RTP padding could be used in conjunction with=20 >encryption as a length-hiding mechanism. The sender can hide the length=20 >of a packet by adding padding, which the receiver will discard. The=20 >encryption will hide the last padding byte, so that an adversary cannot=20 >tell by looking at a ciphertext packet what the length of the payload of=20 >the corresponding plaintext packet is. I don't think that we stated this= =20 >anywhere in the draft, though it seems like a legal use of RTP and SRTP to= me. > >David > >[1] Security Flaws Induced by CBC Padding - Applications to SSL, IPsec,=20 >and WTLS, Serge Vaudenay, online at=20 >http://lasecwww.epfl.ch/php_code/publications/search.php?ref=3DVau02a > >[2] NIST Table of Submitted Modes of Operation, online at=20 >http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ > >At 11:00 AM 6/24/2003 +0200, Mats N=E4slund wrote: > >>Hi, >> >>Colin Perkins wrote: >>>[inline] >>>--> Allison Mankin writes: >>> >>>>SRTP is on the agenda of the IESG again this week. >>>>Some more comments on SRTP may still come in, but I thought >>>>it would be worth sending on those of Russ Housley, the second Security >>>>AD. Steve Bellovin has supported the draft. Russ has comments that=20 >>>>seem straightforward to address. Wait for more comments before sending= =20 >>>>in a revision, but so far things are going well. >>>> >>>>Allison >>>> >>>> >>>>>> Yes No-Objection Discuss * Abstain >>>>>> >>>>>>Russ Housley [ ] [ ] [ X ] [ ] >>>>> >>>>>I have six comments. >>>>> >>>>>1. In section 1, spell out the first use of RTCP. >>>>> >>>>>2. I find the structure of section 2 confusing. I had to read it >>>>>twice to understand it. I think that a second level of indenting would >>>>>be one way to fix it. I am sure there are others. >>>>> >>>>>3. In section 3.1, in the paragraph after figure 1, please delete: >>>>> >>>>> "It is exact for the pre-defined transforms." >>>>> >>>>>This point is made more clearly later in the paragraph. Then, at the >>>>>end of the same paragraph, the document says: >>>>> >>>>> "While it could seem more attractive to specify a fixed padding >>>>> scheme for all transforms, security and flexibility of transform >>>>> specifications REQUIRE that each transform specify a secure >>>>> padding method." >>>>> >>>>>I disagree. IPsec and S/MIME both specify padding schemes that are=20 >>>>>employed by all of the ciphers. Please reword. Do not use "REQUIRE" >>>>>in the replacement. >>>If IPsec and S/MIME both define a standard padding mechanism, why cannot >>>SRTP do the same? And, perhaps, use the standard RTP padding mechanism? >> >> >>To comply with Russ' comment, I have no objection to deleting >>"REQUIRE". I would hesitate to go beyond that. >> >>We will open up new issues in doing so. Do we use the IPsec pad? >>The S/MIME pad? Perhaps none of them is general enough? What about >>new modes? (If I remember correctly, e.g. XCBC had some padding issues.) >>David referenced a paper showing that some common pad schemes >>were "weak". (Even if these weaknesses are "theoretical", we have >>made great effort to make SRTP "maximally" secure, and I would hate >>to sub-optimize at this point.) >> >>It seems to me that the only future proof approach is to let each >>transform specify its own padding, or at least point to were a >>padding spec. can be found. >> >>/Mats >> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 19:45:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20881 for ; Tue, 1 Jul 2003 19:45:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XUoD-0004hN-7B for avt-archive@odin.ietf.org; Tue, 01 Jul 2003 19:45:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h61NjDnB018057 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 19:45:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XUo1-0004gK-Uf; Tue, 01 Jul 2003 19:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XUn6-0004fV-QR for avt@optimus.ietf.org; Tue, 01 Jul 2003 19:44:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20824 for ; Tue, 1 Jul 2003 19:44:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XUn4-0002MM-00 for avt@ietf.org; Tue, 01 Jul 2003 19:44:03 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 19XUn3-0002Lk-00 for avt@ietf.org; Tue, 01 Jul 2003 19:44:01 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Tue, 1 Jul 2003 16:43:24 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Jul 2003 16:43:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Jul 2003 16:43:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Jul 2003 16:43:23 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 1 Jul 2003 16:43:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [AVT] RFC 2190 : Clarification Date: Tue, 1 Jul 2003 16:43:17 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A34701@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] RFC 2190 : Clarification Thread-Index: AcM/6PDaFXVeIiYgRWq4b9aTFozWFQAPfnsQ From: "Gary Sullivan" To: "Muni Chandra" , X-OriginalArrivalTime: 01 Jul 2003 23:43:23.0513 (UTC) FILETIME=[8F65E690:01C3402A] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3402A.9127169D" ------_=_NextPart_001_01C3402A.9127169D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Muni, =20 I believe I basically agree with you on both points. =20 Regarding item 1, yes - I believe you would not be able to decode the data at the start of such a GOB-headerless packet unless you had received the packet or packets before it that provided the necessary header information. =20 Regarding item 2, yes - Placing more than one GOB header within a single RFC 2190 Mode A RTP packet appears to be basically a useless waste of bits, unless you can argue that some form of data corruption is possible somewhere in the transmission channel (possibly through a gateway to some other non-IP environment). =20 As I previously indicated, I am not too fond of RFC 2190. RFC 2429 is a superior design. However, RFC 2190 was done earlier and is therefore still needed for interoperability with devices made before RFc 2429 was developed. =20 Best Regards, =20 Gary Sullivan -----Original Message----- From: Muni Chandra [mailto:mcr_321@yahoo.com]=20 Sent: Tuesday, July 01, 2003 8:53 AM To: Gary Sullivan; avt@ietf.org Subject: RE: [AVT] RFC 2190 : Clarification Hi =20 Thanks a lot for the reponse. =20 One more clarification. =20 1) At MODE-A packet without GOB header at start of it, it not possible to decode, becasue no way of finding out where this GOB belongs in the encoded frame in the case of packet loss case. This is since i feel MODE-A H.263 payload header will not give this information. =20 2) so based on above point, in MODE-A packet first GOB has header then solves the problem. Rest GOBs headers in MODE-A packet are redundant. It is waste of network bandwidth. =20 Please clarify this. =20 Best Regards Muni Chandra Reddy Gary Sullivan wrote: A few comments in response: =20 - RFC 2190 should only be used for H.263 that pre-date 1998 in syntax design (i.e., no use of PLUSPTYPE header format). =20 - RFC 2429 is a better design than 2190, and 2429 can be used for both old and newer versions of H.263 syntax. =20 Regarding the questions: =20 1) I don't think RFC 2190 any prohibition against having additional GOB headers within Mode A packets. The RFC says it "allows fragmentation at GOB boundaries", but I don't see anywhere where it says it *requires* such fragmentation or prohibits GOB headers within packets. =20 2) As far as the H.263 standard (and within RFC 2190, I believe) is concerned, it is up to the discretion of the encoder when to send GOB headers and when not to. Even within a single coded picture, some GOBs can have headers while others do not. In some particular system environments (e.g. in some H.32x environments), there are ways to indicate that GOB headers should be sent or do not need to be sent for all GOBs - but this is outside the scope of H.263 itself. There is nothing in the H.263 video spec itself that requires any particular behavior for whether GOB headers are present or not. =20 3) Given the above statements about item 1, I don't think item 3 is especially relevant anymore. =20 Best Regards, =20 Gary Sullivan =20 -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Muni Chandra Sent: Saturday, June 28, 2003 5:07 AM To: avt@ietf.org Subject: [AVT] RFC 2190 : Clarification Hello=20 =20 I am working on the implementation part of RFC 2190 for H.263 video packtization. =20 I have a clarification. =20 1) As per RFC 2190, In MODE A, beginning of Packet should contain GOB with its Header. So, this means only first GOB (or part of it) in each packet should contain GOB header, rest GOBs will not have GOB header in the same MODE-A packet. =20 2) But H.263 standard says ( this with respective to my discussion with H.263 developers) whether all GOB's should have headers and all should not have GOB headers in a paerticular frame. =20 3) So to acheive above point 1 with respective above point 2, we need to calculate header for all GOB's and transmit GOB header only for first GOB of each MODE - A packet. =20 Please clarify above point 3 is correct or we can calculate GOB headers for only first GOB of each MODE -A packet. So that we can save time of GOB header computation at rest of GOBs. =20 Thanking you in Advance =20 Muni Chanra Reddy _____ =20 Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! _____ =20 Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! ------_=_NextPart_001_01C3402A.9127169D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Muni,
 
I=20 believe I basically agree with you on both points.
 
Regarding item 1, yes - I believe you would not be able = to decode=20 the data at the start of such a GOB-headerless packet unless you had = received=20 the packet or packets before it that provided the necessary header=20 information.
 
Regarding item 2, yes - Placing more than = one GOB header=20 within a single RFC 2190 Mode A RTP packet appears to=20 be basically a useless waste of bits, unless you can argue that = some form=20 of data corruption is possible somewhere in the transmission channel = (possibly=20 through a gateway to some other non-IP environment).
 
As I=20 previously indicated, I am not too fond of RFC 2190.  RFC 2429 is a = superior design.  However, RFC 2190 was done earlier and is = therefore still=20 needed for interoperability with devices made before RFc 2429 was=20 developed.
 
Best=20 Regards,
 
Gary=20 Sullivan
-----Original Message-----
From: Muni = Chandra=20 [mailto:mcr_321@yahoo.com]
Sent: Tuesday, July 01, 2003 = 8:53=20 AM
To: Gary Sullivan; avt@ietf.org
Subject: RE: = [AVT] RFC=20 2190 : Clarification

Hi
 
 Thanks a lot for the reponse.
 
 One more clarification.
 
1) At  MODE-A packet without GOB header at start = of it, it=20 not possible to decode, becasue no way of finding out where this GOB = belongs=20 in the encoded frame in the case of packet loss case. This is since i=20 feel MODE-A H.263 payload header will not give this=20 information.
 
2) so based on above point, in MODE-A packet first GOB has header = then=20 solves the problem. Rest GOBs headers in MODE-A  packet=20 are redundant. It is waste of network bandwidth.
 
Please clarify this.
 
Best Regards
Muni Chandra Reddy

Gary Sullivan=20 <garysull@windows.microsoft.com> wrote:
A=20 few comments in response:
 
-=20 RFC 2190 should only be used for H.263 that pre-date 1998 in syntax = design=20 (i.e., no use of PLUSPTYPE header format).
 
-=20 RFC 2429 is a better design than 2190, and 2429 can be used for both = old and=20 newer versions of H.263 syntax.
 
Regarding the questions:
 
1) I don't think RFC 2190 any=20 prohibition against having additional GOB headers within Mode A = packets.  The RFC says it "allows fragmentation at GOB = boundaries", but=20 I don't see anywhere where it says it *requires* such fragmentation = or=20 prohibits GOB headers within packets.
 
2) As far as the H.263 standard (and within RFC = 2190, I=20 believe) is concerned, it is up to the discretion of the encoder = when to=20 send GOB headers and when not to.  Even within a = single coded=20 picture, some GOBs can have headers while others do = not.  In some=20 particular system environments (e.g. in some H.32x environments), = there are=20 ways to indicate that GOB headers should be sent or do not = need to be=20 sent for all GOBs - but this is outside the scope of H.263 = itself. =20 There is nothing in the H.263 video spec itself that requires any = particular=20 behavior for whether GOB headers are present or = not.
 
3) Given the above statements about item 1, I don't = think item=20 3 is especially relevant anymore.
 
Best Regards,
 
Gary Sullivan
 
 -----Original=20 Message-----
From: avt-admin@ietf.org = [mailto:avt-admin@ietf.org]=20 On Behalf Of Muni Chandra
Sent: Saturday, June 28, = 2003=20 5:07 AM
To: avt@ietf.org
Subject: [AVT] RFC 2190 = :=20 Clarification

Hello
 
I am working on the = implementation part of=20 RFC 2190
for H.263 video packtization.
 
I have a = clarification.
 
1) As per RFC 2190, In MODE = A,  =20 beginning of Packet should contain GOB with its Header. So, this = means=20 only first GOB (or part of it) in  each packet should contain = GOB=20 header, rest GOBs will not have GOB header in the same MODE-A=20 packet.
 
2) But H.263 standard says ( this = with=20 respective to my discussion with H.263 developers) whether all = GOB's=20 should have headers and all should not have GOB headers in a = paerticular=20 frame.
 
3) So to acheive above point 1 = with=20 respective above point 2, we need to  calculate header for = all GOB's=20 and transmit GOB header only for first GOB of each MODE - A=20 packet.
 
Please clarify above point 3 is = correct or we=20 can calculate GOB headers for only first GOB of each MODE -A = packet. So=20 that we can save time of GOB header computation at  rest = of=20 GOBs.
 
Thanking you in = Advance
 
Muni Chanra = Reddy

Do you Yahoo!?
SBC=20 Yahoo! DSL - Now only $29.95 per = month!

Do you Yahoo!?
SBC=20 Yahoo! DSL - Now only $29.95 per month! ------_=_NextPart_001_01C3402A.9127169D-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 1 22:11:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24868 for ; Tue, 1 Jul 2003 22:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX5M-0001s7-EL for avt-archive@odin.ietf.org; Tue, 01 Jul 2003 22:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h622B4q3007183 for avt-archive@odin.ietf.org; Tue, 1 Jul 2003 22:11:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX5J-0001rE-0B; Tue, 01 Jul 2003 22:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX4e-0001qu-R7 for avt@optimus.ietf.org; Tue, 01 Jul 2003 22:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24849 for ; Tue, 1 Jul 2003 22:10:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XX4b-0004JO-00 for avt@ietf.org; Tue, 01 Jul 2003 22:10:17 -0400 Received: from ns5.sony.co.jp ([137.153.0.45]) by ietf-mx with esmtp (Exim 4.12) id 19XX4a-0004JL-00 for avt@ietf.org; Tue, 01 Jul 2003 22:10:16 -0400 Received: from mail6.sony.co.jp (mail6.sony.co.jp [43.0.1.208]) Received: from mail6.sony.co.jp (localhost [127.0.0.1]) by mail6.sony.co.jp (R8/Sony) with ESMTP id h622AFK26305 for ; Wed, 2 Jul 2003 11:10:15 +0900 (JST) Received: from localhost.localdomain ([43.13.117.111]) by mail6.sony.co.jp (R8/Sony) with ESMTP id h622AF226301 for ; Wed, 2 Jul 2003 11:10:15 +0900 (JST) Received: from avfpi.av.crl.sony.co.jp (avfpi [43.13.117.96]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h622AEqW018954 for ; Wed, 2 Jul 2003 11:10:14 +0900 Message-Id: <5.1.1.8.2.20030702104701.00e81958@43.13.117.111> X-Sender: hatanaka@43.13.117.111 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1-J Date: Wed, 02 Jul 2003 11:10:13 +0900 To: avt@ietf.org From: Mitsuyuki Hatanaka Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Revised internet draft of RTP Payload Format for ATRAC-X Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, We have submitted our revised internet draft as "draft-hatanaka-avt-rtp-atracx-02.txt". You will be able to get it from the on-line Internet-Drafts directories. We do not have a plan to discuss in AVT group at Vienna meeting, because this is slight changing version. The revised items are as follows. (1) Changing a terminology of "StreamID" to "ElementID" in section 2.3. (2) Changing a unit of LENGTH "byte" to "bit" in section 2.3. (3) Changing a unit of time stamp "millisecond of a presentation time" to "sample number of a presentation time" in section 7. (4) Addition of the description about multicasting consideration in section 8. We will evaluate the defined functions of this payload with the practical test application until next meeting, and we would like to reflect the results in next document. Best Regards, Mitsuyuki Hatanaka --------------------------------------- Mitsuyuki Hatanaka Sony Corporation E-mail: hatanaka@av.crl.sony.co.jp --------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 2 06:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01668 for ; Wed, 2 Jul 2003 06:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfCc-0001z1-Sj for avt-archive@odin.ietf.org; Wed, 02 Jul 2003 06:51:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Ap64a007612 for avt-archive@odin.ietf.org; Wed, 2 Jul 2003 06:51:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfCY-0001wo-6D; Wed, 02 Jul 2003 06:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfC0-0001vz-6B for avt@optimus.ietf.org; Wed, 02 Jul 2003 06:50:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01380; Wed, 2 Jul 2003 06:50:23 -0400 (EDT) Message-Id: <200307021050.GAA01380@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 06:50:22 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-uncomp-video-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for Uncompressed Video Author(s) : L. Gharai, C. Perkins Filename : draft-ietf-avt-uncomp-video-03.txt Pages : 16 Date : 2003-7-1 This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-uncomp-video-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-uncomp-video-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-uncomp-video-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1133519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-uncomp-video-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-uncomp-video-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1133519.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 2 07:39:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01669 for ; Wed, 2 Jul 2003 06:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfCc-0001yz-SY for avt-archive@odin.ietf.org; Wed, 02 Jul 2003 06:51:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Ap6t6007611 for avt-archive@odin.ietf.org; Wed, 2 Jul 2003 06:51:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfCX-0001wg-MK; Wed, 02 Jul 2003 06:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XfBv-0001vu-NO for avt@optimus.ietf.org; Wed, 02 Jul 2003 06:50:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01364; Wed, 2 Jul 2003 06:50:18 -0400 (EDT) Message-Id: <200307021050.GAA01364@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 06:50:18 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-08.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-mwpp-midi-rtp-08.txt Pages : 101 Date : 2003-7-1 This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-mwpp-midi-rtp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1133505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mwpp-midi-rtp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1133505.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 2 15:44:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09251 for ; Wed, 2 Jul 2003 15:44:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnWW-0006xa-Ih for avt-archive@odin.ietf.org; Wed, 02 Jul 2003 15:44:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62JiCWm026739 for avt-archive@odin.ietf.org; Wed, 2 Jul 2003 15:44:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnWL-0006uS-L9; Wed, 02 Jul 2003 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnW9-0006rH-L2 for avt@optimus.ietf.org; Wed, 02 Jul 2003 15:43:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09232 for ; Wed, 2 Jul 2003 15:43:45 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XnW6-0006M0-00 for avt@ietf.org; Wed, 02 Jul 2003 15:43:46 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19XnW5-0006Lv-00 for avt@ietf.org; Wed, 02 Jul 2003 15:43:45 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19XnVz-0000wr-00 for avt@ietf.org; Wed, 02 Jul 2003 20:43:39 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Wed, 2 Jul 2003 20:43:39 +0100 Message-ID: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> Date: Wed, 2 Jul 2003 20:43:39 +0100 To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Subject: [AVT] draft-herlein-speex-rtp-profile-01 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, An -01 update to draft-herlein-speex-rtp-profile is now available: http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt Comments and feedback welcomed. Regards Phil ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 2 16:15:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11025 for ; Wed, 2 Jul 2003 16:15:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo0M-0000kI-Bc for avt-archive@odin.ietf.org; Wed, 02 Jul 2003 16:15:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KF2Ss002809 for avt-archive@odin.ietf.org; Wed, 2 Jul 2003 16:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo0L-0000iF-V2; Wed, 02 Jul 2003 16:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo08-0000hU-Tm for avt@optimus.ietf.org; Wed, 02 Jul 2003 16:14:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10854; Wed, 2 Jul 2003 16:14:43 -0400 (EDT) Message-Id: <200307022014.QAA10854@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:14:43 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload Format for JVT Video Author(s) : S. Wenger et al. Filename : draft-ietf-avt-rtp-h264-02.txt Pages : 55 Date : 2003-7-2 This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec. This codec was designed as a joint project of the Video Coding Experts Group (VCEG) of ITU-T and the Moving Picture Experts Group (MPEG) of ISO/IEC. Recommendation H.264 was approved by ITU-T on May 2003, and the approved draft specification is available for public review. ISO/IEC International Standard 14496-10 will be technically identical to ITU-T Recommendation H.264. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-h264-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h264-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2160655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h264-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h264-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2160655.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 2 16:15:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11024 for ; Wed, 2 Jul 2003 16:15:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo0M-0000k1-BE for avt-archive@odin.ietf.org; Wed, 02 Jul 2003 16:15:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KF25b002810 for avt-archive@odin.ietf.org; Wed, 2 Jul 2003 16:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo0L-0000i7-E7; Wed, 02 Jul 2003 16:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xo04-0000hP-DX for avt@optimus.ietf.org; Wed, 02 Jul 2003 16:14:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10837; Wed, 2 Jul 2003 16:14:39 -0400 (EDT) Message-Id: <200307022014.QAA10837@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:14:38 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2833bis-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals Author(s) : H. Schulzrinne, S. Petrack Filename : draft-ietf-avt-rfc2833bis-03.txt Pages : 38 Date : 2003-7-2 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. This document updates RFC 2833. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2833bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc2833bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2160619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rfc2833bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rfc2833bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2160619.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 05:22:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03364 for ; Thu, 3 Jul 2003 05:22:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0I0-0005Ad-Se for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 05:22:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h639M41i019860 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 05:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0Hx-00059l-Fu; Thu, 03 Jul 2003 05:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y0HR-000599-Uj for avt@optimus.ietf.org; Thu, 03 Jul 2003 05:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03345 for ; Thu, 3 Jul 2003 05:21:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y0HO-0004WH-00 for avt@ietf.org; Thu, 03 Jul 2003 05:21:26 -0400 Received: from amarseille-201-2-2-126.w217-128.abo.wanadoo.fr ([217.128.162.126] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19Y0HN-0004WE-00 for avt@ietf.org; Thu, 03 Jul 2003 05:21:25 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h639LQ8w009931; Thu, 3 Jul 2003 05:21:26 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Thu, 3 Jul 2003 11:21:26 +0200 From: Colin Perkins To: philkerr@elec.gla.ac.uk Cc: avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 Message-Id: <20030703112126.49344304.csp@csperkins.org> In-Reply-To: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --> philkerr@elec.gla.ac.uk writes: > Dear all, > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > Comments and feedback welcomed. Can you summarize the changes from the previous version, and areas where input is needed? -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 11:28:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15540 for ; Thu, 3 Jul 2003 11:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y60F-0000Z2-T8 for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 11:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FS7fT002164 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 11:28:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y609-0000YJ-88; Thu, 03 Jul 2003 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y608-0000Y8-62 for avt@optimus.ietf.org; Thu, 03 Jul 2003 11:28:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15400; Thu, 3 Jul 2003 11:27:57 -0400 (EDT) Message-Id: <200307031527.LAA15400@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:27:57 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-ilbc-codec-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Internet Low Bit Rate Codec Author(s) : S. Andersen et al. Filename : draft-ietf-avt-ilbc-codec-02.txt Pages : 177 Date : 2003-7-3 This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-ilbc-codec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-ilbc-codec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3111304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-ilbc-codec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-ilbc-codec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111304.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 11:29:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15721 for ; Thu, 3 Jul 2003 11:29:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y617-0000dr-15 for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 11:29:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FT1FD002465 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 11:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y616-0000df-T7; Thu, 03 Jul 2003 11:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y60H-0000Ze-KM for avt@optimus.ietf.org; Thu, 03 Jul 2003 11:28:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15418; Thu, 3 Jul 2003 11:28:07 -0400 (EDT) Message-Id: <200307031528.LAA15418@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:28:06 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-04.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTCP Extensions for Single-Source Multicast Sessions with Unicase Feedback Author(s) : J. Chesterfield et al. Filename : draft-ietf-avt-rtcpssm-04.txt Pages : 37 Date : 2003-7-3 This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender controlled summarised reporting mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcpssm-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcpssm-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3111322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcpssm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcpssm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111322.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 11:29:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15735 for ; Thu, 3 Jul 2003 11:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y617-0000g8-Tf for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 11:29:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FT1PL002550 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 11:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y617-0000f2-MQ; Thu, 03 Jul 2003 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y60L-0000Zk-Pu for avt@optimus.ietf.org; Thu, 03 Jul 2003 11:28:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15434; Thu, 3 Jul 2003 11:28:11 -0400 (EDT) Message-Id: <200307031528.LAA15434@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:28:11 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-ilbc-02.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for iLBC Speech Author(s) : A. Duric, S. Andersen Filename : draft-ietf-avt-rtp-ilbc-02.txt Pages : 10 Date : 2003-7-3 This document describes the RTP payload format for the internet Low Bit Rate Coder (iLBC) Speech [1] developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-ilbc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-ilbc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3111332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-ilbc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ilbc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111332.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 12:41:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23115 for ; Thu, 3 Jul 2003 12:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y78t-0007Ix-Q0 for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 12:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Gf7Zm028050 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 12:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y78m-0007Hm-Ue; Thu, 03 Jul 2003 12:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y78G-0007HM-9h for avt@optimus.ietf.org; Thu, 03 Jul 2003 12:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22996 for ; Thu, 3 Jul 2003 12:40:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y78E-0002Yi-00 for avt@ietf.org; Thu, 03 Jul 2003 12:40:26 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19Y78D-0002Xh-00 for avt@ietf.org; Thu, 03 Jul 2003 12:40:26 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Thu, 03 Jul 2003 09:39:52 -0700 Date: Thu, 3 Jul 2003 09:46:17 -0700 (PDT) From: Aaron Colwell To: avt@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] draft-ietf-avt-rtcp-bw-05.txt question Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What is the expected behavior if only a b=RR line is specified and it's value is greater than 5% of the stream bandwidth. The draft says that if only one parameter is specified then the value of the other is determined by subracting the value of the specified parameter from 5% of the stream bitrate. In the case I have mentioned this would cause a negative bandwidth to be calculated. That is obviously not valid. Could someone please clarify what should happen in this case. Thanks, Aaron _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 14:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00968 for ; Thu, 3 Jul 2003 14:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y97q-0004FP-G5 for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 14:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63ImA3O016324 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 14:48:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y97h-0004Eh-5b; Thu, 03 Jul 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y974-0004EJ-U6 for avt@optimus.ietf.org; Thu, 03 Jul 2003 14:47:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00935 for ; Thu, 3 Jul 2003 14:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y972-0006jI-00 for avt@ietf.org; Thu, 03 Jul 2003 14:47:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Y971-0006ip-00 for avt@ietf.org; Thu, 03 Jul 2003 14:47:19 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2003 11:43:36 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn2-590.cisco.com [10.21.114.78]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h63Ikjpa027338; Thu, 3 Jul 2003 11:46:45 -0700 (PDT) Message-Id: <5.1.1.5.2.20030703113935.02213b48@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Jul 2003 11:46:44 -0700 To: Allison Mankin From: Mark Baugher Cc: mats.naslund@era.ericsson.se, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , mcgrew@cisco.com, "Karl Norrman (EAB)" , oran@cisco.com, avt@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Re: IESG Review of draft-ietf-srtp-08.txt - another set of comments Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Allison, We have addressed five out of the six comments from Russ at http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-09.txt. The document is available with highlighted changes at http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-09.pdf. There have been some small editorial changes made as well and we paired down the authors list from seven authors to five to be in accordance with IETF policy. Rolf Blom and Dave Oran asked that their names be removed to comply with the policy. They played an important role in starting the SRTP effort and in guiding it and we thank them for that. I said that we addressed five out of six comments. We could not agree on what if anything needed to be changed in Section 2 (Russ's item #2) and decided to leave it as it is. We'll submit this version to internet-drafts as well. Mark At 02:13 PM 6/23/2003 -0700, Allison Mankin wrote: >SRTP is on the agenda of the IESG again this week. >Some more comments on SRTP may still come in, but I thought >it would be worth sending on those of Russ Housley, the second Security >AD. Steve Bellovin has supported the draft. Russ has comments that >seem straightforward to address. Wait for more comments before >sending in a revision, but so far things are going well. > >Allison > > > > > > Yes No-Objection Discuss * Abstain > > > > > >Russ Housley [ ] [ ] [ X ] [ ] > > > > I have six comments. > > > > 1. In section 1, spell out the first use of RTCP. > > > > 2. I find the structure of section 2 confusing. I had to read it > twice to > > understand it. I think that a second level of indenting would be one way > > to fix it. I am sure there are others. > > > > 3. In section 3.1, in the paragraph after figure 1, please delete: > > > > "It is exact for the pre-defined transforms." > > > > This point is made more clearly later in the paragraph. Then, at the end > > of the same paragraph, the document says: > > > > "While it could seem more attractive to specify a fixed padding > > scheme for all transforms, security and flexibility of transform > > specifications REQUIRE that each transform specify a secure > > padding method." > > > > I disagree. IPsec and S/MIME both specify padding schemes that are > > employed by all of the ciphers. Please reword. Do not use "REQUIRE" in > > the replacement. > > > > 4. In section 3.2.1, the document says: "the master key(s), which MUST be > > random and kept secret." This is quite a high bar. I suggest that > > pseudo-random is sufficient. Please see the RFC 2828 definitions of > > "random" and "pseudo-random." The document says that it is following > these > > terms. Also, see RFC 1750. Similarly, the requirement on the master salt > > should also be reduced to pseudo-random. > > > > 5. The last paragraph is section 3.2.3 says: > > > > "If no valid context can be found for a packet corresponding to a > > certain context identifier, that packet MUST be discarded from > > further SRTP processing." > > > > Elsewhere, "discarded from further processing" is used. This seems better > > to me. It is discarded, which seems different that no further SRTP > > processing. Also, SRTCP should be covered by this statement. > > > > 6. In section 4.1.1, I am confused by the term "fixed key" in the > following: > > > > "For a fixed Counter Mode key, each IV value used as an input MUST be > > distinct, in order to avoid the security exposure of a two-time pad > > situation (Section 9.1). To satisfy this constraint, an > > implementation MUST ensure that the values of the SRTP packet index > > of ROC || SEQ, and the SSRC used in the construction of the IV are > > distinct for any fixed key. The failure to ensure this uniqueness > > could be catastrophic for Secure RTP. This is in contrast to the > > situation for RTP itself, which may be able to tolerate such > > failures. It is RECOMMENDED that, if a dedicated security module is > > present, the RTP sequence numbers and SSRC either be generated or > > checked by that module (i.e., sequence-number and SSRC processing in > > an SRTP system needs to be protected as well as the key). " > > > > I think that "fixed" means "any particular key" but I am not sure. > > > > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 17:20:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07320 for ; Thu, 3 Jul 2003 17:20:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBVG-0002jE-3c for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 17:20:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63LKU0M010448 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 17:20:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBUw-0002hh-N3; Thu, 03 Jul 2003 17:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBUK-0002h3-BJ for avt@optimus.ietf.org; Thu, 03 Jul 2003 17:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07300 for ; Thu, 3 Jul 2003 17:19:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBUI-0003KJ-00 for avt@ietf.org; Thu, 03 Jul 2003 17:19:30 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19YBUG-0003Je-00 for avt@ietf.org; Thu, 03 Jul 2003 17:19:28 -0400 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h63LIj05064210; Thu, 3 Jul 2003 14:18:45 -0700 (PDT) (envelope-from casner@acm.org) Date: Thu, 3 Jul 2003 14:18:44 -0700 (PDT) From: Stephen Casner To: Aaron Colwell cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-bw-05.txt question In-Reply-To: Message-ID: <20030703141746.M66738-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Aaron, > What is the expected behavior if only a b=RR line is specified and it's > value is greater than 5% of the stream bandwidth. The draft says that if > only one parameter is specified then the value of the other is determined > by subracting the value of the specified parameter from 5% of the stream > bitrate. In the case I have mentioned this would cause a negative > bandwidth to be calculated. That is obviously not valid. Could someone > please clarify what should happen in this case. I propose to simply say that the unspecified parameter is zero in that case. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 3 17:45:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08143 for ; Thu, 3 Jul 2003 17:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBt1-0003q3-W1 for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 17:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Lj35Y014744 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 17:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBsz-0003ph-Qf; Thu, 03 Jul 2003 17:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBsR-0003os-6z for avt@optimus.ietf.org; Thu, 03 Jul 2003 17:44:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08104 for ; Thu, 3 Jul 2003 17:44:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBsO-0004OE-00 for avt@ietf.org; Thu, 03 Jul 2003 17:44:24 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19YBsO-0004Nt-00 for avt@ietf.org; Thu, 03 Jul 2003 17:44:24 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Thu, 03 Jul 2003 14:43:48 -0700 Date: Thu, 3 Jul 2003 14:50:15 -0700 (PDT) From: Aaron Colwell To: Stephen Casner cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-bw-05.txt question In-Reply-To: <20030703141746.M66738-100000@ash.packetdesign.com> Message-ID: References: <20030703141746.M66738-100000@ash.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Steve, This proposal would work fine if only b=RS is present. This would just mean that the client would not send receiver reports. In the case where b=RR is specified that would mean that no sender reports or BYE packets could be sent. Is that allowed? In the A/V case the client would not be able to sync the streams because it would never get their CNAME. I suppose that is the server's fault for not specifying a value for the sender reports. I guess this brings up another question. Does it make sense for the RS value to be 0? Perhaps we could modify your proposal to say, "If only b=RS is specified and it's value is greater than 5% of the stream bitrate, then RR value is 0. If you need a b=RR line that is greater than 5% of the stream bitrate, then you MUST supply a b=RS line." We could say that or we could just make the rule that if you are allocating more than 5% of the stream bitrate to RTCP, you MUST specify both the b=RR and b=RS lines. Aaron On Thu, 3 Jul 2003, Stephen Casner wrote: > Aaron, > > > What is the expected behavior if only a b=RR line is specified and it's > > value is greater than 5% of the stream bandwidth. The draft says that if > > only one parameter is specified then the value of the other is determined > > by subracting the value of the specified parameter from 5% of the stream > > bitrate. In the case I have mentioned this would cause a negative > > bandwidth to be calculated. That is obviously not valid. Could someone > > please clarify what should happen in this case. > > I propose to simply say that the unspecified parameter is zero in that > case. > -- Steve > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 4 04:50:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20930 for ; Fri, 4 Jul 2003 04:50:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YMGd-0001th-3z for avt-archive@odin.ietf.org; Fri, 04 Jul 2003 04:50:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h648o71w007294 for avt-archive@odin.ietf.org; Fri, 4 Jul 2003 04:50:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YMGX-0001tW-Pw; Fri, 04 Jul 2003 04:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YMFs-0001kc-OK for avt@optimus.ietf.org; Fri, 04 Jul 2003 04:49:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20890 for ; Fri, 4 Jul 2003 04:49:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YMFp-0003ZH-00 for avt@ietf.org; Fri, 04 Jul 2003 04:49:17 -0400 Received: from amarseille-201-2-2-126.w217-128.abo.wanadoo.fr ([217.128.162.126] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19YMFo-0003ZE-00 for avt@ietf.org; Fri, 04 Jul 2003 04:49:16 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h648m08w019883; Fri, 4 Jul 2003 04:48:01 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Fri, 4 Jul 2003 10:48:00 +0200 From: Colin Perkins To: avt@ietf.org Cc: casner@acm.org, magnus.westerlund@ericsson.com Message-Id: <20030704104800.40571e4a.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Agenda for Vienna Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Enclosed is the agenda for the AVT meeting in Vienna. Please send any comments or corrections to the chairs. Those who have agenda time scheduled are requested to prepare a summary of the issues they wish to discuss, and to send this to the mailing list ahead of the meeting. This gives those who won't be attending the opportunity to post their comments and concerns, and potentially even reach some consensus, before the meeting time is consumed. It also gives other participants the opportunity to consider the issue in more depth. Summary messages SHOULD be sent to the mailing list by Monday 7th July. We also request that all presenters send us their slides ahead of time, preferably in PDF format. This has multiple purposes: - It streamlines the presentation process by having the presentations on a single laptop. - It avoids the delay that sometimes occurs in getting the presentations sent to us after the meeting, for inclusion in the minutes. - It allows us to preview the presentations to see if they are following the guidelines for what should be covered during the meeting. Presentations SHOULD be submitted to the chairs by Friday 11th July. Agenda time is conditional on sending both a summary of open issues and a copy of your slides ahead of the meeting, and 5 minutes ahead doesn't count! Those presenting new drafts: briefly describe the basic problem and your proposed solution, discuss known issues, limitations and problems, outline where you want input from the working group, and how you wish us to proceed. When presenting work which has been previously discussed: describe only the changes from the previous draft, highlight unresolved problems, and propose future directions. Presenters are reminded of the requirements for disclosure of intellectual property relating to contributions, in section 10 of RFC 2026. We strongly encourage all participants to read all relevent drafts before the meeting, and to comment on the open issues raised on the mailing list. Thanks for your assistance to try to conduct an effective meeting. Colin, Steve and Magnus =============================================================================== Audio/Video Transport Working Group CHAIRS: Steve Casner Colin Perkins Magnus Westerlund Monday, 14th July 2003 at 09:00-11:30 ===================================== Introduction, Status and Charter Update (Chairs) 20 draft-ietf-avt-rtp-retransmission-08.txt [Last call] draft-ietf-avt-rtcp-feedback-07.txt [Last call] draft-burmeister-avt-rtcp-feedback-sim-02.txt [Last call] draft-ietf-avt-crtp-enhance-07.txt [RFC Editor] draft-ietf-avt-rtp-new-12.txt [RFC Editor] draft-ietf-avt-profile-new-13.txt [RFC Editor] draft-ietf-avt-rtp-mime-06.txt [RFC Editor] draft-ietf-avt-rtcp-bw-05.txt [RFC Editor] draft-ietf-avt-dsr-05.txt [RFC Editor] draft-ietf-avt-evrc-smv-03.txt [RFC Editor] draft-ietf-srtp-08.txt [IESG review] draft-ietf-avt-mpeg4-simple-07.txt [IESG review] draft-ietf-avt-rtp-clearmode-00.txt draft-ietf-avt-mwpp-midi-rtp-07.txt draft-lazzaro-avt-mwpp-coding-guidelines-03.txt draft-ietf-avt-rtp-jpeg2000-03.txt draft-hatanaka-avt-rtp-atracx-02.txt draft-flaks-avt-rtp-ac3-03.txt draft-ramalho-rgl-desc-01.txt draft-ramalho-rgl-rtpformat-01.txt draft-chen-rtp-bv-00.txt draft-lazzaro-avt-rtp-framing-contrans-01.txt FAX over RTP in ITU-T SG16 Q.14 New charter RTCP Extended Reports (Friedman) 5 draft-ietf-avt-rtcp-report-extns-06.txt RTP Payload Format for DTMF Digits, Tones, etc (Schulzrinne) 5 draft-ietf-avt-rfc2833bis-03.txt RTP Payload Format for Speex (Kerr) 15 draft-herlein-speex-rtp-profile-01.txt RTP Payload Format for iLBC Speech/iLBC codec (Duric) 15 draft-ietf-avt-rtp-ilbc-02.txt draft-ietf-avt-ilbc-codec-02.txt RTP Payload Format for Uncompressed Video (Gharai) 15 draft-ietf-avt-uncomp-video-03.txt RTP Payload Format for H.264 video (Wenger) 15 draft-ietf-avt-rtp-h264-02.txt RTP Payload Format for 3GPP Timed Text (Rey) 15 draft-rey-avt-3gpp-timed-text-00.txt RTCP Extensions for SSM with Unicast Feedback (Ott) 15 draft-ietf-avt-rtcpssm-04.txt CRTP over MPLS (Ash) 20 draft-ash-e2e-crtp-hdr-compress-01.txt draft-ash-e2e-vompls-hdr-compress-01.txt draft-ash-e2e-voip-hdr-comp-rqmts-00.txt - * - _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 4 04:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21017 for ; Fri, 4 Jul 2003 04:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YMKP-00026e-Oh for avt-archive@odin.ietf.org; Fri, 04 Jul 2003 04:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h648s1Mq008068 for avt-archive@odin.ietf.org; Fri, 4 Jul 2003 04:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YMKP-000261-2H; Fri, 04 Jul 2003 04:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YMK2-00025k-5T for avt@optimus.ietf.org; Fri, 04 Jul 2003 04:53:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20987 for ; Fri, 4 Jul 2003 04:53:35 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YMJz-0003aI-00 for avt@ietf.org; Fri, 04 Jul 2003 04:53:35 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19YMJy-0003aF-00 for avt@ietf.org; Fri, 04 Jul 2003 04:53:34 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19YMJz-0004Yp-00; Fri, 04 Jul 2003 09:53:35 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Fri, 4 Jul 2003 09:53:34 +0100 Message-ID: <1057308814.3f05408ee28c2@dlana.elec.gla.ac.uk> Date: Fri, 4 Jul 2003 09:53:34 +0100 To: Colin Perkins Cc: avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <20030703112126.49344304.csp@csperkins.org> In-Reply-To: <20030703112126.49344304.csp@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Colin / all, Sorry for missing this information out. Changes in the -01 draft. Expanded RTP header section detailing bitfield usage particularly the M bit at the suggestion of Henning Schulzrinne. Expanded payload section detailing frame packing and fragmentation handling at the suggestion of Federico Montesino Pouzols. Expanded example packet section detailing single Speex frame with padding and multiple Speex frame packing at the suggestion of Magnus Westerlund and Ross Finlayson. MIME type section expanded to clarify usage scenario of audio/speex. General text changes to improve clarity. Open issues: Maximum path-MTU discovery to prevent fragmentation. I've booked a slot in Vienna for the Speex I-D, as well as the Vorbis RTP draft. Regards Phil Quoting Colin Perkins : > --> philkerr@elec.gla.ac.uk writes: > > Dear all, > > > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > > > Comments and feedback welcomed. > > Can you summarize the changes from the previous version, and areas where > input is needed? > > -- > Colin Perkins > csp@csperkins.org > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 4 10:38:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28289 for ; Fri, 4 Jul 2003 10:38:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRhS-00006D-6J for avt-archive@odin.ietf.org; Fri, 04 Jul 2003 10:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64EcAbq000377 for avt-archive@odin.ietf.org; Fri, 4 Jul 2003 10:38:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRhK-00004q-AW; Fri, 04 Jul 2003 10:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YRgx-0008Og-LW for avt@optimus.ietf.org; Fri, 04 Jul 2003 10:37:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28270 for ; Fri, 4 Jul 2003 10:37:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YRgv-0006Cm-00 for avt@ietf.org; Fri, 04 Jul 2003 10:37:37 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19YRgu-0006Cg-00 for avt@ietf.org; Fri, 04 Jul 2003 10:37:36 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h64EbYHX010564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Jul 2003 10:37:34 -0400 (EDT) Message-ID: <3F05911D.6080209@cs.columbia.edu> Date: Fri, 04 Jul 2003 10:37:17 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [AVT] Implementation of RFC 3389 (Comfort noise)? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm looking for a library (C, C++ or Java) that generates comfort noise according to RFC 3389. Pointers are appreciated. Thank you. Henning Schulzrinne _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 4 11:27:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29471 for ; Fri, 4 Jul 2003 11:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSSk-0004A6-Bo for avt-archive@odin.ietf.org; Fri, 04 Jul 2003 11:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64FR2Xl015973 for avt-archive@odin.ietf.org; Fri, 4 Jul 2003 11:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSSj-00049Q-At; Fri, 04 Jul 2003 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSRu-00044X-1K for avt@optimus.ietf.org; Fri, 04 Jul 2003 11:26:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29370 for ; Fri, 4 Jul 2003 11:26:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YSRt-0006jc-00 for avt@ietf.org; Fri, 04 Jul 2003 11:26:09 -0400 Received: from romaine.cc.columbia.edu ([128.59.59.210] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19YSRs-0006jX-00 for avt@ietf.org; Fri, 04 Jul 2003 11:26:08 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by romaine.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h64FQ64M013477 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 4 Jul 2003 11:26:06 -0400 (EDT) Message-ID: <3F059C7D.8070304@cs.columbia.edu> Date: Fri, 04 Jul 2003 11:25:49 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [AVT] RFC 2833bis: open issues Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As requested by Colin, the Vienna discussion items for 2833bis (named events and tones): There have been no major changes, except a cleanup of MF description based on ITU and other documents. I believe this is now essentially correct. The example was extended to include a sequence of packets, not just one. Based on feedback from a number of readers, editorial changes were made to make the document easier to read. I believe the draft would be ready for last call if we weren't blocked on interop statements to progress the document to Draft Standard. There has been essentially no progress on this, unfortunately. There are two choices: (1) Cycle at Proposed and hope that somebody else has the energy to drum up interop reports so that the document can progress to Draft at some later point. I wouldn't hold my breath, so this means that 2833bis joins the list of Proposed Standards that run the Internet. (2) Try to come up with a reasonably small list of items to test, such as - support for end-of-event indication - support for end-of-event replication - support for long events - RFC 2198 - frequency generation - list of events supported and hope that people will step up and report. Finding pairs of implementations that, say, support a particular code point is going to be rather challenging, unless we define support as "printf the correct number". I would suggest that a report of usage (transmit & receive) of an event type should be considered sufficient here since there's no dependency on the sender. Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jul 5 19:35:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19898 for ; Sat, 5 Jul 2003 19:35:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YwYm-0004RJ-Ro for avt-archive@odin.ietf.org; Sat, 05 Jul 2003 19:35:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65NZGFJ017063 for avt-archive@odin.ietf.org; Sat, 5 Jul 2003 19:35:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YwYY-0004QR-7h; Sat, 05 Jul 2003 19:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YwXw-0004Pv-No for avt@optimus.ietf.org; Sat, 05 Jul 2003 19:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19891 for ; Sat, 5 Jul 2003 19:34:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YwXv-0006JL-00 for avt@ietf.org; Sat, 05 Jul 2003 19:34:23 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19YwXu-0006JI-00 for avt@ietf.org; Sat, 05 Jul 2003 19:34:22 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h65NY5Q11454 for avt@ietf.org; Sat, 5 Jul 2003 16:34:05 -0700 Date: Sat, 5 Jul 2003 16:34:05 -0700 From: John Lazzaro Message-Id: <200307052334.h65NY5Q11454@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Vienna status reports ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, I won't be presenting at Vienna, however, here are quick status reports for the "RTP MIDI" and "RTP framing for TCP/TLS" I-Ds: draft-ietf-avt-mwpp-midi-rtp-08 ------------------------------- This is the normative RTP MIDI I-D. Two revisions since San Francisco, to address MMA concerns and to achieve compatibility with all of the MMA standards. Presently, I'm recoding sfront networking to support RTP MIDI. In doing so, I expect to catch some RTP MIDI protocol bugs. I may also do a tiny RTSP RTP MIDI server, and add RTSP sfront support, to catch content-streaming bugs, if time permits. Once this coding work is complete, I plan to update the I-D with bugfixes, add in changes in response to any additional comments I receive on the document, and issue a Last Call document. Most probably well before the Minneapolis submission deadline. draft-lazzaro-avt-mwpp-coding-guidelines-03 ------------------------------------------- This is the "RTP MIDI Implementation Guidelines" informative I-D. One revision since San Francisco, to trim away most RTP-generic content, and leave a shorter I-D that focuses on RTP MIDI specific implementation issues. Several months ago, I requested WG item status for this I-D, because I believe that RTP MIDI implementors should read it before starting their design. If the WG agrees, I'll submit a relabeled I-D, and then put this I-D and the normative I-D up for Last Call concurrently. draft-lazzaro-avt-rtp-framing-contrans-01 ----------------------------------------- This is the RTP framing over connection-oriented transport I-D. In response to comments in San Francisco, I rewrote the I-D, removing the RTSP support, and adding RTP/AVP fmt token definitions for use with TCP and TLS. The new document is only 8 pages long. Further action on this document awaits the revised AVT WG charter, and also awaits the mmusic WG reaching consensus on draft-ietf-mmusic-sdp-comedia. ---- I had hoped to also have input on ideas for adding audio synchronization support to the IETF multimedia toolkit, as a potential AVT WG charter addition. Unfortunately, the I-Ds above took precedence ... I think its important to focus on moving RTP MIDI out to Last Call, so further work on synchronization will probably start after the RTP MIDI I-D writing work completes. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jul 6 11:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15506 for ; Sun, 6 Jul 2003 11:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZB9U-00085r-0a for avt-archive@odin.ietf.org; Sun, 06 Jul 2003 11:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66FA7LG031108 for avt-archive@odin.ietf.org; Sun, 6 Jul 2003 11:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZB9N-00085B-Bh; Sun, 06 Jul 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZB8R-0007yc-6Z for avt@optimus.ietf.org; Sun, 06 Jul 2003 11:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15468 for ; Sun, 6 Jul 2003 11:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZB8O-0002yb-00 for avt@ietf.org; Sun, 06 Jul 2003 11:09:00 -0400 Received: from anice-203-2-1-43.w80-14.abo.wanadoo.fr ([80.14.153.43] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19ZB8L-0002yN-00 for avt@ietf.org; Sun, 06 Jul 2003 11:08:58 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h66F858w044931; Sun, 6 Jul 2003 11:08:09 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Sun, 6 Jul 2003 17:08:05 +0200 From: Colin Perkins To: avt@ietf.org Cc: casner@acm.org, magnus.westerlund@ericsson.com Message-Id: <20030706170805.2c3bf118.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sun__6_Jul_2003_17:08:05_+0200_08180800" Subject: [AVT] Revised agenda for Vienna Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Multipart_Sun__6_Jul_2003_17:08:05_+0200_08180800 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Folks, Here's an updated agenda for the Vienna AVT meeting. There are two additions: the RTP payload format for Vorbis, and a mention of IAB concerns re congestion control for VoIP. -- Colin Perkins csp@csperkins.org --Multipart_Sun__6_Jul_2003_17:08:05_+0200_08180800 Content-Type: text/plain; name="agenda.txt" Content-Disposition: attachment; filename="agenda.txt" Content-Transfer-Encoding: quoted-printable Audio/Video Transport Working Group CHAIRS: Steve Casner Colin Perkins Magnus Westerlund Monday, 14th July 2003 at 09:00-11:30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Introduction, Status and Charter Update (Chairs) 20 draft-ietf-avt-rtp-retransmission-08.txt [Last call] draft-ietf-avt-rtcp-feedback-07.txt [Last call] draft-burmeister-avt-rtcp-feedback-sim-02.txt [Last call] draft-ietf-avt-crtp-enhance-07.txt [RFC Editor] draft-ietf-avt-rtp-new-12.txt [RFC Editor] draft-ietf-avt-profile-new-13.txt [RFC Editor] draft-ietf-avt-rtp-mime-06.txt [RFC Editor] draft-ietf-avt-rtcp-bw-05.txt [RFC Editor] draft-ietf-avt-dsr-05.txt [RFC Editor] draft-ietf-avt-evrc-smv-03.txt [RFC Editor] draft-ietf-srtp-08.txt [IESG review] draft-ietf-avt-mpeg4-simple-07.txt [IESG review] draft-ietf-avt-rtp-clearmode-00.txt draft-ietf-avt-mwpp-midi-rtp-07.txt draft-lazzaro-avt-mwpp-coding-guidelines-03.txt draft-ietf-avt-rtp-jpeg2000-03.txt draft-hatanaka-avt-rtp-atracx-02.txt=20 draft-flaks-avt-rtp-ac3-03.txt draft-ramalho-rgl-desc-01.txt draft-ramalho-rgl-rtpformat-01.txt draft-chen-rtp-bv-00.txt draft-lazzaro-avt-rtp-framing-contrans-01.txt FAX over RTP in ITU-T SG16 Q.14 New charter IAB Concerns Regarding Congestion Control for VoIP (Floyd) 5 draft-iab-congestion-00.txt=20 RTCP Extended Reports (Friedman) 5 draft-ietf-avt-rtcp-report-extns-06.txt RTP Payload Format for DTMF Digits, Tones, etc (Schulzrinne) 5 draft-ietf-avt-rfc2833bis-03.txt RTP Payload Format for Speex (Kerr) 10 draft-herlein-speex-rtp-profile-01.txt RTP Payload Format for Vorbis (Kerr) 10 draft-kerr-avt-vorbis-rtp-02.txt RTP Payload Format for iLBC Speech/iLBC codec (Duric) 15 draft-ietf-avt-rtp-ilbc-02.txt draft-ietf-avt-ilbc-codec-02.txt RTP Payload Format for Uncompressed Video (Gharai) 10 draft-ietf-avt-uncomp-video-03.txt RTP Payload Format for H.264 video (Wenger) 15 draft-ietf-avt-rtp-h264-02.txt=20 RTP Payload Format for 3GPP Timed Text (Rey) 15 draft-rey-avt-3gpp-timed-text-00.txt=20 RTCP Extensions for SSM with Unicast Feedback (Ott) 15 draft-ietf-avt-rtcpssm-04.txt CRTP over MPLS (Ash) 20 draft-ash-e2e-crtp-hdr-compress-01.txt draft-ash-e2e-vompls-hdr-compress-01.txt draft-ash-e2e-voip-hdr-comp-rqmts-00.txt - * - --Multipart_Sun__6_Jul_2003_17:08:05_+0200_08180800-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 04:05:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16804 for ; Mon, 7 Jul 2003 04:05:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQzs-0004jQ-5h for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 04:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6785GxT018189 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 04:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZQze-0004ik-DA; Mon, 07 Jul 2003 04:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YTjD-0003OQ-Mv for avt@optimus.ietf.org; Fri, 04 Jul 2003 12:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01850 for ; Fri, 4 Jul 2003 12:48:04 -0400 (EDT) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YTjB-0007nJ-00 for avt@ietf.org; Fri, 04 Jul 2003 12:48:05 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19YTjA-0007nG-00 for avt@ietf.org; Fri, 04 Jul 2003 12:48:04 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id CAF3955A01; Fri, 4 Jul 2003 18:48:03 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA29236; Fri, 4 Jul 2003 18:48:03 +0200 (MET DST) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id SAA16414; Fri, 4 Jul 2003 18:48:02 +0200 (MEST) To: mankin@psg.com Cc: avt@ietf.org, casner@acm.org, csp@csperkins.org, dmackie@apple.com, magnus.westerlund@ericsson.com, mankin@psg.com, ned.freed@mrochek.com, philippe.gentric@philips.com, singer@apple.com, smb@research.att.com, viswanathan.swaminathan@sun.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 4 Jul 2003 18:46:34 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 04/07/2003 18:46:41, Serialize complete at 04/07/2003 18:46:41 Content-Type: multipart/alternative; boundary="=_alternative 005C46FCC1256D59_=" Subject: [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005C46FCC1256D59_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Allison, all, Thanks for the IESG comments. In response I would like to suggest the=20 following: 1) Comment: It is strange to have more than one section labeled "Introduction." Please pick a new label for section 2.1. My proposal is to label 2.1 as "Signaling by MIME format parameters" 2) Where is the security model defined for ECMAScript in this context?=20 (Problems with the model have been part of the Javascript security=20 problem for Web browsers.) MPEG-4 defines some important constraints on the use of ECMA scripts in=20 MPEG-4. An annex to the MPEG-4 system spec describes the differences=20 between "regular" ECMA scipts and "MPEG-4 scripts". As far as I understand = these constraints do not allow dangerous ECMA script constructs, which=20 means there is no need for an ECMA script security model in this context.=20 Below I attached the MPEG-4 annex that describes the differences.=20 I suggest to resolve this as follows: a) replace in section 5 "security considerations" all current references=20 to ECMAScript by MPEG-4 script, and=20 b) add to the fifth paragraph (starting with "In ISO/IEC 14496-1 a=20 security model is defined for ...") the following trailing sentence "Note: = MPEG-4 scripts are based on ECMA scripts, but there is no need for an ECMA = script security model, as the use of insecure ECMA script constructs is=20 impossible in MPEG-4 scripts." 3) 2.4: Why is this form of application-level fragmentation better than IP fragmentation? This is because of error resilience. If IP fragmentation occurs without=20 application-level fragmentation, then all data of the entire Access Unit=20 gets lost when one such fragmented IP packet is lost. When=20 application-level fragmentation is used, and one RTP packet with an AU=20 fragment gets lost, then the received RTP packet(s) with the other AU=20 fragments can still be decoded. I suggest to remove "so as to avoid IP=20 layer fragmentation" from the first sentence of section 2.4, and to add=20 the following after the first sentence: "Hence when an IP packet is lost=20 after IP-level fragmentation, only an AU fragment may get lost instead of=20 the entire AU". Any comments very welcome. Best regards, Jan van der Meer *******begin of MPEG-4 system annex******* MPEG-4 Scripts Have a Rigid Representation=20 MPEG-4 scripts differ slightly from ECMA scripts. The most important=20 difference is that MPEG-4 scripts are not represented textually, but are=20 transmitted as a parse tree representation. This means that only=20 constructs that can be represented by the MPEG-4 parse grammar can be=20 encoded and transmitted. Not all ECMA script constructs can be represented = in MPEG-4 scripts.=20 The differences between ECMA scripts and scripts that can be represented=20 in MPEG-4 are given below. Keywords MPEG-4 scripts cannot utilize the following keywords: catch delete do final= ly in instanceof throw try typeof void with . This means that do ? while loops and for ? in loops are not possible. Relational operators The relational operators "=3D=3D=3D" and "!=3D=3D" cannot be included in M= PEG-4 Scripts.=20 Labeled statements In MPEG-4 scripts it is impossible to label statements and to break or cont= inue to labeled statements. Switch statement restriction MPEG-4 scripts with switch statements can only take numerical case expressi= ons and always must have at least one case statement. In particular this means that=20 switch { case (x+1): ?. } is not possible, while Switch { case 1: ?. } is okay. Functions, not programs The MPEG-4 event driven script model allows only functions to be called in = response to events.=20 Expressions=20 Statements that include statement blocks, such as for are represented in=20 the parse tree as having an empty statement block, where as in ECMA script = they can omit this block. Functionally, the statements behave identically. = For example, the expression:=20 for ( ; ; )=20 must be represented as for ( ; ; ) {} Array and Object Literals Array and object literals of the form [value1, value2, .., valueN] and {pro= perty1:value1, property2: value2, .. propertyN:valueN} cannot be used in MP= EG-4 scripts.=20 *******end of MPEG-4 system annex******* Allison Mankin 2003-06-27 06:19 AM Please respond to mankin =20 To: Jan vanderMeer/EHV/CE/PHILIPS@EMEA3 dmackie@apple.com viswanathan.swaminathan@sun.com singer@apple.com Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 cc: casner@acm.org magnus.westerlund@ericsson.com csp@csperkins.org smb@research.att.com ned.freed@mrochek.com mankin@psg.com avt@ietf.org Subject: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt -= Discuss Comments Classification:=20 The IESG reviewed draft-ietf-avt-mpeg4-simple-07.txt and had a few=20 concerns that should be addressed before the draft can advance. Editorially: Comment: It is strange to have more than one section labeled "Introduction." Please pick a new label for section 2.1. Steve Bellovin and Ned Freed both request that a reference be given in the Security Considerations for security model for ECMAscript. Here is Steve's Discuss comment: Where is the security model defined for ECMAScript in this context?=20 (Problems with the model have been part of the Javascript security=20 problem for Web browsers.) Steve also asked: 2.4: Why is this form of application-level fragmentation better than IP fragmentation? Please discuss the issues in email and we'll see if the fixes to the draft can be done as notes rather than a revised i-d, to be quicker. Allison --=_alternative 005C46FCC1256D59_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Allison, all,

Thanks for the IESG comments. In res= ponse I would like to suggest the following:

1) Comment:  It is strange to = have more than one section labeled
 "Introduction."  Please pick a new label for section = 2.1.

My proposal is to label 2.1 as "= ;Signaling by MIME format parameters"
2) Where is the security model defi= ned for ECMAScript in this context?  
  (Problems with the model have been part of the Javascript security =
  problem for Web browsers.)
MPEG-4 defines some important constr= aints on the use of ECMA scripts in MPEG-4. An annex to the MPEG-4 system s= pec describes the differences between "regular" ECMA scipts and &= quot;MPEG-4 scripts". As far as I understand these constraints do not = allow dangerous ECMA script constructs, which means there is no need for an= ECMA script security model in this context. Below I attached the MPEG-4 an= nex that describes the differences.
I suggest to resolve this as follows= :
a) replace in section 5 "securi= ty considerations" all current references to ECMAScript by MPEG-4 scri= pt, and
b) add to the fifth paragraph (start= ing with "In ISO/IEC 14496-1 a security model is defined for ..."= ) the following trailing sentence "Note: MPEG-4 scripts are based on E= CMA scripts, but there is no need for an ECMA script security model, as the= use of insecure ECMA  script constructs is impossible in MPEG-4 scrip= ts."

3) 2.4:  Why is this form of a= pplication-level fragmentation better than
  IP fragmentation?
This is because of error resilience.= If IP fragmentation occurs without application-level fragmentation, then a= ll data of the entire Access Unit gets lost when one such fragmented IP pac= ket is lost. When application-level fragmentation is used, and one RTP pack= et with an AU fragment gets lost, then the received RTP packet(s)  wit= h the other AU fragments can still be decoded. I suggest to remove "so= as to avoid IP layer fragmentation" from the first sentence of sectio= n 2.4, and to add the following after the first sentence: "Hence when = an IP packet is lost after IP-level fragmentation, only an AU fragment may = get lost instead of the entire AU".

Any comments very welcome.


Best regards,

Jan van der Meer

*******begin of MPEG-4 system annex*= ******

        MPEG-4 Scripts Have a Rigid Representa= tion  
MPEG-4 scripts differ slightly from ECMA = scripts. The most important difference is that MPEG-4 scripts are not repre= sented textually, but are transmitted as a parse tree representation.  = ;This means that only constructs that can be represented by the MPEG-4 pars= e grammar can be encoded and transmitted. Not all ECMA script constructs ca= n be represented in MPEG-4 scripts.

The differences between ECMA scripts and s= cripts that can be represented in MPEG-4 are given below.


        Keywords
MPEG-4 scripts cannot utilize the followi= ng keywords: catch delete do fin= ally in instanceof throw try typeof void with .

This means that  do – loops and  for= – in loops are not p= ossible.

        Relational operators

The relational operators  "=3D=3D=3D" and "!=3D=3D" cannot be included in MPEG-4 Scripts.

        Labeled statements

In MPEG-4 scripts it is impossible to labe= l statements and to break= or to labeled statements.

        Switch statement restriction

MPEG-4 scripts with switch statements= can only take numerical case expressions and always must have at leas= t one case statement.

In particular this means that

switch {

        case (x+= 1):  ….

}

is not possible, while

Switch {

        case 1: =  ….

}

is okay.

        Functions, not programs

The MPEG-4 event driven script model allow= s only functions to be called in response to events.

        Expressions

Statements that include statement blocks, = such as for are represented in the parse tree as having an empty statement = block, where as in ECMA script they can omit this block. Functionally, the = statements behave identically. For example, the expression:

        for ( <expr>; <expr>; &l= t;expr>)

must be represented as


        for ( <expr>; <expr>; &= lt;expr>) {}

        = Array and Object Literals
Array and object literals of the form [value1, value2, .., = valueN] and {property1:value1, property2= : value2, .. propertyN:valueN} cannot be used in MPEG-4 scripts.

*******end of MPEG-4 system annex****= ***











Allison Mankin <mankin@psg.com= >

2003-06-27 06:19 AM
Please respond to mankin

       
        To: &nbs= p;      Jan vanderMeer/EHV/CE/PHILIPS@EMEA3
dmackie@apple.com
viswanathan.swaminathan@sun.com
singer@apple.com
Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1
        cc: &nbs= p;      casner@acm.org
magnus.westerlund@ericsson.com
csp@csperkins.org
smb@research.att.com
ned.freed@mrochek.com
mankin@psg.com
avt@ietf.org
        Subject:=        IESG Review of draft-ietf-avt-mpeg4-simple-07.t= xt - Discuss Comments

        Classific= ation:        




The IESG reviewed draft-ietf-avt-mp= eg4-simple-07.txt and had a few concerns
that should be addressed before the draft can advance.  Editorially:
  Comment:  It is strange to have more than one section labeled<= br>  "Introduction."  Please pick a new label for section = 2.1.

Steve Bellovin and Ned Freed both request that a reference be given in
the Security Considerations for security model for ECMAscript.  Here is Steve's Discuss comment:

  Where is the security model defined for ECMAScript in this context?=  
  (Problems with the model have been part of the Javascript security =
  problem for Web browsers.)

Steve also asked:

  2.4:  Why is this form of application-level fragmentation bett= er than
  IP fragmentation?

Please discuss the issues in email and we'll see if the fixes to the draft<= br> can be done as notes rather than a revised i-d, to be quicker.

Allison

--=_alternative 005C46FCC1256D59_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 10:01:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25263 for ; Mon, 7 Jul 2003 10:01:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWYU-00027n-SI for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 10:01:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67E1MUe008163 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 10:01:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWY9-00026Z-0h; Mon, 07 Jul 2003 10:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWXS-00025r-Ef for avt@optimus.ietf.org; Mon, 07 Jul 2003 10:00:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25223 for ; Mon, 7 Jul 2003 10:00:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWXQ-0004Sl-00 for avt@ietf.org; Mon, 07 Jul 2003 10:00:16 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19ZWXP-0004Si-00 for avt@ietf.org; Mon, 07 Jul 2003 10:00:15 -0400 thread-index: AcNEj93UEvAST8hASwaCmdcRTQo14A== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 15:58:38 +0200 From: "Jose Rey" Content-Class: urn:content-classes:message Priority: normal To: Cc: "Casner@Acm. Org" , "Colin Perkins" , "Magnus Westerlund" , "Y. Matsui" , "Daiji Ido" , "Tadamasa Toma" , "Notoya Youji" , "Rolf Hakenberg" Date: Mon, 7 Jul 2003 15:58:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 Jul 2003 13:58:38.0918 (UTC) FILETIME=[DDD40E60:01C3448F] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA25224 Subject: [AVT] Summary of 3GPP timed text draft Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, here is a quick summary of the draft and a list of the issues we want to start discussion on in Vienna. This draft specifies an RTP payload format for the 3GPP timed text format. 3GPP timed text is currently only conveyed via HTTP. For upcoming services like streaming or multimedia broadcast multicast, an RTP payload format is needed. The main motivation is therefore to have an RTP payload format *ready* for Rel6 (maybe March'04, probably June'04). Envisioned areas of application are 3GPP's MBMS (Multimedia Broadcast/Multicast Services) and PSS (Packet Switched Services) streaming. The open issues/TODO list includes: - resilient transport: repetition, fragmentation, retransmission, FEC (other?). It is our opinion that repetition should be included at the very least. Fragmentation is reasonable when the packets get big and should be documented as well. Retransmission and FEC can be used, if it makes sense for the particular use case. - Transport of sample description information: the sample description box (see draft for more on this) is information which is needed by many different text samples. This amount of information might become too big to be transported out-of-band using SDP. What are the other options? What is the threshold to decide for in- or out-of-band transport? Should both transport options be documented? looking forward to the meeting in Vienna, Jos=E9 Rey____ mailto:rey@panasonic.de Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 http://www.pel.panasonic.de ____________________________________ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 13:53:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05208 for ; Mon, 7 Jul 2003 13:53:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaAj-0000EZ-7F for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 13:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Hr5QL000881 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 13:53:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaAf-0000Da-G7; Mon, 07 Jul 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Za9v-0000D4-72 for avt@optimus.ietf.org; Mon, 07 Jul 2003 13:52:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05200 for ; Mon, 7 Jul 2003 13:52:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Za9s-0007Wx-00 for avt@ietf.org; Mon, 07 Jul 2003 13:52:12 -0400 Received: from mail2.fw-sj.sony.com ([160.33.82.69]) by ietf-mx with esmtp (Exim 4.12) id 19Za9r-0007WZ-00 for avt@ietf.org; Mon, 07 Jul 2003 13:52:12 -0400 Received: from mail2.sjc.in.sel.sony.com (mail2.sjc.in.sel.sony.com [43.134.1.111]) by mail2.fw-sj.sony.com (8.8.8/8.8.8) with ESMTP id RAA03415; Mon, 7 Jul 2003 17:51:27 GMT Received: by mail2.sjc.in.sel.sony.com id RAA10391; Mon, 7 Jul 2003 17:51:25 GMT Received: by us-sj-xims-2.am.sony.com with Internet Mail Service (5.5.2650.21) id <338PFWLZ>; Mon, 7 Jul 2003 10:51:23 -0700 Message-ID: <0DE752C748D0D211A6BE0090272B960B07848610@us-sj-xmsg-2.am.sony.com> From: "Edwards, Eric" To: "'avt@ietf.org'" Cc: "'casner@acm.org'" , "'magnus.westerlund@ericsson.com'" , "'Colin Perkins'" Date: Mon, 7 Jul 2003 10:32:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [AVT] draft-ietf-avt-rtp-jpeg2000-03.txt - resend Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Greetings, The Internet-Draft - draft-ietf-avt-rtp-jpeg2000-03.txt - has been posted. Some time passed before this version was submitted. Most of the time was spent discussing if potential reconciliation with work that was taking place in ISO/IEC JTC1 SC 29 WG 01 (JPEG) was in order. After lengthy discussions it was agreed by the experts in WG 01 that there were different goals and application areas targeted for our respective work and that the JP2/RTP proposal (draft-ietf-avt-rtp-jpeg2000-03.txt) should move forward in IETF as is. So at this stage we are ready to move to Last Call if the AVT experts have no objections to the current draft. Please advise and comment. Best regards, Eric _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 13:58:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05375 for ; Mon, 7 Jul 2003 13:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaFV-0000fa-Az for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 13:58:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Hw16W002570 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 13:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaFU-0000et-Ma; Mon, 07 Jul 2003 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaEi-0000Xi-Mc for avt@optimus.ietf.org; Mon, 07 Jul 2003 13:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05319 for ; Mon, 7 Jul 2003 13:57:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZaEg-0007bp-00 for avt@ietf.org; Mon, 07 Jul 2003 13:57:10 -0400 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19ZaEf-0007b9-00 for avt@ietf.org; Mon, 07 Jul 2003 13:57:09 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h67HpohL008048 for ; Mon, 7 Jul 2003 12:56:39 -0500 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C008AB83E; Mon, 7 Jul 2003 13:56:33 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [AVT] Agenda for Vienna Date: Mon, 7 Jul 2003 12:56:38 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0A68A8@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] Agenda for Vienna Thread-Index: AcNCCZ6lSLFfYszIRverkJLLwcV1CQCpupVg From: "Ash, Gerald R (Jerry), ALABS" To: "Colin Perkins" , Cc: "Ash, Gerald R (Jerry), ALABS" , , Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All, Here is a brief summary regarding the following agenda item: > CRTP over MPLS (Ash) 20 > draft-ash-e2e-crtp-hdr-compress-01.txt > draft-ash-e2e-vompls-hdr-compress-01.txt > draft-ash-e2e-voip-hdr-comp-rqmts-00.txt Background: Some service providers (such as AT&T) have plans to migrate large = amounts of legacy voice traffic to VoIP, as well as to provide VPN = services enabling VoIP. VoIP over MPLS ('VoMPLS') typically uses the = encapsulation voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header = is at least 48 bytes, while the voice payload is typically no more than = 30 bytes. VoIP over MPLS header compression can significantly reduce = the VoIP overhead through various compression mechanisms. This is = important on access links where bandwidth is scarce, and can be = important on backbone facilities, especially where costs are high (e.g., = some global cross-sections). =20 VoIP over MPLS header compression methods have been proposed earlier = (March, 2000) in the MPLS working group, however the relevant drafts = have expired. In particular, George Swallow and Lou Berger proposed a = 'simple' end-to-end compression scheme in which all first-order = differences in the RTP/UDP/IP headers were transmitted, and in which the = header compression context was established through RSVP signaling. The = work was accepted into the MPLS WG pending an addition to the MPLS WG = charter. In the I-D's we propose 3 approaches to VoMPLS header compression: a) = re-use the methods in cRTP to determine the context and MPLS to route = packets, b) re-use the methods in Swallow's and Berger's 'simple' = approach to determine the context and MPLS to route packets, and c) = re-use the methods in cRTP to determine the context and the SCID = (session context ID) to route packets. The work was presented at the IETF-56 MPLS WG meeting (slides and an = excellent set of meetings notes are available at = http://ietf.org/proceedings/03mar/index.html. Issues to discuss: 1. WG charter -- The VoMPLS header compression work is not within the = current charter of the AVT WG, so a charter extension is needed. A = discussion among the Transport Area Directors and Sub-IP Area Directors = suggested that the work fits most closely within the Transport Area/AVT = WG. 2. Protocol extensions -- As detailed in the I-Ds, extensions are = proposed to [cRTP] and [cRTP-ENHANCE], which involve a new packet type = field to identify FULL_HEADER, CONTEXT_STATE, etc. packets. New objects = are defined for [RSVP-TE]. Extensions are also proposed to RFC2547 = VPNs, which create 'SCID routing tables' to allow routing based on the = session context ID (SCID). These extensions need coordination with = other WGs (e.g., MPLS). 3. Resynchronization -- E2E VoMPLS using cRTP header compression might = not perform well with frequent resynchronizations. [cRTP-ENHANCE] seems = appropriate in this context. The 'simple' header compression approach = would avoid the need for resynchronization, but achieves less efficiency = than cRTP. 4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require = a large number of LSPs to be created. There is concern for CE ability = to do the necessary processing and the scalability of the architecture. 4. LDP application -- It would be desirable to signal the VoMPLS tunnels = with LDP, since many RFC2547 VPN implementations use LDP as the = underlying LSP signaling mechanism. Please review the documents and raise any issues/comments to the list. Please review the documents and raise any issues/comments to the list. Thanks, Jerry Ash _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 15:25:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10472 for ; Mon, 7 Jul 2003 15:25:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbbp-0006Wt-9O for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 15:25:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67JP9BW025087 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 15:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbbi-0006Va-2Q; Mon, 07 Jul 2003 15:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbbP-0006V4-45 for avt@optimus.ietf.org; Mon, 07 Jul 2003 15:24:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10407 for ; Mon, 7 Jul 2003 15:24:41 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZbbN-0001Nh-00 for avt@ietf.org; Mon, 07 Jul 2003 15:24:41 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19ZbbN-0001NW-00 for avt@ietf.org; Mon, 07 Jul 2003 15:24:41 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19ZbbG-0006yc-00 for avt@ietf.org; Mon, 07 Jul 2003 20:24:34 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Mon, 7 Jul 2003 20:24:34 +0100 Message-ID: <1057605874.3f09c8f261862@dlana.elec.gla.ac.uk> Date: Mon, 7 Jul 2003 20:24:34 +0100 To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Subject: [AVT] Vorbis RTP issues list for Vienna Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, Last month (11th June) an -02 update to draft-kerr-avt-vorbis-rtp was announced on the AVT list and a slot in Vienna has been booked for discussion. The draft details the RTP delivery of Vorbis audio, SDP values and delivery of the decoders static probability model, 'codebooks'. Examples of Vorbis frame packing and fragmented packet handling are also covered. Open issues: Congestion control. Under development is a mechanism for dynamic bitrate reduction called 'bitrate peeling'. When this feature becomes available it will impact on how congestion is dealt with and a mechanism allowing its use within a multicast environment needs to be explored. Codebook delivery. There are two mechanisms outlined for the delivery of the codebooks, SDP and RTCP. The codebooks may change mid-stream (at the boundary between two tracks) as well as being static for the session lifetime. As the codebooks are needed for the successful decoding of the Vorbis stream a reliable mechanism to handle their delivery of mid-session codebook changes should be investigated (TCP over RTP?) in preference to using RTCP messages. Path MTU. There is a mechanism for splitting large Vorbis frames across multiple RTP packets but a reliable mechanism for path-MTU discovery needs to be outlined to prevent packet fragmentation not dealt with by the above. I've also requested WG status for the I-D. Comments and feedback welcomed. Regards Phil ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 15:34:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10760 for ; Mon, 7 Jul 2003 15:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbkR-0006z3-5B for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 15:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67JY3dA026834 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 15:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbkQ-0006yC-9D; Mon, 07 Jul 2003 15:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbjw-0006x2-7B for avt@optimus.ietf.org; Mon, 07 Jul 2003 15:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10714 for ; Mon, 7 Jul 2003 15:33:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbju-0001UI-00 for avt@ietf.org; Mon, 07 Jul 2003 15:33:30 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Zbju-0001UF-00 for avt@ietf.org; Mon, 07 Jul 2003 15:33:30 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h67JX5t21340 for avt@ietf.org; Mon, 7 Jul 2003 12:33:05 -0700 Date: Mon, 7 Jul 2003 12:33:05 -0700 From: John Lazzaro Message-Id: <200307071933.h67JX5t21340@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > jan.vandermeer@philips.com writes: > > As far as I understand these constraints do not allow dangerous ECMA > script constructs, which means there is no need for an ECMA script > security model in this context. Below I attached the MPEG-4 annex that > describes the differences. Do "MPEG-4 scripts" give the script control over audio volume of the presentation, in a way that could override the levels manually set by the human listening to the decoder? A rogue program that blows out the speakers of the victim's terminal seems like a security risk of some sort, although not of the classical kind since data and CPU and network are not compromised ... if this is an actual risk, might be worth warning implementors in the Security Considerations section ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 15:57:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12090 for ; Mon, 7 Jul 2003 15:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc6h-0000bm-Dx for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 15:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Jv30x002311 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 15:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc6f-0000YP-Uy; Mon, 07 Jul 2003 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc5w-0000Py-Sh for avt@optimus.ietf.org; Mon, 07 Jul 2003 15:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12014 for ; Mon, 7 Jul 2003 15:56:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zc5v-0001rH-00 for avt@ietf.org; Mon, 07 Jul 2003 15:56:15 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Zc5p-0001rB-00 for avt@ietf.org; Mon, 07 Jul 2003 15:56:09 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h67JtiA21422 for avt@ietf.org; Mon, 7 Jul 2003 12:55:44 -0700 Date: Mon, 7 Jul 2003 12:55:44 -0700 From: John Lazzaro Message-Id: <200307071955.h67JtiA21422@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: Re: [AVT] Summary of 3GPP timed text draft Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > "Jose Rey" writes: > > The open issues/TODO list includes: > > - resilient transport: repetition, fragmentation, retransmission, FEC > (other?). It is our opinion that repetition should be included at the > very least. Is RTCP expected to be normally used with this payload format? If so, maybe the core idea behind the RTP MIDI resiliency -- a "recovery journal" in every packet coding the recent past, whose contents grow and shrink as the sender examines RTCP RR reports which indicate the highest sequence number the receiver has received -- could be the starting point of a timed text resiliency scheme. For the default 5 second RTCP sending rate, and text that is not sent too frequently, one could imagine a recovery journal approach would be more efficient that simple repetition. But you need RTCP to make it work ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 17:35:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17214 for ; Mon, 7 Jul 2003 17:35:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdde-00083x-WB for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 17:35:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67LZAhW030988 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 17:35:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZddV-00082F-BU; Mon, 07 Jul 2003 17:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdcq-00081P-5I for avt@optimus.ietf.org; Mon, 07 Jul 2003 17:34:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17176; Mon, 7 Jul 2003 17:34:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zdcn-0003HU-00; Mon, 07 Jul 2003 17:34:17 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19Zdcl-0003HR-00; Mon, 07 Jul 2003 17:34:16 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 7 Jul 2003 16:29:17 UT To: avt@ietf.org, avt-admin@ietf.org, mmusic@ietf.org Cc: , , , csp@csperkins.org, Orit Levin , Roni Even , nismail@cisco.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Mon, 7 Jul 2003 17:34:10 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 07/07/2003 05:30:03 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488" Content-Disposition: inline Subject: [AVT] Requirements draft on video control Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488 Content-type: text/plain; charset=us-ascii Attached you will find draft-basso-avt-videoconreq-00.txt Abstract: A variety of communication services such as video conferencing and video messaging rely on the capability of video encoders and decoders to exchange control commands. This document outlines this set of commands as well as the requirements for their transport. Comments are more than welcome. Andrea Basso NMS Communications (732) 936-2118 (See attached file: draft-basso-avt-videoconreq-00.zip) --0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488 Content-type: application/zip; name="draft-basso-avt-videoconreq-00.zip" Content-Disposition: attachment; filename="draft-basso-avt-videoconreq-00.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAM+L5y44JHRBrRsAAH5dAAAiAAAAZHJhZnQtYmFzc28tYXZ0LXZpZGVvY29ucmVx LTAwLnR4dO1cW28byXJ+D3L+Q8MvkXBIWqRk2TKCYGVZ9sqxLEWUfRAYRtCcaZJ9PBee6RnJXORf nCC/N3Xp21x08R6vn8LF0hQ5U11dXZevqqvnT/8k6HXcpLoUn3SqSnFdycJsyqoWb6uy2YhHv/5k iZ0VtaoKVYvXlVzW99/TfR1PxCtpTOmJvS6TJldF/VKkSG28wF/H8qYe3yC3SVlU6m/jvb1J/c0O 9eF8Lk7KPG8Knchal4XxxP6h18XkvbrRxY8gdnX8+tPZ/Oziw48g9mEizkwudfaPEjvRJinFfGtq lQeZnX7b6EqZl+KdLBpZbcVsb+/gfkLu9a7J6PL9wNk9H/h1pf7WwHi45EYsy0rUXh3LpaA1F7Do dVVm8G+eyyI1D5Kf17JuDBKo19qIc5WX/Uuv8afUqpuAz7LwqjxmVYbB8AdQgmWT4fgFcAgsJErc 6nrtSUn4cVOVN9qQ+sG4c5WgKorpHv519eZktjc7FJ+nXyYDTLdHBUYqoF9WX3Wx8gza2ahgbafF ShdKVXiVn5M0X8WbsgIGd85Or9/sjoRmgtKMeDrwp6O9Qns3wNGHslZAXNZtvkoYr7JXiVxuYZ5g qak2daUXTT3EpDRhNt6kaVaTx82brD4ieCMznZJiSGDhm86bHCVh9DdPJgf1WBuaHTK5UKLZpLJW 6UhUapPJBD8BgXJhykzB92KxtXNzJKIJ4KpvRa1zBYI5q3n95QaWd1NpiXIqRWNUj3mvCwZGXapK oZbkcAPcleHwcF+iSc4qt8ODyAu84QkKUkS+BkZbgRGayZMhvVUigzVAMSRNVaH2dplJgC7IQSYJ EIEJw6xadreu683Lp09vb28nWtXLSVmtnuKHp1OdjuUCFlgmsGToY4eG7ZjJfC3T8la8BjtO6rLS 6vcxYIjMZF3n2YCynJSbbaVX6xq1VYNsO54k/itcu3OyS5x7q5mXCQy4FTvTo6OjMTqrXVjnYzDg K7whrOOVMqq6UemkO1D8anN5bAXXZ/4Y9LiicSOnFoUsgWPBpIwwTbJGleCL3P3oeUil0NpQ0fnn HIQrV/hdpcD1Ah30EIncyIXOdDyaIwQkylRVbC2psn+AaqpvCSjjSvWc7aTjKL1zaOoM/I9hF2sU 66Pz0DCDWwVClYZYqrpe3lGBH3Xk83vrHr0TEhD9lw1Y4t6A9flSwtymX4DUPw/Q4NcJSCOBdxZA KzLFr26Yi9/jD+EvIHkDZCg4NGgOumCx9aTaMrevaosuFsT55Pzj/PrJiP8VHy7o89Xpf3w8uzp9 jZ/nvx6/f+8/eCr2yvmvFx/fvw6fAoWTi/Pz0w+viQhQP/7PJxwmHIEnF5fXgFuO3z/p84zuGjQH zFyjdW0q8q2w4qkyCUQInqe3pzcn49l0eiQ+z764ZW7P+louMoVahCtAUu9JZTpBS67KtKHwOvn+ 18zTmiH0TL5ieCvSh28ceAWcsz+xYBoMCszx4Vt7r0DrYCI+Qnw5kUaZh+8begVazyZeqa01f+/r WazPzyZT8ZqdhjeT76DcoTUDCPMDaB1OxFtVqAqibOxmHibhX4cxX4cwxyuFER408fQbRDz0r5dV WUPykT1ItkNrJs4lWAf836dFQWlVgZ9+HK19cXxTAhh63WwyihtA69EMdmgdiNPlUkMoLJK7Rr/7 9dzTeh70q+80HyY0iWkROZR9pskR3EBkAhDfQMJnv0nhA3x7J8MdWjOwIR8J2SdtHu01OrT2kS8O 1YT8c5VqCVHPmEcQ7NA66NAyelUAyn2c23jRpvVMvNIp4S4gBxYQIukjXh1ah6BN4HeNZpE9fH/8 6tB6Lj4itjGcQ503Wc1/zZvNw9x1aL1g9FZuwMbtapLcGENv7lf8Dq0jcQ3IPts+qEtDr0DrxQQz vAZtF1XfgO+vuPbwMBV+HXlaRxNxnHwtyttMpavvdV30CrSuXObxOyNHTOu4qddl9S9GHKcp5iLf TRNy314A5w+dMN6/7P/x8u/Ay/wxev8BiHn2RyPmFgpr/QzafH0pPh9+wRQcheIsnQS3LjEHpILR OkQG/KlS6AfByj0dctYTIHdyOeIVL/ONLFCP3Oo52iOs5ZS3sEBlTuSp2uAJlYXGBBcUyFZjOA54 ZyKOC1CZNVaIUhpPLJVKFzBBYRLI+wNPqoCQRtopVohedOLUC7WLikmpEmuNooQvmGtI9mHZizQu +VgNRagNHpZQC+S5VFDISrRasQalWihVtHE5CDZoz1znOpMVzDprOE25BfNxbHD9xWxUogEzWIxr J2Qt0BGSqfh1Mjucis/7X+jTvvh88IWDwOXp2/GB+PwsroGdcAEj29LCwJCw1kUpTA13yCoNa244 cHCVyq6R9GRWIP5CyI0FRmjY95gohw9p70LxJZOWUgr/qQPs+57KTmBQKCB3K4zZl5GTxj58JFFM R2I2OvCEQC58zQHpPBZQeGmtR9ropG7QalsFpmUlYbgRV+YcKQwmVFcC7amkvQZLUJCipUAGFzS+ L74+KorxNRNKRbsjugIP6ywqVKo2Ct5wLZ1xBN9HkTqm1+UECJhagfYkskIzLoAKknAUUr10DGgu wgb8hEYBAAiXvCwUzjMvQZN2aEJW7D6wFIX6Jj6QQpKwd/tTw9/qdcNzJE6iiTpCmqcYM1MRqrtR zl57hEG3SdQD1a03TYUyIsa76w1fFSVpGKfXUtyuS4DDi4ZzcEdjI6taIyds4CbHsvQiK5OvOJUM 4IXIZVKVi5K/2zl/tUuTVeQ6z1+FyaHkUg2MNHDfloeewBXMTVmtwHv+ZoepAVYrKk9jzCag7ugY uAiQEtqCuwzvZ2ZGeLfTmkQ5pekYmvMEI2EyCviwvLxPBde/shN5W74yu92iAqqZc46welSbpyIs 2pQzfivlAaMSUdS12opry78x2wYRBBbUyW4QfmflChykq7OjVXWmU0IGkuvfLIjhkEAuDUWebzIK nvyrN6j2xOg9rhH0lemaEUZiybDTp8oThQjDyAMjdx+8RGT8B4Brx/5umGySNSnZCUVoC630N5Az BtbS4IRzhPybLA54rMB8uSmbKiGzhxWBRApuyVT3mhpCeT4RpzIKMBTYZYsK4QOqQ8kU77bm52Ej coSiGLU8CrLOTBcQookCoi5FKYvnpKsUy6rMW2RajNAuhY+TuOvitNrpWaqWurA7EEVLx8j0WceH 9ohmiC3Yjz5qJUipIC9UoLRBRfyquPmF21jahmfo8bNir5JowEvxJgei4W0hc52QgzAqA3UzPCee saPnKoTEKnkM7QlF7z8Aq+7/hOouoPgNuF0Um1NP3G+zLrRQty1pWrmgryOwSCvjSN3qLAsqd7em AZO4Ped0HUJShS6tkxXYtUbTA6+xKR1wRKtAlwwfOYTx2mmzyWQ7xNqpOc7zErQNRHG7VpwmGQi2 YIhlAnmvjeKxwkWlXs5wEoC4lS55nqYuNz2kTu7e4qcg0Vb9Wdd8/62ETw7t3ykqK6OFWqIx6ZB8 Me/KQmmwDL5ywr921nj/XlMbwppI0XsRPyaVdQIYoFV0AUn6ladkhmCqLoYDYCVrtdpCiKK9VlpI kmEPKKAaATB2UEvgjZ4OogWCSwtVI8pzHulvEOIp9UV6CZfdpA3alkfe/PWEFBormDIGvwJVxssf NA9FVg0AnIMH/FdPnpy1JDgPeRvDHBDYBhIqSKBtfkPh1plFjfpY65XknVZIlhUgx6QOcwlZw0Mm ZxcLo1/3UlLKsERWuc0GJgBrTghSQeDBojTuHMsVz4wDLxlpVZVVcKi6wOynqBmg5DnBTtoqirCH i2hxpjEg6mf3628vSnjj0JGHb3sDCtKRd7PW0/UBJBVE8lUT7YLe5Z0gBuZKcr+EHAYksT1hJMft e+tGrBg6boRXhxE8WKl3G8y9I8U8d9YUS9lF0spHW5P7HgXqiop1NKdqQY2lJy9zL6TS3+ike4GE 21+GiM5CZRfSDwVttnBwyeEZ1nh054K0lBo8Sg2hP0g6ihvkhyxj1o9EmAW1Iscdj4UqAO7UvEYQ EnJVr0tKYUpI5k0XqrXDIxrVBgfiH6nklWuqt7tFj+TSFLXO0OOnoCFJa5Hwqo5ERpzsBvOYjbjI JOs7+UlLZSgPW0tO8VJsn7pRHJIWaqWLwipkL5jbmqDXZPB3BtG+Xm5749XYwkMZrSZo5aICWzGE Yx2j4XWAlugwPb7r5p7d5OjwO31EDPb8CvVBn1XPNoJ3OMSggYJfiY26hS7JbKl9JCqBIdm1Xq1R 0RewwBTUQHuMtrDGkaImrJgciCpD0FVgxkUu0zozVKWK9s/QyMCZy21c5YN0Q6sb1nFNWbsDHlYg JZZvIQO12z+2nhTsyBFqjDMU17nkJ4CNMRvbikQCdneTEBZtZIZih9zGab81I4oO9kpiLDLBV5Fr 9VWvUDoTS3yzvjbGpqiZ5DiDF0gb64V6c6D1BAZaeBOvRAxiahvHggGpooTFkDW2Yi1puby6WEUB pTSPpMCYyYi0ISUIPPwV/iE7rESmJC7jEPjGicr0r41hg89ARZh/tq9AjmxVcTwBMBFptCOVS4TF zh8RpYGM/QfkNwc/Ib+5DlpO8bNssjRKUnCGXT0YWZlFDk4hqOQVMKR3RVeDxqRBhVqVNUZEahCz 5hT5FzCykQ3fPqu2O6+0DiMX6QNis1aEyxZFMiyas5XixRALkT/PBhdg+CZbZ+6n4PTe66foXHVf g0RH0lNbWX5TKfWburROPNDzn7AH0UIqE0WLaLfgXmTkNd4iJL47AAPTLAyuLxVuXV4IwuCISha6 qWP3SNEowLMKogBGD/wa8M9vcVGtQN0xTY4FzCqXAVy0QAUgXOOqXpOoF5UponQ8RTeYn5TlA3QP Xb+bM1XdXcXdl3pxwb2jmStFkS84BPjjGStbIdQ3iSJFemvwlFTNd2Pl1Fi4oNvTLvy+r6ulq1Gk A7Qcb6SpP1LPal8PHlADl1B21YC+/w41gPtpH4qCE7c792Bk3aKkZJVpymDJYpoCewa46nojs8Yn PCS86JqAM1oaZfly83FZjs9+raG76+SN1Fmr2Ox2vUCbuLhIthpvynC2YzeSnEpZDQvOgjWMYRd4 /KA0I0Hdd6g19iav+6XP9tcxKeeT2E7IEJzmRw7Gb9r7VB5L4/F+is8rUAMkdqsXXAi9jWM1XLCl +rot7o3oD7h0ZdujDFap7OaoEZmsVly3wTI9e2lHKmzPOJYmGBsaQs2usmMCHiWv2luRBSzarU5r ig28HYEX2t6qGCW7xSBQTAg0VVlUc3AlcpQyRgFJYsnKYqWqEF/q7QYhaii2NpV1Kh3fO+vZ3duL VztLXZkaPoxE0eQLVV0s4Q+z+3iXHNniRlW0eQymhG0v3JCOsx6q+uIwE+GGx7XHSohN8pgXv6WG FzCcdiR8szuaSMz5nYTox0EinSyuVjAFYsn2rdIWrY+jhrdClgC4yNi5MoZ7ywdfRp6QnqgJMDe4 a7OLlAVl/4VRSUNljsColxJtW/FtpIDSlnuC+z0vK04/vG/zHoQ3kAwnbtr2nSh2J5ADWTflCP0d m6kAWza0H471+CfYIC56X1NRLMM9S0oIeFee1jPS2oIWHERIko21kN5/ACp89pNQofL9gozeV2UF epCbKMvp21QMCjmVSMUKnGkdF5ajII75tc3065p3CyS5qyjtBINa45phcbCxwCPnZcQIqArDocez 6ALXUlZjFdWWbfZhy1Y4dKHwuAL4NhgOfi1XBXtG7r1oAAfBvCQWD7xyF3RAZbjgSfju2tYB51wb vK5kqi6Wyx308N92f1+gt/Vi/B3JjcvlEsu6tyqOBq7+SCDPFiYxNnKHB3ZgAQMwFwxLdM4GMD5H mgscZH8aSJXelWALTFmXhS0FoJ82uuJGHMrS49pz5E3OQhTy6IRqapJ3KSma2dM7g06+ZVP3O/u2 7gJkF1fAzBUnMTvn8tsrTahi9xGydzrTlz6pXTcl7sBkdohxxgLzI2sJOj4RzBHyGDw2bY5751zQ bvJSTPf2cKynhlNarmzRtGhvv8OMq1o4MuhrEs62YpYYs7VpeRpYVGpHCs7t4LteeudvitI6WBVy wkOp3YDRHE5orfCEz3KLS4UzssIZWK5rripiUx/tAlNFgjokOOdzQCNaf3d5FDlao3SW4C7Rx8L2 /iQWemvRwQEFnIRBVSNWBIZXpd3SYf1qKU97jUJa1OEXjYa7Y/qb02FBg9bfkdne0UXfvmQq7muN H/Bl1+Q648K+FT+s1ZpqC6BZvptRpTaYYHEmg3mnwesrN1w4H+p7wzCSILT1ZUFW6XClIxK6yXhw LobRvhmVCRsWX0Y4eWWzJ1QA45p9PTuZ7XFvC2gmHtXvP+B40E2o2kXSaAmQBXea9LlrX4wl6nXG TzdX6KO0yYU7LiQWIM2vQYi+aRqtmMOoI4PNirfYekdNkrVtBsc7QLB5vzfhsecSBrWO338ACjr8 SSioq8xO0OFcFbg8FoMtiTSF7c2P1x3WtL8WEx5iWSbNQIsOoqNoC6tNF8GLtG3aVBQeXmmF/f3t 7tH+dQjv7aYDR0LaXPYF/qCYUYTyCgpz+AslCVRE6dB2TYOrSiYKSwxby1HUV4dY2mbo7fnHXmnE RQXFxxWwAh9vEHNtnTJRmVFjVk1bZuia7zCyrh3Hx2Me49WGbM+qBMCwrNwGGXQ9iO2+tBWCjMTq sDbWVpTPYa+BdKHRo3dCcmJPIBBgptoK0BpbPx1Yg8sKXieQFyRUxoQdDEcKk7W7PDZFH/ut8R2Z dfssTNRrxGhOrgDwrwgMlJwN3SU6FFyhslb/x0avVlt0SdYZu7hOe5l+R9aqa4V+G2btD8QM+Jp7 Tyy1L3zUWaS7tMOW/CgFsEU9rvTS9O7LDIIew4VxgoQtiqHDNN7CiQHOKEJQnpRVdQJG3cNUw27O jjhcnhwNpnqg6Nto3zVU7CERX7rejjLqm492Diw3NuWLoa9n2OZ9gFMIVfsScbejiNUxSjwjGuTU 0OHQVhd6zfggyBLPbnu6btdjHaV71EZv5DI6QYT+tonafzChqlSPTOTihuRBeeUOl0ogA1GV+7G3 l7zbzql5A63lvu4++TaA0E7abRfhNvSWCjsvrTumrIGRdoBujko4WUBFKI//effGVdMZ3M1fX8LE YE5PwfBvVTVq9S8sSjwRR0tk7AYCZ+mmm0vYHOIBpEdlq6FjIvC3UT04Sv3w0cSsEivuWlh2B++4 lntPCQbZt0zN8+TcX+n7oIeccI5blhGDUVLn63LtYXVw2tg1TI7Ue2FHxiuAZQLCTocMNZHYwVwE rW9Ld0fQyaFlAvokXdpZR+PADZumwiaQiTgOQTrjtlhvKcRBl7fEaZ9fW9/20A5Ff8w27POfADXP 7Fn7xO2sWRlkIXe34iWEjw22uFXAmhrhMjLgQU0aSL7blvQ4dbRmsywpk/JKie0tdKAIQtua2wJk 3XbQg+oZCQB0YnzHkc9Q0sXFb3PWi8u8Xcc5DparbjQbqE2WtYlxYMePHoi7juoOS+8uZOO9kV+t sL3T3aALQ7R9mO868SIMS2jZvfMwcJ/bc7eAFpKXlV5hZwUaFAomeN3oZKL0jtmRoWMydUtvAgAm V8Up9kKPY8b8yay4xm856ipm71xyfzInQ7opzBby8G9RsLLpgm0bUtLouJnJny+jYwTaxV/Mubpa 38uBHzzvPBB479MXUhPazKTibSIzZbOXQaRNxoX6Tb0P47occxNEwywNHSf4I0afz8/Fzpz78eYO /HlR8FGjNasR7wVGPTRlylvP9LApe27ou5j2NXybBotj5Oa42ArLkdf8wFBnQn43035vj6i481ec pzky3B5R45Yr90nGDYptTP3oE+zxTQ9Mt+1R2Mh0z2c6SgEZlL6rihAspqZg8meXY27pdjtn8VFr R8SzOYpON+7P9kf0z4Hts4BP5x0v2jtz319ZPEJBJ25t36A73U3WaCdT+ybQbmnAUfFZS7xt5LaL wNFjdaSgfRDbqBbjwZC44D6Gb4vHdnbwHCBULAbYyiJvTkdbidiGFznbeB3p/QfAjhc/AXb04hQg +QwCA7rM1lFLG7No1warDzU1XHZ2P0KC1C5lt0a9+0kKfS351+uL1xf/Ft/df3bCgA1JepCBsc1s mf5K/l/6+xzCyu1xe4x/ks+jx4HZWgU1sIi1yqg5uaLzXKL1YKSJuKQ2VNoqttuILUtalVzCuSoL LU5vZDF44os/hCc6DFzRe7lfpkK8qmRaYHY1h5TyCcohPAPN46fLqsQdTzEew0D8+EKx/2QUj/Dq 5FIcjfDxTQKfYTgSF0ld4v789OjocMBJz7pD/7t/ihUGkYZ7a4AcieDM7StGGhuP/h7ShcwAR8jG 9MDyMZ0CR+eyAi8EXDzvM7EPCPL64/gayPK6puzL+Dg2Pvttf3cUTnaD5VDjFz4VFaTQRJ1qQgRv BHFuIybi8EB8pa2gaPb+08HdA+/TwC/igVGFcGTGSHX7xI7wOpe0djaj0Z6Js/nF07PTE5DNwdHh ePYSbHv69DhPJ1P8OAP5n0VHlGssIZZZudqKcV+PTnzHGElibEVRLv5Kfd5j0uvZS2Afv4dFwcGC PQtxKN4R8OD5XePWFxBjgWB4cMy+uwaGR+Lv/PhA/j1ipiM7vPMN7ZjZ6wubLxKWdMqMI/HoESVm xIERJrfjF2hi+wL/uyPF6Z44/nSyO/qfmFRvZjvvPl3v0vzszXiqn6dJA3w6OX07EnDROKLydu/Z nlNddMMDaxp9fC7eTcRFXQuFQBqMiZGwO7gJ1rvUFpzhwyZsEH/jHjkRUdyB658ef7rEJ4Lyg3Xx sYv0XN2qTjZj95iK8d4BPvUR+G7ArbEGRWTwmaK8ChPxF/vMyo17VuWANbwQ1xAxmypTda1JNicg 9EbXKpf4/DmchNxmpUwRAoCS0lzYSlnU0eBz14bHvmh/dqcv8p+OgJaYJ+sm+63SkM6iS8JT0+Sd ribiDUQnfPbGV+6e+jSBQJzgc0ILy93/xgwcR89K9pt6JHwlszEFw+NwjA29lne5iAmYUvT+A1DB 0c94oqF9hOuA5mzGkB+Np1PWGacRl1YjWqrzobxR1NfFTqOv9p1B6UP/GUT9G4+LFA9atx8jfc9D oWF8MQeNqH+DaWEx3f1wBbbzShagCx/eib3nz/dCB8zluizUS7HzfH+2K472D/FJhuFpUKf4NOaX qEHAyH/Rqv5S5GAR4MY607oAoCP4udJhXP906MDj4aH4VVaVNjUmHVdoIOHlrnqbKfwtYY4/zo9F l2Hx5+l4tjcdH744Gh/u7+91Wca8v/4FwjXH/ojhaJgPqsqx7m2fOu2/bz0/GnU9iWDM9Pme+AuW z68l3FZYUccvd+Ucfn1XGrDNk2Nx9Gy6fzCGmwFo0ITiK+2k/jwVB3svxItn++LF8+lBd05Ye4AP vyTIHs2IaTz+vzAmvf8jZmqfO7pHZvp/UEsBAhQAFAAAAAgAz4vnLjgkdEGtGwAAfl0AACIAAAAA AAAAAQAgALaBAAAAAGRyYWZ0LWJhc3NvLWF2dC12aWRlb2NvbnJlcS0wMC50eHRQSwUGAAAAAAEA AQBQAAAA7RsAAAAA --0__=0ABBE7CFDFE094888f9e8a93df938690918c0ABBE7CFDFE09488-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 7 21:25:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23830 for ; Mon, 7 Jul 2003 21:25:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZhEG-0002cj-4P for avt-archive@odin.ietf.org; Mon, 07 Jul 2003 21:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h681PCTx010079 for avt-archive@odin.ietf.org; Mon, 7 Jul 2003 21:25:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZhE5-0002bz-Sr; Mon, 07 Jul 2003 21:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZhD8-0002YD-UL for avt@optimus.ietf.org; Mon, 07 Jul 2003 21:24:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23818 for ; Mon, 7 Jul 2003 21:23:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZhD6-0004zk-00 for avt@ietf.org; Mon, 07 Jul 2003 21:24:00 -0400 Received: from rumi.east.isi.edu ([65.114.168.184]) by ietf-mx with esmtp (Exim 4.12) id 19ZhD5-0004zd-00 for avt@ietf.org; Mon, 07 Jul 2003 21:23:59 -0400 Received: from rumi.east.isi.edu (localhost.east.isi.edu [127.0.0.1]) by rumi.east.isi.edu (8.12.6p2/8.12.6) with ESMTP id h681O037026371 for ; Mon, 7 Jul 2003 21:24:00 -0400 (EDT) (envelope-from ladan@rumi.east.isi.edu) Message-Id: <200307080124.h681O037026371@rumi.east.isi.edu> Reply-to: ladan@isi.edu To: avt@ietf.org Date: Mon, 07 Jul 2003 21:24:00 -0400 From: Ladan Gharai Subject: [AVT] Summary for draft-ietf-avt-uncomp-video-03 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear all: The following is a list of changes made to draft draft-ietf-avt-uncomp-video-03.txt - the tables tabulating pgroup values have been replaced by explanatory text - pgroup is not longer signaled out of band - SDP parameters color-mode and sub-sampling have been merged into a single parameter called sampling. - added text detailing relation to RFC 3497 - added BGR color sub-sampling The only remaining open issue left on the draft is: - are the values listed for the SDP colorimetry parameters sufficient? these values are: BT601-5, BT709-2, SMPTE240M thank you, Ladan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 8 03:53:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13263 for ; Tue, 8 Jul 2003 03:53:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZnHh-00038w-NO for avt-archive@odin.ietf.org; Tue, 08 Jul 2003 03:53:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h687r9CM012083 for avt-archive@odin.ietf.org; Tue, 8 Jul 2003 03:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZnHa-00038H-4D; Tue, 08 Jul 2003 03:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZnHY-000385-QJ for avt@optimus.ietf.org; Tue, 08 Jul 2003 03:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13252 for ; Tue, 8 Jul 2003 03:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZnHW-0007Ji-00 for avt@ietf.org; Tue, 08 Jul 2003 03:52:58 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx with esmtp (Exim 4.12) id 19ZnHV-0007Jf-00 for avt@ietf.org; Tue, 08 Jul 2003 03:52:57 -0400 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19ZnHW-0001D1-00 for avt@ietf.org; Tue, 08 Jul 2003 09:52:58 +0200 Received: from [217.187.176.216] (helo=MAX) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19ZnHW-0008Kv-00 for avt@ietf.org; Tue, 08 Jul 2003 09:52:58 +0200 From: "Claudio Thomas" To: Date: Tue, 8 Jul 2003 09:54:58 +0200 Message-ID: <000c01c34526$3ae13f60$1e0ba8c0@kako.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C34536.FE6A0F60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: [AVT] possible error on testvectors of draft "draft-ietf-avt-srtp-08.txt" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C34536.FE6A0F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actual link: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-08.txt =20 Chapter B.1 AES-f8 Test Vectors (page 52) =20 Position: j=3D2 =20 IV' XOR j : 595b699bbd3bc0df26062093c1ad8f70 Should be IV' XOR j : 595b699bbd3bc0df26062093c1ad8f71 =20 Reason: Last byte of IV' =3D 73, j=3D02: 73 xor 02 =3D 71 (0011 xor 0010 =3D = 0001) =20 If my calculator is right, then the values after this position also = can't be correct. =20 Do someone have already implemented it to give me working vextors? Or = can somebody explain me what is wrong on my calc? =20 Thanks, =20 Claudio =20 =20 ------=_NextPart_000_000D_01C34536.FE6A0F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actual = link: <= span lang=3DEN-GB>http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-08.t= xt

 

Chapter B.1 AES-f8 Test Vectors (page 52)

 

Position: j=3D2

 

IV' = XOR j : 595b699bbd3bc0df26062093c1ad8f70

Should = be

IV' = XOR j : 595b699bbd3bc0df26062093c1ad8f71

 

Reason:

Last = byte of IV' =3D 73, j=3D02:  73 xor 02 =3D 71 (0011 xor 0010 =3D = 0001)

 

If my = calculator is right, then the values after this position also can't be = correct.

 

Do = someone have already implemented it to give me working vextors? Or can somebody = explain me what is wrong on my calc?

 

Thanks,

 

Claudio

 

 

------=_NextPart_000_000D_01C34536.FE6A0F60-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 8 04:03:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13421 for ; Tue, 8 Jul 2003 04:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZnRG-0003bn-H7 for avt-archive@odin.ietf.org; Tue, 08 Jul 2003 04:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68832pd013872 for avt-archive@odin.ietf.org; Tue, 8 Jul 2003 04:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZnRF-0003b9-LK; Tue, 08 Jul 2003 04:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZnQu-0003ah-1f for avt@optimus.ietf.org; Tue, 08 Jul 2003 04:02:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13397 for ; Tue, 8 Jul 2003 04:02:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZnQr-0007MP-00 for avt@ietf.org; Tue, 08 Jul 2003 04:02:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ZnQq-0007MM-00 for avt@ietf.org; Tue, 08 Jul 2003 04:02:36 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6882UGJ007695; Tue, 8 Jul 2003 10:02:30 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW4V3515; Tue, 8 Jul 2003 10:02:30 +0200 Message-ID: <3F0A7A95.6060309@ericsson.com> Date: Tue, 08 Jul 2003 10:02:29 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philkerr@elec.gla.ac.uk CC: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna References: <1057605874.3f09c8f261862@dlana.elec.gla.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Phil, I spent sometime yesterday to read your draft. I have a number of comments that needs to be addressed in the next version of the draft. 1. Section 2.1, Padding bit definition. I don't understand why it is required to use the Padding if one is below the MTU, we should not waste bandwidth unnecessary. I would suggest that the last sentence be removed and replaced with something like: "Padding MAY be used with this payload format according to section x.x of [RFC1889]." 2. Section 2.1, Extension bit. Please don't redefine the extension bit or other fields in the RTP header. An informative sentence or two is fine, however please just say that extension header (field) MAY be used according to RFC 1889. This comment is valid also for CSRC count. 3. Section 2.1, Marker bit. I think that better language in this explanation would make it easier to understand. Suggestion: "Always set to 0, as audio silence suppression is not used by the Vorbis codec." 4. Section 2.1, Timestamp. How many different rates does Vorbis use? Will multiple rates be used in the same session requiring multiple payload types to be defined for this? As RTP has some problem with switching rate within a session, would it possible to use a common denominatior rate for different rates and convey the information somewhere else? 5. Section 2.2, I think this payload header section is coming to early. I would suggest that a new section is created before the current 2.2 to explain the capabilities and basic structure of the payload format. When I read it I asked myself a lot of question that was answered on the following pages. I would suggest that you explain the single packet, fragmentation and aggregation type of packets. 6. Section 2.2: Last paragraph of page 4: "If C is set to one, this number SHOULD be be 0." Based on the following text this is a MUST, or otherwise you must define how one can include fragments and other packets. 7. Section 2.3: Third paragraph, page 5: The limitation that a Vorbis packet shall not be larger than 64k bytes. What about IPv6 Jumbograms and the fragmentation process? It seem possible to have larger packets although it would be a bad idea. 8. Section 2.3, fifth paragraph: Why it the length field only a single byte? In some use cases it seems that having aggregation only for packets smaller than 256 bytes may be limiting. Have you studied what the frequency different packets are created. If you have a lot of packets in the size of 257-500 bytes they may be advantageous to be able to aggregate. 9. Section 2.3, sixth paragraph: Please clarify that the packet length is counted in octets. 10. Section 2.3: How does one perform RTP TS recovery for the individual Vorbis packets in an aggregated packet? Are the RTP TS not needed or are there some implicit method. Please clarify. 11. Path MTU. I think that you should have a separate chapter on Path MTU discovery advice. I would also try to not write 1500 bytes as a common size. However, it might be common, the restraining of thinking is maybe one of the restricting factor that have prevented the usage of larger MTUs. I would recommend you to look at RFC 1191, and RFC1981. It would also be useful to make informative reference to the work in the newly formed PMTUD WG, a proposal draft does exist "draft-mathis-plpmtud-00.txt". 12. Section 3, Some parts of this section should be moved to before 2.2. 13. Section 3, first paragraph: This contradicts the SHOULD in section 2.2. regarding fragmentation. 14. Section 3, third paragraph: This section is mentioning final fragment (F) which is not consistent with the field name in section 2.2. 15. Section 3: The fragmentation rules are lacking. To make the fragmentation proposal work you need to require that all fragments are sent in consecutive RTP packets. And that this schemes does not allow recovery of the fragment unless all packets belonging to the fragment arrives. The TS requirement is not enough, it is the RTP sequence number you must rely on for recovery. 16. Section 3.2: I think it is important to be clear that receiver dropped packets should not be counted or reported as lost in the RTCP statistics. IF one uses congestion control as one should based on RTCP reports the receiver side dropped packets will be counted as lost in the network and as being victim of congestion, that way resulting in reduction of rate. I would also not be so fast to recommend dropping. I would rather say that a receiver should buffer packets (reordering, jitter), and MUST not use unless all fragments arrive. 17. Section 4.1: Use of RTCP padding flag. This MAY be used but has no reason that it is required to use. I don't understand the reference to section 6.6 of RFC1889. Please review padding in RTP specification. 18. Section 4.1: Second paragraph. "VORB RTCP packets MUST be sent just ahead of the change ...". I have two comments about the sentence, first this can't be a MUST as it isn't possible to enforce and guarantee, so make it a SHOULD. Secondly, the "just ahead of" is very hard to understand what it really means. I thing that having a sentence saying that the RTCP packet SHOULD be sent ahead of the change is good. Then further motivate that it is crucial that it arrives before the change. 19. Section 4.1, Second paragraph, The last MUST in the paragraph is also one of this that can't be enforced by sender behaviour. Make it a SHOULD. 20. Section 4.1, If these codebooks, necessary information is so crucial why not use an ACK packet to ACK when it has been received. This way the sender can utilize the RTCP bandwidth as efficient as possible. I would implement it using another SUBtype of the VORB APP packet. 21. Section 4.1, how to utilize the subtype in this APP packet is not defined. 22. Section 4.1 Why have have flags for the different parts when you are required to send all of the fields? 23. Section 4.1, the o flag: I think this flag need more explanation. Also further information on how to handle the situation when the APP packet brings the RTCP packet over the MTU. 24. Section 4.1 Second last paragraph on page 10: "This setup information ... " what does setup information refer to. I don't think this is an explained term. 25. Section 4.1, First paragraph, page 11: First sentence say that a receiver failing to receive the code book should obtain it from SDP. Is this a mistake, or simply lacking explanation on how that would work? 26. Section 4.1, Second paragraph page 11: "This message MUST be sent ..." Why have flags if this MUST exist, secondly why having the enforcement of including a empty header, when it does not contain any information? 27. Section 4.1, what is one expected to use the URI and what types of URIs is allowed? 28. Section 4.2, Codebook caching needs more explanation. 29. Section 5: The usage of "u=", I don't think it is appropriate to use "u=" to include an URI to the codebooks and other stream information. 30. Section 5: The usage of "c=", The Vorbis payload format can't redefine the usage of "c=" field or require it to be used. SIP use the field to declare the receiver address, while RTSP does not use it at all. 31. Section 5.1, I think that all Vorbis specific SDP attributes should be sent in the a=fmtp line and be declared as required MIME parameters if they always must be present. Why are there no parameter for the codebook itself? Also an URI to this information could be included here. However the implications that a client must follow a link to fetch this information must be further explained. 32. Section 6, MIME registration: Parameters optional and required seems to exist and needs to be defined properly. 33. Section 6, Reference to RFCXXXX and a RFC-editor note to ask him to replace the number with the specifications assigned RFC number, is how one usually solves the references in the MIME registration. 34. If this becomes a WG draft AVT needs to be added to the Change control section. 35. IPR statement section is missing, please review ID-Nits. http://www.ietf.org/ID-nits.html This was my comment for this revision. There are a number of serious shortcomings that needs to be addressed. See further comments to your open issues below. philkerr@elec.gla.ac.uk wrote: > Dear all, > > Last month (11th June) an -02 update to draft-kerr-avt-vorbis-rtp was announced > on the AVT list and a slot in Vienna has been booked for discussion. > > The draft details the RTP delivery of Vorbis audio, SDP values and delivery of > the decoders static probability model, 'codebooks'. Examples of Vorbis frame > packing and fragmented packet handling are also covered. > > Open issues: > > Congestion control. Under development is a mechanism for dynamic bitrate > reduction called 'bitrate peeling'. When this feature becomes available it will > impact on how congestion is dealt with and a mechanism allowing its use within a > multicast environment needs to be explored. I think we also need to consider the IAB's statement about congestion control in this draft. However you can separate the congestion control issues for multicast and unicast. The unicast issue must be solved. > > Codebook delivery. There are two mechanisms outlined for the delivery of the > codebooks, SDP and RTCP. The codebooks may change mid-stream (at the boundary > between two tracks) as well as being static for the session lifetime. As the > codebooks are needed for the successful decoding of the Vorbis stream a reliable > mechanism to handle their delivery of mid-session codebook changes should be > investigated (TCP over RTP?) in preference to using RTCP messages. I think there is in fact a third alternative hinted, which is out of band fetching using HTTP, etc. I also think one should consider sessions where RTP with retransmission is used. This can ensure that a client reports if it does receive all fragments of the the code books. I also think that more clear guidelines that having a session long static book is to be preferred. > > Path MTU. There is a mechanism for splitting large Vorbis frames across > multiple RTP packets but a reliable mechanism for path-MTU discovery needs to be > outlined to prevent packet fragmentation not dealt with by the above. > I think that you can lean on the already, not functioning so well methods, plus the newly initiated work on MTU discovery. I think simply having more information on where to go to find solutions is appropriate for this document. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 8 05:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16030 for ; Tue, 8 Jul 2003 05:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zp3x-0008P7-Va for avt-archive@odin.ietf.org; Tue, 08 Jul 2003 05:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h689l5Ne032289 for avt-archive@odin.ietf.org; Tue, 8 Jul 2003 05:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zp3t-0008OE-5C; Tue, 08 Jul 2003 05:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZoyF-0008Gd-US for avt@optimus.ietf.org; Tue, 08 Jul 2003 05:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15927 for ; Tue, 8 Jul 2003 05:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoyC-0000Fd-00 for avt@ietf.org; Tue, 08 Jul 2003 05:41:08 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19ZoyB-0000Fa-00 for avt@ietf.org; Tue, 08 Jul 2003 05:41:07 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h689f8GJ003749; Tue, 8 Jul 2003 11:41:08 +0200 (MEST) Received: from ericsson.com (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8X2Y3BB; Tue, 8 Jul 2003 11:41:08 +0200 Message-ID: <3F0A91B2.7010701@ericsson.com> Date: Tue, 08 Jul 2003 11:41:06 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Thomas CC: avt@ietf.org Subject: Re: [AVT] possible error on testvectors of draft "draft-ietf-avt-srtp-08.txt" References: <000c01c34526$3ae13f60$1e0ba8c0@kako.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Claudio, Your observation appears correct. Unfortunately, the person coding our f8 test code is on vacation, so it will take some time before we can explain what the actual error is. (A *hypothesis* is that our code has side-effects on the variable IV', so that IV' is not kept fixed, but rather updated "by accident".) Thanks for being observant, we will get back as soon as we can. /Mats Claudio Thomas wrote: > Actual link: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-08.txt > > > > Chapter B.1 AES-f8 Test Vectors (page 52) > > > > Position: j=2 > > > > IV' XOR j : 595b699bbd3bc0df26062093c1ad8f70 > > Should be > > IV' XOR j : 595b699bbd3bc0df26062093c1ad8f71 > > > > Reason: > > Last byte of IV' = 73, j=02: 73 xor 02 = 71 (0011 xor 0010 = 0001) > > > > If my calculator is right, then the values after this position also can't be correct. > > > > Do someone have already implemented it to give me working vextors? Or can somebody explain me what is wrong on my calc? > > > > Thanks, > > > > Claudio > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 8 07:59:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18469 for ; Tue, 8 Jul 2003 07:59:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zr7k-0005TY-4P for avt-archive@odin.ietf.org; Tue, 08 Jul 2003 07:59:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Bx8uR021042 for avt-archive@odin.ietf.org; Tue, 8 Jul 2003 07:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zr7d-0005SB-Hl; Tue, 08 Jul 2003 07:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zr7C-0005RF-GT for avt@optimus.ietf.org; Tue, 08 Jul 2003 07:58:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18388 for ; Tue, 8 Jul 2003 07:58:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zr7B-0000wM-00 for avt@ietf.org; Tue, 08 Jul 2003 07:58:33 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19Zr7B-0000wJ-00 for avt@ietf.org; Tue, 08 Jul 2003 07:58:33 -0400 thread-index: AcNFSBaYx4hO+mGfTDSgtZcr9av/mw== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 13:57:21 +0200 From: "Jose Rey" Content-Class: urn:content-classes:message Priority: normal To: "John Lazzaro" Cc: Subject: RE: [AVT] Summary of 3GPP timed text draft Date: Tue, 8 Jul 2003 13:57:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200307071955.h67JtiA21422@snap.CS.Berkeley.EDU> X-OriginalArrivalTime: 08 Jul 2003 11:57:21.0541 (UTC) FILETIME=[16963350:01C34548] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA18389 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi John, thanks for the comments. Please see below. > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of John > Lazzaro > Sent: Monday, July 07, 2003 9:56 PM > To: avt@ietf.org > Subject: Re: [AVT] Summary of 3GPP timed text draft > > > > > "Jose Rey" writes: > > > > The open issues/TODO list includes: > > > > - resilient transport: repetition, fragmentation, > retransmission, FEC > > (other?). It is our opinion that repetition should be > included at the > > very least. > > Is RTCP expected to be normally used with this payload format? Not necessarily. Yes for unicast, but there's no plan to use RTCP feedback in a first stage of the MBMS Service, that's why repetition is important as a base mechanism. cheers, Jos=E9 > If so, > maybe the core idea behind the RTP MIDI resiliency -- a > "recovery journal" > in every packet coding the recent past, whose contents grow and shrink > as the sender examines RTCP RR reports which indicate the highest > sequence number the receiver has received -- could be the starting > point of a timed text resiliency scheme. For the default 5 second > RTCP sending rate, and text that is not sent too frequently, one > could imagine a recovery journal approach would be more efficient > that simple repetition. But you need RTCP to make it work ... > > -------------------------------------------------------------- > ----------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- > UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu > www.cs.berkeley.edu/~lazzaro > -------------------------------------------------------------- > ----------- > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 8 11:03:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25475 for ; Tue, 8 Jul 2003 11:03:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztzs-00075f-2v for avt-archive@odin.ietf.org; Tue, 08 Jul 2003 11:03:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68F3CO4027249 for avt-archive@odin.ietf.org; Tue, 8 Jul 2003 11:03:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztzh-00074p-6N; Tue, 08 Jul 2003 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztyq-000748-DL for avt@optimus.ietf.org; Tue, 08 Jul 2003 11:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25434; Tue, 8 Jul 2003 11:02:02 -0400 (EDT) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ztym-0002MB-00; Tue, 08 Jul 2003 11:02:04 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19Ztyk-0002M8-00; Tue, 08 Jul 2003 11:02:02 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 81FE35A861; Tue, 8 Jul 2003 17:01:56 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA18458; Tue, 8 Jul 2003 17:01:55 +0200 (MET DST) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id RAA09216; Tue, 8 Jul 2003 17:01:54 +0200 (MEST) To: John Lazzaro Cc: avt@ietf.org, avt-admin@ietf.org Subject: Re: [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 8 Jul 2003 17:00:29 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 08/07/2003 17:00:33, Serialize complete at 08/07/2003 17:00:33 Content-Type: multipart/alternative; boundary="=_alternative 005290E3C1256D5D_=" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005290E3C1256D5D_= Content-Type: text/plain; charset="us-ascii" Hello John, Thanks for commenting. > Do "MPEG-4 scripts" give the script control over audio volume of the > presentation, in a way that could override the levels manually set > by the human listening to the decoder? In my understanding, MPEG-4 only provides the capability to control the presence of audio objects (streams) in a scene, hence the audio level can be controlled from zero up to a certain "nominal" level. MPEG-4 does not provide the capability to control the volume level at which the user "enjoys" the scene. In other words, in my understanding the problem that you mention does not exist in MPEG-4. Best regards, Jan John Lazzaro Sent by: avt-admin@ietf.org 2003-07-07 09:33 PM To: avt@ietf.org cc: (bcc: Jan vanderMeer/EHV/CE/PHILIPS) Subject: [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments Classification: > jan.vandermeer@philips.com writes: > > As far as I understand these constraints do not allow dangerous ECMA > script constructs, which means there is no need for an ECMA script > security model in this context. Below I attached the MPEG-4 annex that > describes the differences. Do "MPEG-4 scripts" give the script control over audio volume of the presentation, in a way that could override the levels manually set by the human listening to the decoder? A rogue program that blows out the speakers of the victim's terminal seems like a security risk of some sort, although not of the classical kind since data and CPU and network are not compromised ... if this is an actual risk, might be worth warning implementors in the Security Considerations section ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt --=_alternative 005290E3C1256D5D_= Content-Type: text/html; charset="us-ascii"
Hello John,

Thanks for commenting.

> Do "MPEG-4 scripts" give the script control over audio volume of the  
> presentation, in a way that could override the levels manually set
> by the human listening to the decoder?
In my understanding, MPEG-4 only provides the capability to control the presence of audio objects (streams) in a scene, hence the audio level can be controlled from zero up to a certain "nominal" level. MPEG-4 does not provide the capability to control the volume level at which the user "enjoys" the scene. In other words, in my understanding the problem that you mention does not exist in MPEG-4.

Best regards,

Jan







John Lazzaro <lazzaro@CS.Berkeley.EDU>

Sent by:
avt-admin@ietf.org

2003-07-07 09:33 PM

       
        To:        avt@ietf.org
        cc:        (bcc: Jan vanderMeer/EHV/CE/PHILIPS)
        Subject:        [AVT] Re: IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss Comments

        Classification:        





>  jan.vandermeer@philips.com writes:
>
> As far as I understand these constraints do not allow dangerous ECMA
> script constructs, which means there is no need for an ECMA script
> security model in this context. Below I attached the MPEG-4 annex that
> describes the differences.

Do "MPEG-4 scripts" give the script control over audio volume of the  
presentation, in a way that could override the levels manually set
by the human listening to the decoder?  A rogue program that blows
out the speakers of the victim's terminal seems like a security
risk of some sort, although not of the classical kind since data
and CPU and network are not compromised ... if this is an actual
risk, might be worth warning implementors in the Security
Considerations section ...

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--=_alternative 005290E3C1256D5D_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 8 15:52:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07640 for ; Tue, 8 Jul 2003 15:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZyVU-0000x6-W8 for avt-archive@odin.ietf.org; Tue, 08 Jul 2003 15:52:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Jq801003654 for avt-archive@odin.ietf.org; Tue, 8 Jul 2003 15:52:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZyVN-0000wM-5V; Tue, 08 Jul 2003 15:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZyUs-0000w0-QI for avt@optimus.ietf.org; Tue, 08 Jul 2003 15:51:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07627 for ; Tue, 8 Jul 2003 15:51:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZyUr-0005Xe-00 for avt@ietf.org; Tue, 08 Jul 2003 15:51:29 -0400 Received: from anice-205-1-12-243.w81-249.abo.wanadoo.fr ([81.249.9.243] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19ZyUp-0005XX-00 for avt@ietf.org; Tue, 08 Jul 2003 15:51:28 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h68JpO5e003853; Tue, 8 Jul 2003 15:51:25 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Tue, 8 Jul 2003 19:27:30 +0200 From: Colin Perkins To: "Edwards, Eric" Cc: avt@ietf.org, casner@acm.org, magnus.westerlund@ericsson.com Message-Id: <20030708192730.6ea0d380.csp@csperkins.org> In-Reply-To: <0DE752C748D0D211A6BE0090272B960B07848609@us-sj-xmsg-2.am.sony.com> References: <0DE752C748D0D211A6BE0090272B960B07848609@us-sj-xmsg-2.am.sony.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: draft-ietf-avt-rtp-jpeg2000-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eric, --> "Edwards, Eric" writes: > The Internet-Draft - draft-ietf-avt-rtp-jpeg2000-03.txt - has been > posted. > > Some time passed before this version was submitted. Most of the time was > spent discussing if potential reconciliation with work that was taking > place in ISO/IEC JTC1 SC 29 WG 01 (JPEG) was in order. After lengthy > discussions it was agreed by the experts in WG 01 that there were > different goals and application areas targeted for our respective work > and that the JP2/RTP proposal (draft-ietf-avt-rtp-jpeg2000-03.txt) should > move forward in IETF as is. > > So at this stage we are ready to move to Last Call if the AVT experts > have no objections to the current draft. > > Please advise and comment. I have a number of comments with regards to this draft: - Section 5.1 seems to imply that JPEG 2000 error resilience markers are only used with non-intelligent packetization. Is this correct? Are the error resilience markers not useful if the JPEG stream is intelligently packetized? - Is non-intelligent packetization a requirement? The situations where it will be useful seem very limited. - The extension mechanism in Section 8 is not used. I suggest removing it and marking the X bit in the payload header as "reserved". - The second paragraph of Section 9 is not appropriate, since the payload format cannot specify the type of video content to be transported. Are there no ways in which a malicious sender can disrupt the receiver? - In addition to the MIME type registration, the draft should include a description of how the MIME type is mapped to SDP (Section 8.2 of the H.264 payload format is a good example). - Section 10 may be better written as an informative appendix? - It may be useful to include some examples, showing the complete packets with all headers and data (including the RTP headers). I would also urge a careful proof-reading of the draft for both quality of English, clarity of specification, and appropriate use of the requirements language in RFC 2119. -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 02:39:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20202 for ; Wed, 9 Jul 2003 02:39:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8bl-0005oM-GM for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 02:39:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h696dHbU022334 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 02:39:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8bV-0005ms-4f; Wed, 09 Jul 2003 02:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a2Ru-0001bP-Np for avt@optimus.ietf.org; Tue, 08 Jul 2003 20:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16378; Tue, 8 Jul 2003 20:04:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a2Rs-0001f9-00; Tue, 08 Jul 2003 20:04:40 -0400 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 19a2Rr-0001eL-00; Tue, 08 Jul 2003 20:04:39 -0400 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Jul 2003 17:03:51 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 17:03:51 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jul 2003 17:03:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Jul 2003 17:03:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 8 Jul 2003 17:03:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Requirements draft on video control Date: Tue, 8 Jul 2003 17:03:29 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A3474A@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] Requirements draft on video control Thread-Index: AcNEz9VQ6y2SEFg1QmuFNQm9pmX67wA1yBiA From: "Gary Sullivan" To: "Andrea Basso" , , , Cc: , , , , "Orit Levin" , "Roni Even" , X-OriginalArrivalTime: 09 Jul 2003 00:03:49.0718 (UTC) FILETIME=[932A2F60:01C345AD] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Much of the content of this ID will look familiar to those with experience with ITU-T systems control specifications (such as H.245). Some of it seems like it could use a bit of updating in that regard (e.g., videofastupdateGOB). Draft Recommendation H.241 is one good place to look for such information. Section 3 is a bit confused in its terminology. For example it seems to say that intra frames are also known as inter frames, which is definitely not the case. It mixes the terms "predictive" and "prediction" and seems to consider a "reference" frame to be synonymous with an intra frame. The terms "picture" and "frame" are also kind of mixed up. A more consistent terminology would be as follows: An intra picture is a picture that can be decoded without first decoding any other picture. A predicted (or non-intra) picture is a picture that may require data from one or more previously-decoded pictures in order to be properly decoded. A reference picture is a picture that is stored in the decoder for use as a reference in the decoding process of some subsequent picture in the bitstream. A non-reference picture is a picture that is not used as a reference for the decoding process of any other picture in the bitstream. The concepts of intra versus non-Intra and reference versus non-reference are independent. A particular picture can (in general) be any one of the four types (intra reference, non-intra reference, intra non-reference, non-intra non-reference). A "fast update", also known as an "instantaneous decoder refresh", involves sending an intra picture and thereafter refraining from using any picture sent prior to that intra picture as a reference for the decoding process of any subsequent picture sent in the stream. In particular it is worth noting that some concepts that applied to some older codecs are not really valid in general and should be avoided (e.g., that a non-reference picture is called a B picture or that an intra picture is the same thing as a fast update or that an intra picture is always a reference picture). The characterization of a "slice" or "GOB" as being a "stripe" is not really quite right. For example, a single slice in MPEG-1, H.263 Annex O, or MPEG-4 can consist of a few macroblocks at the right edge of one row and a few macroblocks at the left edge of the next row (i.e., two distinct rectangular regions quite far apart from each other in the picture can be in a single slice). A GOB in H.261 CIF consists of THREE partial rows of macroblocks extending only halfway across a picture. And in H.264/AVC, a slice can be ANY collection of macroblocks scattered around absolutely anywhere in the picture (by use of a feature known as a "slice group map"). In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known as MPEG-2 Video) also supports a freeze picture release within the ITU-T extension. It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC. Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On=20 +> Behalf Of Andrea Basso +> Sent: Monday, July 07, 2003 2:34 PM +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> Cc: casner@acm.org; jo@tzi.uni-bremen.de;=20 +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit=20 +> Levin; Roni Even; nismail@cisco.com +> Subject: [AVT] Requirements draft on video control +>=20 +>=20 +> Attached you will find draft-basso-avt-videoconreq-00.txt +>=20 +> Abstract: +>=20 +> A variety of communication services such as video +> conferencing and video messaging rely on the capability of video +> encoders and decoders to exchange control commands. This document +> outlines this set of commands as well as the requirements for +> their transport. +>=20 +> Comments are more than welcome. +>=20 +>=20 +>=20 +>=20 +>=20 +> Andrea Basso +> NMS Communications +> (732) 936-2118 +> (See attached file: draft-basso-avt-videoconreq-00.zip) +>=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 02:39:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20219 for ; Wed, 9 Jul 2003 02:39:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8bw-0005pE-HI for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 02:39:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h696dS3j022386 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 02:39:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a8bV-0005n0-M6; Wed, 09 Jul 2003 02:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a7n5-0007up-W4 for avt@optimus.ietf.org; Wed, 09 Jul 2003 01:46:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22922; Wed, 9 Jul 2003 01:46:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a7n2-0003kJ-00; Wed, 09 Jul 2003 01:46:52 -0400 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 19a7n1-0003k8-00; Wed, 09 Jul 2003 01:46:51 -0400 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id <31W6KGSH>; Wed, 9 Jul 2003 08:46:24 +0300 Message-ID: From: "Even, Roni" To: "'Gary Sullivan'" , Andrea Basso , avt@ietf.org, avt-admin@ietf.org, mmusic@ietf.org Cc: casner@acm.org, jo@tzi.uni-bremen.de, magnus.westerlund@ericsson.com, csp@csperkins.org, Orit Levin , "Even, Roni" , nismail@cisco.com Subject: RE: [AVT] Requirements draft on video control Date: Wed, 9 Jul 2003 08:46:19 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Gary About "It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC." In case of a video switch in a multipoint conference there is a need to get a new recovery point since the decoder will receive a stream without a previous recovery point. The procedure in H.241 allows for either a full picture at once or gradual recovery based on an SEI recovery point message. Both method are fine as an encoder response to a fast update request. Regards Roni Even -----Original Message----- From: Gary Sullivan [mailto:garysull@windows.microsoft.com] Sent: Wednesday, July 09, 2003 3:03 AM To: Andrea Basso; avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org Cc: casner@acm.org; jo@tzi.uni-bremen.de; magnus.westerlund@ericsson.com; csp@csperkins.org; Orit Levin; Roni Even; nismail@cisco.com Subject: RE: [AVT] Requirements draft on video control Much of the content of this ID will look familiar to those with experience with ITU-T systems control specifications (such as H.245). Some of it seems like it could use a bit of updating in that regard (e.g., videofastupdateGOB). Draft Recommendation H.241 is one good place to look for such information. Section 3 is a bit confused in its terminology. For example it seems to say that intra frames are also known as inter frames, which is definitely not the case. It mixes the terms "predictive" and "prediction" and seems to consider a "reference" frame to be synonymous with an intra frame. The terms "picture" and "frame" are also kind of mixed up. A more consistent terminology would be as follows: An intra picture is a picture that can be decoded without first decoding any other picture. A predicted (or non-intra) picture is a picture that may require data from one or more previously-decoded pictures in order to be properly decoded. A reference picture is a picture that is stored in the decoder for use as a reference in the decoding process of some subsequent picture in the bitstream. A non-reference picture is a picture that is not used as a reference for the decoding process of any other picture in the bitstream. The concepts of intra versus non-Intra and reference versus non-reference are independent. A particular picture can (in general) be any one of the four types (intra reference, non-intra reference, intra non-reference, non-intra non-reference). A "fast update", also known as an "instantaneous decoder refresh", involves sending an intra picture and thereafter refraining from using any picture sent prior to that intra picture as a reference for the decoding process of any subsequent picture sent in the stream. In particular it is worth noting that some concepts that applied to some older codecs are not really valid in general and should be avoided (e.g., that a non-reference picture is called a B picture or that an intra picture is the same thing as a fast update or that an intra picture is always a reference picture). The characterization of a "slice" or "GOB" as being a "stripe" is not really quite right. For example, a single slice in MPEG-1, H.263 Annex O, or MPEG-4 can consist of a few macroblocks at the right edge of one row and a few macroblocks at the left edge of the next row (i.e., two distinct rectangular regions quite far apart from each other in the picture can be in a single slice). A GOB in H.261 CIF consists of THREE partial rows of macroblocks extending only halfway across a picture. And in H.264/AVC, a slice can be ANY collection of macroblocks scattered around absolutely anywhere in the picture (by use of a feature known as a "slice group map"). In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known as MPEG-2 Video) also supports a freeze picture release within the ITU-T extension. It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC. Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On +> Behalf Of Andrea Basso +> Sent: Monday, July 07, 2003 2:34 PM +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit +> Levin; Roni Even; nismail@cisco.com +> Subject: [AVT] Requirements draft on video control +> +> +> Attached you will find draft-basso-avt-videoconreq-00.txt +> +> Abstract: +> +> A variety of communication services such as video +> conferencing and video messaging rely on the capability of video +> encoders and decoders to exchange control commands. This document +> outlines this set of commands as well as the requirements for +> their transport. +> +> Comments are more than welcome. +> +> +> +> +> +> Andrea Basso +> NMS Communications +> (732) 936-2118 +> (See attached file: draft-basso-avt-videoconreq-00.zip) +> _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 04:54:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24468 for ; Wed, 9 Jul 2003 04:54:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAiM-0000xt-Gr for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 04:54:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h698sEUc003710 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 04:54:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAiA-0000x1-MR; Wed, 09 Jul 2003 04:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aAi1-0000t1-Kf for avt@optimus.ietf.org; Wed, 09 Jul 2003 04:53:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24442 for ; Wed, 9 Jul 2003 04:53:50 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aAhy-0005C0-00 for avt@ietf.org; Wed, 09 Jul 2003 04:53:50 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19aAhx-0005Bx-00 for avt@ietf.org; Wed, 09 Jul 2003 04:53:49 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19aAhv-0000yb-00; Wed, 09 Jul 2003 09:53:47 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Wed, 9 Jul 2003 09:53:47 +0100 Message-ID: <1057740827.3f0bd81bac368@dlana.elec.gla.ac.uk> Date: Wed, 9 Jul 2003 09:53:47 +0100 To: Magnus Westerlund Cc: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna References: <1057605874.3f09c8f261862@dlana.elec.gla.ac.uk> <3F0A7A95.6060309@ericsson.com> In-Reply-To: <3F0A7A95.6060309@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Magnus, Thanks for a comprehensive review, comments in-line. Quoting Magnus Westerlund : > Hi Phil, > > I spent sometime yesterday to read your draft. I have a number of > comments that needs to be addressed in the next version of the draft. > > 1. Section 2.1, Padding bit definition. I don't understand why it is > required to use the Padding if one is below the MTU, we should not waste > bandwidth unnecessary. I would suggest that the last sentence be removed > and replaced with something like: "Padding MAY be used with this payload > format according to section x.x of [RFC1889]." Agreed. > > 2. Section 2.1, Extension bit. Please don't redefine the extension bit > or other fields in the RTP header. An informative sentence or two is > fine, however please just say that extension header (field) MAY be used > according to RFC 1889. This comment is valid also for CSRC count. > > 3. Section 2.1, Marker bit. I think that better language in this > explanation would make it easier to understand. Suggestion: "Always set > to 0, as audio silence suppression is not used by the Vorbis codec." Agreed. > > 4. Section 2.1, Timestamp. How many different rates does Vorbis use? > Will multiple rates be used in the same session requiring multiple > payload types to be defined for this? As RTP has some problem with > switching rate within a session, would it possible to use a common > denominatior rate for different rates and convey the information > somewhere else? > > 5. Section 2.2, I think this payload header section is coming to early. > I would suggest that a new section is created before the current 2.2 to > explain the capabilities and basic structure of the payload format. When > I read it I asked myself a lot of question that was answered on the > following pages. I would suggest that you explain the single packet, > fragmentation and aggregation type of packets. Agreed. Section 2.0 should be expanded to outline the basic packet structure. This will make section 2.2 clearer. > > 6. Section 2.2: Last paragraph of page 4: "If C is set to one, this > number SHOULD be be 0." Based on the following text this is a MUST, or > otherwise you must define how one can include fragments and other packets. Yes, this should be a MUST. > > 7. Section 2.3: Third paragraph, page 5: The limitation that a Vorbis > packet shall not be larger than 64k bytes. What about IPv6 Jumbograms > and the fragmentation process? It seem possible to have larger packets > although it would be a bad idea. The codebooks can be far greater than 64k in size but a limit was imposed to allow it to be transported inside a RTCP packet and to reduce the delay a client may have in waiting for a large codebook to be received. Perhaps a note detailing that transport over IPv6 allows greater packet size would cover this scenario. > > 8. Section 2.3, fifth paragraph: Why it the length field only a single > byte? In some use cases it seems that having aggregation only for > packets smaller than 256 bytes may be limiting. Have you studied what > the frequency different packets are created. If you have a lot of > packets in the size of 257-500 bytes they may be advantageous to be able > to aggregate. The length field size was specified in the original draft-moffitt-vorbis-rtp I-D and it's been kept as it seems a fair limit, losing a packet with a 64 or 128 Vorbis frames will cause a greater skip than 32. Aggregating packets larger than 256 bytes is allowed so your scenario is catered for. When you read this section did you get the impression that this was not allowed? If so it can be altered to make it clearer. > > 9. Section 2.3, sixth paragraph: Please clarify that the packet length > is counted in octets. Yes, this will be fixed. > > 10. Section 2.3: How does one perform RTP TS recovery for the individual > Vorbis packets in an aggregated packet? Are the RTP TS not needed or are > there some implicit method. Please clarify. This needs further investigation. > > 11. Path MTU. I think that you should have a separate chapter on Path > MTU discovery advice. I would also try to not write 1500 bytes as a > common size. However, it might be common, the restraining of thinking is > maybe one of the restricting factor that have prevented the usage of > larger MTUs. I would recommend you to look at RFC 1191, and RFC1981. It > would also be useful to make informative reference to the work in the > newly formed PMTUD WG, a proposal draft does exist > "draft-mathis-plpmtud-00.txt". Agreed. > > 12. Section 3, Some parts of this section should be moved to before 2.2. > > 13. Section 3, first paragraph: This contradicts the SHOULD in section > 2.2. regarding fragmentation. This will be fixed. > > 14. Section 3, third paragraph: This section is mentioning final > fragment (F) which is not consistent with the field name in section 2.2. Yes, the naming will be changed for consistency. > > 15. Section 3: The fragmentation rules are lacking. To make the > fragmentation proposal work you need to require that all fragments are > sent in consecutive RTP packets. And that this schemes does not allow > recovery of the fragment unless all packets belonging to the fragment > arrives. The TS requirement is not enough, it is the RTP sequence number > you must rely on for recovery. Section 3.1 describes this, focusing on the sequence number, but it will be expanded for clarity. > > 16. Section 3.2: I think it is important to be clear that receiver > dropped packets should not be counted or reported as lost in the RTCP > statistics. IF one uses congestion control as one should based on RTCP > reports the receiver side dropped packets will be counted as lost in the > network and as being victim of congestion, that way resulting in > reduction of rate. I would also not be so fast to recommend dropping. I > would rather say that a receiver should buffer packets (reordering, > jitter), and MUST not use unless all fragments arrive. Agreed. > > 17. Section 4.1: Use of RTCP padding flag. This MAY be used but has no > reason that it is required to use. I don't understand the reference to > section 6.6 of RFC1889. Please review padding in RTP specification. Will do. > > 18. Section 4.1: Second paragraph. "VORB RTCP packets MUST be sent just > ahead of the change ...". I have two comments about the sentence, first > this can't be a MUST as it isn't possible to enforce and guarantee, so > make it a SHOULD. Secondly, the "just ahead of" is very hard to > understand what it really means. I thing that having a sentence saying > that the RTCP packet SHOULD be sent ahead of the change is good. Then > further motivate that it is crucial that it arrives before the change. Agreed, this section will be re-written to clarify > > 19. Section 4.1, Second paragraph, The last MUST in the paragraph is > also one of this that can't be enforced by sender behaviour. Make it a > SHOULD. Yes, this will be fixed. > > 20. Section 4.1, If these codebooks, necessary information is so crucial > why not use an ACK packet to ACK when it has been received. This way > the sender can utilize the RTCP bandwidth as efficient as possible. I > would implement it using another SUBtype of the VORB APP packet. This is a good idea and will be explored. > > 21. Section 4.1, how to utilize the subtype in this APP packet is not > defined. > > 22. Section 4.1 Why have have flags for the different parts when you are > required to send all of the fields? All of the header information is required for the initial setup of the clients decoder but the codebook and metadata may change mid-session. The meta-data will probably be the most dynamic (track number/title/artist changing) and the flags are used to indicate the payload sub-type. The VORB RTCP packet can contain one, or all of the sub headers components. > > 23. Section 4.1, the o flag: I think this flag need more explanation. > Also further information on how to handle the situation when the APP > packet brings the RTCP packet over the MTU. > > 24. Section 4.1 Second last paragraph on page 10: "This setup > information ... " what does setup information refer to. I don't think > this is an explained term. This should link back to section 4, and the word setup will be changed to configuration. > > 25. Section 4.1, First paragraph, page 11: First sentence say that a > receiver failing to receive the code book should obtain it from SDP. Is > this a mistake, or simply lacking explanation on how that would work? This needs to be explained better and I'll re-write this section. > > 26. Section 4.1, Second paragraph page 11: "This message MUST be sent > ..." Why have flags if this MUST exist, secondly why having the > enforcement of including a empty header, when it does not contain any > information? See comment above regarding point 22. > > 27. Section 4.1, what is one expected to use the URI and what types of > URIs is allowed? > > 28. Section 4.2, Codebook caching needs more explanation. This will be expanded. > > 29. Section 5: The usage of "u=", I don't think it is appropriate to use > "u=" to include an URI to the codebooks and other stream information. > > 30. Section 5: The usage of "c=", The Vorbis payload format can't > redefine the usage of "c=" field or require it to be used. SIP use the > field to declare the receiver address, while RTSP does not use it at all. > > 31. Section 5.1, I think that all Vorbis specific SDP attributes should > be sent in the a=fmtp line and be declared as required MIME parameters > if they always must be present. Why are there no parameter for the > codebook itself? Also an URI to this information could be included here. > However the implications that a client must follow a link to fetch this > information must be further explained. I'll look into this further. > > 32. Section 6, MIME registration: Parameters optional and required seems > to exist and needs to be defined properly. > > 33. Section 6, Reference to RFCXXXX and a RFC-editor note to ask him to > replace the number with the specifications assigned RFC number, is how > one usually solves the references in the MIME registration. > > 34. If this becomes a WG draft AVT needs to be added to the Change > control section. > > 35. IPR statement section is missing, please review ID-Nits. > http://www.ietf.org/ID-nits.html These will be addressed. > > > This was my comment for this revision. There are a number of serious > shortcomings that needs to be addressed. See further comments to your > open issues below. > > > philkerr@elec.gla.ac.uk wrote: > > Dear all, > > > > Last month (11th June) an -02 update to draft-kerr-avt-vorbis-rtp was > announced > > on the AVT list and a slot in Vienna has been booked for discussion. > > > > The draft details the RTP delivery of Vorbis audio, SDP values and delivery > of > > the decoders static probability model, 'codebooks'. Examples of Vorbis > frame > > packing and fragmented packet handling are also covered. > > > > Open issues: > > > > Congestion control. Under development is a mechanism for dynamic bitrate > > reduction called 'bitrate peeling'. When this feature becomes available it > will > > impact on how congestion is dealt with and a mechanism allowing its use > within a > > multicast environment needs to be explored. > > I think we also need to consider the IAB's statement about congestion > control in this draft. However you can separate the congestion control > issues for multicast and unicast. The unicast issue must be solved. Unicast congestion control should be the easier of the two to solve as the client may send an explicit request to downgrade the stream, or the server may do this automatically from the RR's. > > > > > Codebook delivery. There are two mechanisms outlined for the delivery of > the > > codebooks, SDP and RTCP. The codebooks may change mid-stream (at the > boundary > > between two tracks) as well as being static for the session lifetime. As > the > > codebooks are needed for the successful decoding of the Vorbis stream a > reliable > > mechanism to handle their delivery of mid-session codebook changes should > be > > investigated (TCP over RTP?) in preference to using RTCP messages. > > I think there is in fact a third alternative hinted, which is out of > band fetching using HTTP, etc. I also think one should consider sessions > where RTP with retransmission is used. This can ensure that a client > reports if it does receive all fragments of the the code books. I also > think that more clear guidelines that having a session long static book > is to be preferred. Agreed, but in certain usage scenarios the codebooks may change quite frequently such as jingle breaks between two tracks. > > > > > Path MTU. There is a mechanism for splitting large Vorbis frames across > > multiple RTP packets but a reliable mechanism for path-MTU discovery needs > to be > > outlined to prevent packet fragmentation not dealt with by the above. > > > > I think that you can lean on the already, not functioning so well > methods, plus the newly initiated work on MTU discovery. I think simply > having more information on where to go to find solutions is appropriate > for this document. This sounds like the best solution. Many thanks Phil > > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 11:14:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04960 for ; Wed, 9 Jul 2003 11:14:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdc-0001aS-RB for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDiGA006094 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd9-00018B-VC; Wed, 09 Jul 2003 11:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aEtg-0008Se-5H for avt@optimus.ietf.org; Wed, 09 Jul 2003 09:22:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00116 for ; Wed, 9 Jul 2003 09:22:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aEte-0006eA-00 for avt@ietf.org; Wed, 09 Jul 2003 09:22:10 -0400 Received: from host.150.34.23.62.rev.coltfrance.com ([62.23.34.150] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19aEtd-0006e7-00 for avt@ietf.org; Wed, 09 Jul 2003 09:22:09 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h69DM45e007418; Wed, 9 Jul 2003 09:22:05 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 9 Jul 2003 11:05:22 +0200 From: Colin Perkins To: philkerr@elec.gla.ac.uk Cc: avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 Message-Id: <20030709110522.1217e183.csp@csperkins.org> In-Reply-To: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --> philkerr@elec.gla.ac.uk writes: > Dear all, > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > Comments and feedback welcomed. I have a number of questions and comments: - It's not appropriate for the draft to claim that the Speex codec is free from patents and/or royalties. If you wish to make an IPR statement, it should be separately submitted to the IESG Secretary for inclusion on the IPR-claims page the IETF maintains. See also section 10 of RFC 2026. - The draft would benefit from a little more introduction to Speex at the beginning. - The definition of the Padding bit in the RTP header is unusual. It may be better to state that padding MAY be used in the usual RTP manner, unless there is a specific reason why a different padding scheme is needed? - The use of the M bit in the RTP header to signify comfort noise is also unusual. This is not necessarily inappropriate, but it is important to consider if the advantages of this use outweigh the costs of being different to other audio payload formats (which use the M bit to signal the first packet after a silent period). - The definition of the timestamp says "Speex uses 20 msec frames and a variable sampling rate clock". Does this mean that the sample rate can change at anytime within a session? Or is the sample rate chosen from one of a number of values, and then fixed within the session? - Section 3.2 is unclear if the bit rate and sample rate are coupled. Can Speex vary the compression ratio to change the bit rate without changing the sampling rate? - In Section 3.2, it is important to be clear that the padding needed to ensure that the payload is octet aligned is independent of the padding at the RTP level (i.e. the P bit in the RTP header). - The examples in Section 3.3 and 3.4 might be clearer if they show the actual length of the Speex data frames. An example showing two Speex frames in an RTP packet, with the first Speex frame being non-octet aligned, would be useful (to make it clear how to handle padding in this case). - Section 4 "MIME registration of Speex" should be renamed to "IANA considerations", and needs an introductory sentence saying something like "The following MIME type and associated RTP payload format are to be registered". - The usual way in which a MIME type is registered only for particular use is to define the use in the "Encoding considerations" section of the MIME registration form. In this case, you might say something like: This type is defined only for transfer within RTP as specified in Section 4 of RFC XXXX. For file storage, or for transmission over lossless channels (such as TCP), Speex data is transported within an Ogg bitstream [RFC 3534]. This would replace the introductory sentence and last paragraph of the current section 4. If there is a need to register parameters of the Ogg bitstream, that should be done as a separate subsection under section 4. - The "a=fmtp:" parameters from Section 5 should be defined in Section 4, as Optional Parameters to the audio/speex type, and section 5 should be an explanation of how the parameters are mapped onto SDP. - The "ebw" parameter may be redundant, since the clock rate is signalled in the "a=rtpmap:" line? - It may be clearer to separate out the explanation of how parameters are mapped to SDP from the description of how the SDP is used with the offer/ answer model (as two subsections). There are uses of SDP that don't use offer/answer. - Section 6 (use with H.323) is not appropriate in an IETF document. You can include a reference to an ITU - or other - document explaining how to use Speex with H.323, but the IETF can't mandate use of H.245 parameters. - Section 10: RFCs are published using strict US ASCII. If there is an acceptable transliteration of the non-ASCII characters in Jean-Marc Valin's address, it will save a "discussion" with the RFC Editor. See draft-rfc-editor-rfc2223bis-06.txt. - Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 11:50:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06954 for ; Wed, 9 Jul 2003 11:50:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHCk-0006xp-A4 for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 11:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Fo24X026765 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 11:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHCj-0006xa-8r; Wed, 09 Jul 2003 11:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHCP-0006ws-16 for avt@optimus.ietf.org; Wed, 09 Jul 2003 11:49:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06910 for ; Wed, 9 Jul 2003 11:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHCN-0007m4-00 for avt@ietf.org; Wed, 09 Jul 2003 11:49:39 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19aHCM-0007m1-00 for avt@ietf.org; Wed, 09 Jul 2003 11:49:39 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h69FnZGJ014258; Wed, 9 Jul 2003 17:49:35 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 3S6H91F0; Wed, 9 Jul 2003 17:52:07 +0200 Message-ID: <3F0C398F.6030400@ericsson.com> Date: Wed, 09 Jul 2003 17:49:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: philkerr@elec.gla.ac.uk CC: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna References: <1057605874.3f09c8f261862@dlana.elec.gla.ac.uk> <3F0A7A95.6060309@ericsson.com> <1057740827.3f0bd81bac368@dlana.elec.gla.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Phil, Here are a few more comments and some pointers worth checking out. philkerr@elec.gla.ac.uk wrote: > Quoting Magnus Westerlund : >>7. Section 2.3: Third paragraph, page 5: The limitation that a Vorbis >>packet shall not be larger than 64k bytes. What about IPv6 Jumbograms >>and the fragmentation process? It seem possible to have larger packets >>although it would be a bad idea. > > > The codebooks can be far greater than 64k in size but a limit was imposed to > allow it to be transported inside a RTCP packet and to reduce the delay a client > may have in waiting for a large codebook to be received. Perhaps a note > detailing that transport over IPv6 allows greater packet size would cover this > scenario. > I think that we need to clear consider how to get these codebooks transported. A larger than 64kb codebook should neither be transported in SDP or in RTCP. I think that using HTTP can clearly be an alternative, and only provide the URI to the codebook. I wouldn't try to transport a codebook over RTCP that results in a RTCP packet many time the MTU due to the high number of IP fragments. Further such a packet will severely reduce the RTCP report rate in both directions. > >>8. Section 2.3, fifth paragraph: Why it the length field only a single >>byte? In some use cases it seems that having aggregation only for >>packets smaller than 256 bytes may be limiting. Have you studied what >>the frequency different packets are created. If you have a lot of >>packets in the size of 257-500 bytes they may be advantageous to be able >>to aggregate. > > > The length field size was specified in the original draft-moffitt-vorbis-rtp I-D > and it's been kept as it seems a fair limit, losing a packet with a 64 or 128 > Vorbis frames will cause a greater skip than 32. Aggregating packets larger > than 256 bytes is allowed so your scenario is catered for. When you read this > section did you get the impression that this was not allowed? If so it can be > altered to make it clearer. The first indication is the second paragraph in section 3: "Any Vorbis packet that is larger than 256 octets and less than the path-MTU MUST be placed in a RTP packet by itself.". Secondly the payload format does not describe a mechanism to allow it. > >>10. Section 2.3: How does one perform RTP TS recovery for the individual >>Vorbis packets in an aggregated packet? Are the RTP TS not needed or are >>there some implicit method. Please clarify. > > > This needs further investigation. This is probably one of the most important things as most decoders and error recovery mechanism needs to receive the frames/packets in timing order plus with detection of lost frames. > >>21. Section 4.1, how to utilize the subtype in this APP packet is not >>defined. >> >>22. Section 4.1 Why have have flags for the different parts when you are >>required to send all of the fields? > > > All of the header information is required for the initial setup of the clients > decoder but the codebook and metadata may change mid-session. The meta-data > will probably be the most dynamic (track number/title/artist changing) and the > flags are used to indicate the payload sub-type. The VORB RTCP packet can > contain one, or all of the sub headers components. That was not how I read the text. See section 4.1 paragraph 2 on page 11. There is a MUST there in the third sentence that I interpreted as requiring all as needed. I think that sending this meta information in RTCP can be appropriate, or in the packet stream if RTP retransmission is used. However the codebooks will most probably need special treatment, unless they are no bigger than a 1 kb. > >>29. Section 5: The usage of "u=", I don't think it is appropriate to use >>"u=" to include an URI to the codebooks and other stream information. >> >>30. Section 5: The usage of "c=", The Vorbis payload format can't >>redefine the usage of "c=" field or require it to be used. SIP use the >>field to declare the receiver address, while RTSP does not use it at all. >> >>31. Section 5.1, I think that all Vorbis specific SDP attributes should >>be sent in the a=fmtp line and be declared as required MIME parameters >>if they always must be present. Why are there no parameter for the >>codebook itself? Also an URI to this information could be included here. >>However the implications that a client must follow a link to fetch this >>information must be further explained. > > > I'll look into this further. I would suggest that you take a look at the MIME and SDP sections of the H264 payload format (draft-ietf-avt-h264-02.txt) or the AMR payload format (RFC 3267). Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 14:55:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14389 for ; Wed, 9 Jul 2003 14:55:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK60-0003Gf-9W for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 14:55:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69ItGEo012546 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 14:55:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK5l-0003DJ-PS; Wed, 09 Jul 2003 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aK4t-00036C-P9 for avt@optimus.ietf.org; Wed, 09 Jul 2003 14:54:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14273 for ; Wed, 9 Jul 2003 14:54:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aK4q-0001sA-00 for avt@ietf.org; Wed, 09 Jul 2003 14:54:04 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aK4p-0001s5-00 for avt@ietf.org; Wed, 09 Jul 2003 14:54:03 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h69IrUe26293 for avt@ietf.org; Wed, 9 Jul 2003 11:53:30 -0700 Date: Wed, 9 Jul 2003 11:53:30 -0700 From: John Lazzaro Message-Id: <200307091853.h69IrUe26293@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Magnus Westerlund writes: > > I think that we need to clear consider how to get these codebooks > transported. A larger than 64kb codebook should neither be transported > in SDP or in RTCP. I think that using HTTP can clearly be an > alternative, and only provide the URI to the codebook. > > I wouldn't try to transport a codebook over RTCP that results in a > RTCP packet many time the MTU due to the high number of IP > fragments. Further such a packet will severely reduce the RTCP report > rate in both directions. I may be incorrect here, but from my discussions with Phil earlier in the year, the codebook issue has these requirements: -- May change every few minutes (say, once per song when used for Internet radio apps). -- Tightly synchronized with the stream: if you don't have the new codebook in time for the first packet that needs it, its a catastrophe. -- Reliable reception a must, no built in resiliency if it is sent as a stream of UDP packets and some but not all arrive. One way to handle this is to have two synchronized streams in the media session: a UDP RTP/AVP stream for the media data, and a TCP stream (perhaps an RTP/AVP stream if a solution like draft-lazzaro-avt-rtp-framing-contrans happens, or perhaps an opaque TCP stream) for the codebooks. In either case, the synchronization would happen as lip-sync synchronization happens. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 15:18:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16735 for ; Wed, 9 Jul 2003 15:18:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKS2-00057w-EK for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 15:18:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69JI2QZ019704 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 15:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKS0-00056z-VI; Wed, 09 Jul 2003 15:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKRg-000560-D0 for avt@optimus.ietf.org; Wed, 09 Jul 2003 15:17:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16630 for ; Wed, 9 Jul 2003 15:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKRf-0002Am-00 for avt@ietf.org; Wed, 09 Jul 2003 15:17:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aKRe-0002AQ-00 for avt@ietf.org; Wed, 09 Jul 2003 15:17:38 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h69JH5pZ022352; Wed, 9 Jul 2003 12:17:05 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-190.cisco.com [64.100.135.190]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFW16825; Wed, 9 Jul 2003 12:17:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20030709150608.017a3f08@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jul 2003 15:16:55 -0400 To: Colin Perkins , philkerr@elec.gla.ac.uk From: "Michael A. Ramalho" Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 Cc: avt@ietf.org In-Reply-To: <20030709110522.1217e183.csp@csperkins.org> References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Comment on M bit below. At 11:05 AM 7/9/2003 +0200, Colin Perkins wrote: >--> philkerr@elec.gla.ac.uk writes: > > Dear all, > > > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > > > Comments and feedback welcomed. > >I have a number of questions and comments: > >- It's not appropriate for the draft to claim that the Speex codec is free > from patents and/or royalties. If you wish to make an IPR statement, it > should be separately submitted to the IESG Secretary for inclusion on the > IPR-claims page the IETF maintains. See also section 10 of RFC 2026. > >- The draft would benefit from a little more introduction to Speex at the > beginning. > >- The definition of the Padding bit in the RTP header is unusual. It may be > better to state that padding MAY be used in the usual RTP manner, unless > there is a specific reason why a different padding scheme is needed? > >- The use of the M bit in the RTP header to signify comfort noise is also > unusual. This is not necessarily inappropriate, but it is important to > consider if the advantages of this use outweigh the costs of being > different to other audio payload formats (which use the M bit to signal > the first packet after a silent period). Colin, This may be contrary to the guidance I got from Steve a while back. A little background first .. From RFC 1889: "marker (M): 1 bit The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile may define additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type field (see Section 5.3)." But from RFC 1890 (Audio and Video Conferences with Minimal Control that can be used with G.711): "For applications which send no packets during silence, the first packet of a talk spurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero." Then Steve said on 2/2/2003 (in regards to the RGL codec) ... "I believe you should follow the marker bit convention as specified in RFC 1890. The RGL codec is likely to be used in implementations that also use other payload formats (such as PCMU) specified in RFC 1890, and the behavior should be consistent." Thus, since I think that speex will also be used in similar deployments (i.e., packet voice) ... I would think Steve's guidance should apply here as well. My question to the speex authors is that if they simply define the periods in which they desire to send comfort noise to be *identically* the same definition as a RFC 1890 "beginning or ending of a talk spurt", then there would be no inconsistency in the bit's meaning. My $0.02, Michael Ramalho Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 15:27:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16976 for ; Wed, 9 Jul 2003 15:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKaj-0005px-Qr for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 15:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69JR1YV022423 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 15:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKai-0005pO-Uh; Wed, 09 Jul 2003 15:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKZm-0005oC-4L for avt@optimus.ietf.org; Wed, 09 Jul 2003 15:26:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16941 for ; Wed, 9 Jul 2003 15:25:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKZk-0002Fe-00 for avt@ietf.org; Wed, 09 Jul 2003 15:26:00 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19aKZj-0002FP-00 for avt@ietf.org; Wed, 09 Jul 2003 15:26:00 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.9) with ESMTP id h69JObgi042839 for ; Wed, 9 Jul 2003 12:25:52 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.9/Submit) id h69JObj6042835; Wed, 9 Jul 2003 12:24:37 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20030709120904.00b5fc30@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 09 Jul 2003 12:20:32 -0700 To: avt@ietf.org From: Ross Finlayson Subject: Re: [AVT] Vorbis RTP issues list for Vienna In-Reply-To: <200307091853.h69IrUe26293@snap.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , >I may be incorrect here, but from my discussions with Phil earlier >in the year, the codebook issue has these requirements: > > -- May change every few minutes (say, once per song when used for > Internet radio apps). IMHO, this is a flaw in the "Vorbis" architecture. It would be much better to have a fixed, predefined set of codebooks that all receivers would know in advance. Then you'd need to send only a 'codebook id', which should be small enough to include in the Vorbis RTP payload format header. Having to send a complete codebook for each song partially defeats the purpose of audio compression. The Vorbis designers should just figure out a complete set of codebooks that are likely to be useful, and settle on those. Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 16:07:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19535 for ; Wed, 9 Jul 2003 16:07:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLD9-0008RI-8j for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 16:06:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69K6hbB032420 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 16:06:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLCT-0008Pz-VR; Wed, 09 Jul 2003 16:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLCC-0008Pd-4b for avt@optimus.ietf.org; Wed, 09 Jul 2003 16:05:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19467 for ; Wed, 9 Jul 2003 16:05:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLCA-0002o6-00 for avt@ietf.org; Wed, 09 Jul 2003 16:05:42 -0400 Received: from capefear.real.com ([207.188.7.217]) by ietf-mx with esmtp (Exim 4.12) id 19aLC9-0002nw-00 for avt@ietf.org; Wed, 09 Jul 2003 16:05:41 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Wed, 09 Jul 2003 13:05:05 -0700 Date: Wed, 9 Jul 2003 13:12:17 -0700 (PDT) From: Aaron Colwell To: Ross Finlayson cc: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna In-Reply-To: <4.3.1.1.20030709120904.00b5fc30@laptop-localhost> Message-ID: References: <4.3.1.1.20030709120904.00b5fc30@laptop-localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree with Ross on this. It seems that these codebooks are causing too many problems that aren't worth dealing with. People have been suggesting getting the codebooks via HTTP, alternate TCP links, and all sorts of other methods. If your going to go that far why not just use HTTP to deliver the data. That way you are guaranteed to get everything in the right order. My guess is that other video and audio codecs use predefined tables to avoid this very problem. Vorbis should do the same. The Vorbis folks should come up with a "streamable" profile that encodes the audio using predefined codebooks. Doing this makes all of the complicated codebook issues go away. They could also create an offline tool that will translate any Vorbis file into a "streamable" Vorbis file. This idea is similar to hinting tools used for MPEG4 and 3GPP files. Aaron On Wed, 9 Jul 2003, Ross Finlayson wrote: > > >I may be incorrect here, but from my discussions with Phil earlier > >in the year, the codebook issue has these requirements: > > > > -- May change every few minutes (say, once per song when used for > > Internet radio apps). > > IMHO, this is a flaw in the "Vorbis" architecture. It would be much better > to have a fixed, predefined set of codebooks that all receivers would know > in advance. Then you'd need to send only a 'codebook id', which should be > small enough to include in the Vorbis RTP payload format header. > > Having to send a complete codebook for each song partially defeats the > purpose of audio compression. > > The Vorbis designers should just figure out a complete set of codebooks > that are likely to be useful, and settle on those. > > Ross. > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 16:42:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21002 for ; Wed, 9 Jul 2003 16:42:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLlA-0002Db-Qg for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 16:41:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69KfqKU008520 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 16:41:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLkL-00020y-T3; Wed, 09 Jul 2003 16:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLk9-00020W-V4 for avt@optimus.ietf.org; Wed, 09 Jul 2003 16:40:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20891; Wed, 9 Jul 2003 16:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLk7-000396-00; Wed, 09 Jul 2003 16:40:47 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 19aLk7-00038N-00; Wed, 09 Jul 2003 16:40:47 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Jul 2003 13:40:14 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 Jul 2003 13:40:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jul 2003 13:40:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Jul 2003 13:40:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 9 Jul 2003 13:40:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AVT] Requirements draft on video control Date: Wed, 9 Jul 2003 13:39:46 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A34750@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] Requirements draft on video control Thread-Index: AcNGTsrjAD4hxGGpTxa5o1h1z7W8RAABxXyg From: "Gary Sullivan" To: "Andrea Basso" Cc: , , , , , , , "Orit Levin" , "Roni Even" X-OriginalArrivalTime: 09 Jul 2003 20:40:12.0799 (UTC) FILETIME=[4BBA08F0:01C3465A] Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Andrea et al, Perhaps I was having some trouble understanding the purpose of this ID. I thought it was some sort of draft of a formal specification, rather than just an expression of needs to be taken as input by the group. So I criticized the language more heavily than necessary. In regard to the "intra frames" =3D "inter frames" mix-up: +> >intra frames are also known as inter frames, which is +> >definitely not the case +>=20 +> I do not think the text says this. Here is the sentence: +>=20 +> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 +> [5], H.264 [6] can encode video pictures as reference=20 +> frames, also +> known as intra frames or predicted frames, also known as inter +> frames. It seems like what we have is a scoping problem. To what set of words does the first "also known as" phrase apply? To me, when you said "A, also known as B or C, also known as D", I interpreted this as saying that A, B, C, and D are all synonyms (with the first "also known as" applying to the "B or C"). Apparently that's not what you meant. Also, the way the term "reference frame" is used in this document may have contributed to my confusion. As I noted in my original message, that term is used differently here than it is in some other video coding discussions. Best Regards, Gary Sullivan +> -----Original Message----- +> From: Andrea Basso [mailto:Andrea_Basso@nmss.com]=20 +> Sent: Wednesday, July 09, 2003 12:17 PM +> To: Gary Sullivan +> Cc: Andrea Basso; avt@ietf.org; casner@acm.org;=20 +> csp@csperkins.org; jo@tzi.uni-bremen.de;=20 +> magnus.westerlund@ericsson.com; mmusic@ietf.org;=20 +> nismail@cisco.com; Orit Levin; Roni Even +> Subject: RE: [AVT] Requirements draft on video control +>=20 +>=20 +>=20 +> Gary, +> here are some comments. +>=20 +>=20 +> > Some of it seems like it could use a bit of updating in that regard +> > (e.g., videofastupdateGOB). +> > Draft Recommendation H.241 is one good place to look for such +> > information. +>=20 +> H.241 is very focused on H.264 and in very early stages in addressing +> Commands and Indications applicable to all codecs. +> If you look at the H.241 draft section 6 says: +>=20 +>=20 +>=20 +> 6 Commands and Indications +>=20 +>=20 +>=20 +> 6.1 C&I applicable to all video codecs +>=20 +> For further study. +>=20 +>=20 +> We plan to monitor the evolution the H.241 and to update the=20 +> ID accordingly +> if needed. +>=20 +>=20 +> >intra frames are also known as inter frames, which is +> >definitely not the case +>=20 +> I do not think the text says this. Here is the sentence: +>=20 +> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 +> [5], H.264 [6] can encode video pictures as reference=20 +> frames, also +> known as intra frames or predicted frames, also known as inter +> frames. +>=20 +>=20 +> >The terms "picture" and "frame" are also kind of +> >mixed up. +>=20 +> For progressive video, a picture is identical to a frame.=20 +> The difference +> appears for interlaced video only. +> The new text will use the term 'picture' only. +>=20 +>=20 +> >The characterization of a "slice" or "GOB" as being a=20 +> "stripe" is not +> >really quite right. +>=20 +> The text does not say "image stripe" says "stripe" and in=20 +> particular it +> does not imply that such stripe goes border-to-border in the=20 +> image (i.e. +> can cover a partial macroblock row) nor that is should only include a +> single macroblock row (i.e., can cover multiple partial=20 +> rows as in H.261). +> Clarifications will be addressed in the new version of the draft. +>=20 +>=20 +> -A +>=20 +> Andrea Basso +> NMS Communications +> (732) 936-2118 +>=20 +>=20 +>=20 +> =20 +> =20 +> "Gary Sullivan" =20 +> =20 +> "Andrea Basso" , , =20 +> rosoft.com> =20 +> , =20 +> =20 +> cc: =20 +> , , =20 +> 07/08/2003 08:03 PM =20 +> , , "Orit=20 +> Levin" =20 +> =20 +> , "Roni Even" ,=20 +> =20 +> =20 +> =20 +> =20 +> Subject: =20 +> RE: [AVT] Requirements draft on video control =20 +> =20 +> =20 +>=20 +>=20 +>=20 +>=20 +>=20 +> Much of the content of this ID will look familiar to those with +> experience with ITU-T systems control specifications (such as H.245). +>=20 +> Some of it seems like it could use a bit of updating in that regard +> (e.g., videofastupdateGOB). +> Draft Recommendation H.241 is one good place to look for such +> information. +>=20 +> Section 3 is a bit confused in its terminology. For example=20 +> it seems to +> say that intra frames are also known as inter frames, which is +> definitely not the case. It mixes the terms "predictive" and +> "prediction" and seems to consider a "reference" frame to be=20 +> synonymous +> with an intra frame. The terms "picture" and "frame" are=20 +> also kind of +> mixed up. +>=20 +> A more consistent terminology would be as follows: +>=20 +> An intra picture is a picture that can be decoded without=20 +> first decoding +> any other picture. +>=20 +> A predicted (or non-intra) picture is a picture that may require data +> from one or more previously-decoded pictures in order to be properly +> decoded. +>=20 +> A reference picture is a picture that is stored in the=20 +> decoder for use +> as a reference in the decoding process of some subsequent=20 +> picture in the +> bitstream. +>=20 +> A non-reference picture is a picture that is not used as a=20 +> reference for +> the decoding process of any other picture in the bitstream. +>=20 +> The concepts of intra versus non-Intra and reference versus +> non-reference are independent. A particular picture can (in=20 +> general) be +> any one of the four types (intra reference, non-intra=20 +> reference, intra +> non-reference, non-intra non-reference). +>=20 +> A "fast update", also known as an "instantaneous decoder refresh", +> involves sending an intra picture and thereafter refraining=20 +> from using +> any picture sent prior to that intra picture as a reference for the +> decoding process of any subsequent picture sent in the stream. +>=20 +> In particular it is worth noting that some concepts that=20 +> applied to some +> older codecs are not really valid in general and should be avoided +> (e.g., that a non-reference picture is called a B picture or that an +> intra picture is the same thing as a fast update or that an intra +> picture is always a reference picture). +>=20 +> The characterization of a "slice" or "GOB" as being a "stripe" is not +> really quite right. For example, a single slice in MPEG-1,=20 +> H.263 Annex +> O, or MPEG-4 can consist of a few macroblocks at the right=20 +> edge of one +> row and a few macroblocks at the left edge of the next row (i.e., two +> distinct rectangular regions quite far apart from each other in the +> picture can be in a single slice). A GOB in H.261 CIF=20 +> consists of THREE +> partial rows of macroblocks extending only halfway across a picture. +> And in H.264/AVC, a slice can be ANY collection of=20 +> macroblocks scattered +> around absolutely anywhere in the picture (by use of a=20 +> feature known as +> a "slice group map"). +>=20 +> In regard to section 5.1 VideoFreezePicture, I believe H.262=20 +> (also known +> as MPEG-2 Video) also supports a freeze picture release=20 +> within the ITU-T +> extension. +>=20 +> It is also possible to obtain random access recovery without a fast +> update. This is sometimes called "gradual decoder refresh". See for +> example the recovery point SEI message in H.264/AVC. +>=20 +> Best Regards, +>=20 +> Gary Sullivan +>=20 +>=20 +> +> -----Original Message----- +> +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On +> +> Behalf Of Andrea Basso +> +> Sent: Monday, July 07, 2003 2:34 PM +> +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; +> +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit +> +> Levin; Roni Even; nismail@cisco.com +> +> Subject: [AVT] Requirements draft on video control +> +> +> +> +> +> Attached you will find draft-basso-avt-videoconreq-00.txt +> +> +> +> Abstract: +> +> +> +> A variety of communication services such as video +> +> conferencing and video messaging rely on the capability of video +> +> encoders and decoders to exchange control commands. This document +> +> outlines this set of commands as well as the requirements for +> +> their transport. +> +> +> +> Comments are more than welcome. +> +> +> +> +> +> +> +> +> +> +> +> Andrea Basso +> +> NMS Communications +> +> (732) 936-2118 +> +> (See attached file: draft-basso-avt-videoconreq-00.zip) +> +> +>=20 +>=20 +>=20 +>=20 +>=20 +>=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 17:04:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22114 for ; Wed, 9 Jul 2003 17:04:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aM6E-0004WM-HE for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 17:03:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69L3cbD017354 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 17:03:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aM5c-0004Pm-V1; Wed, 09 Jul 2003 17:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aM4v-0004P9-VR for avt@optimus.ietf.org; Wed, 09 Jul 2003 17:02:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22051 for ; Wed, 9 Jul 2003 17:02:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aM4t-0003Sv-00 for avt@ietf.org; Wed, 09 Jul 2003 17:02:15 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19aM4s-0003Sh-00 for avt@ietf.org; Wed, 09 Jul 2003 17:02:15 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h69L123V038901; Wed, 9 Jul 2003 14:01:04 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 9 Jul 2003 14:06:39 -0700 (PDT) From: Stephen Casner To: Aaron Colwell cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-bw-05.txt question In-Reply-To: Message-ID: <20030709132600.C2784-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Aaron, > In the case where b=RR is specified that would mean that no sender reports > or BYE packets could be sent. Is that allowed? In the A/V case the client > would not be able to sync the streams because it would never get their > CNAME. I suppose that is the server's fault for not specifying a value > for the sender reports. I guess this brings up another question. Does it > make sense for the RS value to be 0? We are talking here about a case where b=RR is specified to be > 5%, and b=RS is not specified, so RS would be taken to be zero. However, your interpretation of the effect of RS=0 is incorrect. First, both RS and RR apply to all RTCP packet types that a participant might send. Second, as Magnus and I have been discussing on the list, the "1/4 rule" still applies when RS and/or RR are/is specified, except that we have corrected it to be the "RS/(RS+RR) rule". If RS=0, that simply means that senders do not have any RTCP bandwidth dedicated to them, instead they share RTCP bandwith equally with all participants. I have clarified this in the draft now, during the final stages with the RFC editor. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 17:15:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22611 for ; Wed, 9 Jul 2003 17:15:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMGx-0005ms-6G for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 17:14:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69LEheK022209 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 17:14:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMGI-0005cR-Es; Wed, 09 Jul 2003 17:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMGD-0005bS-CW for avt@optimus.ietf.org; Wed, 09 Jul 2003 17:13:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22515 for ; Wed, 9 Jul 2003 17:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMGB-0003Zc-00 for avt@ietf.org; Wed, 09 Jul 2003 17:13:55 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19aMG9-0003ZA-00 for avt@ietf.org; Wed, 09 Jul 2003 17:13:54 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Wed, 09 Jul 2003 14:13:14 -0700 Date: Wed, 9 Jul 2003 14:19:30 -0700 (PDT) From: Aaron Colwell To: Stephen Casner cc: avt@ietf.org Subject: Re: [AVT] draft-ietf-avt-rtcp-bw-05.txt question In-Reply-To: <20030709132600.C2784-100000@oak.packetdesign.com> Message-ID: References: <20030709132600.C2784-100000@oak.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That makes sense to me. Thanks for the clarifications. Aaron On Wed, 9 Jul 2003, Stephen Casner wrote: > Aaron, > > > In the case where b=RR is specified that would mean that no sender reports > > or BYE packets could be sent. Is that allowed? In the A/V case the client > > would not be able to sync the streams because it would never get their > > CNAME. I suppose that is the server's fault for not specifying a value > > for the sender reports. I guess this brings up another question. Does it > > make sense for the RS value to be 0? > > We are talking here about a case where b=RR is specified to be > 5%, > and b=RS is not specified, so RS would be taken to be zero. However, > your interpretation of the effect of RS=0 is incorrect. First, both > RS and RR apply to all RTCP packet types that a participant might > send. Second, as Magnus and I have been discussing on the list, the > "1/4 rule" still applies when RS and/or RR are/is specified, except > that we have corrected it to be the "RS/(RS+RR) rule". If RS=0, that > simply means that senders do not have any RTCP bandwidth dedicated to > them, instead they share RTCP bandwith equally with all participants. > > I have clarified this in the draft now, during the final stages with > the RFC editor. > > -- Steve > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 18:05:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24752 for ; Wed, 9 Jul 2003 18:05:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aN3G-0001tG-Ax for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 18:04:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69M4c7b007233 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 18:04:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aN2e-0001lx-W7; Wed, 09 Jul 2003 18:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aN20-0001l9-9J for avt@optimus.ietf.org; Wed, 09 Jul 2003 18:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24521 for ; Wed, 9 Jul 2003 18:03:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aN1x-0004Ba-00 for avt@ietf.org; Wed, 09 Jul 2003 18:03:17 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aN1w-0004BW-00 for avt@ietf.org; Wed, 09 Jul 2003 18:03:16 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h69M2gb27052 for avt@ietf.org; Wed, 9 Jul 2003 15:02:42 -0700 Date: Wed, 9 Jul 2003 15:02:42 -0700 From: John Lazzaro Message-Id: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > Aaron Colwell writes: > I agree with Ross on this. It seems that these codebooks are causing too > many problems that aren't worth dealing with. People have been suggesting > getting the codebooks via HTTP, alternate TCP links, and all sorts of > other methods. If your going to go that far why not just use HTTP to > deliver the data. That way you are guaranteed to get everything in the > right order. I think its just an instance of a general problem -- transport of hybrid streams with two components: -- A steady flow of media information that can handle the occassional packet loss episode gracefully and without retransmission -- Occassional chunks of data, which can be sent well ahead of its need, which needs reliability, and which is synchronous to the media flow. So, I think its a good idea for RTP to offer solutions that work in this domain. There are some studio-oriented uses of RTP MIDI which fit into the model, and my motivation for doing draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in a general way, so that when things like Vorbis codebooks come along, RTP has a way to support them. I really don't think that posing the question as all-or-none -- RTP streaming or Shoutcast-esqe pseudo-streaming -- benefits AVT, it will just spawn more HTTP streaming implementations. That said: > The Vorbis folks > should come up with a "streamable" profile that encodes the audio using > predefined codebooks. This is a good option too -- my guess is that most Vorbis setups will only need one codebook for the life of the stream, and that need will be known in advance. A URL in the session description to support HTTP download of that one codebook would be a way to go, with perhaps a known set of "standard codebooks" codable by speak tokens or by GUIDs for the MIME HTTP codebook object. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 18:59:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27913 for ; Wed, 9 Jul 2003 18:59:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNtc-0006c1-Bc for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 18:58:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Mwifx025413 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 18:58:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNsw-0006Xc-0M; Wed, 09 Jul 2003 18:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNsI-0006XE-4E for avt@optimus.ietf.org; Wed, 09 Jul 2003 18:57:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27856 for ; Wed, 9 Jul 2003 18:57:17 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aNsE-0004uP-00 for avt@ietf.org; Wed, 09 Jul 2003 18:57:18 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19aNsE-0004uM-00 for avt@ietf.org; Wed, 09 Jul 2003 18:57:18 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19aNsC-000227-00; Wed, 09 Jul 2003 23:57:16 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Wed, 9 Jul 2003 23:57:16 +0100 Message-ID: <1057791436.3f0c9dcc90ee7@dlana.elec.gla.ac.uk> Date: Wed, 9 Jul 2003 23:57:16 +0100 To: Colin Perkins Cc: avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <20030709110522.1217e183.csp@csperkins.org> In-Reply-To: <20030709110522.1217e183.csp@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Colin, Thanks for the feedback, comments in-line: Quoting Colin Perkins : > --> philkerr@elec.gla.ac.uk writes: > > Dear all, > > > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > > > Comments and feedback welcomed. > > I have a number of questions and comments: > > - It's not appropriate for the draft to claim that the Speex codec is free > from patents and/or royalties. If you wish to make an IPR statement, it > should be separately submitted to the IESG Secretary for inclusion on the > IPR-claims page the IETF maintains. See also section 10 of RFC 2026. Submitting an IPR statement should be no problem. > > - The draft would benefit from a little more introduction to Speex at the > beginning. Agreed. This section can be expanded. > > - The definition of the Padding bit in the RTP header is unusual. It may be > better to state that padding MAY be used in the usual RTP manner, unless > there is a specific reason why a different padding scheme is needed? Changing the Padding bit to MAY should be fine. > > - The use of the M bit in the RTP header to signify comfort noise is also > unusual. This is not necessarily inappropriate, but it is important to > consider if the advantages of this use outweigh the costs of being > different to other audio payload formats (which use the M bit to signal > the first packet after a silent period). Its use was suggested by Henning Schulzrinne to the other Speex draft authors and I've based it on their notes and Section 4.1 of RFC 1890. If there is some discrepency in its use, as highlighted in the feedback by Michael Ramalho, then we may need to look at this section again to determine best practice. > > - The definition of the timestamp says "Speex uses 20 msec frames and a > variable sampling rate clock". Does this mean that the sample rate can > change at anytime within a session? Or is the sample rate chosen from > one of a number of values, and then fixed within the session? There is a fixed range of values for the sample rate but the rate may change mid session. > > - Section 3.2 is unclear if the bit rate and sample rate are coupled. Can > Speex vary the compression ratio to change the bit rate without changing > the sampling rate? I will need to check this just to make sure. > > - In Section 3.2, it is important to be clear that the padding needed to > ensure that the payload is octet aligned is independent of the padding > at the RTP level (i.e. the P bit in the RTP header). This can be made clearer. > > - The examples in Section 3.3 and 3.4 might be clearer if they show the > actual length of the Speex data frames. An example showing two Speex > frames in an RTP packet, with the first Speex frame being non-octet > aligned, would be useful (to make it clear how to handle padding in > this case). > > - Section 4 "MIME registration of Speex" should be renamed to "IANA > considerations", and needs an introductory sentence saying something > like "The following MIME type and associated RTP payload format are > to be registered". > > - The usual way in which a MIME type is registered only for particular > use is to define the use in the "Encoding considerations" section of > the MIME registration form. In this case, you might say something like: > > This type is defined only for transfer within RTP as specified in > Section 4 of RFC XXXX. For file storage, or for transmission over > lossless channels (such as TCP), Speex data is transported within > an Ogg bitstream [RFC 3534]. > > This would replace the introductory sentence and last paragraph of the > current section 4. If there is a need to register parameters of the Ogg > bitstream, that should be done as a separate subsection under section 4. The text can be amended as suggested. > > - The "a=fmtp:" parameters from Section 5 should be defined in Section 4, > as Optional Parameters to the audio/speex type, and section 5 should be > an explanation of how the parameters are mapped onto SDP. Agreed, this will be changed. > > - The "ebw" parameter may be redundant, since the clock rate is signalled > in the "a=rtpmap:" line? I'll need to check this, but if it is redundant it can be removed. > > - It may be clearer to separate out the explanation of how parameters are > mapped to SDP from the description of how the SDP is used with the offer/ > answer model (as two subsections). There are uses of SDP that don't use > offer/answer. Agreed, this section will be split into two. > > - Section 6 (use with H.323) is not appropriate in an IETF document. You > can include a reference to an ITU - or other - document explaining how > to use Speex with H.323, but the IETF can't mandate use of H.245 > parameters. Agreed. I presume we can also link back to a Speex document if further explanation is required, with the usual proviso about linking to URLs as mentioned in the ID-nits. > > - Section 10: RFCs are published using strict US ASCII. If there is an > acceptable transliteration of the non-ASCII characters in Jean-Marc > Valin's address, it will save a "discussion" with the RFC Editor. See > draft-rfc-editor-rfc2223bis-06.txt. I will check with Jean-Marc to see if his address can be written in US ASCII. > > - > Colin Perkins > csp@csperkins.org > Thanks Phil ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 19:07:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28196 for ; Wed, 9 Jul 2003 19:07:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aO1F-0007Em-0R for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 19:06:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69N6asI027814 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 19:06:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aO0e-00077y-Fr; Wed, 09 Jul 2003 19:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNzo-000766-KB for avt@optimus.ietf.org; Wed, 09 Jul 2003 19:05:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28174 for ; Wed, 9 Jul 2003 19:05:03 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aNzl-00050c-00 for avt@ietf.org; Wed, 09 Jul 2003 19:05:05 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19aNzk-00050Z-00 for avt@ietf.org; Wed, 09 Jul 2003 19:05:04 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19aNzk-00024y-00; Thu, 10 Jul 2003 00:05:04 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Thu, 10 Jul 2003 00:05:04 +0100 Message-ID: <1057791904.3f0c9fa014c0b@dlana.elec.gla.ac.uk> Date: Thu, 10 Jul 2003 00:05:04 +0100 To: Magnus Westerlund Cc: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna References: <1057605874.3f09c8f261862@dlana.elec.gla.ac.uk> <3F0A7A95.6060309@ericsson.com> <1057740827.3f0bd81bac368@dlana.elec.gla.ac.uk> <3F0C398F.6030400@ericsson.com> In-Reply-To: <3F0C398F.6030400@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Magnus, Quoting Magnus Westerlund : > Hi Phil, > > Here are a few more comments and some pointers worth checking out. > > > philkerr@elec.gla.ac.uk wrote: > > Quoting Magnus Westerlund : > > > >>7. Section 2.3: Third paragraph, page 5: The limitation that a Vorbis > >>packet shall not be larger than 64k bytes. What about IPv6 Jumbograms > >>and the fragmentation process? It seem possible to have larger packets > >>although it would be a bad idea. > > > > > > The codebooks can be far greater than 64k in size but a limit was imposed > to > > allow it to be transported inside a RTCP packet and to reduce the delay a > client > > may have in waiting for a large codebook to be received. Perhaps a note > > detailing that transport over IPv6 allows greater packet size would cover > this > > scenario. > > > > I think that we need to clear consider how to get these codebooks > transported. A larger than 64kb codebook should neither be transported > in SDP or in RTCP. I think that using HTTP can clearly be an > alternative, and only provide the URI to the codebook. > > I wouldn't try to transport a codebook over RTCP that results in a RTCP > packet many time the MTU due to the high number of IP fragments. Further > such a packet will severely reduce the RTCP report rate in both directions. Agreed. The size should be less than 64k, even if IPv6 can accomodate it and in normal use they are typically under 15k. Having very large codebooks wizzing around is less than optimal. > > > > >>8. Section 2.3, fifth paragraph: Why it the length field only a single > >>byte? In some use cases it seems that having aggregation only for > >>packets smaller than 256 bytes may be limiting. Have you studied what > >>the frequency different packets are created. If you have a lot of > >>packets in the size of 257-500 bytes they may be advantageous to be able > >>to aggregate. > > > > > > The length field size was specified in the original > draft-moffitt-vorbis-rtp I-D > > and it's been kept as it seems a fair limit, losing a packet with a 64 or > 128 > > Vorbis frames will cause a greater skip than 32. Aggregating packets > larger > > than 256 bytes is allowed so your scenario is catered for. When you read > this > > section did you get the impression that this was not allowed? If so it can > be > > altered to make it clearer. > > The first indication is the second paragraph in section 3: "Any Vorbis > packet that is larger than 256 octets and less than the path-MTU MUST be > placed in a RTP packet by itself.". Secondly the payload format does not > describe a mechanism to allow it. I have a feeling that this limit is artifically low and I'll check the to see if it can be raised to allow larger Vorbis frames to be aggregated as you outlined in your previous feedback. > > > > >>10. Section 2.3: How does one perform RTP TS recovery for the individual > >>Vorbis packets in an aggregated packet? Are the RTP TS not needed or are > >>there some implicit method. Please clarify. > > > > > > This needs further investigation. > > This is probably one of the most important things as most decoders and > error recovery mechanism needs to receive the frames/packets in timing > order plus with detection of lost frames. Agreed. > > > > >>21. Section 4.1, how to utilize the subtype in this APP packet is not > >>defined. > >> > >>22. Section 4.1 Why have have flags for the different parts when you are > >>required to send all of the fields? > > > > > > All of the header information is required for the initial setup of the > clients > > decoder but the codebook and metadata may change mid-session. The > meta-data > > will probably be the most dynamic (track number/title/artist changing) and > the > > flags are used to indicate the payload sub-type. The VORB RTCP packet can > > contain one, or all of the sub headers components. > > That was not how I read the text. See section 4.1 paragraph 2 on page > 11. There is a MUST there in the third sentence that I interpreted as > requiring all as needed. I'll review this section and alter to remove any ambiguity. > > I think that sending this meta information in RTCP can be appropriate, > or in the packet stream if RTP retransmission is used. However the > codebooks will most probably need special treatment, unless they are no > bigger than a 1 kb. > > > > >>29. Section 5: The usage of "u=", I don't think it is appropriate to use > >>"u=" to include an URI to the codebooks and other stream information. > >> > >>30. Section 5: The usage of "c=", The Vorbis payload format can't > >>redefine the usage of "c=" field or require it to be used. SIP use the > >>field to declare the receiver address, while RTSP does not use it at all. > >> > >>31. Section 5.1, I think that all Vorbis specific SDP attributes should > >>be sent in the a=fmtp line and be declared as required MIME parameters > >>if they always must be present. Why are there no parameter for the > >>codebook itself? Also an URI to this information could be included here. > >>However the implications that a client must follow a link to fetch this > >>information must be further explained. > > > > > > I'll look into this further. > > I would suggest that you take a look at the MIME and SDP sections of the > H264 payload format (draft-ietf-avt-h264-02.txt) or the AMR payload > format (RFC 3267). Will do. Cheers Phil > > Cheers > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 19:26:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28823 for ; Wed, 9 Jul 2003 19:26:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOJf-0000Kv-04 for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 19:25:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69NPcPl001287 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 19:25:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOJ4-0000EH-KS; Wed, 09 Jul 2003 19:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOIb-0000By-0D for avt@optimus.ietf.org; Wed, 09 Jul 2003 19:24:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28806; Wed, 9 Jul 2003 19:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOIZ-0005BG-00; Wed, 09 Jul 2003 19:24:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19aOIY-0005AL-00; Wed, 09 Jul 2003 19:24:30 -0400 Received: from SCOTTF-W2K5.cisco.com (dhcp-128-107-141-78.cisco.com [128.107.141.78]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h69NNapq018857; Wed, 9 Jul 2003 16:23:37 -0700 (PDT) Message-Id: <4.3.1.2.20030709161949.02181180@mira-sjcm-3.cisco.com.> X-Sender: nismail@mira-sjcm-3.cisco.com. X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 09 Jul 2003 16:25:05 -0700 To: "Gary Sullivan" From: Nermeen Ismail Subject: RE: [AVT] Requirements draft on video control Cc: "Andrea Basso" , , , , , , , "Orit Levin" , "Roni Even" In-Reply-To: <91D7F2CEE3425A4A9D11311D09FCE24602A34750@WIN-MSG-10.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Gary, Thanks for the comments. Definitely we need to add consistency in the terms we are using in the draft. >Andrea et al, > >Perhaps I was having some trouble understanding the purpose of this ID. >I thought it was some sort of draft of a formal specification, rather >than just an expression of needs to be taken as input by the group. So >I criticized the language more heavily than necessary. So now that this is clarified we need to discuss the requirements that are specified in that draft and see if people think that these are legitimate requirements that need to be addressed or not. nermeen >In regard to the "intra frames" = "inter frames" mix-up: > >+> >intra frames are also known as inter frames, which is >+> >definitely not the case >+> >+> I do not think the text says this. Here is the sentence: >+> >+> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 >+> [5], H.264 [6] can encode video pictures as reference >+> frames, also >+> known as intra frames or predicted frames, also known as inter >+> frames. > >It seems like what we have is a scoping problem. To what set of words >does the first "also known as" phrase apply? To me, when you said "A, >also known as B or C, also known as D", I interpreted this as saying >that A, B, C, and D are all synonyms (with the first "also known as" >applying to the "B or C"). Apparently that's not what you meant. > >Also, the way the term "reference frame" is used in this document may >have contributed to my confusion. As I noted in my original message, >that term is used differently here than it is in some other video coding >discussions. > >Best Regards, > >Gary Sullivan > > >+> -----Original Message----- >+> From: Andrea Basso [mailto:Andrea_Basso@nmss.com] >+> Sent: Wednesday, July 09, 2003 12:17 PM >+> To: Gary Sullivan >+> Cc: Andrea Basso; avt@ietf.org; casner@acm.org; >+> csp@csperkins.org; jo@tzi.uni-bremen.de; >+> magnus.westerlund@ericsson.com; mmusic@ietf.org; >+> nismail@cisco.com; Orit Levin; Roni Even >+> Subject: RE: [AVT] Requirements draft on video control >+> >+> >+> >+> Gary, >+> here are some comments. >+> >+> >+> > Some of it seems like it could use a bit of updating in that regard >+> > (e.g., videofastupdateGOB). >+> > Draft Recommendation H.241 is one good place to look for such >+> > information. >+> >+> H.241 is very focused on H.264 and in very early stages in addressing >+> Commands and Indications applicable to all codecs. >+> If you look at the H.241 draft section 6 says: >+> >+> >+> >+> 6 Commands and Indications >+> >+> >+> >+> 6.1 C&I applicable to all video codecs >+> >+> For further study. >+> >+> >+> We plan to monitor the evolution the H.241 and to update the >+> ID accordingly >+> if needed. >+> >+> >+> >intra frames are also known as inter frames, which is >+> >definitely not the case >+> >+> I do not think the text says this. Here is the sentence: >+> >+> Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 >+> [5], H.264 [6] can encode video pictures as reference >+> frames, also >+> known as intra frames or predicted frames, also known as inter >+> frames. >+> >+> >+> >The terms "picture" and "frame" are also kind of >+> >mixed up. >+> >+> For progressive video, a picture is identical to a frame. >+> The difference >+> appears for interlaced video only. >+> The new text will use the term 'picture' only. >+> >+> >+> >The characterization of a "slice" or "GOB" as being a >+> "stripe" is not >+> >really quite right. >+> >+> The text does not say "image stripe" says "stripe" and in >+> particular it >+> does not imply that such stripe goes border-to-border in the >+> image (i.e. >+> can cover a partial macroblock row) nor that is should only include a >+> single macroblock row (i.e., can cover multiple partial >+> rows as in H.261). >+> Clarifications will be addressed in the new version of the draft. >+> >+> >+> -A >+> >+> Andrea Basso >+> NMS Communications >+> (732) 936-2118 >+> >+> >+> >+> >+> >+> "Gary Sullivan" >+> >+> +> "Andrea Basso" , , >+> rosoft.com> >+> , >+> >+> cc: >+> , , >+> 07/08/2003 08:03 PM >+> , , "Orit >+> Levin" >+> >+> , "Roni Even" , >+> >+> >+> >+> >+> Subject: >+> RE: [AVT] Requirements draft on video control >+> >+> >+> >+> >+> >+> >+> >+> Much of the content of this ID will look familiar to those with >+> experience with ITU-T systems control specifications (such as H.245). >+> >+> Some of it seems like it could use a bit of updating in that regard >+> (e.g., videofastupdateGOB). >+> Draft Recommendation H.241 is one good place to look for such >+> information. >+> >+> Section 3 is a bit confused in its terminology. For example >+> it seems to >+> say that intra frames are also known as inter frames, which is >+> definitely not the case. It mixes the terms "predictive" and >+> "prediction" and seems to consider a "reference" frame to be >+> synonymous >+> with an intra frame. The terms "picture" and "frame" are >+> also kind of >+> mixed up. >+> >+> A more consistent terminology would be as follows: >+> >+> An intra picture is a picture that can be decoded without >+> first decoding >+> any other picture. >+> >+> A predicted (or non-intra) picture is a picture that may require data >+> from one or more previously-decoded pictures in order to be properly >+> decoded. >+> >+> A reference picture is a picture that is stored in the >+> decoder for use >+> as a reference in the decoding process of some subsequent >+> picture in the >+> bitstream. >+> >+> A non-reference picture is a picture that is not used as a >+> reference for >+> the decoding process of any other picture in the bitstream. >+> >+> The concepts of intra versus non-Intra and reference versus >+> non-reference are independent. A particular picture can (in >+> general) be >+> any one of the four types (intra reference, non-intra >+> reference, intra >+> non-reference, non-intra non-reference). >+> >+> A "fast update", also known as an "instantaneous decoder refresh", >+> involves sending an intra picture and thereafter refraining >+> from using >+> any picture sent prior to that intra picture as a reference for the >+> decoding process of any subsequent picture sent in the stream. >+> >+> In particular it is worth noting that some concepts that >+> applied to some >+> older codecs are not really valid in general and should be avoided >+> (e.g., that a non-reference picture is called a B picture or that an >+> intra picture is the same thing as a fast update or that an intra >+> picture is always a reference picture). >+> >+> The characterization of a "slice" or "GOB" as being a "stripe" is not >+> really quite right. For example, a single slice in MPEG-1, >+> H.263 Annex >+> O, or MPEG-4 can consist of a few macroblocks at the right >+> edge of one >+> row and a few macroblocks at the left edge of the next row (i.e., two >+> distinct rectangular regions quite far apart from each other in the >+> picture can be in a single slice). A GOB in H.261 CIF >+> consists of THREE >+> partial rows of macroblocks extending only halfway across a picture. >+> And in H.264/AVC, a slice can be ANY collection of >+> macroblocks scattered >+> around absolutely anywhere in the picture (by use of a >+> feature known as >+> a "slice group map"). >+> >+> In regard to section 5.1 VideoFreezePicture, I believe H.262 >+> (also known >+> as MPEG-2 Video) also supports a freeze picture release >+> within the ITU-T >+> extension. >+> >+> It is also possible to obtain random access recovery without a fast >+> update. This is sometimes called "gradual decoder refresh". See for >+> example the recovery point SEI message in H.264/AVC. >+> >+> Best Regards, >+> >+> Gary Sullivan >+> >+> >+> +> -----Original Message----- >+> +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On >+> +> Behalf Of Andrea Basso >+> +> Sent: Monday, July 07, 2003 2:34 PM >+> +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org >+> +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; >+> +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit >+> +> Levin; Roni Even; nismail@cisco.com >+> +> Subject: [AVT] Requirements draft on video control >+> +> >+> +> >+> +> Attached you will find draft-basso-avt-videoconreq-00.txt >+> +> >+> +> Abstract: >+> +> >+> +> A variety of communication services such as video >+> +> conferencing and video messaging rely on the capability of video >+> +> encoders and decoders to exchange control commands. This document >+> +> outlines this set of commands as well as the requirements for >+> +> their transport. >+> +> >+> +> Comments are more than welcome. >+> +> >+> +> >+> +> >+> +> >+> +> >+> +> Andrea Basso >+> +> NMS Communications >+> +> (732) 936-2118 >+> +> (See attached file: draft-basso-avt-videoconreq-00.zip) >+> +> >+> >+> >+> >+> >+> >+> > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 19:27:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28847 for ; Wed, 9 Jul 2003 19:27:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOKd-0000Yx-0p for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 19:26:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69NQcZA002153 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 19:26:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOK0-0000PN-G5; Wed, 09 Jul 2003 19:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOJd-0000Kd-RV for avt@optimus.ietf.org; Wed, 09 Jul 2003 19:25:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28812 for ; Wed, 9 Jul 2003 19:25:34 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOJc-0005BU-00 for avt@ietf.org; Wed, 09 Jul 2003 19:25:36 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19aOJb-0005BR-00 for avt@ietf.org; Wed, 09 Jul 2003 19:25:35 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19aOJb-0002By-00; Thu, 10 Jul 2003 00:25:35 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Thu, 10 Jul 2003 00:25:35 +0100 Message-ID: <1057793135.3f0ca46f5ad99@dlana.elec.gla.ac.uk> Date: Thu, 10 Jul 2003 00:25:35 +0100 To: John Lazzaro Cc: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna References: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> In-Reply-To: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John / Aaron / Ross, John, yes you are right when you state that the codebooks can change quite frequently, between tracks, and this is a function of the codec which the RTP stream must cope with. Your draft-lazzaro-avt-rtp-framing-contrans-01 looks like it could offer a good solution and I should track its development more closely. Ross / Aaron, the number of codebooks that can be found 'in the wild' is a reasonably large, but not infinite, number and the caching mechanism is meant to reduce the need to retransmit them each time. Having a general purpose streaming codebook is a reasonable suggestion, John and I discussed when we met, but it is uncertain if a fully generic one can be produced which will cater for all scenarios. Regards Phil Quoting John Lazzaro : > > > Aaron Colwell writes: > > I agree with Ross on this. It seems that these codebooks are causing too > > many problems that aren't worth dealing with. People have been suggesting > > getting the codebooks via HTTP, alternate TCP links, and all sorts of > > other methods. If your going to go that far why not just use HTTP to > > deliver the data. That way you are guaranteed to get everything in the > > right order. > > I think its just an instance of a general problem -- transport of > hybrid streams with two components: > > -- A steady flow of media information that can handle the > occassional packet loss episode gracefully and without > retransmission > > -- Occassional chunks of data, which can be sent well ahead of > its need, which needs reliability, and which is synchronous > to the media flow. > > So, I think its a good idea for RTP to offer solutions that work > in this domain. There are some studio-oriented uses of RTP MIDI > which fit into the model, and my motivation for doing > draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in > a general way, so that when things like Vorbis codebooks come > along, RTP has a way to support them. I really don't think that > posing the question as all-or-none -- RTP streaming or Shoutcast-esqe > pseudo-streaming -- benefits AVT, it will just spawn more HTTP > streaming implementations. > > That said: > > > The Vorbis folks > > should come up with a "streamable" profile that encodes the audio using > > predefined codebooks. > > This is a good option too -- my guess is that most Vorbis setups > will only need one codebook for the life of the stream, and that > need will be known in advance. A URL in the session description > to support HTTP download of that one codebook would be a way to > go, with perhaps a known set of "standard codebooks" codable by > speak tokens or by GUIDs for the MIME HTTP codebook object. > > ------------------------------------------------------------------------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro > ------------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 19:46:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29408 for ; Wed, 9 Jul 2003 19:46:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOcz-0002E7-4r for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 19:45:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Njb5F008552 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 19:45:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOcP-00028G-4T; Wed, 09 Jul 2003 19:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOcD-00027V-Gq for avt@optimus.ietf.org; Wed, 09 Jul 2003 19:44:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29334 for ; Wed, 9 Jul 2003 19:44:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOcB-0005Lj-00 for avt@ietf.org; Wed, 09 Jul 2003 19:44:47 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19aOcA-0005LD-00 for avt@ietf.org; Wed, 09 Jul 2003 19:44:46 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Wed, 09 Jul 2003 16:44:11 -0700 Date: Wed, 9 Jul 2003 16:51:25 -0700 (PDT) From: Aaron Colwell To: John Lazzaro cc: avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna In-Reply-To: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> Message-ID: References: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 9 Jul 2003, John Lazzaro wrote: > > > Aaron Colwell writes: > > I agree with Ross on this. It seems that these codebooks are causing too > > many problems that aren't worth dealing with. People have been suggesting > > getting the codebooks via HTTP, alternate TCP links, and all sorts of > > other methods. If your going to go that far why not just use HTTP to > > deliver the data. That way you are guaranteed to get everything in the > > right order. > > I think its just an instance of a general problem -- transport of > hybrid streams with two components: > > -- A steady flow of media information that can handle the > occassional packet loss episode gracefully and without > retransmission > > -- Occassional chunks of data, which can be sent well ahead of > its need, which needs reliability, and which is synchronous > to the media flow. > > So, I think its a good idea for RTP to offer solutions that work > in this domain. There are some studio-oriented uses of RTP MIDI > which fit into the model, and my motivation for doing > draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in > a general way, so that when things like Vorbis codebooks come > along, RTP has a way to support them. I really don't think that > posing the question as all-or-none -- RTP streaming or Shoutcast-esqe > pseudo-streaming -- benefits AVT, it will just spawn more HTTP > streaming implementations. When stated in these more general terms I can see your point about how this scenario could be useful. Another use may be a key stream for encrypted content that changes encryption keys often. You would want this data to be transmitted reliably and ensure that it gets there before the data that depends on it arrives. I did not mean to actually suggest the use of HTTP as a viable delivery mechanism instead of RTP. I don't really want more "Shoutcast-esqe pseudo-streaming" solutions either. I'll be a little more careful with comments like this. I'll take a look at the draft that you mentioned and send you any comments I may have. > > That said: > > > The Vorbis folks > > should come up with a "streamable" profile that encodes the audio using > > predefined codebooks. > > This is a good option too -- my guess is that most Vorbis setups > will only need one codebook for the life of the stream, and that > need will be known in advance. A URL in the session description > to support HTTP download of that one codebook would be a way to > go, with perhaps a known set of "standard codebooks" codable by > speak tokens or by GUIDs for the MIME HTTP codebook object. Hopefully they will embrace these ideas. I think it could simplify client implementations a bit. If they used just predefined codebooks or only used one codebook and specified it via SDP, Vorbis would be just like many other datatypes and would not require a lot of extra work to support in existing players. Aaron > > ------------------------------------------------------------------------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro > ------------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 20:06:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29988 for ; Wed, 9 Jul 2003 20:06:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOwM-0003v7-Ul for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 20:05:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A05cZD014995 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 20:05:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvl-0003nD-9z; Wed, 09 Jul 2003 20:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvZ-0003mm-4T for avt@optimus.ietf.org; Wed, 09 Jul 2003 20:04:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29926 for ; Wed, 9 Jul 2003 20:04:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOvX-0005Wp-00 for avt@ietf.org; Wed, 09 Jul 2003 20:04:47 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19aOvW-0005Wl-00 for avt@ietf.org; Wed, 09 Jul 2003 20:04:46 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.9) with ESMTP id h6A03Pgi040599 for ; Wed, 9 Jul 2003 17:04:44 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.9/Submit) id h6A03PLj040598; Wed, 9 Jul 2003 17:03:25 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20030709165921.00b806f0@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 09 Jul 2003 17:03:03 -0700 To: avt@ietf.org From: Ross Finlayson Subject: Re: [AVT] Vorbis RTP issues list for Vienna In-Reply-To: <1057793135.3f0ca46f5ad99@dlana.elec.gla.ac.uk> References: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , >Having a general purpose streaming codebook is a reasonable suggestion, >John and I discussed when we met, but it is uncertain if a fully generic >one can be produced which will cater for all scenarios. There doesn't have to be just one 'codebook for streaming'. Having a small number of pre-defined ones would be OK also. E.g., if there were <= 256 pre-defined 'codebooks for streaming', then you could use a 1-byte field within the RTP payload format to indicate which one. But I suspect that <= 16 pre-defined codebooks (i.e., 4 bits) would be enough. Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 9 20:26:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00606 for ; Wed, 9 Jul 2003 20:26:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aPFi-000579-3D for avt-archive@odin.ietf.org; Wed, 09 Jul 2003 20:25:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A0PcX5019658 for avt-archive@odin.ietf.org; Wed, 9 Jul 2003 20:25:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aPF7-00050M-LD; Wed, 09 Jul 2003 20:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aPEq-000502-1L for avt@optimus.ietf.org; Wed, 09 Jul 2003 20:24:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00602 for ; Wed, 9 Jul 2003 20:24:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aPEn-0005gE-00 for avt@ietf.org; Wed, 09 Jul 2003 20:24:41 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19aPEm-0005gB-00 for avt@ietf.org; Wed, 09 Jul 2003 20:24:40 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Wed, 09 Jul 2003 17:24:04 -0700 Date: Wed, 9 Jul 2003 17:31:18 -0700 (PDT) From: Aaron Colwell To: philkerr@elec.gla.ac.uk cc: John Lazzaro , avt@ietf.org Subject: Re: [AVT] Vorbis RTP issues list for Vienna In-Reply-To: <1057793135.3f0ca46f5ad99@dlana.elec.gla.ac.uk> Message-ID: References: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> <1057793135.3f0ca46f5ad99@dlana.elec.gla.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 10 Jul 2003 philkerr@elec.gla.ac.uk wrote: > Hi John / Aaron / Ross, > > John, yes you are right when you state that the codebooks can change quite > frequently, between tracks, and this is a function of the codec which the RTP > stream must cope with. Your draft-lazzaro-avt-rtp-framing-contrans-01 looks > like it could offer a good solution and I should track its development more > closely. > > Ross / Aaron, the number of codebooks that can be found 'in the wild' is a > reasonably large, but not infinite, number and the caching mechanism is > meant to > reduce the need to retransmit them each time. Having a general purpose > streaming codebook is a reasonable suggestion, John and I discussed > when we met, > but it is uncertain if a fully generic one can be produced which will > cater for all scenarios. Could a set of codebooks help? Perhaps you could predefine a set of standard codebooks that are close to ones that are in the wild. For any codebooks that don't match one of these, a predefined codebook could be specified, plus some sort of codebook diff. My guess is that if the predefined codebooks are pretty representative of codebooks in the wild, the diff should be rather small. There is still the problem of sending the diff when codebook changes mid-stream. I can't see a way around this other than either using a reliable transport for transmitting it or sending the diff's periodically. The diffs should be much smaller than the actual codebook so periodic sending of diffs won't be as bad as doing the same with the actual codebooks. I'll have to think about this a little more. I think my idea of a codebook translation tool could also help deal with all the files that are out in the wild. Whoever wants to stream the file can convert any existing file to one that uses one of the predefined codebooks. Aaron > > Regards > > Phil > > Quoting John Lazzaro : > > > > > > Aaron Colwell writes: > > > I agree with Ross on this. It seems that these codebooks are causing too > > > many problems that aren't worth dealing with. People have been suggesting > > > getting the codebooks via HTTP, alternate TCP links, and all sorts of > > > other methods. If your going to go that far why not just use HTTP to > > > deliver the data. That way you are guaranteed to get everything in the > > > right order. > > > > I think its just an instance of a general problem -- transport of > > hybrid streams with two components: > > > > -- A steady flow of media information that can handle the > > occassional packet loss episode gracefully and without > > retransmission > > > > -- Occassional chunks of data, which can be sent well ahead of > > its need, which needs reliability, and which is synchronous > > to the media flow. > > > > So, I think its a good idea for RTP to offer solutions that work > > in this domain. There are some studio-oriented uses of RTP MIDI > > which fit into the model, and my motivation for doing > > draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in > > a general way, so that when things like Vorbis codebooks come > > along, RTP has a way to support them. I really don't think that > > posing the question as all-or-none -- RTP streaming or Shoutcast-esqe > > pseudo-streaming -- benefits AVT, it will just spawn more HTTP > > streaming implementations. > > > > That said: > > > > > The Vorbis folks > > > should come up with a "streamable" profile that encodes the audio using > > > predefined codebooks. > > > > This is a good option too -- my guess is that most Vorbis setups > > will only need one codebook for the life of the stream, and that > > need will be known in advance. A URL in the session description > > to support HTTP download of that one codebook would be a way to > > go, with perhaps a known set of "standard codebooks" codable by > > speak tokens or by GUIDs for the MIME HTTP codebook object. > > > > ------------------------------------------------------------------------- > > John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley > > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro > > ------------------------------------------------------------------------- > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 10 03:03:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20286 for ; Thu, 10 Jul 2003 03:03:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVSO-0004jj-UP for avt-archive@odin.ietf.org; Thu, 10 Jul 2003 03:03:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A7389l018206 for avt-archive@odin.ietf.org; Thu, 10 Jul 2003 03:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVSH-0004it-Bc; Thu, 10 Jul 2003 03:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKRe-000559-H0 for avt@optimus.ietf.org; Wed, 09 Jul 2003 15:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16623; Wed, 9 Jul 2003 15:17:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKRd-0002Ah-00; Wed, 09 Jul 2003 15:17:37 -0400 Received: from [63.163.229.65] (helo=gateus.nmss.com) by ietf-mx with smtp (Exim 4.12) id 19aKRc-0002Ae-00; Wed, 09 Jul 2003 15:17:36 -0400 Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 9 Jul 2003 14:12:37 UT Subject: RE: [AVT] Requirements draft on video control To: "Gary Sullivan" Cc: "Andrea Basso" , avt@ietf.org, casner@acm.org, csp@csperkins.org, jo@tzi.uni-bremen.de, magnus.westerlund@ericsson.com, mmusic@ietf.org, nismail@cisco.com, "Orit Levin" , "Roni Even" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Wed, 9 Jul 2003 15:17:29 -0400 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.12 |February 13, 2003) at 07/09/2003 03:13:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Gary, here are some comments. > Some of it seems like it could use a bit of updating in that regard > (e.g., videofastupdateGOB). > Draft Recommendation H.241 is one good place to look for such > information. H.241 is very focused on H.264 and in very early stages in addressing Commands and Indications applicable to all codecs. If you look at the H.241 draft section 6 says: 6 Commands and Indications 6.1 C&I applicable to all video codecs For further study. We plan to monitor the evolution the H.241 and to update the ID accordingly if needed. >intra frames are also known as inter frames, which is >definitely not the case I do not think the text says this. Here is the sentence: Current coding schemes such as H.261 [2], H.263 [3], MPEG-1, 2,4 [5], H.264 [6] can encode video pictures as reference frames, also known as intra frames or predicted frames, also known as inter frames. >The terms "picture" and "frame" are also kind of >mixed up. For progressive video, a picture is identical to a frame. The difference appears for interlaced video only. The new text will use the term 'picture' only. >The characterization of a "slice" or "GOB" as being a "stripe" is not >really quite right. The text does not say "image stripe" says "stripe" and in particular it does not imply that such stripe goes border-to-border in the image (i.e. can cover a partial macroblock row) nor that is should only include a single macroblock row (i.e., can cover multiple partial rows as in H.261). Clarifications will be addressed in the new version of the draft. -A Andrea Basso NMS Communications (732) 936-2118 "Gary Sullivan" , , rosoft.com> , cc: , , 07/08/2003 08:03 PM , , "Orit Levin" , "Roni Even" , Subject: RE: [AVT] Requirements draft on video control Much of the content of this ID will look familiar to those with experience with ITU-T systems control specifications (such as H.245). Some of it seems like it could use a bit of updating in that regard (e.g., videofastupdateGOB). Draft Recommendation H.241 is one good place to look for such information. Section 3 is a bit confused in its terminology. For example it seems to say that intra frames are also known as inter frames, which is definitely not the case. It mixes the terms "predictive" and "prediction" and seems to consider a "reference" frame to be synonymous with an intra frame. The terms "picture" and "frame" are also kind of mixed up. A more consistent terminology would be as follows: An intra picture is a picture that can be decoded without first decoding any other picture. A predicted (or non-intra) picture is a picture that may require data from one or more previously-decoded pictures in order to be properly decoded. A reference picture is a picture that is stored in the decoder for use as a reference in the decoding process of some subsequent picture in the bitstream. A non-reference picture is a picture that is not used as a reference for the decoding process of any other picture in the bitstream. The concepts of intra versus non-Intra and reference versus non-reference are independent. A particular picture can (in general) be any one of the four types (intra reference, non-intra reference, intra non-reference, non-intra non-reference). A "fast update", also known as an "instantaneous decoder refresh", involves sending an intra picture and thereafter refraining from using any picture sent prior to that intra picture as a reference for the decoding process of any subsequent picture sent in the stream. In particular it is worth noting that some concepts that applied to some older codecs are not really valid in general and should be avoided (e.g., that a non-reference picture is called a B picture or that an intra picture is the same thing as a fast update or that an intra picture is always a reference picture). The characterization of a "slice" or "GOB" as being a "stripe" is not really quite right. For example, a single slice in MPEG-1, H.263 Annex O, or MPEG-4 can consist of a few macroblocks at the right edge of one row and a few macroblocks at the left edge of the next row (i.e., two distinct rectangular regions quite far apart from each other in the picture can be in a single slice). A GOB in H.261 CIF consists of THREE partial rows of macroblocks extending only halfway across a picture. And in H.264/AVC, a slice can be ANY collection of macroblocks scattered around absolutely anywhere in the picture (by use of a feature known as a "slice group map"). In regard to section 5.1 VideoFreezePicture, I believe H.262 (also known as MPEG-2 Video) also supports a freeze picture release within the ITU-T extension. It is also possible to obtain random access recovery without a fast update. This is sometimes called "gradual decoder refresh". See for example the recovery point SEI message in H.264/AVC. Best Regards, Gary Sullivan +> -----Original Message----- +> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On +> Behalf Of Andrea Basso +> Sent: Monday, July 07, 2003 2:34 PM +> To: avt@ietf.org; avt-admin@ietf.org; mmusic@ietf.org +> Cc: casner@acm.org; jo@tzi.uni-bremen.de; +> magnus.westerlund@ericsson.com; csp@csperkins.org; Orit +> Levin; Roni Even; nismail@cisco.com +> Subject: [AVT] Requirements draft on video control +> +> +> Attached you will find draft-basso-avt-videoconreq-00.txt +> +> Abstract: +> +> A variety of communication services such as video +> conferencing and video messaging rely on the capability of video +> encoders and decoders to exchange control commands. This document +> outlines this set of commands as well as the requirements for +> their transport. +> +> Comments are more than welcome. +> +> +> +> +> +> Andrea Basso +> NMS Communications +> (732) 936-2118 +> (See attached file: draft-basso-avt-videoconreq-00.zip) +> _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 10 03:25:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20965 for ; Thu, 10 Jul 2003 03:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVna-0006LJ-Kb for avt-archive@odin.ietf.org; Thu, 10 Jul 2003 03:25:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A7P2Rf024380 for avt-archive@odin.ietf.org; Thu, 10 Jul 2003 03:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVnZ-0006L7-PC; Thu, 10 Jul 2003 03:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVmr-0006Ju-06 for avt@optimus.ietf.org; Thu, 10 Jul 2003 03:24:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20950; Thu, 10 Jul 2003 03:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVmo-00009K-00; Thu, 10 Jul 2003 03:24:14 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19aVmn-00009G-00; Thu, 10 Jul 2003 03:24:13 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6A7ODIi024452; Thu, 10 Jul 2003 09:24:13 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XJHS49; Thu, 10 Jul 2003 09:24:13 +0200 Message-ID: <3F0D149A.70807@ericsson.com> Date: Thu, 10 Jul 2003 09:24:10 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org, mmusic@ietf.org Subject: Re: [AVT] Requirements draft on video control References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I have some remarks around the posting of these messages. First is the receipients list, its way to long. I would recommed that we drop it to only the mailing lists. I assume that all persons being directly addressed are in fact part at least one of the lists. The list is in fact so long that it get caugth in the mailing list software and needs approval for every mail. The second thing is the crosspostings. We should move to a single list, I propose AVT as it has the most subscribers while I know there is need to include both communities. Due to the crosspostings, if a person is not memeber of both list it will get caught in that lists filter and need manual approval by the chairs. If you need to inform some other list about a subject, the recommended way is to post to each list individually and state that any discussion will take place on one of these list. Third, don't post to avt-admin@ietf.org unless it has something to do with administrative matters regarding the mailing list. We chairs are members of the list and don't need to get a second copy through the avt-admin@ietf.org address. In fact before trimming this receipient list I should have received 4 copies of each mail. So please follow this recommendations any you will make us chairs life easier. Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 10 09:48:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01984 for ; Thu, 10 Jul 2003 09:48:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abmJ-0000u8-Tl for avt-archive@odin.ietf.org; Thu, 10 Jul 2003 09:48:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ADm7ZX003472 for avt-archive@odin.ietf.org; Thu, 10 Jul 2003 09:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abmD-0000to-GO; Thu, 10 Jul 2003 09:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abll-0000tY-Ns for avt@optimus.ietf.org; Thu, 10 Jul 2003 09:47:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01960 for ; Thu, 10 Jul 2003 09:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ablj-0002xE-00 for avt@ietf.org; Thu, 10 Jul 2003 09:47:31 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19abli-0002wh-00 for avt@ietf.org; Thu, 10 Jul 2003 09:47:31 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2003 06:45:03 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn3-457.cisco.com [10.21.65.201]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6ADkvpa014912; Thu, 10 Jul 2003 06:46:58 -0700 (PDT) Message-Id: <5.1.1.5.2.20030710063437.05a8ba48@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 10 Jul 2003 06:46:56 -0700 To: Aaron Colwell From: Mark Baugher Subject: Re: [AVT] Vorbis RTP issues list for Vienna Cc: John Lazzaro , avt@ietf.org, mcgrew@cisco.com In-Reply-To: References: <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> <200307092202.h69M2gb27052@snap.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 04:51 PM 7/9/2003 -0700, Aaron Colwell wrote: >On Wed, 9 Jul 2003, John Lazzaro wrote: > > > > > > Aaron Colwell writes: > > > I agree with Ross on this. It seems that these codebooks are causing too > > > many problems that aren't worth dealing with. People have been suggesting > > > getting the codebooks via HTTP, alternate TCP links, and all sorts of > > > other methods. If your going to go that far why not just use HTTP to > > > deliver the data. That way you are guaranteed to get everything in the > > > right order. > > > > I think its just an instance of a general problem -- transport of > > hybrid streams with two components: > > > > -- A steady flow of media information that can handle the > > occassional packet loss episode gracefully and without > > retransmission > > > > -- Occassional chunks of data, which can be sent well ahead of > > its need, which needs reliability, and which is synchronous > > to the media flow. > > > > So, I think its a good idea for RTP to offer solutions that work > > in this domain. There are some studio-oriented uses of RTP MIDI > > which fit into the model, and my motivation for doing > > draft-lazzaro-avt-rtp-framing-contrans-01 is to support those in > > a general way, so that when things like Vorbis codebooks come > > along, RTP has a way to support them. I really don't think that > > posing the question as all-or-none -- RTP streaming or Shoutcast-esqe > > pseudo-streaming -- benefits AVT, it will just spawn more HTTP > > streaming implementations. > >When stated in these more general terms I can see your point about how >this scenario could be useful. Another use may be a key stream for >encrypted content that changes encryption keys often. You would want this >data to be transmitted reliably and ensure that it gets there before the >data that depends on it arrives. The keys to the data need to be delivered "at least as reliably" as the data but not necessarily "reliably." Putting keys in the data packet is one such method, but we are not likely to use this method in RTP (poor separation of functions, no third-party key mgt, etc). But there have been proposals for using RTCP or SRTCP. Rather than extend RTCP or SRTCP for this purpose, however, a better approach IMHO is to put the key in the SDP and send it "at least as reliably" as the SRTP. The SDP must of course be authenticated/integrity-checked and encrypted. >I did not mean to actually suggest the use of HTTP as a viable delivery >mechanism instead of RTP. I don't really want more "Shoutcast-esqe >pseudo-streaming" solutions either. I'll be a little more careful with >comments like this. It's hard to engineer a network where media flows masquerade as something else. Mark >I'll take a look at the draft that you mentioned and send you any comments >I may have. > > > > > That said: > > > > > The Vorbis folks > > > should come up with a "streamable" profile that encodes the audio using > > > predefined codebooks. > > > > This is a good option too -- my guess is that most Vorbis setups > > will only need one codebook for the life of the stream, and that > > need will be known in advance. A URL in the session description > > to support HTTP download of that one codebook would be a way to > > go, with perhaps a known set of "standard codebooks" codable by > > speak tokens or by GUIDs for the MIME HTTP codebook object. > >Hopefully they will embrace these ideas. I think it could simplify client >implementations a bit. If they used just predefined codebooks or only used >one codebook and specified it via SDP, Vorbis would be just like many >other datatypes and would not require a lot of extra work to support in >existing players. > >Aaron > > > > > ------------------------------------------------------------------------- > > John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley > > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro > > ------------------------------------------------------------------------- > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 11 08:21:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27115 for ; Fri, 11 Jul 2003 08:21:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19awtj-00054A-Nb for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 08:21:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BCLBiF019466 for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 08:21:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19awtZ-000533-Av; Fri, 11 Jul 2003 08:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19awtD-00052V-JM for avt@optimus.ietf.org; Fri, 11 Jul 2003 08:20:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27094 for ; Fri, 11 Jul 2003 08:20:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19awtC-0005F8-00 for avt@ietf.org; Fri, 11 Jul 2003 08:20:38 -0400 Received: from h004.c015.snv.cp.net ([209.228.35.119] helo=c015.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19awtB-0005F5-00 for avt@ietf.org; Fri, 11 Jul 2003 08:20:37 -0400 Received: (cpmta 20898 invoked from network); 11 Jul 2003 05:20:33 -0700 Received: from 195.242.54.251 (HELO pavarotti) by smtp.globalipsound.com (209.228.35.119) with SMTP; 11 Jul 2003 05:20:33 -0700 X-Sent: 11 Jul 2003 12:20:33 GMT Reply-To: From: "Alan Duric" To: Cc: "'Colin Perkins'" , , Date: Fri, 11 Jul 2003 14:19:09 +0200 Message-ID: <003901c347a6$a5d3cbd0$fb36f2c3@global.int> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] Agenda item RTP Payload Format for iLBC Speech/iLBC codec Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, here is some info about the agenda item: RTP Payload Format for iLBC Speech/iLBC codec (Duric) 15min draft-ietf-avt-rtp-ilbc-02.txt draft-ietf-avt-ilbc-codec-02.txt and the issues that will be addressed/discussed at the meeting on Monday, July the 14th: - details about the changes made from 01 versions - feedback and results of the iLBC codec spec review - resolve potential issue with the use of "mode" parameter in SDP "a=fmtp" attribute, for the RTP Payload Format draft - next steps - time slot for Q&A Drafts are available under the following links: http://www.ietf.org/internet-drafts/draft-ietf-avt-ilbc-codec-02.txt - iLBC codec spec http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ilbc-02.txt - RTP payload profile for iLBC Best regards, Alan ----------------------------------------------------------------------- | www.ilbcfreeware.org - For the Internet World, Royalty Free for all | ----------------------------------------------------------------------- ________________________________________________________________________ ____________ Cuius rei demonstrationem mirabilem sane detexi hanc marginis exiguitas non caperet. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 11 11:13:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03070 for ; Fri, 11 Jul 2003 11:13:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aza9-00022b-Rh for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 11:13:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BFD9v3007828 for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 11:13:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azZz-00021N-Kd; Fri, 11 Jul 2003 11:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19azZI-00020W-B4 for avt@optimus.ietf.org; Fri, 11 Jul 2003 11:12:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03021 for ; Fri, 11 Jul 2003 11:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19azZG-0006La-00 for avt@ietf.org; Fri, 11 Jul 2003 11:12:14 -0400 Received: from ppp-62-245-161-201.mnet-online.de ([62.245.161.201] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19azZ9-0006LJ-00 for avt@ietf.org; Fri, 11 Jul 2003 11:12:07 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6BFBVkf001168; Fri, 11 Jul 2003 11:11:34 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Thu, 10 Jul 2003 13:23:46 +0200 From: Colin Perkins To: Mitsuyuki Hatanaka Cc: avt@ietf.org Subject: Re: [AVT] Revised internet draft of RTP Payload Format for ATRAC-X Message-Id: <20030710132346.3a6ad5a1.csp@csperkins.org> In-Reply-To: <5.1.1.8.2.20030702104701.00e81958@43.13.117.111> References: <5.1.1.8.2.20030702104701.00e81958@43.13.117.111> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --> Mitsuyuki Hatanaka writes: > We have submitted our revised internet draft as > "draft-hatanaka-avt-rtp-atracx-02.txt". You will be able to get it from > the on-line Internet-Drafts directories. > > We do not have a plan to discuss in AVT group at Vienna meeting, > because this is slight changing version. > > The revised items are as follows. > (1) Changing a terminology of "StreamID" to "ElementID" in section 2.3. > (2) Changing a unit of LENGTH "byte" to "bit" in section 2.3. > (3) Changing a unit of time stamp "millisecond of a presentation time" > to "sample number of a presentation time" in section 7. > (4) Addition of the description about multicasting consideration in > section 8. > > We will evaluate the defined functions of this payload with the practical > test application until next meeting, and we would like to reflect the > results in next document. Thanks for submitting the update, I see that some of the concerns we discussed at the San Francisco IETF meeting have been addressed (in particular, the use of the sample clock for presentation time rather than milliseconds). In addition to including the results of your practical tests, do you have plans to further update the draft? If I recall correctly, there was some confusion about the terminology used, which it would be useful to clarify. Regards, -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 11 15:59:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14493 for ; Fri, 11 Jul 2003 15:59:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b42w-0006tj-Ms for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 15:59:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJxAZJ026511 for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 15:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b42o-0006t1-03; Fri, 11 Jul 2003 15:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b42I-0006sh-9T for avt@optimus.ietf.org; Fri, 11 Jul 2003 15:58:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14457 for ; Fri, 11 Jul 2003 15:58:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b42G-0001aH-00 for avt@ietf.org; Fri, 11 Jul 2003 15:58:28 -0400 Received: from ppp-62-245-211-162.mnet-online.de ([62.245.211.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19b42F-0001Zy-00 for avt@ietf.org; Fri, 11 Jul 2003 15:58:28 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6BJvJkf004615; Fri, 11 Jul 2003 15:57:25 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Fri, 11 Jul 2003 21:57:19 +0200 From: Colin Perkins To: "Michael A. Ramalho" Cc: philkerr@elec.gla.ac.uk, avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 Message-Id: <20030711215719.453e6118.csp@csperkins.org> In-Reply-To: <4.3.2.7.2.20030709150608.017a3f08@mira-sjc5-9.cisco.com> References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <4.3.2.7.2.20030709150608.017a3f08@mira-sjc5-9.cisco.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael, --> "Michael A. Ramalho" writes: >--> Colin Perkins writes: >>- The use of the M bit in the RTP header to signify comfort noise is also >> unusual. This is not necessarily inappropriate, but it is important >> to consider if the advantages of this use outweigh the costs of being >> different to other audio payload formats (which use the M bit to >> signal the first packet after a silent period). > > This may be contrary to the guidance I got from Steve a while back. > > A little background first .. > > From RFC 1889: > > "marker (M): 1 bit The interpretation of the marker is defined by a > profile. It > is intended to allow significant events such as frame boundaries to be > marked in the packet stream. A profile may define additional marker bits > or specify that there is no marker bit by changing the number of bits in > the payload type field (see Section 5.3)." > > But from RFC 1890 (Audio and Video Conferences with Minimal Control > that can be used with G.711): > > "For applications which send no packets during silence, the first packet > of a talk spurt (first packet after a silence period) is distinguished by > setting the marker bit in the RTP data header. Applications without > silence suppression set the bit to zero." > > Then Steve said on 2/2/2003 (in regards to the RGL codec) ... > > "I believe you should follow the marker bit convention as specified in > RFC 1890. The RGL codec is likely to be used in implementations that > also use other payload formats (such as PCMU) specified in RFC 1890, > and the behavior should be consistent." > > Thus, since I think that speex will also be used in similar > deployments (i.e., packet voice) ... I would think Steve's > guidance should apply here as well. > > My question to the speex authors is that if they simply define > the periods in which they desire to send comfort noise to be > *identically* the same definition as a RFC 1890 "beginning or > ending of a talk spurt", then there would be no inconsistency > in the bit's meaning. I'm not sure I understand your suggestion. I was expecting a period of comfort noise to be treated identically to a silent period. Hence the M bit would be set on the first packet after the comfort noise (and not set on any of the comfort noise packet). -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 11 16:22:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15137 for ; Fri, 11 Jul 2003 16:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4P7-0008NK-1K for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 16:22:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BKM5wX032190 for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 16:22:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4P3-0008MS-Az; Fri, 11 Jul 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4O7-0008Ls-Fa for avt@optimus.ietf.org; Fri, 11 Jul 2003 16:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15092 for ; Fri, 11 Jul 2003 16:20:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4O5-0001ms-00 for avt@ietf.org; Fri, 11 Jul 2003 16:21:01 -0400 Received: from ppp-62-245-161-226.mnet-online.de ([62.245.161.226] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19b4O4-0001mc-00 for avt@ietf.org; Fri, 11 Jul 2003 16:21:01 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6BKK3kf004933; Fri, 11 Jul 2003 16:20:04 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Fri, 11 Jul 2003 22:20:03 +0200 From: Colin Perkins To: philkerr@elec.gla.ac.uk Cc: avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 Message-Id: <20030711222003.5ca749fe.csp@csperkins.org> In-Reply-To: <1057791436.3f0c9dcc90ee7@dlana.elec.gla.ac.uk> References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <20030709110522.1217e183.csp@csperkins.org> <1057791436.3f0c9dcc90ee7@dlana.elec.gla.ac.uk> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, --> philkerr@elec.gla.ac.uk writes: ... > Quoting Colin Perkins : > > --> philkerr@elec.gla.ac.uk writes: > > > Dear all, > > > > > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > > > > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > > > > > Comments and feedback welcomed. > > > > I have a number of questions and comments: ... > > - The definition of the Padding bit in the RTP header is unusual. It > > may be better to state that padding MAY be used in the usual RTP > > manner, unless there is a specific reason why a different padding > > scheme is needed? > > Changing the Padding bit to MAY should be fine. The main issue is the text "P is set if the total packet size is less than the MTU" which implies that padding is used to bring the packet size up to the MTU. I'm assuming that is not intended! > > - The use of the M bit in the RTP header to signify comfort noise is > > also > > unusual. This is not necessarily inappropriate, but it is important > > to consider if the advantages of this use outweigh the costs of being > > different to other audio payload formats (which use the M bit to > > signal the first packet after a silent period). > > Its use was suggested by Henning Schulzrinne to the other Speex draft > authors and I've based it on their notes and Section 4.1 of RFC 1890. If > there is some discrepency in its use, as highlighted in the feedback by > Michael Ramalho, then we may need to look at this section again to > determine best practice. Does my reply to Michael clarify? > > - The definition of the timestamp says "Speex uses 20 msec frames and a > > variable sampling rate clock". Does this mean that the sample rate > > can change at anytime within a session? Or is the sample rate chosen > > from one of a number of values, and then fixed within the session? > > There is a fixed range of values for the sample rate but the rate may > change mid session. It's easier from the point of view of RTP and signalling in SDP if each different sample rate is sent using a different payload type number. In SDP, something like: m=audio 49170 RTP/AVP 97 98 a=rtpmap:97 speex/8000 a=rtpmap:98 speex/16000 Might be useful to make this mandatory in the draft? > > - Section 3.2 is unclear if the bit rate and sample rate are coupled. > > Can > > Speex vary the compression ratio to change the bit rate without > > changing the sampling rate? > > I will need to check this just to make sure. > ... > > - Section 6 (use with H.323) is not appropriate in an IETF document. > > You > > can include a reference to an ITU - or other - document explaining > > how to use Speex with H.323, but the IETF can't mandate use of H.245 > > parameters. > > Agreed. I presume we can also link back to a Speex document if further > explanation is required, with the usual proviso about linking to URLs as > mentioned in the ID-nits. Correct. How is Speex itself being referenced? Cheers, -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 11 16:55:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16466 for ; Fri, 11 Jul 2003 16:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4v2-0002Yk-MS for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 16:55:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BKt4hn009837 for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 16:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4v0-0002Xr-KK; Fri, 11 Jul 2003 16:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4ui-0002XA-Uq for avt@optimus.ietf.org; Fri, 11 Jul 2003 16:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16444 for ; Fri, 11 Jul 2003 16:54:40 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4ug-0002FF-00 for avt@ietf.org; Fri, 11 Jul 2003 16:54:42 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19b4ug-0002FB-00 for avt@ietf.org; Fri, 11 Jul 2003 16:54:42 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19b4ue-0001vk-00; Fri, 11 Jul 2003 21:54:40 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Fri, 11 Jul 2003 21:54:40 +0100 Message-ID: <1057956880.3f0f24106b226@dlana.elec.gla.ac.uk> Date: Fri, 11 Jul 2003 21:54:40 +0100 To: Colin Perkins Cc: avt@ietf.org Subject: Re: [AVT] draft-herlein-speex-rtp-profile-01 References: <1057175019.3f0335eb5bf7c@dlana.elec.gla.ac.uk> <20030709110522.1217e183.csp@csperkins.org> <1057791436.3f0c9dcc90ee7@dlana.elec.gla.ac.uk> <20030711222003.5ca749fe.csp@csperkins.org> In-Reply-To: <20030711222003.5ca749fe.csp@csperkins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thanks Colin, Quoting Colin Perkins : > Hi, > > --> philkerr@elec.gla.ac.uk writes: > ... > > Quoting Colin Perkins : > > > --> philkerr@elec.gla.ac.uk writes: > > > > Dear all, > > > > > > > > An -01 update to draft-herlein-speex-rtp-profile is now available: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-herlein-speex-rtp-profile-01.txt > > > > > > > > Comments and feedback welcomed. > > > > > > I have a number of questions and comments: > ... > > > - The definition of the Padding bit in the RTP header is unusual. It > > > may be better to state that padding MAY be used in the usual RTP > > > manner, unless there is a specific reason why a different padding > > > scheme is needed? > > > > Changing the Padding bit to MAY should be fine. > > The main issue is the text "P is set if the total packet size is less than > the MTU" which implies that padding is used to bring the packet size up to > the MTU. I'm assuming that is not intended! It was, but can be changed so it is not intended. > > > > - The use of the M bit in the RTP header to signify comfort noise is > > > also > > > unusual. This is not necessarily inappropriate, but it is important > > > to consider if the advantages of this use outweigh the costs of being > > > different to other audio payload formats (which use the M bit to > > > signal the first packet after a silent period). > > > > Its use was suggested by Henning Schulzrinne to the other Speex draft > > authors and I've based it on their notes and Section 4.1 of RFC 1890. If > > there is some discrepency in its use, as highlighted in the feedback by > > Michael Ramalho, then we may need to look at this section again to > > determine best practice. > > Does my reply to Michael clarify? Yes. > > > > - The definition of the timestamp says "Speex uses 20 msec frames and a > > > variable sampling rate clock". Does this mean that the sample rate > > > can change at anytime within a session? Or is the sample rate chosen > > > from one of a number of values, and then fixed within the session? > > > > There is a fixed range of values for the sample rate but the rate may > > change mid session. > > It's easier from the point of view of RTP and signalling in SDP if each > different sample rate is sent using a different payload type number. In > SDP, something like: > > m=audio 49170 RTP/AVP 97 98 > a=rtpmap:97 speex/8000 > a=rtpmap:98 speex/16000 > > Might be useful to make this mandatory in the draft? Agreed. > > > > - Section 3.2 is unclear if the bit rate and sample rate are coupled. > > > Can > > > Speex vary the compression ratio to change the bit rate without > > > changing the sampling rate? > > > > I will need to check this just to make sure. > > > ... > > > - Section 6 (use with H.323) is not appropriate in an IETF document. > > > You > > > can include a reference to an ITU - or other - document explaining > > > how to use Speex with H.323, but the IETF can't mandate use of H.245 > > > parameters. > > > > Agreed. I presume we can also link back to a Speex document if further > > explanation is required, with the usual proviso about linking to URLs as > > mentioned in the ID-nits. > > Correct. How is Speex itself being referenced? A reference needs to be added pointing back to the website. Cheers Phil > > Cheers, > -- > Colin Perkins > csp@csperkins.org > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 11 19:54:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25672 for ; Fri, 11 Jul 2003 19:54:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7iM-0006Kh-4M for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 19:54:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BNsALB024339 for avt-archive@odin.ietf.org; Fri, 11 Jul 2003 19:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7iC-0006Jt-U2; Fri, 11 Jul 2003 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7hH-0006JV-VH for avt@optimus.ietf.org; Fri, 11 Jul 2003 19:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25600 for ; Fri, 11 Jul 2003 19:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7hF-00055R-00 for avt@ietf.org; Fri, 11 Jul 2003 19:53:01 -0400 Received: from mail6.fw-sj.sony.com ([160.33.82.73]) by ietf-mx with esmtp (Exim 4.12) id 19b7hE-000554-00 for avt@ietf.org; Fri, 11 Jul 2003 19:53:01 -0400 Received: from mail2.sjc.in.sel.sony.com (mail2.sjc.in.sel.sony.com [43.134.1.111]) by mail6.fw-sj.sony.com (8.8.8/8.8.8) with ESMTP id XAA11348; Fri, 11 Jul 2003 23:52:21 GMT Received: by mail2.sjc.in.sel.sony.com id XAA22838; Fri, 11 Jul 2003 23:52:21 GMT Received: by us-sj-xims-2.am.sony.com with Internet Mail Service (5.5.2650.21) id <338PG3GZ>; Fri, 11 Jul 2003 16:52:20 -0700 Message-ID: <0DE752C748D0D211A6BE0090272B960B07848654@us-sj-xmsg-2.am.sony.com> From: "Edwards, Eric" To: "'Colin Perkins'" , "Edwards, Eric" Cc: avt@ietf.org, casner@acm.org, magnus.westerlund@ericsson.com Date: Fri, 11 Jul 2003 16:52:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [AVT] RE: draft-ietf-avt-rtp-jpeg2000-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear Colin and all, Sorry for the delay. Unfortunately, my Sony colleagues and I are tied up for the next few weeks. So, we will not be able to make all necessary updates to the jp2/rtp draft for the Vienna meeting. We should be able to post an updated version in about two weeks. As to your questions, my colleague has forwarded these answers - > > - Section 5.1 seems to imply that JPEG 2000 error resilience markers are > only used with non-intelligent packetization. Is this correct? Are the > error resilience markers not useful if the JPEG stream is intelligently > packetized? The first sentence is not true. In non-intelligent packetization, a serious quality distortion will be occured without JPEG 2000 error resilience markers, but it does not imply that error resilience markers are only used with non-intelligent packetization. The error resilient markers are also useful with intelligent packetization. > - Is non-intelligent packetization a requirement? The situations where it > will be useful seem very limited. Non-intelligent packetization is not always required (optional) at a sender, but is required at a receiver. It is true that the situations where non-intelligent packetization will be used are limited, but a receiver who received the non-intelligent packets must process the packets properly. > - The extension mechanism in Section 8 is not used. I suggest removing it > and marking the X bit in the payload header as "reserved". We agree. -> it is an item to change in the next version. > - The second paragraph of Section 9 is not appropriate, since the payload > format cannot specify the type of video content to be transported. Are > there no ways in which a malicious sender can disrupt the receiver? It is entirely correct. I will refer to other drafts and find the better expressions. > - In addition to the MIME type registration, the draft should include a > description of how the MIME type is mapped to SDP (Section 8.2 of the > H.264 payload format is a good example). We agree. -> it is another item to change in the next version. > - Section 10 may be better written as an informative appendix? We agree. -> it is also an item to change in the next version. > - It may be useful to include some examples, showing the complete packets > with all headers and data (including the RTP headers). We agree. -> it is also an item to change in the next version I will proof-read for clarity before we post the next draft. Best regards, Eric -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Tuesday, July 08, 2003 10:28 AM To: Edwards, Eric Cc: avt@ietf.org; casner@acm.org; magnus.westerlund@ericsson.com Subject: Re: draft-ietf-avt-rtp-jpeg2000-03.txt Eric, --> "Edwards, Eric" writes: > The Internet-Draft - draft-ietf-avt-rtp-jpeg2000-03.txt - has been > posted. > > Some time passed before this version was submitted. Most of the time was > spent discussing if potential reconciliation with work that was taking > place in ISO/IEC JTC1 SC 29 WG 01 (JPEG) was in order. After lengthy > discussions it was agreed by the experts in WG 01 that there were > different goals and application areas targeted for our respective work > and that the JP2/RTP proposal (draft-ietf-avt-rtp-jpeg2000-03.txt) should > move forward in IETF as is. > > So at this stage we are ready to move to Last Call if the AVT experts > have no objections to the current draft. > > Please advise and comment. I have a number of comments with regards to this draft: - Section 5.1 seems to imply that JPEG 2000 error resilience markers are only used with non-intelligent packetization. Is this correct? Are the error resilience markers not useful if the JPEG stream is intelligently packetized? - Is non-intelligent packetization a requirement? The situations where it will be useful seem very limited. - The extension mechanism in Section 8 is not used. I suggest removing it and marking the X bit in the payload header as "reserved". - The second paragraph of Section 9 is not appropriate, since the payload format cannot specify the type of video content to be transported. Are there no ways in which a malicious sender can disrupt the receiver? - In addition to the MIME type registration, the draft should include a description of how the MIME type is mapped to SDP (Section 8.2 of the H.264 payload format is a good example). - Section 10 may be better written as an informative appendix? - It may be useful to include some examples, showing the complete packets with all headers and data (including the RTP headers). I would also urge a careful proof-reading of the draft for both quality of English, clarity of specification, and appropriate use of the requirements language in RFC 2119. -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jul 12 02:46:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27509 for ; Sat, 12 Jul 2003 02:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bE96-0006Ti-B4 for avt-archive@odin.ietf.org; Sat, 12 Jul 2003 02:46:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6C6kCOK024900 for avt-archive@odin.ietf.org; Sat, 12 Jul 2003 02:46:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bE8u-0006Sn-Kw; Sat, 12 Jul 2003 02:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bBIs-0002L5-Fo for avt@optimus.ietf.org; Fri, 11 Jul 2003 23:44:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05075 for ; Fri, 11 Jul 2003 23:44:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bBIq-0007YP-00 for avt@ietf.org; Fri, 11 Jul 2003 23:44:04 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19bBIp-0007Xv-00 for avt@ietf.org; Fri, 11 Jul 2003 23:44:03 -0400 Received: from tmima-w2k01.cisco.com (rtp-vpn1-408.cisco.com [10.82.225.152]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6C3hM0s005010; Fri, 11 Jul 2003 23:43:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20030711182950.0303f2a8@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Jul 2003 20:41:24 -0700 To: Stephen Casner , avt@ietf.org From: Tmima Koren Cc: RFC Editor , , , , Allison Mankin , Jon Peterson , , , Tmima Koren In-Reply-To: <20030710152138.H4360-100000@oak.packetdesign.com> References: <4.3.2.7.2.20030703143001.02a60310@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_25267062==_.ALT" Subject: [AVT] Proposed change to Enhanced CRTP Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --=====================_25267062==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed We'd like to propose a change to the Enhanced CRTP draft, draft-ietf-avt-crtp-enhance-07.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-07.txt One of the enhancements is to add a Headers Checksum (HDRCKSUM) when UDP checksum is not present (see section 2.2). The UDP checksum is used by the decompressor to periodically validate the reconstructed packets. When not present, a HDRCKSUM may be inserted by the compressor replacing the missing UDP checksum. The decompressor removes the HDRCKSUM after validating the reconstructed packet. Currently the HDRCKSUM covers the pseudo-IP header, the UDP header and the fixed part of the RTP header (first 12 bytes). Those are the only parts of the reconstructed packet that can be validated by the HDRCKSUM. The CSRC list is not included in the HDRCKSUM. We propose to include the CSRC list in the HDRCKSUM since the CSRC list is part of the header compression context. The CSRC list is stored at the decompressor context and inserted to the restored packets. If the HDRCKSUM does not cover the CSRC list and the CSRC list at the decompressor is errored, a bad CSRC list will be restored into multiple packets until the CSRC list changes and is resent by the compressor as an update. If the HDRCKSUM covers the CSRC list, an error in the CSRC list will be caught early and corrected. When there is a change in the CSRC list, the CSRC list is sent as an update to the context. The CSRC list should be treated in the same way as the other context updating changes and be included in the HDRCKSUM. On the other hand, adding the CSRC list to the HDRCKSUM requires more processing calculating the HDRCKSUM. Also if the accuracy of the CSRC list is not crucial and the CSRC list is included in the HDRCKSUM, then an error in the CSRC list will result in dropping a few packets while the contexts are getting synchronized. The proposed change to the text is as follows: Old: The HDRCKSUM is calculated in the same way as a UDP checksum except that it does not cover all of the UDP data. That is, the HDRCKSUM is the 16-bit one's complement of the one's complement sum of the pseudo-IP header (as defined for UDP), the UDP header, and the first 12 bytes of the UDP data which are assumed to hold the fixed part of an RTP header. The extended part of the RTP header and the RTP data will not be included in the HDRCKSUM. New: The HDRCKSUM is calculated in the same way as a UDP checksum except that it does not cover all of the UDP data. That is, the HDRCKSUM is the 16-bit one's complement of the one's complement sum of the pseudo-IP header (as defined for UDP), the UDP header, the first ^^^^ 12 bytes of the UDP data which are assumed to hold the fixed part of an RTP header, and the CSRC list. ^^^^^^^^^^^^^^^^^^^ The extended part of the RTP header beyond the CSRC list and the RTP data ^^^^^^^^^^^^^^^^^^^^ will not be included in the HDRCKSUM. --=====================_25267062==_.ALT Content-Type: text/html; charset="us-ascii"

We'd like to propose a change to the Enhanced CRTP draft, draft-ietf-avt-crtp-enhance-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-07.txt

One of the enhancements is to add a Headers Checksum (HDRCKSUM) when UDP checksum is not present (see section 2.2).
The UDP checksum is used by the decompressor to periodically validate the reconstructed packets. When not present,
a HDRCKSUM may be inserted by the compressor replacing the missing UDP checksum. The decompressor removes the HDRCKSUM after validating the reconstructed packet.

Currently the HDRCKSUM covers the pseudo-IP header, the UDP header and the fixed part of the RTP header (first 12 bytes).
Those are the only parts of the reconstructed packet that can be validated by the HDRCKSUM.
The CSRC list is not included in the HDRCKSUM.

We propose to include the CSRC list in the HDRCKSUM since the CSRC list is part of the header compression context.

The CSRC list is stored at the decompressor context and inserted to the restored packets. If the HDRCKSUM does not cover the CSRC list and the CSRC list at the decompressor is errored, a bad CSRC list will be restored into multiple packets until the CSRC
list changes and is resent by the compressor as an update.
If the HDRCKSUM covers the CSRC list, an error in the CSRC list will be caught early and corrected.

When there is a change in the CSRC list, the CSRC list is sent as an update to the context.
The CSRC list should be treated in the same way as the other context updating changes and be included in the HDRCKSUM.

On the other hand, adding the CSRC list to the HDRCKSUM requires more processing calculating the HDRCKSUM. Also if
the accuracy of the CSRC list is not crucial and the CSRC list is included in the HDRCKSUM, then an error in the CSRC list
will result in dropping a few packets while the contexts are getting synchronized.


The proposed change to the text is as follows:

Old:

   The HDRCKSUM is calculated in the same way as a UDP checksum except
   that it does not cover all of the UDP data.  That is, the HDRCKSUM is
   the 16-bit one's complement of the one's complement sum of the
   pseudo-IP header (as defined for UDP), the UDP header, and the first
   12 bytes of the UDP data which are assumed to hold the fixed part of
   an RTP header.  The extended part of the RTP header and the RTP data
   will not be included in the HDRCKSUM.

New:

   The HDRCKSUM is calculated in the same way as a UDP checksum except
   that it does not cover all of the UDP data.  That is, the HDRCKSUM is
   the 16-bit one's complement of the one's complement sum of the
   pseudo-IP header (as defined for UDP), the UDP header,     the first
                                                          ^^^^
   12 bytes of the UDP data which are assumed to hold the fixed part of
   an RTP header, and the CSRC list.
                ^^^^^^^^^^^^^^^^^^^
   The extended part of the RTP header beyond the CSRC list and the RTP data
                                       ^^^^^^^^^^^^^^^^^^^^
   will not be included in the HDRCKSUM.
 --=====================_25267062==_.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jul 12 12:02:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24950 for ; Sat, 12 Jul 2003 12:02:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bMof-00032P-Sq for avt-archive@odin.ietf.org; Sat, 12 Jul 2003 12:01:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6CG1f3s011676 for avt-archive@odin.ietf.org; Sat, 12 Jul 2003 12:01:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bMo6-0002tF-UE; Sat, 12 Jul 2003 12:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bMnT-0002ij-5S for avt@optimus.ietf.org; Sat, 12 Jul 2003 12:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24880 for ; Sat, 12 Jul 2003 12:00:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bMnR-0001Zr-00 for avt@ietf.org; Sat, 12 Jul 2003 12:00:26 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19bMnR-0001Zo-00 for avt@ietf.org; Sat, 12 Jul 2003 12:00:25 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6CG0OkM023286 for ; Sat, 12 Jul 2003 12:00:24 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6CG0NN14760 for ; Sat, 12 Jul 2003 12:00:24 -0400 Message-ID: <3F102FA2.4040800@cs.columbia.edu> Date: Sat, 12 Jul 2003 11:56:18 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'avt@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] IMA; DVI Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The Interactive Multimedia Association has either disappeared or merged with another organization. (The IMTC does not seem have been involved, http://www.imtc.org/faqbody.asp#17). Does anybody know its whereabouts? Suspecting its untimely ascension to the great Association of Federations cemetary, does anybody have access to a softcopy of the DVI (32 kb/s and 24 kb/s) audio spec? Thanks. Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jul 13 05:49:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07434 for ; Sun, 13 Jul 2003 05:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdSm-0000v1-QM for avt-archive@odin.ietf.org; Sun, 13 Jul 2003 05:49:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6D9mCoD003527 for avt-archive@odin.ietf.org; Sun, 13 Jul 2003 05:48:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bdSb-0000tv-Ut; Sun, 13 Jul 2003 05:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bXpQ-0004Vb-ID for avt@optimus.ietf.org; Sat, 12 Jul 2003 23:47:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05056; Sat, 12 Jul 2003 23:45:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bXnr-0003Yh-00; Sat, 12 Jul 2003 23:45:35 -0400 Received: from orion.lrg.ufsc.br ([150.162.63.1] helo=lrg.ufsc.br) by ietf-mx with esmtp (Exim 4.12) id 19bXnq-0003YT-00; Sat, 12 Jul 2003 23:45:34 -0400 Received: from localhost (westphal@localhost) by (8.9.3+Sun/8.9.3) with ESMTP id AAA24228 Date: Sun, 13 Jul 2003 00:41:31 -0400 (WST) From: Carlos Becker Westphall To: noms2004-oc@noms2004.org cc: liste_cfip@info.uqam.ca, tccc@comsoc.org, itc@comsoc.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, avt@ietf.org, nanog@merit.edu, news-announce-conferences@uunet.uu.net, amlist@takilab.k.dendai.ac.jp, disman@dorothy.bmc.com, aaa-wg@merit.edu, rmonmib@ietf.org, policy@ietf.org, snmpv3@lists.tislabs.com, sming@ops.ietf.org, mpls@uu.net, mobile-ip@sunroof.eng.sun.com, gsmp@ietf.org, diffserv@ietf.org, sip@ietf.org, manet@ietf.org, cfp@mmlab.snu.ac.kr, conf@colmar.uha.fr, multicomm@research.panasonic.com, nemo@nal.motlabs.com, seamoby@ietf.org, TCPC.Mail@rome.ece.cornell.edu, dares-announcement@enst-bretagne.fr, dnac_2002@yahoo.fr, all@inf.ethz.ch, all_ifi@ifi.unizh.ch, arl@arl.wustl.edu, commsoft@ieee.org, comswtc@ieee.org, confs-conferencesa@comsoc.org, cost263@fokus.gmd.de, cost264@lip6.fr, disman@dorothy.bmc.com, enternet@bbn.com, gi-fb3@fokus.gmd.de, giga@tele.pitt.edu, ifip-tc6@informatik.rwth-aachen.de, int-serv@ISI.EDU, issll@mercury.lcs.mit.edu, itc@i-teletraffic.org, itc@ieee.org, kom-meeting@KOM.th-darmstadt.de, KUVS-L@listserv.uni-heidelberg.de, kuvs-elg@fokus.gmd.de, mmb@ira.uka.de, multicomm@comsoc.org, members@ngni.org, netnomics@listserver.tue.nl, nichains@BXL.DG13.cec.eu.int, pilc@grc.nasa.gov, reres@laas.fr, RHDM@lip6.fr, rm@openmash.org, sigmetrics-bb@haven.epm.ornl.gov, spects02@comp.leeds.ac.uk, tcgn@ieee.org, tcgn@majordomo.ieee.org, tcpp-announce@eece.unm.edu, tik@tik.ee.ethz.ch, wiss-mitarb@ee.ethz.ch, xtp-relay@cs.concordia.ca In-Reply-To: <06d001c2fdf1$e17daa10$841933c1@BRUNE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] NOMS 2004 Papers Due - August 1, 2003 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Call for Papers 2004 IEEE/IFIP Network Operations and Management Symposium (NOMS 2004) "Managing Next Generation Convergence Networks and Services" Seoul Korea, 19-23, April 2004 http://www.noms2004.org The 9th IEEE/IFIP Network Operations and Management Symposium (NOMS 2004) will be held 19-23 April, 2004 in COEX Convention Center, Seoul, Korea. NOMS 2004 will present the latest approaches and technical solutions in the area of network operations and management. Held in the even-numbered years since 1988, NOMS 2004 continues the established tradition of NOMS and IM as the primary forum for technical exchange of research, standards, development, systems integrator, service providers, and user communities. An exciting, peer-reviewed program of technical sessions, application sessions, panels, tutorials, posters, and vendor exhibits will address the ever-increasing interest in overall management solutions for all types of communications and computing networks, systems, services and enterprise applications. The symposium is sponsored by the IEEE Communications Society Technical Committee on Network Operations and Management (CNOM), and by the International Federation for Information Processing (IFIP) Working Group 6.6 on Management of Networks and Distributed Systems. The concept of network convergence has recently emerged as a new attempt for the merging of telephony and data networks into a single, multi-service network exploiting the ubiquity of the Internet. For this increasingly attractive business model, in both wired and wireless domains, strategic research is required to devise the best integration architectures, operations and management solutions. This creates a unique opportunity for the network operations and management community to respond to the ever-increasing demand for network resilience, security, quality-of-service and mobility management at unprecedented scales. NOMS 2004 provides the forum for discussing these research challenges and many others inherent to the integrated management of next generation converged networks and services. NOMS 2004 will broaden the scope of previous NOMS by expanding its program to include a broader set of topics ranging from network operations and management to network planning, service engineering and business processes for network and service management. Special attention will be given to experiences that emphasize lessons learned and reports on practice from industry. The NOMS 2004 program consists of three distinct sessions: technical, application, and panels. Technical sessions present the papers on the latest research results in the network operations and management area. Application sessions present the papers focusing on the experience of IT/telecommunications industries (service providers, OSS/equipment vendors, etc.) and customers based on their system implementation and business practice in the operations and management. Panel sessions focus on business implications, market trends of cutting edge technologies, and applications with the panelists consisting of technology experts and business executives. In addition, NOMS 2004 will feature tutorials, posters, birds-of-a-feather sessions, and vendor exhibitions. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal. Authors are also invited to submit proposals for tutorials, panel sessions, poster demonstrations and BoF sessions. Important Dates: Deadline for Technical Session Papers: 1 August 2003 Deadline for Application Session Papers: 15 September 2003 Deadline for Tutorials, Panels and Posters: 15 September 2003 Notification of Acceptance: 15 November 2003 Deadline for Submitting Revised Papers: 15 December 2003 Final Camera Ready Papers Due: 15 January 2004 Visit http://www.noms2004.org for the detailed information _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jul 13 18:24:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08169 for ; Sun, 13 Jul 2003 18:24:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bpGM-0006Qs-EB for avt-archive@odin.ietf.org; Sun, 13 Jul 2003 18:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6DMOAWA024720 for avt-archive@odin.ietf.org; Sun, 13 Jul 2003 18:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bpGD-0006Pz-BX; Sun, 13 Jul 2003 18:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bpFW-0006N2-H6 for avt@optimus.ietf.org; Sun, 13 Jul 2003 18:23:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08159 for ; Sun, 13 Jul 2003 18:23:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bpFT-0007bU-00 for avt@ietf.org; Sun, 13 Jul 2003 18:23:15 -0400 Received: from [81.160.15.136] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19bpFS-0007bR-00 for avt@ietf.org; Sun, 13 Jul 2003 18:23:14 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6DMN9A6031450; Sun, 13 Jul 2003 23:23:09 +0100 (BST) (envelope-from csp@csperkins.org) Date: Mon, 14 Jul 2003 00:23:09 +0200 From: Colin Perkins To: avt@ietf.org Cc: casner@acm.org, magnus.westerlund@ericsson.com, mankin@psg.com Message-Id: <20030714002309.377f68da.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Mon__14_Jul_2003_00:23:09_+0200_0819d200" Subject: [AVT] Draft charter revision Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Multipart_Mon__14_Jul_2003_00:23:09_+0200_0819d200 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Attached is a draft for the revised AVT charter. This will be discussed in the session tomorrow morning; comments are welcome. -- Colin Perkins csp@csperkins.org --Multipart_Mon__14_Jul_2003_00:23:09_+0200_0819d200 Content-Type: text/plain; name="avt-charter.txt" Content-Disposition: attachment; filename="avt-charter.txt" Content-Transfer-Encoding: base64 ClRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgV29ya2luZyBHcm91cCB3YXMgZm9ybWVkIHRvIHNw ZWNpZnkgYQpwcm90b2NvbCBmb3IgcmVhbC10aW1lIHRyYW5zbWlzc2lvbiBvZiBhdWRpbyBhbmQg dmlkZW8gb3ZlciB1bmljYXN0CmFuZCBtdWx0aWNhc3QgVURQL0lQLiBUaGlzIGlzIHRoZSBSZWFs LXRpbWUgVHJhbnNwb3J0IFByb3RvY29sLCBSVFAsCnRvZ2V0aGVyIHdpdGggaXRzIGFzc29jaWF0 ZWQgcHJvZmlsZXMgYW5kIHBheWxvYWQgZm9ybWF0cy4gVGhlIApjdXJyZW50IGFpbXMgb2YgdGhl IHdvcmtpbmcgZ3JvdXAgYXJlOiAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogLSB0byBhZHZhbmNlIHRoZSBtYWluIFJUUCBzcGVjaWZpY2F0aW9uIGFuZCBS VFAgUHJvZmlsZSAKICAgZm9yIEF1ZGlvIGFuZCBWaWRlbyBDb25mZXJlbmNlcyB3aXRoIE1pbmlt YWwgQ29udHJvbCAKICAgZm9yIHB1YmxpY2F0aW9uIGFzIGZ1bGwgSW50ZXJuZXQgU3RhbmRhcmRz CgogLSB0byByZXZpZXcgYW5kIHJldmlzZSBleGlzdGluZyBwYXlsb2FkIGZvcm1hdHMgdG8gYWR2 YW5jZSB0aG9zZQogICB3aGljaCBhcmUgdXNlZnVsIHRvIERyYWZ0IFN0YW5kYXJkIFJGQywgYW5k IHRvIGRlY2xhcmUgb3RoZXJzCiAgIGFzIEhpc3RvcmljLiBNaWxlc3RvbmVzIHdpbGwgYmUgZXN0 YWJsaXNoZWQgYXMgYSBjaGFtcGlvbiBmb3IgCiAgIGVhY2ggcGF5bG9hZCBmb3JtYXQgaXMgaWRl bnRpZmllZC4KIAogLSB0byBkZXZlbG9wIHBheWxvYWQgZm9ybWF0cyBmb3IgbmV3IG1lZGlhIGNv ZGVjcywgYW5kIHRvCiAgIGRvY3VtZW50IGJlc3QtY3VycmVudCBwcmFjdGljZXMgaW4gcGF5bG9h ZCBmb3JtYXQgZGVzaWduLiAKICAgVGhlIGdyb3VwIGNvbnRpbnVlcyB0byBiZSBwcmVjbHVkZWQg ZnJvbSB3b3JrIG9uIGNvZGVjcyAKICAgdGhlbXNlbHZlcyBiZWNhdXNlIG9mIG92ZXJsYXAgd2l0 aCB0aGUgb3RoZXIgc3RhbmRhcmRzIAogICBib2RpZXMsIGFuZCBiZWNhdXNlIHRoZSBJRVRGIGRv ZXMgbm90IGhhdmUgdGhlIGFiaWxpdHkgCiAgIHRvIGVmZmVjdGl2ZWx5IHJldmlldyBuZXcgY29k ZWNzLiBBbiBleGNlcHRpb24gd2FzIG1hZGUgCiAgIGZvciB0aGUgZnJlZXdhcmUgaUxCQyBjb2Rl YyBvbiBhIGhpZ2hseSBleHBlcmltZW50YWwgYmFzaXMsIAogICBidXQgYWNjZXB0YW5jZSBvZiBu ZXcgY29kZWMgd29yayBpcyB1bmV4cGVjdGVkIGFuZCBzdWJqZWN0IAogICB0byByZWNoYXJ0ZXJp bmcuCgogLSB0byBjb21wbGV0ZSB0aGUgZm9yd2FyZCBlcnJvciBjb3JyZWN0aW9uIHdvcmsgaW4g dGhlIFVMUCBhbmQKICAgVVhQIHBheWxvYWQgZm9ybWF0cwoKIC0gdG8gZXh0ZW5kIFJUUCB0byB3 b3JrIHdpdGggU291cmNlLVNwZWNpZmljIE11bHRpY2FzdCBzZXNzaW9ucwogICB3aXRoIHVuaWNh c3QgZmVlZGJhY2sKCiAtIHRvIHByb3ZpZGUgYSBmcmFtaW5nIG1lY2hhbmlzbSBmb3IgUlRQIG92 ZXIgVENQIGFuZCBUTFMKCiAtIHRvIHJldmlldyB0aGUgYXBwbGljYWJpbGl0eSBvZiBDb21wcmVz c2VkIFJUUCBvcGVyYXRpb24gb24KICAgTVBMUyBuZXR3b3JrcywgZGV2ZWxvcGluZyBleHRlbnNp b25zIGFzIG5lY2Vzc2FyeQoKIC0gdG8gZGV2ZWxvcCBhIG5ldyBSVFAgcHJvZmlsZSBhcyB0aGUg Y29tYmluYXRpb24gb2YgdGhlIFNSVFAKICAgcHJvZmlsZSBhbmQgdGhlIEV4dGVuZGVkIFJUUCBQ cm9maWxlIGZvciBSVENQLWJhc2VkIEZlZWRiYWNrCiAgIChSVFAvU0FWUEYpCgpUaGUgZ3JvdXAg d2lsbCBhbHNvIGNvb3JkaW5hdGUgd2l0aCB0aGUgRENDUCB3b3JraW5nIGdyb3VwIHRvCmVuc3Vy ZSB0aGF0IFJUUCBjYW4gYmUgZWZmaWNpZW50bHkgdHJhbnNwb3J0ZWQgb3ZlciBEQ0NQLgoKVGhl IGxvbmdlciB0ZXJtIGdvYWxzIG9mIHRoZSB3b3JraW5nIGdyb3VwIGFyZSB0byBhZHZhbmNlIHRo ZSAKU1JUUCBQcm9maWxlLCB0aGUgRXh0ZW5kZWQgUlRQIFByb2ZpbGUgZm9yIFJUQ1AtYmFzZWQg RmVlZGJhY2ssCnRoZSBDb21wcmVzc2VkIFJUUCBmcmFtZXdvcmssIGFuZCB0aGUgUlRQIE1JQiB0 byBEcmFmdCBTdGFuZGFyZC4gCgpUaGUgZ3JvdXAgaGFzIG5vIHBsYW5zIHRvIGRldmVsb3AgbmV3 IFJUUCBwcm9maWxlcyBiZXlvbmQgdGhvc2UKbGlzdGVkIGFib3ZlLCBidXQgd2lsbCBjb25zaWRl ciByZWNoYXJ0ZXJpbmcgdG8gcHJvZHVjZSBwcm9maWxlCmxldmVsIGV4dGVuc2lvbnMgaWYgYXBw cm9wcmlhdGUuICAgICAgICAgICAgCiAgICAgICAKTWlsZXN0b25lczoKCk9jdCAyMDAzICBSZXZp ZXcgRENDUCBpbmNsdWRpbmcgcHJvdG90eXBlcyBhbmQgQVBJOyBmZWVkYmFjayB0byBEQ0NQIFdH Ck5vdiAyMDAzICBJbml0aWFsIGRyYWZ0IHJlcXVpcmVtZW50cyBmb3IgRUNSVFAgb3ZlciBNUExT OyBkaXNjdXNzIHdpdGggTVBMUyBXRwpEZWMgMjAwMyAgU3VibWl0IFVYUCBQYXlsb2FkIEZvcm1h dCBmb3IgUHJvcG9zZWQgU3RhbmRhcmQgICAgICAgICAgICAgIApEZWMgMjAwMyAgU3VibWl0IFVM UCBQYXlsb2FkIEZvcm1hdCBmb3IgUHJvcG9zZWQgU3RhbmRhcmQgCkRlYyAyMDAzICBTdWJtaXQg UlRDUC9TU00gZHJhZnQgZm9yIFByb3Bvc2VkIFN0YW5kYXJkCkphbiAyMDA0ICBBZHZhbmNlIFJU UCBzcGVjaWZpY2F0aW9uIGFuZCBBL1YgcHJvZmlsZSB0byBGdWxsIFN0YW5kYXJkCk1hciAyMDA0 ICBJZGVudGlmeSBwYXlsb2FkIGZvcm1hdHMgdG8gY2xhc3NpZnkgYXMgSGlzdG9yaWMKTWFyIDIw MDQgIEZpbmlzaCByZXF1aXJlbWVudHMgZm9yIEVDUlRQIG92ZXIgTVBMUzsgcmVjaGFydGVyIGZv ciBzdWJzZXF1ZW50IHdvcmsKSnVsIDIwMDQgIFN1Ym1pdCBSVFAvU0FWUEYgcHJvZmlsZSBmb3Ig UHJvcG9zZWQgU3RhbmRhcmQKSnVsIDIwMDQgIEJlZ2luIHVwZGF0ZSBvZiBTUlRQIHByb2ZpbGUg Zm9yIERyYWZ0IFN0YW5kYXJkIFJGQwpKdWwgMjAwNCAgQmVnaW4gdXBkYXRlIG9mIFJUUC9BVlBG IHByb2ZpbGUgZm9yIERyYWZ0IFN0YW5kYXJkIFJGQwpBdWcgMjAwNCAgQ29uc2lkZXIgdXBkYXRl IG9mIFJUUCBNSUIKTm92IDIwMDQgIENvbGxlY3QgU1JUUCBpbXBsZW1lbnRhdGlvbiByZXBvcnRz Ck5vdiAyMDA0ICBDb2xsZWN0IFJUUC9BVlBGIGltcGxlbWVudGF0aW9uIHJlcG9ydHMKTWFyIDIw MDUgIFN1Ym1pdCBTUlRQIGZvciBEcmFmdCBTdGFuZGFyZApNYXIgMjAwNSAgU3VibWl0IFJUUC9B VlBGIGZvciBEcmFmdCBTdGFuZGFyZAoK --Multipart_Mon__14_Jul_2003_00:23:09_+0200_0819d200-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jul 13 22:25:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11613 for ; Sun, 13 Jul 2003 22:25:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bt1Z-0005gs-Pd for avt-archive@odin.ietf.org; Sun, 13 Jul 2003 22:25:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E2P9Ve021868 for avt-archive@odin.ietf.org; Sun, 13 Jul 2003 22:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bt1S-0005eJ-6U; Sun, 13 Jul 2003 22:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bt0n-0005dE-72 for avt@optimus.ietf.org; Sun, 13 Jul 2003 22:24:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11561 for ; Sun, 13 Jul 2003 22:24:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bt0k-0000i1-00 for avt@ietf.org; Sun, 13 Jul 2003 22:24:18 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19bt0j-0000hw-00 for avt@ietf.org; Sun, 13 Jul 2003 22:24:17 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6E2NjuJ027230; Sun, 13 Jul 2003 19:23:45 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (sjc-vpn2-806.cisco.com [10.21.115.38]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFZ60176; Sun, 13 Jul 2003 19:23:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20030713220122.01742a28@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 13 Jul 2003 22:23:43 -0400 To: Colin Perkins , avt@ietf.org From: "Michael A. Ramalho" Subject: Re: [AVT] Draft charter revision Cc: casner@acm.org, magnus.westerlund@ericsson.com, mankin@psg.com In-Reply-To: <20030714002309.377f68da.csp@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 12:23 AM 7/14/2003 +0200, Colin Perkins wrote: >Attached is a draft for the revised AVT charter. This will be discussed in >the session tomorrow morning; comments are welcome. > >-- >Colin Perkins >csp@csperkins.org Colin/Magnus/Steve, I've got two questions regarding the following snippet from the re-charter: "The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering." 1) With regard to iLBC, while I understood that the issue was not fully resolved, I thought AVT was to be the "primary repository" for iLBC's definition (that is, not the ITU-T or other standards defining bodies). I more or less understand what "experimental" means in the IETF - but what does "highly experimental" mean? Is it even less probable that iLBC will eventually attain standards status by the additional adjective? 2) With regard to RGL (for people unfamiliar to RGL, see www.vovida.org for details), RGL is really a "lossless data compression technique" applied to (A or mu-law) G.711. Steve had requested that "avt" be included in the titles of RGL revisions - so I assumed it was a working group item. Is RGL covered in the "re-chartering statement" (above)? Or is RGL, by virtue of it having more in common with a data compression algorithm than a (lossy) signal processing codec, exempt (no codec expertise needed - a rational noted above)? If this is unclear, could you obtain further guidance from the ADs (Allison) or the IESG? Thanks, Michael Ramalho Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 14 03:21:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29343 for ; Mon, 14 Jul 2003 03:21:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxe6-00089d-Na for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 03:21:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6E7LEuT031307 for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 03:21:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxdt-00087L-VA; Mon, 14 Jul 2003 03:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bxdg-00086V-7p for avt@optimus.ietf.org; Mon, 14 Jul 2003 03:20:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29334 for ; Mon, 14 Jul 2003 03:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bxde-0002FG-00 for avt@ietf.org; Mon, 14 Jul 2003 03:20:46 -0400 Received: from [81.160.158.191] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19bxdc-0002FD-00 for avt@ietf.org; Mon, 14 Jul 2003 03:20:45 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6E7KmUO000856 for ; Mon, 14 Jul 2003 08:20:49 +0100 (BST) (envelope-from csp@csperkins.org) Date: Mon, 14 Jul 2003 09:20:48 +0200 From: Colin Perkins To: avt@ietf.org Message-Id: <20030714092048.61f39603.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Slides for today's session Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Copies of the slides for today's session can be found at http://www.east.isi.edu/~csp/avt57.zip These will migrate onto the IETF proceedings site shortly. -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 14 08:59:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16753 for ; Mon, 14 Jul 2003 08:59:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2vB-0003IY-CE for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 08:59:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ECxDbO012640 for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 08:59:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2uz-0003H8-2y; Mon, 14 Jul 2003 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2uw-0003Gw-8i for avt@optimus.ietf.org; Mon, 14 Jul 2003 08:58:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16731 for ; Mon, 14 Jul 2003 08:58:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2uu-0006ol-00 for avt@ietf.org; Mon, 14 Jul 2003 08:58:56 -0400 Received: from foxtrot.nab.org ([209.116.240.194]) by ietf-mx with esmtp (Exim 4.12) id 19c2ut-0006oc-00 for avt@ietf.org; Mon, 14 Jul 2003 08:58:56 -0400 Received: from mail.nab.org by [209.116.240.194] via smtpd (for [132.151.6.1]) with ESMTP; Mon, 14 Jul 2003 08:58:55 -0400 Received: (private information removed) Message-ID: <5A659834E1607E4EBD72FCE2FE5C9CF102FEB685@mail.NAB.ORG> From: "Allison, Art" To: "'Henning Schulzrinne'" , "'avt@ietf.org'" Subject: RE: [AVT] IMA; DVI Date: Mon, 14 Jul 2003 08:58:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IMA indeed has folded. What is the date of the DVI spec? We may have it in backups...but need a date (and Title) to search. Art ::{) Art Allison Director Advanced Engineering NAB 1771 N St NW Washington DC 20036 202 429 5418 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Saturday, July 12, 2003 11:56 AM To: 'avt@ietf.org' Subject: [AVT] IMA; DVI The Interactive Multimedia Association has either disappeared or merged with another organization. (The IMTC does not seem have been involved, http://www.imtc.org/faqbody.asp#17). Does anybody know its whereabouts? Suspecting its untimely ascension to the great Association of Federations cemetary, does anybody have access to a softcopy of the DVI (32 kb/s and 24 kb/s) audio spec? Thanks. Henning _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 14 09:04:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16892 for ; Mon, 14 Jul 2003 09:04:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2zp-0003b5-OM for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 09:04:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ED41Lr013812 for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 09:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2zp-0003aY-6g; Mon, 14 Jul 2003 09:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c2zg-0003Ze-AH for avt@optimus.ietf.org; Mon, 14 Jul 2003 09:03:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16855 for ; Mon, 14 Jul 2003 09:03:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c2ze-0006qL-00 for avt@ietf.org; Mon, 14 Jul 2003 09:03:50 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19c2ze-0006qI-00 for avt@ietf.org; Mon, 14 Jul 2003 09:03:50 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6ED3nkM014761; Mon, 14 Jul 2003 09:03:49 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6ED3mk04384; Mon, 14 Jul 2003 09:03:49 -0400 Message-ID: <3F12A93E.7040807@cs.columbia.edu> Date: Mon, 14 Jul 2003 08:59:42 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Allison, Art" CC: "'avt@ietf.org'" Subject: Re: [AVT] IMA; DVI References: <5A659834E1607E4EBD72FCE2FE5C9CF102FEB685@mail.NAB.ORG> In-Reply-To: <5A659834E1607E4EBD72FCE2FE5C9CF102FEB685@mail.NAB.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I suspect around 1992, since it has been in RTP profile for a while. My citation is @TECHREPORT{IMAD9210:Recommended, AUTHOR="I. M. A Digital Audio Focus and Technical Working Groups", TITLE="Recommended practices for enhancing digital audio compatibility in multimedia systems (Version 3.00)", INSTITUTION="Interactive Multimedia Association", ADDRESS="Annapolis, Maryland", MONTH=oct, YEAR=1992, KEYWORDS="audio; standard; ADPCM", ANNOTE="Audio interchange formats; reference implementations", } Allison, Art wrote: > The IMA indeed has folded. What is the date of the DVI spec? > We may have it in backups...but need a date (and Title) to search. > > Art > ::{) > Art Allison > Director Advanced Engineering > NAB > 1771 N St NW > Washington DC 20036 > 202 429 5418 > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 14 11:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29432 for ; Mon, 14 Jul 2003 11:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5Ou-0005IM-TO for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 11:38:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EFc4xO020347 for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 11:38:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5Os-0005Hb-4c; Mon, 14 Jul 2003 11:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c5OW-0005CK-7M for avt@optimus.ietf.org; Mon, 14 Jul 2003 11:37:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29338 for ; Mon, 14 Jul 2003 11:37:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c5OS-0001lC-00 for avt@ietf.org; Mon, 14 Jul 2003 11:37:36 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19c5OQ-0001k9-00 for avt@ietf.org; Mon, 14 Jul 2003 11:37:34 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h6EFal3V078393; Mon, 14 Jul 2003 08:36:48 -0700 (PDT) (envelope-from casner@acm.org) Date: Mon, 14 Jul 2003 08:43:28 -0700 (PDT) From: Stephen Casner To: Colin Perkins cc: avt@ietf.org Subject: Re: [AVT] Slides for today's session In-Reply-To: <20030714092048.61f39603.csp@csperkins.org> Message-ID: <20030714084158.J6493-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Mon, 14 Jul 2003, Colin Perkins wrote: > Copies of the slides for today's session can be found at > http://www.east.isi.edu/~csp/avt57.zip > These will migrate onto the IETF proceedings site shortly. Colin, Did you send these yet? I guess we need to make up a presentation list to go along with the files. And the filenames should be avt0, avt1 etc. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 14 14:40:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12905 for ; Mon, 14 Jul 2003 14:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8F3-0000rV-9r for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 14:40:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EIe5Yh003309 for avt-archive@odin.ietf.org; Mon, 14 Jul 2003 14:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8Ez-0000qo-3I; Mon, 14 Jul 2003 14:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8En-0000lx-CQ for avt@optimus.ietf.org; Mon, 14 Jul 2003 14:39:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12813 for ; Mon, 14 Jul 2003 14:39:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8Ek-00055I-00 for avt@ietf.org; Mon, 14 Jul 2003 14:39:46 -0400 Received: from [81.160.147.207] (helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19c8Ej-00055C-00 for avt@ietf.org; Mon, 14 Jul 2003 14:39:45 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6EIdXe6003657; Mon, 14 Jul 2003 19:39:34 +0100 (BST) (envelope-from csp@csperkins.org) Date: Mon, 14 Jul 2003 20:39:33 +0200 From: Colin Perkins To: "Michael A. Ramalho" Cc: avt@ietf.org, casner@acm.org, magnus.westerlund@ericsson.com, mankin@psg.com Subject: Re: [AVT] Draft charter revision Message-Id: <20030714203933.7b1d6b43.csp@csperkins.org> In-Reply-To: <4.3.2.7.2.20030713220122.01742a28@mira-sjc5-9.cisco.com> References: <20030714002309.377f68da.csp@csperkins.org> <4.3.2.7.2.20030713220122.01742a28@mira-sjc5-9.cisco.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael, --> "Michael A. Ramalho" writes: > I've got two questions regarding the following snippet from the > re-charter: > > "The group continues to be precluded from work on codecs themselves > because of overlap with the other standards bodies, and because the > IETF does not have the ability to effectively review new codecs. An > exception was made for the freeware iLBC codec on a highly experimental > basis, but acceptance of new codec work is unexpected and subject > to rechartering." > > 1) With regard to iLBC, while I understood that the issue was not fully > resolved, I thought AVT was to be the "primary repository" for iLBC's > definition (that is, not the ITU-T or other standards defining bodies). > I more or less understand what "experimental" means in the IETF - but > what does "highly experimental" mean? Is it even less probable that > iLBC will eventually attain standards status by the additional adjective? The iLBC codec specification is on track to be published as an Experimental RFC. There are no plans to advance it to the standards track. > 2) With regard to RGL (for people unfamiliar to RGL, see www.vovida.org > for details), RGL is really a "lossless data compression technique" > applied to (A or mu-law) G.711. Steve had requested that "avt" be > included in the titles of RGL revisions - so I assumed it was a working > group item. Is RGL covered in the "re-chartering statement" (above)? Or > is RGL, by virtue of it having more in common with a data compression > algorithm than a(lossy) signal processing codec, exempt (no codec > expertise needed - a rational noted above)? If this is unclear, could you > obtain further guidance from the ADs (Allison) or the IESG? The RGL codec and payload format are not currently AVT work items. The codec is covered by the statement that "acceptance of new codec work is unexpected and subject to rechartering". -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 15 07:28:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14563 for ; Tue, 15 Jul 2003 07:28:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNyZ-0008Pq-BV for avt-archive@odin.ietf.org; Tue, 15 Jul 2003 07:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FBS7a0032335 for avt-archive@odin.ietf.org; Tue, 15 Jul 2003 07:28:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNyT-0008Om-5L; Tue, 15 Jul 2003 07:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cNyG-0008OW-BC for avt@optimus.ietf.org; Tue, 15 Jul 2003 07:27:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14498 for ; Tue, 15 Jul 2003 07:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cNy5-0000n2-00 for avt@ietf.org; Tue, 15 Jul 2003 07:27:38 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19cNxg-0000m7-00 for avt@ietf.org; Tue, 15 Jul 2003 07:27:12 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA01751; Tue, 15 Jul 2003 07:25:42 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA26442; Tue, 15 Jul 2003 07:25:42 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MT221>; Tue, 15 Jul 2003 07:25:42 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5BF4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mark Baugher'" , Aaron Colwell Cc: John Lazzaro , avt@ietf.org, mcgrew@cisco.com Subject: RE: [AVT] Vorbis RTP issues list for Vienna Date: Tue, 15 Jul 2003 07:25:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , > The keys to the data need to be delivered "at least as > reliably" as the > data but not necessarily "reliably." Putting keys in the > data packet is > one such method, but we are not likely to use this method in > RTP (poor > separation of functions, no third-party key mgt, etc). But > there have been > proposals for using RTCP or SRTCP. Rather than extend RTCP > or SRTCP for > this purpose, however, a better approach IMHO is to put the > key in the SDP > and send it "at least as reliably" as the SRTP. The SDP must > of course be > authenticated/integrity-checked and encrypted. I'm not sure this is a good idea. At least in SIP, the media path is considerably different, and in most cases, considerably shorter than the signalling path, because the signalling path has intermediaries that the media path does not. Key change is not something I would want to see delayed by the intermediaries. It really is a "real time" transport problem, although somewhat less real time than the actual media. Passing keys may be best done in the media path. Brian _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 15 10:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20126 for ; Tue, 15 Jul 2003 10:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQXD-000858-9y for avt-archive@odin.ietf.org; Tue, 15 Jul 2003 10:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FEC3jR031062 for avt-archive@odin.ietf.org; Tue, 15 Jul 2003 10:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQXB-00084K-9X; Tue, 15 Jul 2003 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cQWJ-0007wD-MS for avt@optimus.ietf.org; Tue, 15 Jul 2003 10:11:07 -0400 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19946 for ; Tue, 15 Jul 2003 10:11:02 -0400 (EDT) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 07:09:53 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6FEASuG028973; Tue, 15 Jul 2003 07:10:28 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-190.cisco.com [64.100.135.190]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGB03160; Tue, 15 Jul 2003 07:10:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20030715084931.016feea0@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Jul 2003 10:10:26 -0400 To: "Rosen, Brian" , "'Mark Baugher'" , Aaron Colwell From: "Michael A. Ramalho" Subject: RE: [AVT] Vorbis RTP issues list for Vienna Cc: John Lazzaro , avt@ietf.org, mcgrew@cisco.com In-Reply-To: <313680C9A886D511A06000204840E1CF070B5BF4@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I'd like to add to Brian's comment ... but I fear it might start a long-winded DCCP/PR-SCTP/UDP-congestion-backoff discussion. Here goes ... Michael Ramalho At 07:25 AM 7/15/2003 -0400, Rosen, Brian wrote: > > The keys to the data need to be delivered "at least as > > reliably" as the > > data but not necessarily "reliably." Putting keys in the > > data packet is > > one such method, but we are not likely to use this method in > > RTP (poor > > separation of functions, no third-party key mgt, etc). But > > there have been > > proposals for using RTCP or SRTCP. Rather than extend RTCP > > or SRTCP for > > this purpose, however, a better approach IMHO is to put the > > key in the SDP > > and send it "at least as reliably" as the SRTP. The SDP must > > of course be > > authenticated/integrity-checked and encrypted. >I'm not sure this is a good idea. At least in SIP, the >media path is considerably different, and in most cases, >considerably shorter than the signalling path, because >the signalling path has intermediaries that the media >path does not. Key change is not something I would >want to see delayed by the intermediaries. It really >is a "real time" transport problem, although somewhat >less real time than the actual media. >Passing keys may be best done in the media path. > >Brian I agree with Brian here - ideally the keys should be passed reliably in the media path. But what to do? The transport people know that we have a protocol that can do this job ... it just not being used yet because it new and has not gone through IETF last call. pr-SCTP has the ability to have "reliable" and "unreliable" streams present on the same "association". That is, you can run RTP over a "unreliable stream" whilst sending the keying material over a "reliable stream" to the same (potentially set of) IP address(es). Like DCCP, RTP over an "unreliable pr-sctp stream" has the desired property of having "TCP-friendly" backoff under congestion. Unlike DCCP - pr-SCTP has a "reliable option" (and was the first offering of pr-sctp, via it's SCTP origin). On the other side of the same coin, DCCP has a notion of which packets provided to it were dropped (or not forwarded) ... so a layer above DCCP could be designed to add "reliability" to a particular packet. However this layer wouldn't have the advantage of being integrated in the transport. This potentially adds more delay for the keys (Brian's primary comment above). As a side note, more complex codecs have the notion of "frame/payload" importance (e.g., base frames of a video codec having more importance than interpolated frames). I'm waiting for the discussion of the need of "mixed reliability/importance/persistence" payloads in AVT payload formats for particular codecs ... and the inevitable impact on proposed transport protocols. I think this must be addressed with a high level of interaction with the transport WG to get it right (i.e., anywhere near optimal). Michael Ramalho Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 15 12:37:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26291 for ; Tue, 15 Jul 2003 12:37:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cSnc-0006sE-84 for avt-archive@odin.ietf.org; Tue, 15 Jul 2003 12:37:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FGb8tc026420 for avt-archive@odin.ietf.org; Tue, 15 Jul 2003 12:37:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cSnV-0006q4-T3; Tue, 15 Jul 2003 12:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cSme-0006pO-Th for avt@optimus.ietf.org; Tue, 15 Jul 2003 12:36:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26278 for ; Tue, 15 Jul 2003 12:36:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cSmd-0003Xk-00 for avt@ietf.org; Tue, 15 Jul 2003 12:36:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19cSmR-0003XW-00 for avt@ietf.org; Tue, 15 Jul 2003 12:35:55 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2003 09:34:39 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn3-223.cisco.com [10.21.64.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6FGZHuK026033; Tue, 15 Jul 2003 09:35:17 -0700 (PDT) Message-Id: <5.1.1.5.2.20030715093345.064be288@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 15 Jul 2003 09:35:13 -0700 To: "Michael A. Ramalho" From: Mark Baugher Subject: RE: [AVT] Vorbis RTP issues list for Vienna Cc: "Rosen, Brian" , Aaron Colwell , John Lazzaro , avt@ietf.org, mcgrew@cisco.com In-Reply-To: <4.3.2.7.2.20030715084931.016feea0@mira-sjc5-9.cisco.com> References: <313680C9A886D511A06000204840E1CF070B5BF4@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 10:10 AM 7/15/2003 -0400, Michael A. Ramalho wrote: >I'd like to add to Brian's comment ... but I fear it might start a >long-winded DCCP/PR-SCTP/UDP-congestion-backoff >discussion. > >Here goes ... > >Michael Ramalho > >At 07:25 AM 7/15/2003 -0400, Rosen, Brian wrote: >> > The keys to the data need to be delivered "at least as >> > reliably" as the >> > data but not necessarily "reliably." Putting keys in the >> > data packet is >> > one such method, but we are not likely to use this method in >> > RTP (poor >> > separation of functions, no third-party key mgt, etc). But >> > there have been >> > proposals for using RTCP or SRTCP. Rather than extend RTCP >> > or SRTCP for >> > this purpose, however, a better approach IMHO is to put the >> > key in the SDP >> > and send it "at least as reliably" as the SRTP. The SDP must >> > of course be >> > authenticated/integrity-checked and encrypted. >>I'm not sure this is a good idea. At least in SIP, the >>media path is considerably different, and in most cases, >>considerably shorter than the signalling path, because >>the signalling path has intermediaries that the media >>path does not. Key change is not something I would >>want to see delayed by the intermediaries. It really >>is a "real time" transport problem, although somewhat >>less real time than the actual media. >>Passing keys may be best done in the media path. >> >>Brian > >I agree with Brian here - ideally the keys should be passed >reliably in the media path. But what to do? > >The transport people know that we have a protocol that >can do this job ... What transport protocol has been designed to send cryptographic keys? Mark >it just not being used yet because it >new and has not gone through IETF last call. > >pr-SCTP has the ability to have "reliable" and "unreliable" >streams present on the same "association". That is, you >can run RTP over a "unreliable stream" whilst sending the >keying material over a "reliable stream" to the same >(potentially set of) IP address(es). > >Like DCCP, RTP over an "unreliable pr-sctp stream" has >the desired property of having "TCP-friendly" backoff under >congestion. Unlike DCCP - pr-SCTP has a "reliable >option" (and was the first offering of pr-sctp, via it's >SCTP origin). > >On the other side of the same coin, DCCP has a notion >of which packets provided to it were dropped (or not >forwarded) ... so a layer above DCCP could be designed >to add "reliability" to a particular packet. However this >layer wouldn't have the advantage of being integrated >in the transport. This potentially adds more delay for >the keys (Brian's primary comment above). > >As a side note, more complex codecs have the notion >of "frame/payload" importance (e.g., base frames of >a video codec having more importance than interpolated >frames). I'm waiting for the discussion of the need of >"mixed reliability/importance/persistence" payloads in >AVT payload formats for particular codecs ... and the >inevitable impact on proposed transport protocols. I >think this must be addressed with a high level of >interaction with the transport WG to get it right >(i.e., anywhere near optimal). > >Michael Ramalho > >Michael A. Ramalho, Ph.D. >Office email: mramalho@cisco.com >Personal email: mar42@cornell.edu >Office: +1.941.708.4650 >Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 16 14:38:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11898 for ; Wed, 16 Jul 2003 14:38:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crAE-0004sM-Ow for avt-archive@odin.ietf.org; Wed, 16 Jul 2003 14:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GIc64m018733 for avt-archive@odin.ietf.org; Wed, 16 Jul 2003 14:38:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19crA9-0004q9-9F; Wed, 16 Jul 2003 14:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cq4e-00008W-6h for avt@optimus.ietf.org; Wed, 16 Jul 2003 13:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09321 for ; Wed, 16 Jul 2003 13:28:12 -0400 (EDT) From: musicnetwork@violino.dsi.unifi.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cq4c-0001OC-00 for avt@ietf.org; Wed, 16 Jul 2003 13:28:14 -0400 Received: from violino.dsi.unifi.it ([150.217.15.208]) by ietf-mx with esmtp (Exim 4.12) id 19cq4M-0001Nm-00 for avt@ietf.org; Wed, 16 Jul 2003 13:27:58 -0400 Received: (from musicnetwork@localhost) by violino.dsi.unifi.it (8.8.7/8.8.7) id TAA21177 for avt@ietf.org; Wed, 16 Jul 2003 19:09:03 +0200 Date: Wed, 16 Jul 2003 19:09:03 +0200 Message-Id: <200307161709.TAA21177@violino.dsi.unifi.it> X-Authentication-Warning: violino.dsi.unifi.it: Processed from queue /var/spool/bulkmail/musicnetwork/mqueue To: avt@ietf.org Subject: [AVT] MUSICNETWORK Workshop & WEDELMUSIC Conference, Leeds, UK, September 2003 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Dear MUSICNETWORK and WEDELMUSIC Friend All the most recent innovations and hot topics related to music and multimedia will be discussed in Leeds, UK, 15-18 September, 2003, Open to all You are invited to attend the work of the second MUSICNETWORK open workshop. A lot of interesting topics will be addressed: Digital right management, music notation (XML and non), optical music recognition, restoring, audio processing, personalisation, indexing, retrieval, libraries and archives, music publication, internet publication, cross media distribution and protection, MPEG standards, music and standards, etc. Innovative applications, case studies tutorials, demonstrators, etc. http://www.interactivemusicnetwork.org for the FINAL program see: http://www.interactivemusicnetwork.org/events/Second_OpenWorkshop_2003/programme_openworkshop_2003.html The workshop is colocated with the WEDELMUSIC conference innovative aspects of multimedia, DRM technologies, http://www.wedelmusic.org/wedelmusic2003/index.html The final program of the WEDELMUSIC conference will be ready in the next days. The general arrangements and schedule of all the events is reported in the above page. The registration pages are available on line for both events, the registration for the MUSICNETWORK is free of charge. cheers, Paolo Nesi (MUSICNETWORK, Thematic Network of the European Commission) Kia Ng (General Chair of WEDELMUSIC2003 conference, UNIV. Leeds) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 18 06:45:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26434 for ; Fri, 18 Jul 2003 06:45:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSjZ-0000fl-Mm for avt-archive@odin.ietf.org; Fri, 18 Jul 2003 06:45:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IAj5wL002581 for avt-archive@odin.ietf.org; Fri, 18 Jul 2003 06:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSjV-0000f4-LK; Fri, 18 Jul 2003 06:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dSjB-0000en-Hf for avt@optimus.ietf.org; Fri, 18 Jul 2003 06:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26429 for ; Fri, 18 Jul 2003 06:44:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dSj7-0007fz-00 for avt@ietf.org; Fri, 18 Jul 2003 06:44:37 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19dSir-0007fn-00 for avt@ietf.org; Fri, 18 Jul 2003 06:44:21 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h6IAiDkM014854 for ; Fri, 18 Jul 2003 06:44:13 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h6IAiCg21604 for ; Fri, 18 Jul 2003 06:44:13 -0400 Message-ID: <3F17CE84.9000505@cs.columbia.edu> Date: Fri, 18 Jul 2003 06:40:04 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] DVI ADPCM documentation Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Does anybody have a copy or a reference to msdn.microsoft.com for this document? (The organization that published the document is defunct and we'd like to have a reasonable reference in the new RTP profile.) % A specification titled ``DVI ADPCM Wave % Type'' can also be found in the \emph{Microsoft Developer Network % Development Library} CD ROM published quarterly by Microsoft. The % relevant section is found under Product Documentation, SDKs, % Multimedia Standards Update, New Multimedia Data Types and Data % Techniques, Revision 3.0, April 15, 1994. Thank you. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 22 04:29:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05640 for ; Tue, 22 Jul 2003 04:29:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esWX-0003kb-BF for avt-archive@odin.ietf.org; Tue, 22 Jul 2003 04:29:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M8TS7i014380 for avt-archive@odin.ietf.org; Tue, 22 Jul 2003 04:29:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esW6-0003jK-In; Tue, 22 Jul 2003 04:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19esVk-0003j9-1J for avt@optimus.ietf.org; Tue, 22 Jul 2003 04:28:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05634 for ; Tue, 22 Jul 2003 04:28:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19esVh-0002ZO-00 for avt@ietf.org; Tue, 22 Jul 2003 04:28:37 -0400 Received: from mail5.infineon.com ([203.126.245.197] helo=mail5-i.infineon.com) by ietf-mx with esmtp (Exim 4.12) id 19esVW-0002ZG-00 for avt@ietf.org; Tue, 22 Jul 2003 04:28:26 -0400 Received: from sinse004.ap.infineon.com (sgpk993a.sin.infineon.com [172.17.65.75]) by mail5-i.infineon.com (8.11.7+Sun/8.11.6) with ESMTP id h6M8SKv10622 for ; Tue, 22 Jul 2003 16:28:20 +0800 (SGT) Received: from blrw502w.blr.infineon.com ([172.29.142.21]) by sinse004.ap.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PM4XJW37; Tue, 22 Jul 2003 16:28:20 +0800 Received: by blrw502w.blr.infineon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 13:50:27 +0530 Message-ID: <0C674B14EAEBD61196D900B0D03DB49FB4D459@blrw502w.blr.infineon.com> From: "Kumar Premendra (IFIN DC COM)" To: avt@ietf.org Date: Tue, 22 Jul 2003 13:50:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [AVT] (no subject) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hello, I have some doubt while implementing RTP/RTCP....please clarify my doubt if possible. Q. We must send RTCP packet in compound packet format ,Always ? If not, how do we identify whether received packet is normal RTCP packet or compound packet. Thanks in advance prem _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 22 05:32:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07039 for ; Tue, 22 Jul 2003 05:32:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etVV-0006Ip-Jh for avt-archive@odin.ietf.org; Tue, 22 Jul 2003 05:32:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M9WTfU024178 for avt-archive@odin.ietf.org; Tue, 22 Jul 2003 05:32:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etV4-0006Gh-8C; Tue, 22 Jul 2003 05:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etV2-0006GE-E9 for avt@optimus.ietf.org; Tue, 22 Jul 2003 05:32:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07014 for ; Tue, 22 Jul 2003 05:31:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etUy-0002wg-00 for avt@ietf.org; Tue, 22 Jul 2003 05:31:56 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19etUo-0002wT-00 for avt@ietf.org; Tue, 22 Jul 2003 05:31:46 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6M9VDjG010387; Tue, 22 Jul 2003 11:31:13 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XL96KK; Tue, 22 Jul 2003 11:31:13 +0200 Message-ID: <3F1D0461.3060403@ericsson.com> Date: Tue, 22 Jul 2003 11:31:13 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kumar Premendra (IFIN DC COM)" CC: avt@ietf.org Subject: Re: [AVT] (no subject) References: <0C674B14EAEBD61196D900B0D03DB49FB4D459@blrw502w.blr.infineon.com> In-Reply-To: <0C674B14EAEBD61196D900B0D03DB49FB4D459@blrw502w.blr.infineon.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, RTCP packets are always compound packets. A RTCP compound packet must consist of at least RR and SDES or SR and SDES packets. Other packet types may also be present. I hope that you are using draft-ietf-avt-rtp-new-12 when implementing. Best Regards Magnus Kumar Premendra (IFIN DC COM) wrote: > > Hello, > > I have some doubt while implementing RTP/RTCP....please clarify my doubt if > possible. > > Q. We must send RTCP packet in compound packet format ,Always ? > If not, how do we identify whether received packet is normal RTCP packet > or compound packet. > > > Thanks in advance > prem > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 22 06:17:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07041 for ; Tue, 22 Jul 2003 05:32:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etVV-0006Ir-Jr for avt-archive@odin.ietf.org; Tue, 22 Jul 2003 05:32:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6M9WTaW024182 for avt-archive@odin.ietf.org; Tue, 22 Jul 2003 05:32:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etV3-0006GX-Oc; Tue, 22 Jul 2003 05:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19etV2-0006GD-DZ for avt@optimus.ietf.org; Tue, 22 Jul 2003 05:32:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07015 for ; Tue, 22 Jul 2003 05:31:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19etUy-0002wb-00 for avt@ietf.org; Tue, 22 Jul 2003 05:31:57 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19etUd-0002wB-00 for avt@ietf.org; Tue, 22 Jul 2003 05:31:36 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h6M9UX2B087919; Tue, 22 Jul 2003 02:30:33 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 02:30:32 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7C7B@misty.packetvideo.com> From: Thomas Zeng To: "'Kumar Premendra (IFIN DC COM) '" , "'avt@ietf.org '" Subject: RE: [AVT] (no subject) Date: Tue, 22 Jul 2003 02:30:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Prem: see below. - thomas -----Original Message----- From: Kumar Premendra (IFIN DC COM) To: avt@ietf.org Sent: 22.07.2003 01:20 Subject: [AVT] (no subject) Hello, I have some doubt while implementing RTP/RTCP....please clarify my doubt if possible. Q. We must send RTCP packet in compound packet format ,Always ? If not, how do we identify whether received packet is normal RTCP packet or compound packet. [tz] based on size of each rtcp packet, as well as overall size of the UDP packet, you can tell whether you are getting a correctly formated RTCP compound packet. If it is not a compound RTCP packet, it is ill-formated. Thanks in advance prem _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 23 03:08:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04073 for ; Wed, 23 Jul 2003 03:08:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDjO-0004Rs-0E for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 03:08:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N789qG017101 for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 03:08:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDjG-0004QH-NI; Wed, 23 Jul 2003 03:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDix-0004Mz-RR for avt@optimus.ietf.org; Wed, 23 Jul 2003 03:07:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04035 for ; Wed, 23 Jul 2003 03:07:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDit-0002Th-00 for avt@ietf.org; Wed, 23 Jul 2003 03:07:40 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19fDij-0002TQ-00 for avt@ietf.org; Wed, 23 Jul 2003 03:07:29 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h6N76Bcs007892; Wed, 23 Jul 2003 00:06:11 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 23 Jul 2003 00:14:43 -0700 (PDT) From: Stephen Casner To: Tmima Koren cc: avt@ietf.org, RFC Editor , , , , Allison Mankin , Jon Peterson , , In-Reply-To: <4.3.2.7.2.20030711182950.0303f2a8@mira-sjcm-2.cisco.com> Message-ID: <20030723000831.D10531-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: Proposed change to Enhanced CRTP Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The change to the Enhanced CRTP draft proposed in the message enclosed below has received no objections on the AVT mailing list. The change was also discussed in the AVT session at the IETF meeting just concluded in Vienna, where comments in favor were received. Therefore, we consider this change request to be appropriately reviewed by the working group and accepted. -- Steve On Fri, 11 Jul 2003, Tmima Koren wrote: > We'd like to propose a change to the Enhanced CRTP draft, > draft-ietf-avt-crtp-enhance-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-07.txt > > One of the enhancements is to add a Headers Checksum (HDRCKSUM) when UDP > checksum is not present (see section 2.2). > The UDP checksum is used by the decompressor to periodically validate the > reconstructed packets. When not present, > a HDRCKSUM may be inserted by the compressor replacing the missing UDP > checksum. The decompressor removes the HDRCKSUM after validating the > reconstructed packet. > > Currently the HDRCKSUM covers the pseudo-IP header, the UDP header and the > fixed part of the RTP header (first 12 bytes). > Those are the only parts of the reconstructed packet that can be validated > by the HDRCKSUM. > The CSRC list is not included in the HDRCKSUM. > > We propose to include the CSRC list in the HDRCKSUM since the CSRC list is > part of the header compression context. > > The CSRC list is stored at the decompressor context and inserted to the > restored packets. If the HDRCKSUM does not cover the CSRC list and the CSRC > list at the decompressor is errored, a bad CSRC list will be restored into > multiple packets until the CSRC > list changes and is resent by the compressor as an update. > If the HDRCKSUM covers the CSRC list, an error in the CSRC list will be > caught early and corrected. > > When there is a change in the CSRC list, the CSRC list is sent as an update > to the context. > The CSRC list should be treated in the same way as the other context > updating changes and be included in the HDRCKSUM. > > On the other hand, adding the CSRC list to the HDRCKSUM requires more > processing calculating the HDRCKSUM. Also if > the accuracy of the CSRC list is not crucial and the CSRC list is included > in the HDRCKSUM, then an error in the CSRC list > will result in dropping a few packets while the contexts are getting > synchronized. > > > The proposed change to the text is as follows: > > Old: > > The HDRCKSUM is calculated in the same way as a UDP checksum except > that it does not cover all of the UDP data. That is, the HDRCKSUM is > the 16-bit one's complement of the one's complement sum of the > pseudo-IP header (as defined for UDP), the UDP header, and the first > 12 bytes of the UDP data which are assumed to hold the fixed part of > an RTP header. The extended part of the RTP header and the RTP data > will not be included in the HDRCKSUM. > > New: > > The HDRCKSUM is calculated in the same way as a UDP checksum except > that it does not cover all of the UDP data. That is, the HDRCKSUM is > the 16-bit one's complement of the one's complement sum of the > pseudo-IP header (as defined for UDP), the UDP header, the first > ^^^^ > 12 bytes of the UDP data which are assumed to hold the fixed part of > an RTP header, and the CSRC list. > ^^^^^^^^^^^^^^^^^^^ > The extended part of the RTP header beyond the CSRC list and the RTP data > ^^^^^^^^^^^^^^^^^^^^ > will not be included in the HDRCKSUM. > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 23 10:18:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14624 for ; Wed, 23 Jul 2003 10:18:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKRR-0003tz-Je for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 10:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NEI5Nj014995 for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 10:18:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKRN-0003tJ-IT; Wed, 23 Jul 2003 10:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKR2-0003s5-GZ for avt@optimus.ietf.org; Wed, 23 Jul 2003 10:17:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14604 for ; Wed, 23 Jul 2003 10:17:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKR0-0004zN-00 for avt@ietf.org; Wed, 23 Jul 2003 10:17:38 -0400 Received: from [209.172.119.195] (helo=node24.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 19fKQp-0004yy-00 for avt@ietf.org; Wed, 23 Jul 2003 10:17:27 -0400 Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h6NEGhS1028200 for ; Wed, 23 Jul 2003 07:16:43 -0700 Received: from neomagic.com ([192.168.31.247]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h6NEGaAG032007 for ; Wed, 23 Jul 2003 07:16:37 -0700 Message-ID: <3F1E9C47.6090304@neomagic.com> Date: Wed, 23 Jul 2003 20:01:35 +0530 From: B Prashanth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt Content-Type: multipart/alternative; boundary="------------080603010207070101030907" Subject: [AVT] Frame Interleaving in AMR profile->RFC 3267 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --------------080603010207070101030907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear All The frame interleaving in the AMR profile (RFC 3267) states that " The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I. When performing interleaving the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleave group is less or equal to I, i.e., N*(L+1)<=I. " ILL is the interleaving Length i.e. number of RTP packets across which interleaving happens. NOTE: The value of ILL starts from 0. Hence, one needs to do ILL +1 in the above formula. Nmax, the maximum value N (number of frame-blocks per payload) can take, is calculated by the formula -> Nmax = (RTP MTU SIZE)/(The frame size of a frame block) Assuming, RTP MTU SIZE = 1500 bytes, and The frame size of a AMR frame block = 13 octets for AMR frame type=0 The above assumption gives: Nmax = 1500/13 = 115 packets. The information obtained from out-of-band means, say, SDP is "interleaving=30", which means that an interleaving group can have a maximum of 30 frames per group such that: (ILL+1) * N less than or equal to I where N varies from 0 I (i.e. 115>30). So, the condition (ILL+1)*N less than or equal to I with N=Nmax doesn't hold good. So, how does one select the value of N and ILL such that it is less than I, in the above case? Right now, I can think of only one option of handling this: My option: Assume the minimum value of ILL, say 1. A value of 2 makes sense because one needs at least 2 RTP packets to do interleaving. Based on this value calculate N N = (30/2)-1 N = 14 With this value of N we satisfy both the conditions, namely, (ILL+1) * N less than or equal to I -> (2+1) and N varies from 0 Dear All
The frame interleaving in the AMR profile (RFC 3267) states that

" The sender of the payload MUST only apply interleaving if the
   receiver has signalled its use through out-of-band means.  Since
   interleaving will increase buffering requirements at the receiver,
   the receiver uses MIME parameter "interleaving=I" to set the maximum
   number of frame-blocks allowed in an interleaving group to I.

   When performing interleaving the sender MUST use a proper number of
   frame-blocks per payload (N) and ILL so that the resulting size of an
   interleave group is less or equal to I, i.e., N*(L+1)<=I. "

ILL is the interleaving Length i.e. number of RTP packets across which interleaving happens.
NOTE: The value of ILL starts from 0. Hence, one needs to do ILL +1 in the above formula.

Nmax, the maximum value N (number of frame-blocks per payload) can take, is calculated by the formula ->
Nmax = (RTP MTU SIZE)/(The frame size of a frame block)

Assuming,

RTP MTU SIZE = 1500 bytes, and
The frame size of a AMR frame block = 13 octets for AMR frame type=0

The above assumption gives:
Nmax = 1500/13 = 115 packets.

The information obtained from out-of-band means, say, SDP is "interleaving=30", which means that an interleaving group can have a maximum of 30 frames per group such that:
(ILL+1) * N less than or equal to I  
        where    N varies from 0<N<Nmax.
                      ILL is the interleaving Length i.e. number of RTP packets across which interleaving happens.

Now, in the case taken by me above, Nmax > I   (i.e. 115>30). So, the condition (ILL+1)*N less than or equal to I with N=Nmax doesn't hold good.

So, how does one select the value of N and ILL such that it is less than I, in the above case?

Right now, I can think of only one option of handling this:
My option:  Assume the minimum value of ILL, say 1. A value of 2 makes sense because one needs at least 2 RTP packets to do interleaving. Based on this value calculate N
N = (30/2)-1
N = 14
With this value of N we satisfy both the conditions, namely,
(ILL+1) * N less than or equal to I  -> (2+1)
and
N varies from 0<N<Nmax.

I wanted to ask the others on this list whether this solution is the only solution? Or there are other ways of handling this?
Shouldn't the values of N and ILL be very apparent rather than AMR profile designer making such assumptions about it? 
-- 
Prashanth B.P.
Sr. Design Engr.
NeoMagic Design Center.
Polyplex Building, First Floor
B-37 Sector 1
Noida 
INDIA 201301
E-Mail:  bprashanth@neomagic.com
Tel:     +91-120-2536208
Fax:     +91-120-2536207
--------------080603010207070101030907-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 23 11:47:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17482 for ; Wed, 23 Jul 2003 11:47:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLpZ-0007x3-LV for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 11:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NFl5o2030559 for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 11:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLpU-0007wK-Rt; Wed, 23 Jul 2003 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fLpE-0007vs-6q for avt@optimus.ietf.org; Wed, 23 Jul 2003 11:46:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17460 for ; Wed, 23 Jul 2003 11:46:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fLpC-0005bz-00 for avt@ietf.org; Wed, 23 Jul 2003 11:46:42 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19fLp2-0005b9-00 for avt@ietf.org; Wed, 23 Jul 2003 11:46:32 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6NFjKU00430; Wed, 23 Jul 2003 10:45:20 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301TZZ46>; Wed, 23 Jul 2003 10:45:21 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF648736@zrc2c000.us.nortel.com> From: "Peter Barany" To: Stephen Casner , Magnus Westerlund Cc: IETF AVT WG Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Date: Wed, 23 Jul 2003 10:45:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35131.6C2887CE" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35131.6C2887CE Content-Type: text/plain; charset="iso-8859-1" Hi, Just for clarification, in Appendix A.7 of RFC 1889 bis Internet draft have the following changes been agreed to (or are these changes not required per the agreed changes to the RTCP bandwidth modifier Internet draft)? (1) "RTCP_RCVR_BW_FRACTION = 0.25" changed to "RTCP_RCVR_BW_FRACTION = rtcp_bw_senders/(rtcp_bw_senders + rtcp_bw_receivers)" and (2) "senders > 0" removed? Thanks. Regards, Pete -----Original Message----- From: Jose Rey [mailto:rey@panasonic.de] Sent: Monday, June 16, 2003 6:32 AM To: Stephen Casner; Magnus Westerlund Cc: IETF AVT WG Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Hi, > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Stephen > Casner > Sent: Monday, June 16, 2003 8:47 AM > To: Magnus Westerlund; Jose Rey > Cc: IETF AVT WG > Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt > > > Some more thoughts on this: > > To simplify the unicast streaming application, we could specify that > when RTCP bw is specified with RS and RR those values are used > separately for senders and non-senders without any consideration of > treating senders and receivers together when the number of senders is > greater than RS/(RS+RR). I think this is the best and easiest solution. In 3GPP unicast streaming it is the server that sets the RS and RR values, that means the server should consider well how much bandwidth it is needed for own reporting and for the sender's. There's no case where the algorithm must adapt, the scenario is rather static. > > However, that would not be good for conversational applications > (unicast or multicast) because the classification as sender changes > over time. At times when both ends have sent within two intervals, > they would be using the RS bw only and ignoring the RR bw. To get > around this we could set RS to be the total, and RR zero, but then if > one was sending and the other just listening for a long time, the > listener would get nothing. For these applications, you need the > smooth transision that the existing algorithm was intended to > provide. > I see. I was referring more to the streaming unicast scenario. I guess my characterization was not accure enough. cheers, Jose > -- Steve > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt ------_=_NextPart_001_01C35131.6C2887CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

Hi,

Just for clarification, in Appendix A.7 of RFC 1889 = bis Internet draft have the following changes been agreed to (or are = these changes not required per the agreed changes to the RTCP bandwidth = modifier Internet draft)?

(1) "RTCP_RCVR_BW_FRACTION =3D 0.25"
changed to
"RTCP_RCVR_BW_FRACTION =3D = rtcp_bw_senders/(rtcp_bw_senders + rtcp_bw_receivers)"

and

(2) "senders > 0" removed?

Thanks.

Regards,

Pete

-----Original Message-----
From: Jose Rey [mailto:rey@panasonic.de]
Sent: Monday, June 16, 2003 6:32 AM
To: Stephen Casner; Magnus Westerlund
Cc: IETF AVT WG
Subject: RE: [AVT] Re: Errors in = draft-ietf-avt-rtcp-bw-05.txt


Hi,

> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On = Behalf Of Stephen
> Casner
> Sent: Monday, June 16, 2003 8:47 AM
> To: Magnus Westerlund; Jose Rey
> Cc: IETF AVT WG
> Subject: Re: [AVT] Re: Errors in = draft-ietf-avt-rtcp-bw-05.txt
>
>
> Some more thoughts on this:
>
> To simplify the unicast streaming application, = we could specify that
> when RTCP bw is specified with RS and RR those = values are used
> separately for senders and non-senders without = any consideration of
> treating senders and receivers together when = the number of senders is
> greater than RS/(RS+RR).

I think this is the best and easiest solution. In = 3GPP unicast streaming it is
the server that sets the RS and RR values, that = means the server should consider
well how much bandwidth it is needed for own = reporting and for the sender's.
There's no case where the algorithm must adapt, the = scenario is rather static.

>
> However, that would not be good for = conversational applications
> (unicast or multicast) because the = classification as sender changes
> over time.  At times when both ends have = sent within two intervals,
> they would be using the RS bw only and ignoring = the RR bw.  To get
> around this we could set RS to be the total, = and RR zero, but then if
> one was sending and the other just listening = for a long time, the
> listener would get nothing.  For these = applications, you need the
> smooth transision that the existing algorithm = was intended to
> provide.
>
I see. I was referring more to the streaming unicast = scenario. I guess my
characterization was not accure enough.

cheers,

Jose

>          = ;            = ;            = ;            = ;           -- = Steve
>
> = _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

------_=_NextPart_001_01C35131.6C2887CE-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 23 14:43:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23260 for ; Wed, 23 Jul 2003 14:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOZu-0008KB-Rc for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 14:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NIh6td031988 for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 14:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOZo-0008JM-SV; Wed, 23 Jul 2003 14:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOZi-0008JB-Hq for avt@optimus.ietf.org; Wed, 23 Jul 2003 14:42:54 -0400 Received: from mailman.packetdesign.com (www.routeexplorer.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23218 for ; Wed, 23 Jul 2003 14:42:50 -0400 (EDT) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h6NIfZcs024619; Wed, 23 Jul 2003 11:41:36 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 23 Jul 2003 11:41:35 -0700 (PDT) From: Stephen Casner To: Peter Barany cc: Magnus Westerlund , IETF AVT WG Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt In-Reply-To: <870397D7C140C84DB081B88396458DAF648736@zrc2c000.us.nortel.com> Message-ID: <20030723111221.X12614-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Peter, > Just for clarification, in Appendix A.7 of RFC 1889 bis Internet draft have > the following changes been agreed to (or are these changes not required per > the agreed changes to the RTCP bandwidth modifier Internet draft)? > > (1) "RTCP_RCVR_BW_FRACTION = 0.25" > changed to > "RTCP_RCVR_BW_FRACTION = rtcp_bw_senders/(rtcp_bw_senders + > rtcp_bw_receivers)" > > and > > (2) "senders > 0" removed? Those changes have logically been agreed, but the edits are not exactly as you state. In Section 6.2, the proportion of senders has been changed from 1/4 to S/(S+R). In Section 6.3.1 item 1, the "senders > 0" clause has been removed, and the following text added at the end: As stated in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth may be explicitly defined by two separate parameters (call them S and R) for those participants which are senders and those which are not. In that case, the 25% fraction becomes S/(S+R) and the 75% fraction becomes R/(S+R). Note that if R is zero, the percentage of senders is never greater than S/(S+R), and the implementation must avoid division by zero. In Appendix A.7, the "senders < 0" clause has been removed and the inequality is changed from "<" to "<=" so that the inequality is always true when RTCP_SENDER_BW_FRACTION is 1.0: if (senders <= members * RTCP_SENDER_BW_FRACTION) { However, your change (1) above has not been made because I did not want to make modifications to the extent that would be required to add rtcp_bw_senders and rtcp_bw_receivers as arguments to the function and all calls to it. Instead, I added the following paragraph just before the rtcp_interval() function: These functions would have to be extended for an implementation that allows the RTCP bandwidth fractions for senders and non-senders to be specified as explict parameters rather than fixed values of 25% and 75%. The extended implementation of rtcp_interval() would need to avoid division by zero if one of the parameters was zero. The full RFCs should be released within a few days. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 23 15:15:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25419 for ; Wed, 23 Jul 2003 15:15:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP4r-0001Eu-HP for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 15:15:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJF5i9004757 for avt-archive@odin.ietf.org; Wed, 23 Jul 2003 15:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP4n-0001E2-Vj; Wed, 23 Jul 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP3y-0001Bl-H9 for avt@optimus.ietf.org; Wed, 23 Jul 2003 15:14:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24997; Wed, 23 Jul 2003 15:14:02 -0400 (EDT) Message-Id: <200307231914.PAA24997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 23 Jul 2003 15:14:02 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-09.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : The Secure Real-time Transport Protocol Author(s) : M. Baugher et al. Filename : draft-ietf-avt-srtp-09.txt Pages : 56 Date : 2003-7-23 This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-srtp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-srtp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-23150851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-srtp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-srtp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23150851.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 24 03:44:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27606 for ; Thu, 24 Jul 2003 03:44:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19falL-0001qX-IF for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 03:43:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O7hhCa007096 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 03:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fakf-0001mQ-2o; Thu, 24 Jul 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fakb-0001mF-GC for avt@optimus.ietf.org; Thu, 24 Jul 2003 03:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27548 for ; Thu, 24 Jul 2003 03:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fakZ-00041E-00 for avt@ietf.org; Thu, 24 Jul 2003 03:42:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19fakO-00040w-00 for avt@ietf.org; Thu, 24 Jul 2003 03:42:44 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6O7g3G6020478; Thu, 24 Jul 2003 09:42:03 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366DSMC2; Thu, 24 Jul 2003 09:42:42 +0200 Message-ID: <3F1F8DCA.3030509@ericsson.com> Date: Thu, 24 Jul 2003 09:42:02 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: B Prashanth CC: avt Subject: Re: [AVT] Frame Interleaving in AMR profile->RFC 3267 References: <3F1E9C47.6090304@neomagic.com> In-Reply-To: <3F1E9C47.6090304@neomagic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, When it comes to meeting the limitations the sender side has the freedom to select any combination of ILL and number of frames that satisfies the restrictions. Another restriction then I that may be used is "maxptime" which puts a limit on the number of frames per packet. In your example with I=30 the sender has the choice to go from ILL=0 (No interleaving, with 30 frames in a single RTP packet, up to ILL=14 and only two frames per packet. It is assumed that the sender will use the combination most suitable for the current network performance and congestion state. There is no need for the payload format to put in more limitations. The RTP payload format has great flexibility and for any receiver implementing the interleaving mode can decode these payloads independent of which ratio between ILL and N that are used. The I restriction value is there to put a limit on buffering and interleaving induced delay. However using many AMR frames per packet is generally not a good idea. If one would use the 130 frames per packet that you calculate, I hope you are aware that this represent 2.6 seconds. That can be a whole sentence lost if this single packet is lost. So filling voice packet to the limit is not suitable in environments where losses occur. However if one has retransmission or uses a reliable channel more frames per packets may give satisfactory performance. My opinion is that more than 5-10 frames per packet is to much. And if one is going as high as 10 frames per packet one should definitely consider using interleaving with fairly decent length. [Chairs hat on] RFC 3267 is a payload format NOT a profile. A RTP profile is something else and must not be confused with payload formats. I have seen this mistake being done also by others. The current available profiles are RFC 1890 (AVP) or rather draft-ietf-avt-profile-new-13. Two new profiles are with the IESG, SRTP (SAVP) draft-ietf-avt-srtp-09 and Extended RTCP feedback (AVPF) draft-ietf-avt-rtcp-feedback-07. [chairs hat off] Best Regards Magnus B Prashanth wrote: > Dear All > The frame interleaving in the AMR profile (RFC 3267) states that > > " The sender of the payload MUST only apply interleaving if the > receiver has signalled its use through out-of-band means. Since > interleaving will increase buffering requirements at the receiver, > the receiver uses MIME parameter "interleaving=I" to set the maximum > number of frame-blocks allowed in an interleaving group to I. > > When performing interleaving the sender MUST use a proper number of > frame-blocks per payload (N) and ILL so that the resulting size of an > interleave group is less or equal to I, i.e., N*(L+1)<=I. " > > ILL is the interleaving Length i.e. number of RTP packets across which > interleaving happens. > NOTE: The value of ILL starts from 0. Hence, one needs to do ILL +1 in > the above formula. > > Nmax, the maximum value N (number of frame-blocks per payload) can take, > is calculated by the formula -> > Nmax = (RTP MTU SIZE)/(The frame size of a frame block) > > Assuming, > > RTP MTU SIZE = 1500 bytes, and > The frame size of a AMR frame block = 13 octets for AMR frame type=0 > > The above assumption gives: > Nmax = 1500/13 = 115 packets. > > The information obtained from out-of-band means, say, SDP is > "interleaving=30", which means that an interleaving group can have a > maximum of 30 frames per group such that: > (ILL+1) * N less than or equal to I > where N varies from 0 ILL is the interleaving Length i.e. number of RTP > packets across which interleaving happens. > > Now, in the case taken by me above, Nmax > I (i.e. 115>30). So, the > condition (ILL+1)*N less than or equal to I with N=Nmax doesn't hold good. > > So, how does one select the value of N and ILL such that it is less than > I, in the above case? > > Right now, I can think of only one option of handling this: > My option: Assume the minimum value of ILL, say 1. A value of 2 makes > sense because one needs at least 2 RTP packets to do interleaving. Based > on this value calculate N > N = (30/2)-1 > N = 14 > With this value of N we satisfy both the conditions, namely, > (ILL+1) * N less than or equal to I -> (2+1) > and > N varies from 0 > I wanted to ask the others on this list whether this solution is the > only solution? Or there are other ways of handling this? > Shouldn't the values of N and ILL be very apparent rather than AMR > profile designer making such assumptions about it? > > -- > Prashanth B.P. > Sr. Design Engr. > NeoMagic Design Center. > Polyplex Building, First Floor > B-37 Sector 1 > Noida > INDIA 201301 > E-Mail: bprashanth@neomagic.com > Tel: +91-120-2536208 > Fax: +91-120-2536207 > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 24 06:02:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01009 for ; Thu, 24 Jul 2003 06:02:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcux-0000vl-Mx for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 06:01:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OA1lsu003576 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 06:01:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcuD-0000pP-KT; Thu, 24 Jul 2003 06:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fcu1-0000jc-7P for avt@optimus.ietf.org; Thu, 24 Jul 2003 06:00:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00963 for ; Thu, 24 Jul 2003 06:00:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fctx-0004vL-00 for avt@ietf.org; Thu, 24 Jul 2003 06:00:45 -0400 Received: from [209.172.119.195] (helo=node24.neomagic.com) by ietf-mx with esmtp (Exim 4.12) id 19fctm-0004ut-00 for avt@ietf.org; Thu, 24 Jul 2003 06:00:34 -0400 Received: from node26.neomagic.com (node26.neomagic.com [192.168.51.26]) by node24.neomagic.com (8.12.5/8.12.5) with ESMTP id h6O9xbS1006118; Thu, 24 Jul 2003 02:59:37 -0700 Received: from neomagic.com ([192.168.31.247]) by node26.neomagic.com (8.12.5/8.12.5) with ESMTP id h6O9xVAG008620; Thu, 24 Jul 2003 02:59:35 -0700 Message-ID: <3F1FB187.5050402@neomagic.com> Date: Thu, 24 Jul 2003 15:44:31 +0530 From: B Prashanth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: avt Subject: Re: [AVT] Frame Interleaving in AMR profile->RFC 3267 References: <3F1E9C47.6090304@neomagic.com> <3F1F8DCA.3030509@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Magnus! Thanks for replying in detail. It has cleared lot of my doubts. Regards, Prashanth Magnus Westerlund wrote: > Hi, > > When it comes to meeting the limitations the sender side has the > freedom to select any combination of ILL and number of frames that > satisfies the restrictions. Another restriction then I that may be > used is "maxptime" which puts a limit on the number of frames per packet. > > In your example with I=30 the sender has the choice to go from ILL=0 > (No interleaving, with 30 frames in a single RTP packet, up to ILL=14 > and only two frames per packet. It is assumed that the sender will use > the combination most suitable for the current network performance and > congestion state. > > There is no need for the payload format to put in more limitations. > The RTP payload format has great flexibility and for any receiver > implementing the interleaving mode can decode these payloads > independent of which ratio between ILL and N that are used. The I > restriction value is there to put a limit on buffering and > interleaving induced delay. However using many AMR frames per packet > is generally not a good idea. If one would use the 130 frames per > packet that you calculate, I hope you are aware that this represent > 2.6 seconds. That can be a whole sentence lost if this single packet > is lost. So filling voice packet to the limit is not suitable in > environments where losses occur. However if one has retransmission or > uses a reliable channel more frames per packets may give satisfactory > performance. My opinion is that more than 5-10 frames per packet is to > much. And if one is going as high as 10 frames per packet one should > definitely consider using interleaving with fairly decent length. > > > [Chairs hat on] > > RFC 3267 is a payload format NOT a profile. A RTP profile is something > else and must not be confused with payload formats. I have seen this > mistake being done also by others. The current available profiles are > RFC 1890 (AVP) or rather draft-ietf-avt-profile-new-13. Two new > profiles are with the IESG, SRTP (SAVP) draft-ietf-avt-srtp-09 and > Extended RTCP feedback (AVPF) draft-ietf-avt-rtcp-feedback-07. > > [chairs hat off] > > Best Regards > > > Magnus > > > B Prashanth wrote: > >> Dear All >> The frame interleaving in the AMR profile (RFC 3267) states that >> >> " The sender of the payload MUST only apply interleaving if the >> receiver has signalled its use through out-of-band means. Since >> interleaving will increase buffering requirements at the receiver, >> the receiver uses MIME parameter "interleaving=I" to set the maximum >> number of frame-blocks allowed in an interleaving group to I. >> >> When performing interleaving the sender MUST use a proper number of >> frame-blocks per payload (N) and ILL so that the resulting size of an >> interleave group is less or equal to I, i.e., N*(L+1)<=I. " >> >> ILL is the interleaving Length i.e. number of RTP packets across >> which interleaving happens. >> NOTE: The value of ILL starts from 0. Hence, one needs to do ILL +1 >> in the above formula. >> >> Nmax, the maximum value N (number of frame-blocks per payload) can >> take, is calculated by the formula -> >> Nmax = (RTP MTU SIZE)/(The frame size of a frame block) >> >> Assuming, >> >> RTP MTU SIZE = 1500 bytes, and >> The frame size of a AMR frame block = 13 octets for AMR frame type=0 >> >> The above assumption gives: >> Nmax = 1500/13 = 115 packets. >> >> The information obtained from out-of-band means, say, SDP is >> "interleaving=30", which means that an interleaving group can have a >> maximum of 30 frames per group such that: >> (ILL+1) * N less than or equal to I where N varies from >> 0> ILL is the interleaving Length i.e. number of >> RTP packets across which interleaving happens. >> >> Now, in the case taken by me above, Nmax > I (i.e. 115>30). So, the >> condition (ILL+1)*N less than or equal to I with N=Nmax doesn't hold >> good. >> >> So, how does one select the value of N and ILL such that it is less >> than I, in the above case? >> >> Right now, I can think of only one option of handling this: >> My option: Assume the minimum value of ILL, say 1. A value of 2 >> makes sense because one needs at least 2 RTP packets to do >> interleaving. Based on this value calculate N >> N = (30/2)-1 >> N = 14 >> With this value of N we satisfy both the conditions, namely, >> (ILL+1) * N less than or equal to I -> (2+1) >> and >> N varies from 0> >> I wanted to ask the others on this list whether this solution is the >> only solution? Or there are other ways of handling this? >> Shouldn't the values of N and ILL be very apparent rather than AMR >> profile designer making such assumptions about it? >> >> -- >> Prashanth B.P. >> Sr. Design Engr. >> NeoMagic Design Center. >> Polyplex Building, First Floor >> B-37 Sector 1 >> Noida INDIA 201301 >> E-Mail: bprashanth@neomagic.com >> Tel: +91-120-2536208 >> Fax: +91-120-2536207 >> > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 24 08:08:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03291 for ; Thu, 24 Jul 2003 08:08:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fest-0007kS-KA for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 08:07:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OC7lDj029778 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 08:07:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fes9-0007QR-Q3; Thu, 24 Jul 2003 08:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ferZ-0007Pj-7a for avt@optimus.ietf.org; Thu, 24 Jul 2003 08:06:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03228 for ; Thu, 24 Jul 2003 08:06:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ferY-0005VU-00 for avt@ietf.org; Thu, 24 Jul 2003 08:06:24 -0400 Received: from mailbe4.getronics.com ([158.67.5.172]) by ietf-mx with esmtp (Exim 4.12) id 19ferS-0005VJ-00 for avt@ietf.org; Thu, 24 Jul 2003 08:06:18 -0400 Received: from MAILBE2.getronics.com ([192.58.226.24]) by mailbe4.getronics.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 13:35:04 +0200 Received: from mail pickup service by MAILBE2.getronics.com with Microsoft SMTPSVC; Thu, 24 Jul 2003 13:35:04 +0200 Received: from asgard.ietf.org ([132.151.6.40]) by MAILBE3.getronics.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 23 Jul 2003 21:27:14 +0200 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19fP4N-0003NC-Bm for ietf-announce-list@asgard.ietf.org; Wed, 23 Jul 2003 15:14:35 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19fP3t-0003ET-BI for all-ietf@asgard.ietf.org; Wed, 23 Jul 2003 15:14:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24997; Wed, 23 Jul 2003 15:14:02 -0400 (EDT) Message-Id: <200307231914.PAA24997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 23 Jul 2003 15:14:02 -0400 Precedence: bulk X-OriginalArrivalTime: 23 Jul 2003 19:27:14.0541 (UTC) FILETIME=[6BDD61D0:01C35150] Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-09.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : The Secure Real-time Transport Protocol Author(s) : M. Baugher et al. Filename : draft-ietf-avt-srtp-09.txt Pages : 56 Date : 2003-7-23 This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-srtp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-srtp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-23150851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-srtp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-srtp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23150851.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 24 11:38:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11213 for ; Thu, 24 Jul 2003 11:38:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fiA9-0004hU-WA for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 11:37:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OFbnNY018049 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 11:37:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fi9O-0004LT-OL; Thu, 24 Jul 2003 11:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fi8u-0004KG-TP for avt@optimus.ietf.org; Thu, 24 Jul 2003 11:36:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11169 for ; Thu, 24 Jul 2003 11:36:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fi8t-0006xC-00 for avt@ietf.org; Thu, 24 Jul 2003 11:36:31 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19fi8j-0006x3-00 for avt@ietf.org; Thu, 24 Jul 2003 11:36:21 -0400 thread-index: AcNR+QxbEuZrj+uyTKSQzC0u19Uqbg== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Jul 2003 17:34:19 +0200 From: "Jose Rey" Content-Class: urn:content-classes:message Priority: normal To: Date: Thu, 24 Jul 2003 17:34:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 24 Jul 2003 15:34:19.0240 (UTC) FILETIME=[0C596E80:01C351F9] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA11170 Subject: [AVT] Retransmission draft Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, for your information: Matsushita has sent an IPR disclosure to the IETF IPR website regarding patent rights applicable to the draft-ietf-rtp-retransmission-08.txt. More information can be found under http://www.ietf.org/ipr cheers, Jos=E9 Rey____ mailto:rey@panasonic.de Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 http://www.pel.panasonic.de ____________________________________ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 24 14:13:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19395 for ; Thu, 24 Jul 2003 14:13:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fka9-0003uy-Ja for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 14:12:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OICngc015037 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 14:12:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkZO-0003kQ-0R; Thu, 24 Jul 2003 14:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkYv-0003jf-0M for avt@optimus.ietf.org; Thu, 24 Jul 2003 14:11:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19292; Thu, 24 Jul 2003 14:11:22 -0400 (EDT) Message-Id: <200307241811.OAA19292@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , avt@ietf.org From: The IESG Date: Thu, 24 Jul 2003 14:11:21 -0400 Subject: [AVT] Protocol Action: RTP Control Protocol Extended Reports (RTCP XR) to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'RTP Control Protocol Extended Reports (RTCP XR)' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are A. Mankin and J. Peterson Technical Summary This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. Security considerations including the use of Secure RTCP to overcome the heightened amount of information provided by the XR packet type are described. Working Group Summary The working group divided for a time on whether to include more complex types of monitoring in the initial seven block types, but the resolution on the framework achieved a very good consensus. Protocol Quality Prototype implementations exist of the XR packet type and have been discussed in reviewing the specification. The review of the specification was very active due to strong interest by a variety of communities. The review for the IESG was done by Allison Mankin. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 24 17:23:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01533 for ; Thu, 24 Jul 2003 17:23:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnXw-00070p-ND for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 17:22:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLMiFH026935 for avt-archive@odin.ietf.org; Thu, 24 Jul 2003 17:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnXF-0006qn-FB; Thu, 24 Jul 2003 17:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnXA-0006qM-6A for avt@optimus.ietf.org; Thu, 24 Jul 2003 17:21:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01498 for ; Thu, 24 Jul 2003 17:21:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fnX7-0002Ry-00 for avt@ietf.org; Thu, 24 Jul 2003 17:21:53 -0400 Received: from sea2-f39.sea2.hotmail.com ([207.68.165.39] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19fnWx-0002Pg-00 for avt@ietf.org; Thu, 24 Jul 2003 17:21:43 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Jul 2003 14:19:20 -0700 Received: from 193.220.224.9 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 24 Jul 2003 21:19:16 GMT X-Originating-IP: [193.220.224.9] X-Originating-Email: [siteshdube@hotmail.com] From: "sitesh dube" To: avt@ietf.org Date: Thu, 24 Jul 2003 21:19:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jul 2003 21:19:20.0718 (UTC) FILETIME=[3F644AE0:01C35229] Subject: [AVT] timestamp Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hello, can u help me out on how to actually generate and implement the RTP timestamp for mpeg1. Thank you sitesh _________________________________________________________________ Attention NRIs. Send money home. http://server1.msn.co.in/msnleads/citibankrca/citibankrca2.asp?type=txt Do it in a jiffy! _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 25 10:30:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07507 for ; Fri, 25 Jul 2003 10:30:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3Zw-0006Dm-VN for avt-archive@odin.ietf.org; Fri, 25 Jul 2003 10:29:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PETq1N023913 for avt-archive@odin.ietf.org; Fri, 25 Jul 2003 10:29:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3Z7-00062T-SU; Fri, 25 Jul 2003 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3Z3-00062F-Jz for avt@optimus.ietf.org; Fri, 25 Jul 2003 10:28:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07396 for ; Fri, 25 Jul 2003 10:28:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3Z1-0000fz-00 for avt@ietf.org; Fri, 25 Jul 2003 10:28:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19g3Yq-0000fU-00 for avt@ietf.org; Fri, 25 Jul 2003 10:28:44 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6PERvG6015069 for ; Fri, 25 Jul 2003 16:27:57 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XMXMDG; Fri, 25 Jul 2003 16:27:57 +0200 Message-ID: <3F213E6A.7020505@ericsson.com> Date: Fri, 25 Jul 2003 16:27:54 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Comments on draft-chen-rtp-bv-00.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Here are some comments on this draft. Before this I would like to say thank you to the authors for providing a very good initial version of the draft. I have very few comments. 1. There is need to tighten up the use of aggregation of consecutive frames. I would propose that in section 3.2 and 4.2 add a sentence stating that any frames in payload MUST be consecutive. If that is not intended there is need for having some mechanism for recovering the timestamp for each individual frame. 2. Section 3 and 4 are both missing specification for how to use the marker bit. I would suggest the normal definition that for packets with there first frame being an speech onset the marker bit is set to 1, otherwise 0. Please see draft-ietf-avt-profile-new-13.txt 3. I would also like to see some more text on how one recovers the RTP timestamp for an aggregated frame. I now that as long as you only intend to aggregate consecutive frames it will be RTP TS + TS_rate*0.005*(n-1) however this should be written out. 4. I would also suggest that you tighten the language in Section 5 regarding that BroadVoice 16 and 32 frames shall not be mixed in a file. Please use the suitable RFC 2119 language for this. 5. Section 6.1, the usage of maxptime. Are there any need to define a default value for maxptime and especially of selecting 200 ms? 6. Section 6.1, Public Specification. This needs to be a complete reference. 7. Section 7. I would suggest that you improve your text for how to map the parameters to SDP. I would suggest borrowing text from section 8.3 of RFC 3267. 8. The reference list needs to be split into normative and informative references. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jul 25 11:35:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09403 for ; Fri, 25 Jul 2003 11:35:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4aj-0001ir-7b for avt-archive@odin.ietf.org; Fri, 25 Jul 2003 11:34:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFYjik006583 for avt-archive@odin.ietf.org; Fri, 25 Jul 2003 11:34:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4a1-0001eU-Co; Fri, 25 Jul 2003 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4ZB-0001Y4-Vy for avt@optimus.ietf.org; Fri, 25 Jul 2003 11:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09345 for ; Fri, 25 Jul 2003 11:33:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4ZA-0001B8-00 for avt@ietf.org; Fri, 25 Jul 2003 11:33:09 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19g4Z0-0001B1-00 for avt@ietf.org; Fri, 25 Jul 2003 11:32:58 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6PFWaG6026455 for ; Fri, 25 Jul 2003 17:32:36 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 366D5715; Fri, 25 Jul 2003 17:33:20 +0200 Message-ID: <3F214D92.50808@ericsson.com> Date: Fri, 25 Jul 2003 17:32:34 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF AVT WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Chair on vaction Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi everybody, I will be on vacation for three weeks from now. I will be back the 18th of July. Any questions will have to be answered by Colin and Steve. But please cc me anyway so I can know what has happened. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jul 26 21:10:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23013 for ; Sat, 26 Jul 2003 21:10:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ga3R-0006ME-MM for avt-archive@odin.ietf.org; Sat, 26 Jul 2003 21:10:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6R1ATfX024400 for avt-archive@odin.ietf.org; Sat, 26 Jul 2003 21:10:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ga2z-0006Kq-JU; Sat, 26 Jul 2003 21:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ga23-0006Fj-RD for avt@optimus.ietf.org; Sat, 26 Jul 2003 21:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23008 for ; Sat, 26 Jul 2003 21:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ga21-0006Ug-00 for avt@ietf.org; Sat, 26 Jul 2003 21:09:01 -0400 Received: from host18.belle.hyatthsia.com ([12.110.82.18] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19ga20-0006Ub-00 for avt@ietf.org; Sat, 26 Jul 2003 21:09:00 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6R18lvA003931; Sun, 27 Jul 2003 02:08:48 +0100 (BST) (envelope-from csp@csperkins.org) Date: Sat, 26 Jul 2003 16:37:16 +0100 From: Colin Perkins To: Magnus Westerlund Cc: avt@ietf.org Subject: Re: [AVT] Comments on draft-chen-rtp-bv-00.txt Message-Id: <20030726163716.32de75bb.csp@csperkins.org> In-Reply-To: <3F213E6A.7020505@ericsson.com> References: <3F213E6A.7020505@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.3 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, --> Magnus Westerlund writes: > Here are some comments on this draft. Before this I would like to say > thank you to the authors for providing a very good initial version of > the draft. I have very few comments. ...[snip several good comments]... > 5. Section 6.1, the usage of maxptime. Are there any need to define a > default value for maxptime and especially of selecting 200 ms? The maxptime attribute can probably be defined by reference to draft-ietf- mmusic-sdp-new-13.txt, rather than by copying the definition. > 6. Section 6.1, Public Specification. This needs to be a complete > reference. > > 7. Section 7. I would suggest that you improve your text for how to map > the parameters to SDP. I would suggest borrowing text from section 8.3 > of RFC 3267. > > 8. The reference list needs to be split into normative and informative > references. 9. The mention, in section 2, that BroadVoice16 might be adopted in a future PacketCable standard is not appropriate, and will need to be removed or replaced by a reference to the published PacketCable standard before this draft can become an RFC (I made a similar comment to the iLBC authors during at meeting). Cheers, -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jul 27 19:20:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28558 for ; Sun, 27 Jul 2003 19:20:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19guoU-0003XB-Kx for avt-archive@odin.ietf.org; Sun, 27 Jul 2003 19:20:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RNKQOq013581 for avt-archive@odin.ietf.org; Sun, 27 Jul 2003 19:20:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gun7-0003PV-8E; Sun, 27 Jul 2003 19:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gumM-0003Og-Ts for avt@optimus.ietf.org; Sun, 27 Jul 2003 19:18:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28470 for ; Sun, 27 Jul 2003 19:18:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gumL-00011w-00 for avt@ietf.org; Sun, 27 Jul 2003 19:18:13 -0400 Received: from host18.belle.hyatthsia.com ([12.110.82.18] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19gumK-00011l-00 for avt@ietf.org; Sun, 27 Jul 2003 19:18:12 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6RNI8vA050280; Mon, 28 Jul 2003 00:18:08 +0100 (BST) (envelope-from csp@csperkins.org) Date: Sun, 27 Jul 2003 16:17:04 -0700 From: Colin Perkins To: avt@ietf.org Cc: casner@acm.org, magnus.westerlund@ericsson.com Message-Id: <20030727161704.432b7b18.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sun__27_Jul_2003_16:17:04_-0700_0817bc00" Subject: [AVT] Draft minutes for Vienna meeting Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Multipart_Sun__27_Jul_2003_16:17:04_-0700_0817bc00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Folks, Attached are draft minutes for the AVT meeting at the 57th IETF in Vienna. Please send any comments or corrections to the chairs by 1st August. -- Colin Perkins csp@csperkins.org --Multipart_Sun__27_Jul_2003_16:17:04_-0700_0817bc00 Content-Type: text/plain; name="avt-minutes-ietf57.txt" Content-Disposition: attachment; filename="avt-minutes-ietf57.txt" Content-Transfer-Encoding: quoted-printable Audio/Video Transport Working Group Minutes Reported by Magnus Westerlund and Colin Perkins=20 The AVT working group met once at the 57th IETF in Vienna. During this session the working group discussed the updated charter, current status, VoIP congestion control concerns raised by the IAB, the SSM RTCP Extensi= on and numerous RTP payload formats.=20 Introduction and document status The meeting started by Stephen Casner announcing that this will be his last meeting as AVT co-chair. Allison Mankin presented Stephen with a plaque enumerating the RFCs that Stephen has been shepherding during his time as chair for AVT since its start in 1992. The working group showed its appreciation for his long service with thundering applause. Stephen Casner outlined the current working group status. No RFCs relating to AVT have been published since the last meeting, however there are a currently 7 in the RFC editor's queue. The RTP specification is currently in author's 48 hours and has gone through one substantial change. The usage of the SDP RR and RS bandwidth modifier results in change to the RTCP interval calculation mechanism. An RTP active sender is allowed to take its part of the RR part when the number of senders are larger than RS/(RS+RR). This is a generalisation of the previous 25% rule that was present. The senders=3D0 clause in the example algorithm (A.7) has also been removed to prevent senders bandwidth bleeding to receivers when RR=3D0. =20 =20 The other AVT drafts in the RFC editor's queue are the AVP profile, the RTP profile MIME registration, the SDP bandwidth modifier for RTCP, the RTP payload format for EVRC/SMV and the RTP payload format for ETSI ES 201 108 DSR. The specification for Enhanced IP/UDP/RTP header compression is with the RFC Editor, but the authors would like to fix one technical shortcoming before publication. This can be done if the Area Director and Working Group approve of the change. The issue is to include the CSRC list in the calculation of the Headers Checksum (HDRCKSUM), to enable header validation and prevent error propagation in the CSRC list. The working group was given until 18th July (the end of the IETF week) to comment on this change. Positive comments were made during the meeting, and there were no objections on the mailing list. The working group also has a number of drafts in IESG review: Tunnelling multiplexed compressed RTP (TCRTP), Secure RTP (which has had some recen= t=20 modifications in response to AD review), the Payload format for MPEG-4, RTCP extended reports, RTCP feedback (draft-ietf-avt-rtcp-feedback-07) and associated simulations (draft-burmeister-avt-rtcp-feedback-sim-02), and RTP retransmission (draft-ietf-avt-rtp-retransmission-08). The drafts of Uneven Level Protection (draft-ietf-avt-ulp-07.txt) and Unequal erasure protection (draft-ietf-avt-uxp-05.txt) were not updated for this meeting.=20 Colin Perkins noted that ITU-T SG16 Q.14 is working on standards for FAX over RTP. He expressed interest in increasing coordination between ITU-T and AVT to ensure that solutions developed do not conflict. He also noted that a MIME type registration must be done to ensure that the FAX over RTP work can be referenced by IETF protocols - such a registration should be coordinated with AVT. Charter Update A preliminary updated WG charter with milestones was presented and has also be posted to the mailing list. Please review and send any comments to the list. The updated charter contains the following items:=20 - Advance RTP and the A/V profile to Full standard RFC - Review and revise RTP payload formats for Draft Standard RFC, as appropriate - Develop new RTP payload formats as needed.=20 - Complete the generic FEC formats (ULP & UXP) - Complete the RTCP extensions for SSM sessions=20 - Develop a framing method for use of RTP/RTCP over TCP & TLS=20 - Review applicability of RTP header compression for MPLS=20 - Develop a new RTP profile combining AVPF and SAVP=20 - Coordinate with the DCCP working group to ensure efficient transport of RTP over DCCP, and to ensure an appropriate API is developed Longer term goals of the working group are to move to Draft Standard=20 the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,=20 the Compressed RTP (CRTP) framework, including Enhanced CRTP, and the RTP MIB. Further development of media codecs is not expected to be chartered.=20 DCCP http://www.ietf.org/html.charters/dccp-charter.html Aaron Falk made a short informational speech about DCCP and its upcoming design review. He encouraged people to read the specification, and come to the design review. He especially desired people in AVT to comment on any API related issues, as this relates to the possible usage of DCCP.=20 RTP Payload Format for MIDI draft-ietf-avt-mwpp-midi-rtp-08.txt draft-lazzaro-avt-mwpp-coding-guidelines-03.txt Colin Perkins outlined some slides from John Lazarro regarding the RTP payload format for MIDI. This format has been reviewed by the MMA (the MIDI Manufacturers Association) and their comments have been addressed. An implementation exists and will be updated in regards to the changes during the summer. It is expected that the draft will be ready for working group last call before the next meeting.=20 The companion implementation guide for RTP MIDI has been updated to more concern the MIDI parts, like recovery journal, than to deal with general RTP things. John Lazzaro has requested that this document becomes a AVT working group document. A hum was performed with some indication for approval and none against. =20 RTP framing for TCP and TLS draft-lazzaro-avt-rtp-framing-contrans-01.txt Colin Perkins updated the group on the RTP framing for TCP and TLS. This draft has been awaiting resolution of the MMUSIC WG comedia work and the rechartering. It can be expected to make progress once the new charter is accepted.=20 IAB Concerns Regarding VoIP congestion control=20 draft-iab-congestion-00.txt Sally Floyd made a short presentation on an initial draft of IAB recommendations regarding congestion control for Voice over IP flows. The basic recommendation is that any flow that is facing persistent high rates of packet loss should stop sending. Having congestion control of some type will ensure that congestion collapse does not happen, user quality can be maintained, and that fairness against other VoIP flows and TCP flows can be maintained in a best effort network.=20 The draft does not recommend any particular deployment path for VoIP, like best effort, QoS reservations, etc. It also not specifying any behaviour, it is only a recommendation that there is a need to address these issues. It also tries to address some of the framing problems and what assumptions that can be made, like what is fairness, and is the network, bit-rate or processor limited.=20 Several questions and comments where raised. One was the need to clarify what it means to terminate a connection: in this case stop sending media (not necessarily to terminate any signalling relationship). It was asked if RTCP information is sufficient for deciding when to terminate the data flow, which will need further investigation.=20 Is was also asked why the draft is restricted to VoIP and doesn't addres= s=20 other media types? This is not because other media don't need congestion control for other media, rather it's a reaction to the special treatment often proposed for voice (e.g. because flows are low bandwidth). This special treatment is not considered appropriate. It was also clarified that the document does not address congestion control for multicast.=20 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals=20 draft-ietf-avt-rfc2833bis-03.txt Henning Schulzrinne presented the current status of the draft. No major technical changes have occurred, and it is now believed that all events have been tracked down (however, review from someone working in this area would be appreciated). The examples in the draft have also been improved. Henning believes that the document is ready for WG last call, however some more dedicated review would be beneficial. Tom Taylor and Flemming Andreasen volunteered to perform a review of the document. The goal is to have the draft ready for last call before or around the next IETF meeting.=20 This draft was originally intended to become a Draft Standard RFC, however so far the interop testing has not progressed. Henning questioned the level of interoperability testing that will be needed: if every event needs to be tested that will be a futile effort as they are over a 100 in total, and from several different systems. Alternatives are:=20 - interop testing only needs to show that the basic timing and redundan= cy=20 mechanisms works - to strip all events that can't be tested, which probably will result in only DTMF tones will be left - the last alternative is to leave this as a proposed standard for all future.=20 The chairs will ask the area directors if basic timing and redundancy interoperability is sufficient for testing for draft standard. It was proposed that the draft be continued to be progressed to WG last call and be published as Proposed Standard RFC, while work continues on interoperability testing. The only consideration is if any of the interoperability will result in technical changes to the document,=20 in that case it might be better to wait. It would be advantageous if someone actually doing implementation work using this format could be participate in the interoperability testing.=20 Payload format for Speex Codec=20 draft-herlein-speex-rtp-profile-01.txt Phil Kerr presented an update to the RTP payload format for Speex. The format has received extensive comments on the mailing list that need to be addressed in next version. Comments in the meeting were regarding the usage of the RTP timestamp rate. There has been some consideration that a codec parameter for rate may be redundant, since the codec has some functionality for recovering sampling rate. Another alternative would be to use different RTP payload types and timestamp rates depending on codec rate, this is however not without problem as Stephen Casner pointed out. The issue needs further investigation. The recovery of the timestamp for different frames when performing aggregation also needs to be clarified.=20 Payload format for Vorbis=20 draft-kerr-avt-vorbis-rtp-02.txt Phil Kerr presented an update, where the main issue is related to the codebooks that the codec uses. One thing introduced in the last version is caching of the codebooks. This needs to be clarified, especially in cases where the code book needs to transfered. A codebook is not limited in size but they are commonly in the size 10-14 kbytes. So far suggested mechanism are: 1) Transfer in HTTP, 2) send it RTCP APP packets, 3) Use RTP over TCP, 4) try to define a limited set of codebooks that has to be cached and are simply referenced. Steve Casner commented that in RTP version 1 there was a mechanism to transfer parameters in parallel. However this was removed due to synchronisation problems. Having any such mechanism is a slippery slope and needs to be threaded carefully.=20 What is the gain from performing application level fragmentation, rather than using IP level fragmentation? Need to be further clarified and evaluated if enough gain is present to warrant the complexity of the mechanism. There has also been a number of other general comments on the draft on the mailing list regarding usage of SDP parameters, Path MTU discovery, RTP timestamp recovery, and frame aggregation that needs to be resolved.=20 Internet Low Bit Rate Codec and RTP payload format draft-ietf-avt-ilbc-codec-02.txt draft-ietf-avt-rtp-ilbc-02.txt Alan Duric presented an update of the codec and payload format. The codec has been reviewed by speech coding experts and their comments=20 will be distributed when the last call is announced. As a result of=20 the review the codec specification has been clarified and corrected. The new version should be possible to implement based only on the description rather then the source code. The payload format has an open issue with mode flag if only one side=20 is capable of supporting 20 ms frame length in an SDP Offer/Answer negotiation. The proposal to fix this is to include an offer/answer section in the draft, specifying bi-directional behaviour for the mode flag. A related issue is that ptime can't double as mode flag (this should be explained in the text, since it is a common question).=20 As there has been no demand for comfort noise (CN) generation it will not be included in the Codec. Henry Sinnreich commented that Voice Activity Detection (VAD) and CN generation is important. The counter comment was that an external VAD and the generic CN can be used anyway. There might also be future work to provide iLBC with VAD and CN.=20 Colin Perkins asked if there is any need for test vectors? The answer from Alan is that the codec specification is desired to remain being a floating-point defined one and therefore exact test vectors can't be used. However there is a possibility to provide test vector and then use PESQ measurements to check how far from the nominal output ones implementation produces. If any vector will be provided they will be in a separate draft. Jon Peterson asked if the mode parameter is a more generic parameter and therefore should be defined as such. Alan said that he had seen it in some other codecs. Magnus Westerlund commented that any mode parameter and their values are codec specific and should therefore be defined as such.=20 RTP Payload Format for Uncompressed Video=20 draft-ietf-avt-uncomp-video-03.txt The current status and remaining open issues were presented by Ladan Gharai. There have been few technical changes since the last version, mostly editorial and related to understanding. The two payload parameters sub-sampling and color-mode has been combined into one parameter (sampling) to avoid the usage of "impossible" combinations.=20 The remaining open issue is if the currently defined colorimetry values are sufficient or if there are more that should be defined? David Singer also had an comment that YUV-4:4:2 sampling can have their chroma samples in different orders. This needs to be addressed.=20 After the next update the draft is expected to be mature enough for working group last call.=20 RTP Payload for H.264/JVT Video=20 draft-ietf-avt-rtp-h264-02.txt Stephan Wenger presented the current status. The video codec itself has now been approved by ITU as H.264 and will soon also be approved by ISO/IEC. Work will continue in the JVT for professional extensions, however the NALU interface will not be changed, so this work is not believed to effect the payload format. The updated draft has been significantly improved regarding understanding, especially of the decoding order number (DON) concept.=20 There are a few remaining open issues. Should we do base64 encoding of the parameters sets instead of base16? There does not seem to be any formal problem of using this, and it will provide better efficiency.=20 The security consideration needs to be improved and carefully reviewed. There is concern over Timing SEI messages, since broken implementations may disregard the RTP timestamp. There is need for strong clarifications on the problem of doing that. Steve Casner commented that at least the blame and cause are on the same side, namely with the decoder.=20 RTP Payload format for 3GPP Timed Text=20 draft-rey-avt-3gpp-timed-text-00.txt Jose Rey presented for the first time a proposal for an RTP payload format for the 3GPP timed text format. The timed text format provides decorated and timed text, that can be used for karaoke and subtitling. There is a need to complete this work fairly quickly as the 3GPP Release 6 deadline is officially march 2004, and may move to June 2004.=20 Steve Casner commented that the current proposal seems to provide much flexibility that does not provide any useful functionality, and only complicates the format. Colin Perkins also questioned how this work relates to RFC 2793, RTP Payload for Text Conversation. The answer is that text conversation does not provide modifiers for style and fonts and other decorations as 3GPP Timed Text provides.=20 Joerg Ott raised the most substantial question: should this be a more generic work. The applications are not limited to 3GPP mobile phones with streaming, and a generic format seams appropriate. David Singer commented that he had hoped that the W3C and MPEG work on authoring and transport of decorated and timed text would be further progressed at this time, and could provide input into this work. However Dave also pointed out that there is a strong need to meet the 3GPP deadline. Magnus Westerlund further commented that he hoped that people were talking about a generic payload format rather than specifying a generic set of operations on text (i.e. a text codec) in duplication of work ongoing in other standards bodies. David singer further commented that there are usually no comments when people standardise multiple different codecs, that one generic is enough. The conclusion is that there is need to further explore the scope of the work here. The subject should be clarified through a mail discussion or internet draft.=20 The request for working group status has been delayed until the open issues regarding how generic the work should be can be resolved.=20 RTCP Extensions for SSM Sessions with Unicast Feedback=20 draft-ietf-avt-rtcpssm-04.txt Joerg Ott presented the update of the draft. The format has reverted back to using its own RSI RTCP format instead of defining XR extension formats. Some editorial issues have not been fixed yet. The authors believe there are only a few remaining technical issues for this draft. One issue is if the distribution source should be allowed to use only the senders RTCP bandwidth part or also the receivers? Steve commented that the appropriate thing would be to allow the distribution source to use all RTCP bandwidth as it summaries all RTCP. Magnus Westerlund also commented that care should be take to define the RTCP behaviour for SSM in the draft as the default, however future profiles may redefine this behaviour.=20 The second issue is the possible need to have values indicating for which sources, or number of sources, the gathered information in RSI mode applies to. This may be an unnecessary complication of the format, and Magnus Westerlund commented that it only seems to be applicable to some of the formats. Joerg asked if there is any need for this feature=20 otherwise the authors plan to go for simplicity here (meaning that the receivers have to trust the sender to do the reasonable thing when summarising).=20 The third issue is that RTCP BYE packets are reported five times (as is done for SSRC collisions). However there seems to be little necessity of doing this for normal RTCP BYE packets. Steve Casner commented that it seems to be an advantage of having this to work in the same way as standard RTCP. Colin commented that there is probably no need to report a collision more than one every time you detect it: if the receiver that causes the collision does not receive the report packet, the collision will continue and a new collision report will be sent after the next observation of it by the source.=20 There is significant interest in this work and the authors should do their best to meet the December milestone in the preliminary revised charter. Colin Perkins pointed out that the definition of the "a=3Drtcp"= =20 attribute contradicts the definition in draft-ietf-mmusic-sdp-nat-05.txt= .=20 The intention from the authors was to use it as defined in the SDP NAT draft.=20 Colin Perkins noted that while the Security Considerations section has a thorough declaration of the problems present with this RTCP extension, there is a need to have normative declaration on how these security considerations shall be addressed in different applications. If not, there will not be possible to have an interoperable implementations.=20 Requirements for performing RTP header compression over MPLS networks draft-ash-e2e-voip-hdr-comp-rqmts-00.txt draft-ash-e2e-vompls-hdr-compress-01.txt draft-ash-e2e-crtp-hdr-compress-01.txt Jerry Ash presented an introduction and motivation for the work that has previously been discussed in the MPLS working group. There are several ideas that has been proposed in this context. The main idea is to provide RTP/UDP/IP header compression over several hops in backbones that have expensive bit-rate costs. Ideas include that one can perform header compression from an ingress point in an MPLS network to the egress point without doing compression/decompression for each link. Instead the MPLS router can forward the compressed packets based on either MPLS labels, or the compression context IDs. However the scalability of each solution needs to be further investigated. The context switch idea could also be applied outside an MPLS network for other links. Another part of the complete framework is to ensure that the header compression mechanism can handle the long delay that may result between the compression and decompression points. So far the assumption is that ECRTP will be enough for this.=20 There were several voices raised questioning the need of this work. There seems to be interest to migrate legacy voice channels done over circuit switched connections to instead use VoIP. Further there was a lot of confusion in the public in regards to what End-to-End in the presentation meant. However this is either MPLS ingress to egress, or in some optimised cases may be through end-to-end if all nodes from end- point to end-point support CCID switching and header compression. This mechanism will not be media dependent as it will be able to compress the header for any RTP transported media. The actual work to be done is not clear and some people address concern that it seems to be a very strange idea. It is clear that the work must first start with writing an requirements document that people agree on and to get the people understand what the goals of this work is.=20 Co-coordination with other working groups will be needed, in particular the MPLS working group, and it is hoped that the people from other WG will participate in also in the initial phases defining requirements. = =20 - * - --Multipart_Sun__27_Jul_2003_16:17:04_-0700_0817bc00-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 28 00:04:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04596 for ; Mon, 28 Jul 2003 00:04:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gzFP-0002Yn-A3 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 00:04:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S44VGU009812 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 00:04:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gzEv-0002WF-LY; Mon, 28 Jul 2003 00:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gzEE-0002Uv-0o for avt@optimus.ietf.org; Mon, 28 Jul 2003 00:03:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04540 for ; Mon, 28 Jul 2003 00:03:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gzEB-0003af-00 for avt@ietf.org; Mon, 28 Jul 2003 00:03:15 -0400 Received: from host44.belle.hyatthsia.com ([12.110.82.44] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19gzEB-0003aY-00 for avt@ietf.org; Mon, 28 Jul 2003 00:03:15 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6S43Atv000342 for ; Mon, 28 Jul 2003 05:03:11 +0100 (BST) (envelope-from csp@csperkins.org) Date: Sun, 27 Jul 2003 18:15:03 -0700 From: Colin Perkins To: avt@ietf.org Message-Id: <20030727181503.3e3ce1d3.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Working group last call: draft-ietf-avt-rfc2833bis-03.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is to announce a working group last call on the RTP Payload for DTMF Digits, Telephony Tones and Signals . Please send any final comments on this draft to the mailing list by 11th August 2003. If no substantive technical issues are raised, we intend to submit this draft for publication as a proposed standard RFC to obsolete RFC 2833. Note that this draft will not be advanced until we receive at least one valid review from someone not directly involved with production of the draft (i.e., not an author or contributor). -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 28 05:46:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25465 for ; Mon, 28 Jul 2003 05:46:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h4YM-0007Ww-J4 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 05:44:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6S9iQMc028924 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 05:44:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h4Xx-0007Vq-2E; Mon, 28 Jul 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h4Xk-0007Va-TX for avt@optimus.ietf.org; Mon, 28 Jul 2003 05:43:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25423 for ; Mon, 28 Jul 2003 05:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h4Xh-0000BE-00 for avt@ietf.org; Mon, 28 Jul 2003 05:43:45 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19h4Xg-0000BA-00 for avt@ietf.org; Mon, 28 Jul 2003 05:43:44 -0400 thread-index: AcNU7IdD8C+CB/KJSDKP2FHowkcwTw== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Jul 2003 11:42:15 +0200 From: "Jose Rey" Content-Class: urn:content-classes:message Priority: normal To: Date: Mon, 28 Jul 2003 11:42:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 28 Jul 2003 09:42:15.0315 (UTC) FILETIME=[87294630:01C354EC] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA25424 Subject: [AVT] 3GPP timed text draft: more generic? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, during the presentation of the payload format for 3GPP timed text some concerns arose on whether this work should be more generic. On the other hand I also emphasized the fact that there's a deadline to meet here for 3GPP Release 6: March '04. It is our opinion that, in this case, a more specific payload format for the 3GPP timed text format is the right way to go. Does anybody think otherwise? We would like to hear comments/critic on this, in order to progress to working group work item. How could it be made more generic? thanks in advance, Jos=E9 Rey____ mailto:rey@panasonic.de Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 http://www.pel.panasonic.de ____________________________________ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 28 09:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00619 for ; Mon, 28 Jul 2003 09:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h7v2-0005Ps-75 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 09:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SDK4Gr020818 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 09:20:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h7u1-0005IX-LM; Mon, 28 Jul 2003 09:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h7tA-0005I6-OG for avt@optimus.ietf.org; Mon, 28 Jul 2003 09:18:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00572 for ; Mon, 28 Jul 2003 09:18:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h7t9-0002DS-00 for avt@ietf.org; Mon, 28 Jul 2003 09:18:07 -0400 Received: from host44.belle.hyatthsia.com ([12.110.82.44] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19h7t8-0002DM-00 for avt@ietf.org; Mon, 28 Jul 2003 09:18:06 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6SDHwq5007069; Mon, 28 Jul 2003 14:17:58 +0100 (BST) (envelope-from csp@csperkins.org) Date: Mon, 28 Jul 2003 06:17:58 -0700 From: Colin Perkins To: "Jose Rey" Cc: avt@ietf.org Subject: Re: [AVT] 3GPP timed text draft: more generic? Message-Id: <20030728061758.2c17d347.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --> "Jose Rey" writes: > > Hi all, > > during the presentation of the payload format for 3GPP timed text some > concerns arose on whether this work should be more generic. On the > other hand I also emphasized the fact that there's a deadline to meet > here for 3GPP Release 6: March '04. > > It is our opinion that, in this case, a more specific payload format for > the 3GPP timed text format is the right way to go. Does anybody think > otherwise? We would like to hear comments/critic on this, in order to > progress to working group work item. How could it be made more generic? A specific payload format for 3GPP timed text might be appropriate, but I would like to understand the options and alternatives before we make that choice. Is 3GPP the only body doing timed and/or decorated text? If not, what are the alternatives, and how do they relate? -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jul 28 09:26:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00775 for ; Mon, 28 Jul 2003 09:26:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h80j-0005dL-6H for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 09:25:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SDPv9u021616 for avt-archive@odin.ietf.org; Mon, 28 Jul 2003 09:25:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h7zp-0005Vw-1m; Mon, 28 Jul 2003 09:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h7zl-0005VF-Bh for avt@optimus.ietf.org; Mon, 28 Jul 2003 09:24:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00716 for ; Mon, 28 Jul 2003 09:24:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h7zP-0002IK-00 for avt@ietf.org; Mon, 28 Jul 2003 09:24:35 -0400 Received: from host44.belle.hyatthsia.com ([12.110.82.44] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19h7zP-0002IH-00 for avt@ietf.org; Mon, 28 Jul 2003 09:24:35 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h6SDOWq5007161; Mon, 28 Jul 2003 14:24:32 +0100 (BST) (envelope-from csp@csperkins.org) Date: Mon, 28 Jul 2003 06:24:32 -0700 From: Colin Perkins To: "Jose Rey" Cc: avt@ietf.org Subject: Re: [AVT] Retransmission draft Message-Id: <20030728062432.116b4e47.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jose, --> "Jose Rey" writes: > for your information: > > Matsushita has sent an IPR disclosure to the IETF IPR website regarding > patent rights applicable to the draft-ietf-rtp-retransmission-08.txt. > > More information can be found under http://www.ietf.org/ipr Is it possible for you to elaborate on which parts of the retransmission format are covered by the Matsushita IPR? -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 05:53:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17192 for ; Tue, 29 Jul 2003 05:53:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hRAf-0004ch-AG for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 05:53:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6T9rTBa017765 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 05:53:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hRAD-0004bn-9X; Tue, 29 Jul 2003 05:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hR9h-0004Yx-Sc for avt@optimus.ietf.org; Tue, 29 Jul 2003 05:52:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17175 for ; Tue, 29 Jul 2003 05:52:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hR9e-0003qP-00 for avt@ietf.org; Tue, 29 Jul 2003 05:52:26 -0400 Received: from c2mailgwalt.mailcentro.com ([207.183.238.112]) by ietf-mx with esmtp (Exim 4.12) id 19hR9d-0003q9-00 for avt@ietf.org; Tue, 29 Jul 2003 05:52:25 -0400 Received: from c2web204 (c0mailgwalt1.prontomail.com [207.183.238.111]) by c2mailgwalt.mailcentro.com (8.12.8/8.12.0-c2mailgw04) with SMTP id h6T9s9VT005211; Tue, 29 Jul 2003 02:54:09 -0700 X-Version: Mailcentro(english) X-SenderIP: 203.200.24.199 X-SenderID: 8114614 From: "Neo Anderson" Message-Id: <4F2B0A162724F4A478553D3C4FC99A12@neo.wiseone.zzn.com> Date: Tue, 29 Jul 2003 15:21:17 +0530 X-Priority: Normal Content-Type: text/html To: Premendra.Kumar@infineon.com, avt@ietf.org Subject: Re: [AVT] (no subject) X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by Mailcentro using amavisd-milter wirh reject option Content-Transfer-Encoding: quoted-printable Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable
---= - Begin Original Message ----

From: "Kumar Premendra (IFIN DC COM)" <Premendra.Kumar@inf= ineon.com>
Sent: Tue, 22 Jul 2003 13:50:26 +0530
To: avt@ietf.org
Subject: [AVT] (no subject)



Hello,

I have some doubt while implementing RTP/RTCP....please clarify my
= doubt if
possible.

Q. =A0We must send RTCP packet =A0in compound packet format ,Always ?
Yes.

> If not, how do we identify whether received packet is =A0normal RT= CP
packet or compound packet.

RFC 1889, 6.1 Says:
"There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to
provide an overall length to determine the end of the compound
packet."

Using udp for example, recvfrom () will give the length of the packet <= BR> which is received. This length has to be crosschecked with the length <= BR> field in the fixed header of RTCP packet(s).

--Neo







Get your own Free E-mail at Witc= h Wisdom http://www.witchwisdom.com
_________________________________= __________________________
Get your own Web-based E-mail Service at h= ttp://www.zzn.com

_______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 19:49:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15879 for ; Tue, 29 Jul 2003 19:49:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heDi-0006EO-4k for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:49:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNnUUs023948 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:49:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heDE-0006Ab-Qe; Tue, 29 Jul 2003 19:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heD5-0006A6-HD for avt@optimus.ietf.org; Tue, 29 Jul 2003 19:48:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15863; Tue, 29 Jul 2003 19:48:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heD3-000369-00; Tue, 29 Jul 2003 19:48:49 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19heD2-000366-00; Tue, 29 Jul 2003 19:48:48 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6TNmmJ12297; Tue, 29 Jul 2003 16:48:49 -0700 (PDT) Message-Id: <200307292348.h6TNmmJ12297@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Jul 2003 16:48:48 -0700 Subject: [AVT] RFC 3550 on RTP: A Transport Protocol for Real-Time Applications Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3550 Title: RTP: A Transport Protocol for Real-Time Applications Author(s): H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Status: Standards Track Date: July 2003 Mailbox: schulzrinne@cs.columbia.edu, casner@acm.org, ronf@bluecoat.com, van@packetdesign.com Pages: 104 Characters: 259985 Obsoletes: 1889 I-D Tag: draft-ietf-avt-rtp-new-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3550.txt This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. This document is a product of the Audio/Video Tranposrt Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030729164556.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3550 --OtherAccess Content-Type: Message/External-body; name="rfc3550.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030729164556.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 19:53:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15946 for ; Tue, 29 Jul 2003 19:53:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heHT-0006Te-Ai for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:53:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNrNi2024890 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heH7-0006NK-4A; Tue, 29 Jul 2003 19:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heGD-0006KQ-Jn for avt@optimus.ietf.org; Tue, 29 Jul 2003 19:52:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15916; Tue, 29 Jul 2003 19:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heGB-00037A-00; Tue, 29 Jul 2003 19:52:03 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19heGA-000377-00; Tue, 29 Jul 2003 19:52:02 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6TNq1J14235; Tue, 29 Jul 2003 16:52:01 -0700 (PDT) Message-Id: <200307292352.h6TNq1J14235@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Jul 2003 16:52:01 -0700 Subject: [AVT] RFC 3551 on RTP Profile for Audio and Video Conferences with Minimal Control Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3551 Title: RTP Profile for Audio and Video Conferences with Minimal Control Author(s): H. Schulzrinne, S. Casner Status: Standards Track Date: July 2003 Mailbox: schulzrinne@cs.columbia.edu, casner@acm.org Pages: 44 Characters: 106621 Obsoletes: 1890 I-D Tag: draft-ietf-avt-profile-new-13.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3551.txt This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Draft Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030729164925.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3551 --OtherAccess Content-Type: Message/External-body; name="rfc3551.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030729164925.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 19:54:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15998 for ; Tue, 29 Jul 2003 19:54:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heIP-0006b7-22 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:54:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNsL79025356 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:54:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heI4-0006Ul-U0; Tue, 29 Jul 2003 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heHq-0006UN-Io for avt@optimus.ietf.org; Tue, 29 Jul 2003 19:53:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15940; Tue, 29 Jul 2003 19:53:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heHo-00037t-00; Tue, 29 Jul 2003 19:53:44 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19heHn-00037q-00; Tue, 29 Jul 2003 19:53:43 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6TNriJ15351; Tue, 29 Jul 2003 16:53:44 -0700 (PDT) Message-Id: <200307292353.h6TNriJ15351@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Jul 2003 16:53:43 -0700 Subject: [AVT] RFC 3555 on MIME Type Registration of RTP Payload Formats Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3555 Title: MIME Type Registration of RTP Payload Formats Author(s): S. Casner, P. Hoschka Status: Standards Track Date: July 2003 Mailbox: casner@acm.org, ph@w3.org Pages: 45 Characters: 56618 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-mime-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3555.txt This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030729165219.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3555 --OtherAccess Content-Type: Message/External-body; name="rfc3555.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030729165219.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 19:56:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16099 for ; Tue, 29 Jul 2003 19:56:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heKK-0006kV-7r for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:56:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNuK3X025932 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 19:56:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heK0-0006eF-3R; Tue, 29 Jul 2003 19:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heJl-0006de-89 for avt@optimus.ietf.org; Tue, 29 Jul 2003 19:55:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16064; Tue, 29 Jul 2003 19:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heJj-00039C-00; Tue, 29 Jul 2003 19:55:43 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19heJi-000399-00; Tue, 29 Jul 2003 19:55:42 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6TNtgJ15819; Tue, 29 Jul 2003 16:55:42 -0700 (PDT) Message-Id: <200307292355.h6TNtgJ15819@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Jul 2003 16:55:42 -0700 Subject: [AVT] RFC 3556 on Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3556 Title: Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth Author(s): S. Casner Status: Standards Track Date: July 2003 Mailbox: casner@acm.org Pages: 8 Characters: 15310 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtcp-bw-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3556.txt This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030729165404.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3556 --OtherAccess Content-Type: Message/External-body; name="rfc3556.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030729165404.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 20:01:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16283 for ; Tue, 29 Jul 2003 20:01:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hePI-00076W-Hb for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 20:01:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U01Sji027302 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 20:01:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heOs-0006ze-E6; Tue, 29 Jul 2003 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heOF-0006ws-NF for avt@optimus.ietf.org; Tue, 29 Jul 2003 20:00:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16213; Tue, 29 Jul 2003 20:00:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heOD-0003Bn-00; Tue, 29 Jul 2003 20:00:21 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19heOC-0003Bk-00; Tue, 29 Jul 2003 20:00:20 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6U00LJ17943; Tue, 29 Jul 2003 17:00:21 -0700 (PDT) Message-Id: <200307300000.h6U00LJ17943@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Jul 2003 17:00:20 -0700 Subject: [AVT] RFC 3557 on RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3557 Title: RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding Author(s): Q. Xie, Ed. Status: Standards Track Date: July 2003 Mailbox: Qiaobing.Xie@motorola.com Pages: 15 Characters: 29692 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-dsr-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3557.txt This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030729165601.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3557 --OtherAccess Content-Type: Message/External-body; name="rfc3557.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030729165601.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jul 29 20:03:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16330 for ; Tue, 29 Jul 2003 20:03:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heR7-0007En-GW for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 20:03:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U03L15027814 for avt-archive@odin.ietf.org; Tue, 29 Jul 2003 20:03:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heQn-00078D-Bs; Tue, 29 Jul 2003 20:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heQH-00077k-Fm for avt@optimus.ietf.org; Tue, 29 Jul 2003 20:02:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16300; Tue, 29 Jul 2003 20:02:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heQF-0003D7-00; Tue, 29 Jul 2003 20:02:27 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19heQE-0003D4-00; Tue, 29 Jul 2003 20:02:26 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6U02QJ18091; Tue, 29 Jul 2003 17:02:26 -0700 (PDT) Message-Id: <200307300002.h6U02QJ18091@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Jul 2003 17:02:26 -0700 Subject: [AVT] RFC 3558 on RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3558 Title: RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) Author(s): A. Li Status: Standards Track Date: July 2003 Mailbox: adamli@icsl.ucla.edu Pages: 23 Characters: 49787 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-evrc-smv-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3558.txt This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030729170111.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3558 --OtherAccess Content-Type: Message/External-body; name="rfc3558.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030729170111.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jul 30 09:15:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29757 for ; Wed, 30 Jul 2003 09:15:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hqnd-000082-BJ for avt-archive@odin.ietf.org; Wed, 30 Jul 2003 09:15:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UDFPic000477 for avt-archive@odin.ietf.org; Wed, 30 Jul 2003 09:15:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hqnG-00006w-Bl; Wed, 30 Jul 2003 09:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hqmV-0008VN-0N for avt@optimus.ietf.org; Wed, 30 Jul 2003 09:14:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29709 for ; Wed, 30 Jul 2003 09:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hqmT-0007fy-00 for avt@ietf.org; Wed, 30 Jul 2003 09:14:13 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19hqmS-0007fq-00 for avt@ietf.org; Wed, 30 Jul 2003 09:14:12 -0400 thread-index: AcNWnD1U4nDZNEydThCPW04jp3bWOQ== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Wed, 30 Jul 2003 15:12:33 +0200 From: "Jose Rey" Content-Class: urn:content-classes:message Priority: normal To: "Colin Perkins" Cc: Subject: RE: [AVT] Retransmission draft Date: Wed, 30 Jul 2003 15:12:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20030728062432.116b4e47.csp@csperkins.org> X-OriginalArrivalTime: 30 Jul 2003 13:12:33.0908 (UTC) FILETIME=[3D414340:01C3569C] Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Colin, all, > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, July 28, 2003 3:25 PM > To: Jose Rey > Cc: avt@ietf.org > Subject: Re: [AVT] Retransmission draft > > > Jose, > > --> "Jose Rey" writes: > > for your information: > > > > Matsushita has sent an IPR disclosure to the IETF IPR > website regarding > > patent rights applicable to the > draft-ietf-rtp-retransmission-08.txt. > > > > More information can be found under http://www.ietf.org/ipr > > Is it possible for you to elaborate on which parts of the > retransmission > format are covered by the Matsushita IPR? The disclosed IPR covers the fact that a packet has two sequence numbers, one of each is used to determine the transmission order and the other one is for the reproduction order. Applying this to the draft these two sequence numbers map to the "standard" RTP SN and to the Original Sequence Number (OSN) fields, respectively. cheers, Jose > > -- > Colin Perkins > csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jul 31 17:59:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15251 for ; Thu, 31 Jul 2003 17:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLSK-0007QD-6y for avt-archive@odin.ietf.org; Thu, 31 Jul 2003 17:59:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VLxSRR028525 for avt-archive@odin.ietf.org; Thu, 31 Jul 2003 17:59:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLRs-0007NL-Mo; Thu, 31 Jul 2003 17:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iLR5-0007Ml-Gx for avt@optimus.ietf.org; Thu, 31 Jul 2003 17:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15151; Thu, 31 Jul 2003 17:58:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iLR2-00006a-00; Thu, 31 Jul 2003 17:58:08 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19iLR1-00006W-00; Thu, 31 Jul 2003 17:58:07 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6VLw7J13512; Thu, 31 Jul 2003 14:58:07 -0700 (PDT) Message-Id: <200307312158.h6VLw7J13512@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, avt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 31 Jul 2003 14:58:06 -0700 Subject: [AVT] RFC 3545 on Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3545 Title: Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering Author(s): T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy Status: Standards Track Date: July 2003 Mailbox: tmima@cisco.com, casner@acm.org, geevjohn@hotmail.com, brucet@cisco.com, pruddy@cisco.com Pages: 22 Characters: 48278 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-crtp-enhance-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3545.txt This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. This document is a product of the Audio Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030731145612.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3545 --OtherAccess Content-Type: Message/External-body; name="rfc3545.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030731145612.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt