From avt-bounces@ietf.org Fri Jul 01 04:08:55 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoGZz-0007l7-4w; Fri, 01 Jul 2005 04:08:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Do61o-0004L7-Vb
	for avt@megatron.ietf.org; Thu, 30 Jun 2005 16:52:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22661
	for <avt@ietf.org>; Thu, 30 Jun 2005 16:52:54 -0400 (EDT)
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6Re-0003ZW-DA
	for avt@ietf.org; Thu, 30 Jun 2005 17:19:38 -0400
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com
	[47.129.230.97])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j5UKqj823825; Thu, 30 Jun 2005 15:52:45 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 30 Jun 2005 16:52:29 -0400
Message-ID: <183DD1B052A11A40B76125E42F1CBAAB048C3AC7@zcarhxm1.corp.nortel.com>
Thread-Topic: RFC3711 non-zero key derivation rate and the logic to update key
	derivation
Thread-Index: AcV9taEAfFebUBgzQe2/aJptS2gtCg==
From: "Guoqiang Lu" <guoqian@nortel.com>
To: <avt@ietf.org>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
X-Mailman-Approved-At: Fri, 01 Jul 2005 04:08:54 -0400
Cc: mcgrew@cisco.com, mats.naslund@ericsson.com
Subject: [AVT] RFC3711 non-zero key derivation rate and the logic to update
	key derivation
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1969010836=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1969010836==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C57DB5.A13262D8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C57DB5.A13262D8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have a few questions about the key derivation as specified in RFC
3711.

1. What is the "r" in the sentence "...when r > 0, a key derivation is
performed whenever index mod r equals zero ... "? Is it the one later
defined:  r =3D index DIV key_derivation_rate?
2. The logic for performing a new key derivation is only mentioned in
the RFC 3711 as " .. a key derivation is performed whenever index mod r
equals zero ". In reality, more complicated logic is probably needed
considering the following scenarios:
Assume: Key_derivation_rate =3D 4, ROC =3D 0
Scenario 1:
For pakcet seq =3D 16, index =3D 16, r =3D 16 DIV 4 =3D 4, so 16 mod 4 =
=3D 0 a new
key is derived on the receiver side. But then packet seq =3D 14 arrived, =
r
=3D 14 DIV 4 =3D 3, but 14 mod 3 is not 0 so no new key derivation is
performed. But we can't use the key derived for seq =3D 16, the old key
should be used. So we need more complicated logic than the " index mod r
=3D =3D 0 " to determine whether to use the old key for seq =3D 14 =20
Scenario 2: Same as above but assume packet 16 is lost and never reached
the receiver, then for packet 17, r =3D 17 DIV 4 =3D 4, 17 mod 4 is not =
zero
and no new key is derived for packet 17 but on the sender side, packet
17 uses the new key.=20

Am I understanding it correctly?

Thanks!

Regards,

Guoqiang


------_=_NextPart_001_01C57DB5.A13262D8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.55">
<TITLE>RFC3711 non-zero key derivation rate and the logic to update key =
derivation</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a few questions about the key =
derivation as specified in RFC 3711.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. What is the &quot;r&quot; in the =
sentence &quot;...</FONT><FONT SIZE=3D2 FACE=3D"Arial">when r &gt; 0, a =
key derivation is performed whenever index mod r equals zero ... &quot;? =
Is it the one later defined:&nbsp; r =3D index DIV =
key_derivation_rate?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2</FONT><FONT FACE=3D"Times New =
Roman">.</FONT> <FONT SIZE=3D2 FACE=3D"Arial">The logic for performing a =
new key derivation is only mentioned in the RFC 3711 as &quot; .. a key =
derivation is performed whenever index mod r equals zero &quot;. In =
reality, more complicated logic is probably needed considering the =
following scenarios:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Assume: Key_derivation_rate =3D 4, ROC =
=3D 0</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Scenario 1:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">For pakcet seq =3D 16, index =3D 16, r =
=3D 16 DIV 4 =3D 4, so 16 mod 4 =3D 0 a new key is derived on the =
receiver side. But then packet seq =3D 14 arrived, r =3D 14 DIV 4 =3D 3, =
but 14 mod 3 is not 0 so no new key derivation is performed. But we =
can't use the key derived for seq =3D 16, the old key should be used. So =
we need more complicated logic than the &quot; index mod r =3D =3D 0 =
&quot; to determine whether to use the old key for seq =3D 14&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Scenario 2: Same as above but assume =
packet 16 is lost and never reached the receiver, then for packet 17, r =
=3D 17 DIV 4 =3D 4, 17 mod 4 is not zero and no new key is derived for =
packet 17 but on the sender side, packet 17 uses the new key. =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Am I understanding it correctly?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT FACE=3D"Simsun">Guoqiang</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57DB5.A13262D8--


--===============1969010836==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1969010836==--




From avt-bounces@ietf.org Fri Jul 01 04:17:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoGhf-0001aa-V4; Fri, 01 Jul 2005 04:16:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DoGhd-0001aC-K2
	for avt@megatron.ietf.org; Fri, 01 Jul 2005 04:16:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05647
	for <avt@ietf.org>; Fri, 1 Jul 2005 04:16:47 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoH7W-0007MG-MH
	for avt@ietf.org; Fri, 01 Jul 2005 04:43:37 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 41C06D6C; 
	Fri,  1 Jul 2005 10:16:38 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 1 Jul 2005 10:16:37 +0200
Received: from ericsson.com ([147.214.118.190]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 1 Jul 2005 10:16:37 +0200
Message-ID: <42C4FBE4.7040700@ericsson.com>
Date: Fri, 01 Jul 2005 10:16:36 +0200
From: =?ISO-8859-1?Q?Mats_N=E4slund?= <mats.naslund@ericsson.com>
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: Guoqiang Lu <guoqian@nortel.com>
References: <183DD1B052A11A40B76125E42F1CBAAB048C3AC7@zcarhxm1.corp.nortel.com>
In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB048C3AC7@zcarhxm1.corp.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Jul 2005 08:16:37.0134 (UTC)
	FILETIME=[336112E0:01C57E15]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
Cc: mcgrew@cisco.com, avt@ietf.org
Subject: [AVT] Re: RFC3711 non-zero key derivation rate and the logic to
 update key derivation
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Guoqiang,

This is by far the most common "FAQ" for SRTP ;-)

You are right, due e.g. to packet re-oredering it may not suffice
to only perform derivation when "index mod r equals zero". This is
informative text that describes the *principle*, but not the
actual way to implement it.

The normative text (later) is:

"Key derivation SHALL be defined as follows
  ...
  The n-bit SRTP key (or salt) for this packet SHALL
  then be derived ...  as follows:"

Please notice the text "for *this* packet" which is intended
to indicate that this is potentially a per-packet issue.

Best,

/Mats


Guoqiang Lu wrote:
> 
> I have a few questions about the key derivation as specified in RFC 3711.
> 
> 1. What is the "r" in the sentence "...when r > 0, a key derivation is 
> performed whenever index mod r equals zero ... "? Is it the one later 
> defined:  r = index DIV key_derivation_rate?
> 
> 2. The logic for performing a new key derivation is only mentioned in 
> the RFC 3711 as " .. a key derivation is performed whenever index mod r 
> equals zero ". In reality, more complicated logic is probably needed 
> considering the following scenarios:
> 
> Assume: Key_derivation_rate = 4, ROC = 0
> Scenario 1:
> For pakcet seq = 16, index = 16, r = 16 DIV 4 = 4, so 16 mod 4 = 0 a new 
> key is derived on the receiver side. But then packet seq = 14 arrived, r 
> = 14 DIV 4 = 3, but 14 mod 3 is not 0 so no new key derivation is 
> performed. But we can't use the key derived for seq = 16, the old key 
> should be used. So we need more complicated logic than the " index mod r 
> = = 0 " to determine whether to use the old key for seq = 14 
> 
> Scenario 2: Same as above but assume packet 16 is lost and never reached 
> the receiver, then for packet 17, r = 17 DIV 4 = 4, 17 mod 4 is not zero 
> and no new key is derived for packet 17 but on the sender side, packet 
> 17 uses the new key.
> 
> Am I understanding it correctly?
> 
> Thanks!
> 
> Regards,
> 
> Guoqiang



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



From avt-bounces@ietf.org Fri Jul 01 13:16:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoP8G-0003cb-9b; Fri, 01 Jul 2005 13:16:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DoP8B-0003bs-HD; Fri, 01 Jul 2005 13:16:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16762;
	Fri, 1 Jul 2005 13:16:44 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DoPYC-00078t-2y; Fri, 01 Jul 2005 13:43:40 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1DoP8A-0002R7-Pn; Fri, 01 Jul 2005 13:16:46 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1DoP8A-0002R7-Pn@newodin.ietf.org>
Date: Fri, 01 Jul 2005 13:16:46 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: avt@ietf.org
Subject: [AVT] Last Call: 'RTP Payload Format for AC-3 Audio' to Proposed
	Standard 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

The IESG has received a request from the Audio/Video Transport WG to consider 
the following document:

- 'RTP Payload Format for AC-3 Audio '
   <draft-ietf-avt-rtp-ac3-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-15.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ac3-07.txt


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



From avt-bounces@ietf.org Sat Jul 02 11:16:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DojjK-00070k-IO; Sat, 02 Jul 2005 11:16:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DojjI-0006z1-5q
	for avt@megatron.ietf.org; Sat, 02 Jul 2005 11:16:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27130
	for <avt@ietf.org>; Sat, 2 Jul 2005 11:16:25 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dok9S-0005v8-WE
	for avt@ietf.org; Sat, 02 Jul 2005 11:43:32 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63648
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1Dojit-00085F-D2; Sat, 02 Jul 2005 16:16:03 +0100
In-Reply-To: <F5DC0AC0-9790-4283-8783-35A002D58A10@jp.sony.com>
References: <F5DC0AC0-9790-4283-8783-35A002D58A10@jp.sony.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E63C940E-90D3-4525-B9E0-B5DC0126E7C3@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] syncing sessions
Date: Sat, 2 Jul 2005 16:15:56 +0100
To: Matthew Romaine <Matthew.Romaine@jp.sony.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 27 Jun 2005, at 10:23, Matthew Romaine wrote:
> I've got a question about synchronizing multiple sessions related  
> to a single payload format.
>
> I am working on a payload format which will support separation of  
> data into "required" and "enhancements" categories - aka a variant  
> on scalable streaming. In addition to sending all frame-based data  
> over one session, I would like to support sending over two sessions  
> (necessary data on one session, enhancement data on a second session).
>
> I'm sure this isn't anything new for many of you, but my Google  
> chops aren't serving me very well so I thought I would seek some  
> pointers/suggestions on payloads to use as a reference.  (Not to  
> mention using an RFC as a reference last time was a mistake :)
>
> My main question is how to specify how one session "belongs" to  
> another - i.e., is there an SDP exchange to let a client calculate  
> which two receiving-end ports need to be "associated"? Or is this  
> all strictly an application-level implementation issue? (there is  
> enough data in each payload for a client to realize which session  
> they are dealing with (required or enhancement)).

You can signal layered coding in SDP using the "slash" notation on  
either the "c=" or "m=" lines. For example, you might say:

     m=video 49170/2 RTP/AVP 31

specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172  
and 49173 form the second RTP/RTCP pair. Alternatively, you might use  
the grouping framework (RFC 3388).

Colin

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



From avt-bounces@ietf.org Sat Jul 02 11:18:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DojlP-00083n-Pn; Sat, 02 Jul 2005 11:18:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DojlO-00083f-8v
	for avt@megatron.ietf.org; Sat, 02 Jul 2005 11:18:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27314
	for <avt@ietf.org>; Sat, 2 Jul 2005 11:18:35 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DokBa-0006At-7I
	for avt@ietf.org; Sat, 02 Jul 2005 11:45:42 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63663
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DojlE-0008JM-Rz; Sat, 02 Jul 2005 16:18:29 +0100
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60119FF70@aclmsg.corp.audiocodes.com>
References: <79B4F738DDD4EF4F85A4641A0FE5EFD60119FF70@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DA5383E4-8C9B-43C4-AEC6-2E20DB57C52D@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Sat, 2 Jul 2005 16:18:23 +0100
To: Vladimir Ulybin <Vladimir@audiocodes.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

You might review draft-ietf-avt-rtp-retransmission-11.txt, which  
discusses this issue and proposes an RTP-friendly approach to  
retransmission.

Colin



On 30 Jun 2005, at 09:31, Vladimir Ulybin wrote:
> In T.38 UDPTL protocol, every primary fax packet has a unique  
> sequence number.
>
> To immune a fax session of packet loss in the network, gateways use  
> redundancy and packet retransmissions.
>
> When a T.38 UDPTL packet is retransmitted, the sequence number is  
> unchanged.
>
> In T.38 over RTP protocol, the RTP sequence number must be used.  
> The RFC 3550 defines the sequence number as monotonically  
> incremented by one for every packet sent to the network.
>
>
> If RTP sequence number is incremented per every retransmission,  
> then the retransmission of fax packets containing T.38 DATA packets  
> in primary or redundant RTP payloads is problematic because the T. 
> 30 data may be re-modulated incorrectly.
>
> The problem exists also for retransmission of T.38 INDICATOR  
> packets: If a primary T.38 INDICATOR is lost, the retransmitted T. 
> 38 INDICATOR arrived with a gap in RTP sequence number may be  
> delayed in packet recovery module, so the start of corresponding  
> fax signal may be delayed when it should not.
>
>
> The obvious solution is to increment RTP sequence number  
> conditionally by the same way as in T.38 UDPTL:
>
> The RTP sequence number is to be incremented per every new primary  
> fax packet, but remains unchanged if RTP packet transfers a  
> retransmitted primary fax packet.
>
>
> The questions:
>
> Does this conflict with some RTP protocol?
>
> What kind of interoperability problems (excluding RTCP statistics  
> of packet loss) may exist?
>
>
> Thanks,
>
> Vladimir Ulybin
>
> AudioCodes Ltd.
>
>
>
> _______________________________________________
> 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 avt-bounces@ietf.org Sun Jul 03 01:21:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DowvS-0004Fi-9S; Sun, 03 Jul 2005 01:21:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DowvQ-0004Er-K7
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 01:21:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07173
	for <avt@ietf.org>; Sun, 3 Jul 2005 01:21:52 -0400 (EDT)
Received: from m205-236.dsl.tsoft.com ([198.144.205.236]
	helo=hawaii.herlein.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DoxLk-00033c-0M for avt@ietf.org; Sun, 03 Jul 2005 01:49:04 -0400
Received: by hawaii.herlein.com (Postfix, from userid 1000)
	id 78EE78CC202; Sat,  2 Jul 2005 21:14:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by hawaii.herlein.com (Postfix) with ESMTP id 768C48CC1FE
	for <avt@ietf.org>; Sat,  2 Jul 2005 21:14:18 -0700 (PDT)
Date: Sat, 2 Jul 2005 21:14:18 -0700 (PDT)
From: Greg Herlein <gherlein@herlein.com>
To: avt@ietf.org
Message-ID: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Subject: [AVT] Syncronization of co-located clients?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I've got a scenario where I need to multicast RTP streams to 
multiple clients, and some of those may be within visual (and 
worse, audible) range of another client.

Is there a profile or other trick to help ensure syncronization 
*between* the clients?  In other words, ensure that the 
presentation of the material from one client is in sync with the 
others nearby?

I have some approaches to this, and have been hunting for other 
ideas.

Any links, references, research papers - whatever - would be 
appreciated.

Greg

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



From avt-bounces@ietf.org Sun Jul 03 10:44:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dp5i8-00007g-3q; Sun, 03 Jul 2005 10:44:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp5i6-000072-LZ
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 10:44:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04720
	for <avt@ietf.org>; Sun, 3 Jul 2005 10:44:40 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19] helo=imss.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp68S-000401-1y
	for avt@ietf.org; Sun, 03 Jul 2005 11:11:58 -0400
Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan
	Messaging Security Suite; Sun, 03 Jul 2005 17:47:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Sun, 3 Jul 2005 17:44:53 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A03EF@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcV/GWOSJB+r3e0BS5Wl3lLa79FlRgAtApEg
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: <avt@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Content-Transfer-Encoding: quoted-printable
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Colin,

Possibly I used the term "retransmission" non-correctly for T.38 over
RTP. In the draft-ietf-avt-rtp-retransmission-11.txt, the term
"retransmission" is applied to packets retransmitted as a response onto
the request of packet receiver detected packet lost. Such retransmission
reduces a reliability of fax relay, because enlarges the round-trip
delay of fax commands and responses.

But I assume a simple packet repetition following an original packet
transmission to improve a reliability of delivering important T.30
commands or responses. This repetition shall be done without any request
on retransmission from remote side. In T.38 UDPTL protocol the packet
repetition is widely used by different gateway vendors.

For example, the original fax packet "t38-v21-preamble-flags" is sent
with sequence number SN at time offset To. Waiting for "v21-hdlc-data"
with SN'=3DSN+1 for redundant transmission "t38-v21-preamble-flags" is =
not
a good solution for reliable fax relay, because if the original
"t38-v21-preamble-flags" is lost in the network, then the redundant
"t38-v21-preamble-flags" may reach the packet receiver when a linked fax
disconnects on timeout or the V.21 re-modulation cannot be started.

The repetition of primary "t38-v21-preamble-flags" done one ore more
times k>=3D1 at offsets To + k*T (where T is a short interval =
T=3D0..Nms)
with the same SN solves the problem of packet lost in a best way. The
incrementing SN as it is recommended in RFC 3550 cannot be accepted for
this case because reduces reliability of V.21 relay in conditions of
packet lost.

The same is valid for some other T.38 packets like
"fcs-OK"/"sig-end/no-signal", etc. Furthermore, incrementing SN for
repeated "fcs-OK"/"sig-end/no-signal" containing T.30 data as secondary
packets may cause incorrect data modulation toward a fax machine.

Taking into account for T.38-over-RTP that

1. Fax relay is asynchronous communication having long periods of packet
absence;
2. The redundancy and repetition of important fax packets significantly
improves the fax session reliability;
3. Incrementing RTP sequence number for repeated T.38 packets cannot be
accepted;
4. Reliability of fax session has a much higher priority vs. a correct
RTCP statistics;

I think we may use for RTP sequence number the same rules of
incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
primary IFP packet and do not increment SN if a fax packet is repeated.

Regards,
Vladimir Ulybin


-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]=20
Sent: Saturday, July 02, 2005 6:18 PM
To: Vladimir Ulybin
Cc: avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

You might review draft-ietf-avt-rtp-retransmission-11.txt, which =20
discusses this issue and proposes an RTP-friendly approach to =20
retransmission.

Colin



On 30 Jun 2005, at 09:31, Vladimir Ulybin wrote:
> In T.38 UDPTL protocol, every primary fax packet has a unique =20
> sequence number.
>
> To immune a fax session of packet loss in the network, gateways use =20
> redundancy and packet retransmissions.
>
> When a T.38 UDPTL packet is retransmitted, the sequence number is =20
> unchanged.
>
> In T.38 over RTP protocol, the RTP sequence number must be used. =20
> The RFC 3550 defines the sequence number as monotonically =20
> incremented by one for every packet sent to the network.
>
>
> If RTP sequence number is incremented per every retransmission, =20
> then the retransmission of fax packets containing T.38 DATA packets =20
> in primary or redundant RTP payloads is problematic because the T.=20
> 30 data may be re-modulated incorrectly.
>
> The problem exists also for retransmission of T.38 INDICATOR =20
> packets: If a primary T.38 INDICATOR is lost, the retransmitted T.=20
> 38 INDICATOR arrived with a gap in RTP sequence number may be =20
> delayed in packet recovery module, so the start of corresponding =20
> fax signal may be delayed when it should not.
>
>
> The obvious solution is to increment RTP sequence number =20
> conditionally by the same way as in T.38 UDPTL:
>
> The RTP sequence number is to be incremented per every new primary =20
> fax packet, but remains unchanged if RTP packet transfers a =20
> retransmitted primary fax packet.
>
>
> The questions:
>
> Does this conflict with some RTP protocol?
>
> What kind of interoperability problems (excluding RTCP statistics =20
> of packet loss) may exist?
>
>
> Thanks,
>
> Vladimir Ulybin
>
> AudioCodes Ltd.
>
>
>
> _______________________________________________
> 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 avt-bounces@ietf.org Sun Jul 03 13:05:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dp7uR-00036M-H3; Sun, 03 Jul 2005 13:05:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp7uQ-00036H-8E
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 13:05:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16932
	for <avt@ietf.org>; Sun, 3 Jul 2005 13:05:31 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp8Kp-0006OC-Kd
	for avt@ietf.org; Sun, 03 Jul 2005 13:32:52 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73])
	(authenticated bits=0)
	by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id
	j63H5V4K003802
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for <avt@ietf.org>; Sun, 3 Jul 2005 10:05:32 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <20050703160528.3B51235ACS@mxtreme0.EECS.Berkeley.EDU>
References: <20050703160528.3B51235ACS@mxtreme0.EECS.Berkeley.EDU>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B30BC73B-A940-45E6-9FA0-6168DED94AB6@eecs.berkeley.edu>
Content-Transfer-Encoding: 7bit
From: lazzaro <lazzaro@eecs.berkeley.edu>
Date: Sun, 3 Jul 2005 10:06:02 -0700
To: avt@ietf.org
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: Syncronization of co-located clients?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


On Jul 3, 2005, at 9:05 AM Greg Herlein wrote:
> I've got a scenario where I need to multicast RTP streams to  
> multiple clients, and some of those may be within visual (and  
> worse, audible) range of another client.
>
> Is there a profile or other trick to help ensure syncronization  
> *between* the clients?  In other words, ensure that the  
> presentation of the material from one client is in sync with the  
> others nearby?
>
> I have some approaches to this, and have been hunting for other ideas.
>
> Any links, references, research papers - whatever - would be  
> appreciated.

For a fixed installation, the simplest solution is low-tech:

http://www.auralex.com/

If this isn't quite what you had in mind ...

One technical approach is to run tightly synchronized clocks everywhere,
and communicate an absolute presentation time to all clients.  This will
require mechanisms for doing perceptually unobjectionable time slips
to handle clock drifts in the audio D/A conversion for each host.  We  
had
a good discussion about this topic on AVT a few years ago. See:

http://www.opensoundcontrol.org/papers/clock_sync_in_music_systems/

for a good summary of the clock synchronization part of the problem.

A second way is to use a feed-forward approach instead of synced  
clocks.  This
works if the network media has reliable nominal latency (outlier late  
packets are OK,
if there are methods of detecting them with good reliability).  For N  
 > 2 hosts,
algorithms exist that estimate the one-way latency between host pairs  
with
good accuracy (no references handy, maybe someone can post ...).  If you
have a good estimate of one-way latencies, it can substitute for tightly
synchronized clocks ...

To my knowledge, no support exists in RTP/SDP/SIP/RTSP stack to
implement either [1] or [2] above in an interoperable way ... but the
stack does support adding carefully placed foam panels onsite :-).

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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



From avt-bounces@ietf.org Sun Jul 03 14:02:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dp8n6-0001ps-Rp; Sun, 03 Jul 2005 14:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8n4-0001pn-Ia
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 14:02:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22733
	for <avt@ietf.org>; Sun, 3 Jul 2005 14:02:01 -0400 (EDT)
Received: from dns.packetdesign.com ([65.192.41.10]
	helo=mailman.packetdesign.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp9DT-0002Rt-GU
	for avt@ietf.org; Sun, 03 Jul 2005 14:29:20 -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
	j63I1Za2043536; Sun, 3 Jul 2005 11:01:36 -0700 (PDT)
	(envelope-from casner@acm.org)
Date: Sun, 3 Jul 2005 11:01:32 -0700 (PDT)
From: Stephen Casner <casner@acm.org>
To: Greg Herlein <gherlein@herlein.com>
Subject: Re: [AVT] Syncronization of co-located clients?
In-Reply-To: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
Message-ID: <20050703105831.L9967@oak.packetdesign.com>
References: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On Sat, 2 Jul 2005, Greg Herlein wrote:

> I've got a scenario where I need to multicast RTP streams to
> multiple clients, and some of those may be within visual (and
> worse, audible) range of another client.
>
> Is there a profile or other trick to help ensure syncronization
> *between* the clients?  In other words, ensure that the
> presentation of the material from one client is in sync with the
> others nearby?
>
> I have some approaches to this, and have been hunting for other
> ideas.
>
> Any links, references, research papers - whatever - would be
> appreciated.

The following paper describes a nice synchronization protocol
developed by Julio Escobar and colleagues at BBN which allows
specifying the synchronization goals and dynamically determining the
offsets needed to achieve sync:

    Julio Escobar, Craig Partridge, Debra Deutsch, "Flow
    Synchronization Protocol" IEEE/ACM Transactions on Networking,
    Vol.2, No. 2, pp.111-121, April 1994.

This may be more academic than you want; it defines a synchronization
model and what information needs to be communicated, rather than
providing a detailed protocol specification.  This protocol was
discussed in AVT for a while to consider whether RTP itself needed any
changes to support more general synchronization, but we concluded that
it did not.

This synchronization protocol was used in a demonstration of
distributed music performance that I helped implement at the ACM
Multimedia Conference 1994.  The music was a Haydn trio performed from
three different locations across the country.  Since only two
performers were available, one part was recorded.  That part was
transmitted over the network and played out simultaneously at the two
other locations.  The two live performers played their parts along
with that first one, not hearing each other.  All three parts were
multicast to multiple receivers, each of which synchronized the three
streams to play out the trio in unison.  The synchronization was
achieved through the timestamps on the media packets in combination
with delay offsets calculated by the synchronization protocol.

The synchronization goal for this demo is different from yours, but
the protocol is general.  You may find that you need to implement
something specific for your application, and this paper will give you
the theory behind it so you know what information needs to be
communicated where.

                                                        -- Steve

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



From avt-bounces@ietf.org Sun Jul 03 16:17:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpAuX-0002To-2w; Sun, 03 Jul 2005 16:17:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpAuV-0002QO-0G
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 16:17:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06755
	for <avt@ietf.org>; Sun, 3 Jul 2005 16:17:49 -0400 (EDT)
Received: from m205-236.dsl.tsoft.com ([198.144.205.236]
	helo=hawaii.herlein.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1DpBKv-0003Pt-3C for avt@ietf.org; Sun, 03 Jul 2005 16:45:10 -0400
Received: by hawaii.herlein.com (Postfix, from userid 1000)
	id 785E78CC20D; Sun,  3 Jul 2005 12:10:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by hawaii.herlein.com (Postfix) with ESMTP id 7608E8CC20C
	for <avt@ietf.org>; Sun,  3 Jul 2005 12:10:04 -0700 (PDT)
Date: Sun, 3 Jul 2005 12:10:04 -0700 (PDT)
From: Greg Herlein <gherlein@herlein.com>
To: avt@ietf.org
Subject: Re: [AVT] Syncronization of co-located clients?
In-Reply-To: <20050703105831.L9967@oak.packetdesign.com>
Message-ID: <Pine.LNX.4.61.0507031200380.20914@hawaii.herlein.com>
References: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
	<20050703105831.L9967@oak.packetdesign.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I found this as well - might provide a mechanism for sync based 
on SMPTE time code:

http://www.ietf.org/internet-drafts/draft-singer-smpte-rtp-01.txt

Assuming all clients controlled the playout buffer using the 
SMPTE time code, this could likely do it.  My particular 
application is on a local LAN (a controlled VLAN actually) so I 
am not expecting the network to present significant problems.

I've yet to review the recommended reading and products - I very 
much look forward to it.  If possible, I'd like to generalize a 
solution to this problem - which may indeed be something that the 
wider AVT audience wants to participate in.  I'd welcome that.

I'll also be shifting my participation in AVT to my work email 
(greg_herlein@prn.com) since this project is work and not 
personal.  I'd been active here using this email before so 
thought I'd use personal mail for my initial posts.

Greg

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



From avt-bounces@ietf.org Sun Jul 03 17:46:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpCI4-0006bd-M5; Sun, 03 Jul 2005 17:46:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpCI2-0006bS-B5
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 17:46:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14019
	for <avt@ietf.org>; Sun, 3 Jul 2005 17:46:12 -0400 (EDT)
Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpCiT-0001eI-F9
	for avt@ietf.org; Sun, 03 Jul 2005 18:13:34 -0400
Received: from or-67-76-145-81.sta.sprint-hsd.net (HELO erols.com)
	(67.76.145.81)
	by smtp04.mrf.mail.rcn.net with ESMTP; 03 Jul 2005 17:46:07 -0400
X-IronPort-AV: i="3.93,254,1115006400"; 
	d="scan'208"; a="54677830:sNHT19377400"
Message-ID: <42C85C92.23D59931@erols.com>
Date: Sun, 03 Jul 2005 14:45:54 -0700
From: Chuck Harrison <cfharr@erols.com>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Greg Herlein <gherlein@herlein.com>
Subject: Re: [AVT] Syncronization of co-located clients?
References: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
	<20050703105831.L9967@oak.packetdesign.com>
	<Pine.LNX.4.61.0507031200380.20914@hawaii.herlein.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Greg,

This is definitely an area of interest to me. Let's continue
the discussion here on AVT.

Peace,
  Chuck


Greg Herlein wrote:
> 
[...]> 
> I've yet to review the recommended reading and products - I very
> much look forward to it.  If possible, I'd like to generalize a
> solution to this problem - which may indeed be something that the
> wider AVT audience wants to participate in.  I'd welcome that.
>

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



From avt-bounces@ietf.org Sun Jul 03 19:08:25 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpDZZ-000390-K2; Sun, 03 Jul 2005 19:08:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpDZY-00038v-FU
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 19:08:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22799
	for <avt@ietf.org>; Sun, 3 Jul 2005 19:08:21 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.202])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpE00-0007to-7W
	for avt@ietf.org; Sun, 03 Jul 2005 19:35:45 -0400
Received: by wproxy.gmail.com with SMTP id i6so612615wra
	for <avt@ietf.org>; Sun, 03 Jul 2005 16:08:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=GGkCy2rq9a+uLUDuXvzK1csYk+bFHvNlQiwrLIei5c3VV+EbOGcFUi5Qgwd0y9uggQZtS/v1Rt9H0VjSiHJjnwF4SMpwc7RzXojNFPTNKn9vDYiE5wPK3bn+Wh17VBisf1FZWfNLCK14bppdCNxRVYX+SAIwOboLCEYKZMA3IL8=
Received: by 10.54.11.25 with SMTP id 25mr3187522wrk;
	Sun, 03 Jul 2005 16:08:14 -0700 (PDT)
Received: by 10.54.63.20 with HTTP; Sun, 3 Jul 2005 16:08:13 -0700 (PDT)
Message-ID: <2729632a05070316087858205d@mail.gmail.com>
Date: Sun, 3 Jul 2005 16:08:14 -0700
From: <skillzero@gmail.com>
To: avt@ietf.org
Subject: Re: [AVT] Syncronization of co-located clients?
In-Reply-To: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: skillzero@gmail.com
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 7/2/05, Greg Herlein <gherlein@herlein.com> wrote:
> I've got a scenario where I need to multicast RTP streams to
> multiple clients, and some of those may be within visual (and
> worse, audible) range of another client.
>=20
> Is there a profile or other trick to help ensure syncronization
> *between* the clients?  In other words, ensure that the
> presentation of the material from one client is in sync with the
> others nearby?

I may be oversimplifying your problem, but have you looked into using
the NTP and RTP timestamp information in RTCP sender/receiver reports
to synchronize? These RTCP reports allow you to determine the relative
offset of each client to the reference clock of the sender. Using
this, each client can adjust its playout delay to play at an absolute
time that is the same as the other clients.

I'm certainly not an expert, but this is what I am doing to play an
RTP audio stream in sync to multiple clients within audible range of
each other. What I found helpful is the book "RTP: Audio and Video for
the Internet" by Colin Perkins (ISBN 0-672-32248-8). The chapter on
Lip Synchronization describes the process of syncing streams using
RTCP reports.

It would be great to hear about other techniques, experiences, and
reading material.

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



From avt-bounces@ietf.org Sun Jul 03 19:22:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpDnS-0005O3-0Y; Sun, 03 Jul 2005 19:22:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpDnQ-0005Nt-1X
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 19:22:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23829
	for <avt@ietf.org>; Sun, 3 Jul 2005 19:22:41 -0400 (EDT)
Received: from dns.packetdesign.com ([65.192.41.10]
	helo=mailman.packetdesign.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpEDs-0000Zj-LQ
	for avt@ietf.org; Sun, 03 Jul 2005 19:50:05 -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
	j63NMOa2048632; Sun, 3 Jul 2005 16:22:24 -0700 (PDT)
	(envelope-from casner@acm.org)
Date: Sun, 3 Jul 2005 16:21:58 -0700 (PDT)
From: Stephen Casner <casner@acm.org>
To: Greg Herlein <gherlein@herlein.com>
Subject: Re: [AVT] Syncronization of co-located clients?
In-Reply-To: <Pine.LNX.4.61.0507031200380.20914@hawaii.herlein.com>
Message-ID: <20050703161251.N9967@oak.packetdesign.com>
References: <Pine.LNX.4.61.0507022110250.14450@hawaii.herlein.com>
	<20050703105831.L9967@oak.packetdesign.com>
	<Pine.LNX.4.61.0507031200380.20914@hawaii.herlein.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On Sun, 3 Jul 2005, Greg Herlein wrote:

> I found this as well - might provide a mechanism for sync based
> on SMPTE time code:
>
> http://www.ietf.org/internet-drafts/draft-singer-smpte-rtp-01.txt
>
> Assuming all clients controlled the playout buffer using the
> SMPTE time code, this could likely do it.  My particular
> application is on a local LAN (a controlled VLAN actually) so I
> am not expecting the network to present significant problems.

I don't think the SMPTE timecodes help unless they are representing an
absolute time in the future, where the sender has made a prediction
about the amount of time needed for propagation to all receivers and
buffering time within each receiver.  That might work in a controlled
LAN environment, but it is not a general solution.

The BBN Synchronization Protocol that I mentioned is based on using
synchronized clocks at the receivers (e.g., using NTP).  Each receiver
relates its earliest possible playout time for a media timestamp to
real time, and communicates that back to the controller.  The
controller finds the latest of these times and informs all the
receives so they can choose the same playout time.  There's more to it
than that, of course.  Sync "epochs" were used to deal with media
clock drifts, etc.

[I state the above without having read the paper in a long time.  I
seem to remember a centralized controller, but it could be done in a
distributed manner as well.]

                                                        -- Steve

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



From avt-bounces@ietf.org Sun Jul 03 21:11:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpFUM-00070R-2F; Sun, 03 Jul 2005 21:11:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFUK-00070M-D2
	for avt@megatron.ietf.org; Sun, 03 Jul 2005 21:11:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02467
	for <avt@ietf.org>; Sun, 3 Jul 2005 21:11:07 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpFun-0007yj-4Q
	for avt@ietf.org; Sun, 03 Jul 2005 21:38:30 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73])
	(authenticated bits=0)
	by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id
	j641Ave2004999
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for <avt@ietf.org>; Sun, 3 Jul 2005 18:11:02 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Transfer-Encoding: 7bit
Message-Id: <844C1EF2-9904-454F-A92C-697B259EA6F9@eecs.berkeley.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: avt@ietf.org
From: lazzaro <lazzaro@eecs.berkeley.edu>
Subject: Re: [AVT] Syncronization of co-located clients?
Date: Sun, 3 Jul 2005 18:11:28 -0700
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Stephen Casner <casner at acm.org> writes:
> I don't think the SMPTE timecodes help unless they are representing an
> absolute time in the future, where the sender has made a prediction
> about the amount of time needed for propagation to all receivers and
> buffering time within each receiver.  That might work in a controlled
> LAN environment, but it is not a general solution.

I think it might make sense to revisit the ideas in the BBN protocol,
but start with the latency model of a modern wired and wireless LAN,
and define a simplified protocol for this special case.  Zeroconf is
an example of a protocol that limited itself to "networking in the  
small"
and was very successful, and I think speaker synchronization could
be just as successful ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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



From avt-bounces@ietf.org Mon Jul 04 03:21:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpLGq-0004es-3z; Mon, 04 Jul 2005 03:21:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpLGn-0004ek-Bx
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 03:21:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26526
	for <avt@ietf.org>; Mon, 4 Jul 2005 03:21:32 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpLhI-0006Fu-Fg
	for avt@ietf.org; Mon, 04 Jul 2005 03:48:58 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A48EDE57; 
	Mon,  4 Jul 2005 09:21:29 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 4 Jul 2005 09:21:28 +0200
Received: from [147.214.34.71] ([147.214.34.71]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 4 Jul 2005 09:21:28 +0200
Message-ID: <42C8E378.1070108@ericsson.com>
Date: Mon, 04 Jul 2005 09:21:28 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vladimir Ulybin <Vladimir@audiocodes.com>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
References: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A03EF@aclmsg.corp.audiocodes.com>
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A03EF@aclmsg.corp.audiocodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Jul 2005 07:21:28.0685 (UTC)
	FILETIME=[FEA111D0:01C58068]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir Ulybin wrote:
> 
> I think we may use for RTP sequence number the same rules of
> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> primary IFP packet and do not increment SN if a fax packet is repeated.
> 

There exist at least two possible ways of performing this without 
screwing up the RTCP statistics and fulfilling your other requirements:

The first one is to use FEC to provide the packet repetition. I would 
suggest that you use RFC 2733 to provide repetition in a smarter way. 
This way one FEC packet can cover a few RTP packets. If this is done 
using RFC 2198 packetization then you don't even need to run two RTP 
sessions.

The second is actually to use that Retransmission RTP payload format for 
repetitions. The payload format is really for repetitions and the spec 
provides with necessary information on bind and sync. Simple skip the 
NACK process.

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 avt-bounces@ietf.org Mon Jul 04 04:32:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpMN4-0001Fm-4w; Mon, 04 Jul 2005 04:32:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpMN1-0001F0-Nx
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 04:32:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05862
	for <avt@ietf.org>; Mon, 4 Jul 2005 04:32:01 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19] helo=imss.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpMnW-0003NU-Ie
	for avt@ietf.org; Mon, 04 Jul 2005 04:59:29 -0400
Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan
	Messaging Security Suite; Mon, 04 Jul 2005 11:34:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Mon, 4 Jul 2005 11:32:19 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A0533@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAaRhrtrDpCU39QpSvsDtizf8meAAAX4Ig
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Thanks.

Magnus Westerlund wrote:
> The first one is to use FEC to provide the packet repetition...=20
> The second is actually to use that Retransmission RTP payload format
for=20
> repetitions...

But,
1. Not all gateways support FEC.
2. The RTP payload retransmission is under consideration (draft
document) and is not supported by all gateways. Also, the using it may
give additional interoperability conflicts, when one gateway supports
NACK but the other ignores it.=20

Regards,
Vladimir Ulybin

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Monday, July 04, 2005 10:21 AM
To: Vladimir Ulybin
Cc: avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir Ulybin wrote:
>=20
> I think we may use for RTP sequence number the same rules of
> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> primary IFP packet and do not increment SN if a fax packet is
repeated.
>=20

There exist at least two possible ways of performing this without=20
screwing up the RTCP statistics and fulfilling your other requirements:

The first one is to use FEC to provide the packet repetition. I would=20
suggest that you use RFC 2733 to provide repetition in a smarter way.=20
This way one FEC packet can cover a few RTP packets. If this is done=20
using RFC 2198 packetization then you don't even need to run two RTP=20
sessions.

The second is actually to use that Retransmission RTP payload format for

repetitions. The payload format is really for repetitions and the spec=20
provides with necessary information on bind and sync. Simple skip the=20
NACK process.

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 avt-bounces@ietf.org Mon Jul 04 04:49:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpMe0-0004Yz-Tj; Mon, 04 Jul 2005 04:49:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpMdy-0004YY-Mz
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 04:49:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08333
	for <avt@ietf.org>; Mon, 4 Jul 2005 04:49:32 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpN4T-0004nc-6n
	for avt@ietf.org; Mon, 04 Jul 2005 05:17:00 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63571
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DpMdb-0008Mc-6l; Mon, 04 Jul 2005 09:49:11 +0100
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A03EF@aclmsg.corp.audiocodes.com>
References: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A03EF@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <651BD409-AD1A-4BA6-825F-318B13A83817@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Mon, 4 Jul 2005 09:49:05 +0100
To: Vladimir Ulybin <Vladimir@audiocodes.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 3 Jul 2005, at 15:44, Vladimir Ulybin wrote:
> Possibly I used the term "retransmission" non-correctly for T.38 over
> RTP. In the draft-ietf-avt-rtp-retransmission-11.txt, the term
> "retransmission" is applied to packets retransmitted as a response  
> onto
> the request of packet receiver detected packet lost. Such  
> retransmission
> reduces a reliability of fax relay, because enlarges the round-trip
> delay of fax commands and responses.
>
> But I assume a simple packet repetition following an original packet
> transmission to improve a reliability of delivering important T.30
> commands or responses. This repetition shall be done without any  
> request
> on retransmission from remote side. In T.38 UDPTL protocol the packet
> repetition is widely used by different gateway vendors.

As Magnus says, the RFC 2733 FEC format is appropriate, or the  
retransmission draft I suggested.

> Taking into account for T.38-over-RTP that
>
> 1. Fax relay is asynchronous communication having long periods of  
> packet
> absence;
> 2. The redundancy and repetition of important fax packets  
> significantly
> improves the fax session reliability;
> 3. Incrementing RTP sequence number for repeated T.38 packets  
> cannot be
> accepted;
> 4. Reliability of fax session has a much higher priority vs. a correct
> RTCP statistics;
>
> I think we may use for RTP sequence number the same rules of
> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> primary IFP packet and do not increment SN if a fax packet is  
> repeated.

Not if you wish to be compatible with RTP: RTP requires the sequence  
numbers to be unique.

Colin

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



From avt-bounces@ietf.org Mon Jul 04 05:58:40 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpNiq-00075s-82; Mon, 04 Jul 2005 05:58:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpNio-00075P-R8
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 05:58:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17492
	for <avt@ietf.org>; Mon, 4 Jul 2005 05:58:35 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19] helo=imss.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpO9K-0004Hq-BR
	for avt@ietf.org; Mon, 04 Jul 2005 06:26:04 -0400
Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan
	Messaging Security Suite; Mon, 04 Jul 2005 13:01:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Mon, 4 Jul 2005 12:58:47 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A059D@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjw
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On my suggestion from 3 Jul 2005, at 15:44:
>> I think we may use for RTP sequence number the same rules of
>> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
>> primary IFP packet and do not increment SN if a fax packet is =20
>> repeated.

Colin Perkins wrote:
> Not if you wish to be compatible with RTP: RTP requires the sequence =20
> numbers to be unique.

1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550 as a
basic RTP protocol to be used for encapsulation.
2. The RFC 3550 does not define the packet repetition, also does not use
SHOULD or MUST for sequence number advances (in contrast to RFC 2833bis
were the MUST is used).=20
3. Different RTP sequence numbers assigned to the same fax signal state
or the same binary data cannot be considered as unique.
4. I try to find a more reliable transport for T.38 over RTP. The blind
assignment of new sequence numbers for ALL packets is full compatible
with RFC 3550, but highly reduces the reliability of fax relay, because
gateways may not repeat fax packets.
5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
only problem of packet repetition with the same SN is a distorted RTCP
statistics. In absence of other ways this violation is better than to
loose connection during fax relay.

Regards,
Vladimir Ulybin

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



From avt-bounces@ietf.org Mon Jul 04 06:30:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpODx-00049x-8a; Mon, 04 Jul 2005 06:30:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpODv-00048l-Fv
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 06:30:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20762
	for <avt@ietf.org>; Mon, 4 Jul 2005 06:30:44 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19] helo=imss.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpOb6-0007kq-GC
	for avt@ietf.org; Mon, 04 Jul 2005 06:54:46 -0400
Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan
	Messaging Security Suite; Mon, 04 Jul 2005 13:29:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Mon, 4 Jul 2005 13:27:31 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A05AD@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAAKlLHA=
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Corrected item 3:
3. Different RTP sequence numbers assigned to a fax state (or binary
data) detected (or demodulated) at ONE moment of time cannot be
considered as unique, because the one fax state will share some
different packets. There is no mutual correspondence.
Sorry,
Vladimir Ulybin


-----Original Message-----
From: Vladimir Ulybin=20
Sent: Monday, July 04, 2005 12:59 PM
To: 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

On my suggestion from 3 Jul 2005, at 15:44:
>> I think we may use for RTP sequence number the same rules of
>> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
>> primary IFP packet and do not increment SN if a fax packet is =20
>> repeated.

Colin Perkins wrote:
> Not if you wish to be compatible with RTP: RTP requires the sequence =20
> numbers to be unique.

1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550 as a
basic RTP protocol to be used for encapsulation.
2. The RFC 3550 does not define the packet repetition, also does not use
SHOULD or MUST for sequence number advances (in contrast to RFC 2833bis
were the MUST is used).=20
3. Different RTP sequence numbers assigned to the same fax signal state
or the same binary data cannot be considered as unique.
4. I try to find a more reliable transport for T.38 over RTP. The blind
assignment of new sequence numbers for ALL packets is full compatible
with RFC 3550, but highly reduces the reliability of fax relay, because
gateways may not repeat fax packets.
5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
only problem of packet repetition with the same SN is a distorted RTCP
statistics. In absence of other ways this violation is better than to
loose connection during fax relay.

Regards,
Vladimir Ulybin

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



From avt-bounces@ietf.org Mon Jul 04 06:47:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpOUW-00078v-QX; Mon, 04 Jul 2005 06:47:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpOUU-00078M-Nu
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 06:47:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23341
	for <avt@ietf.org>; Mon, 4 Jul 2005 06:47:48 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpOj0-0000jO-R9
	for avt@ietf.org; Mon, 04 Jul 2005 07:02:56 -0400
Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:49310)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DpOII-0001ke-Cy; Mon, 04 Jul 2005 11:35:18 +0100
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A059D@aclmsg.corp.audiocodes.com>
References: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A059D@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BF7AD458-91F9-4003-8C71-D0E21ADF786A@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Mon, 4 Jul 2005 11:35:15 +0100
To: Vladimir Ulybin <Vladimir@audiocodes.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 4 Jul 2005, at 10:58, Vladimir Ulybin wrote:
> On my suggestion from 3 Jul 2005, at 15:44:
>>> I think we may use for RTP sequence number the same rules of
>>> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
>>> primary IFP packet and do not increment SN if a fax packet is
>>> repeated.
>
> Colin Perkins wrote:
>> Not if you wish to be compatible with RTP: RTP requires the sequence
>> numbers to be unique.
>
> 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550  
> as a
> basic RTP protocol to be used for encapsulation.
> 2. The RFC 3550 does not define the packet repetition, also does  
> not use
> SHOULD or MUST for sequence number advances (in contrast to RFC  
> 2833bis
> were the MUST is used).

The RTP specification says "The sequence number increments by one for  
each RTP data packet sent".

> 3. Different RTP sequence numbers assigned to a fax state (or binary
> data) detected (or demodulated) at ONE moment of time cannot be
> considered as unique, because the one fax state will share some
> different packets. There is no mutual correspondence.

Using either RFC 2733, the RTP retransmission framework, or RTP over  
TCP will retain the sequence number. This is not a problem.

> 4. I try to find a more reliable transport for T.38 over RTP. The  
> blind
> assignment of new sequence numbers for ALL packets is full compatible
> with RFC 3550, but highly reduces the reliability of fax relay,  
> because
> gateways may not repeat fax packets.

As you say, gateways may not repeat the packets. This is because RTP  
requires all packets to have a unique sequence number - a gateway  
which suppresses the duplicates is behaving correctly.

> 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> only problem of packet repetition with the same SN is a distorted RTCP
> statistics. In absence of other ways this violation is better than to
> loose connection during fax relay.

The AVT working group has developed three alternatives to improve the  
quality of the media: RFC 2733, the RTP retransmission framework, or  
RTP over TCP. I believe one of those would be appropriate for your  
usage.

Colin

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



From avt-bounces@ietf.org Mon Jul 04 11:19:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DpSiz-00075K-9r; Mon, 04 Jul 2005 11:19:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSix-00074s-Ig
	for avt@megatron.ietf.org; Mon, 04 Jul 2005 11:19:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00356
	for <avt@ietf.org>; Mon, 4 Jul 2005 11:19:05 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpT9X-0003IS-84
	for avt@ietf.org; Mon, 04 Jul 2005 11:46:36 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j64FHXX02449 for <avt@ietf.org>; Mon, 4 Jul 2005 11:17:33 -0400 (EDT)
Received: from [127.0.0.1] (acart264.ca.nortel.com [47.130.17.133]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id MRAFQQ58; Mon, 4 Jul 2005 11:18:44 -0400
Message-ID: <42C95352.7080108@nortel.com>
Date: Mon, 04 Jul 2005 11:18:42 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Subject: [AVT] V.8 bis events in 2833bisdata
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I'm rewriting the V.8 bis events in 2833bisdata based on recent 
discussion.  I'm hoping no one is wedded to the previous codepoints. 
Please let me know if there is a problem.

Here are the changes, pending comment.  I have a separate question on 
ESi and ESr which I pose below.  "Old meaning" includes two tone 
segments in the same event.  "New meaning" includes only one segment, 
either the first or the second.

Codepoint    Old Meaning    New Meaning

41             CRdi            CRd (seg 2)
42             CRdr          unused
43             CRe             CRe (seg 2)
44             ESi           unused??
45             ESr           unused??
46             MRdi            MRd (seg 2)
47             MRdr          unused
48             MRe             MRe (seg 2)
65            unused         V8bisInit (seg 1)
66            unused         V8bisResp (seg 1)

The question marks on ESi and ESr are because when they are isolated to 
a single segment they become identical (except for duration) to V.21 '1' 
bits in low and high channel respectively.  I am wondering if I should 
therefore assign the same codepoints (38 and 40) to them as are assigned 
to the V.21 bits.

Any concerns or objections?

Tom Taylor


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



From avt-bounces@ietf.org Tue Jul 05 15:47:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DptNt-00018a-NK; Tue, 05 Jul 2005 15:47:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DptNp-00013s-G2
	for avt@megatron.ietf.org; Tue, 05 Jul 2005 15:47:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13969
	for <avt@ietf.org>; Tue, 5 Jul 2005 15:47:00 -0400 (EDT)
Received: from carrierpigeon.cs.umd.edu ([128.8.129.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DptjX-0003ll-Hf
	for avt@ietf.org; Tue, 05 Jul 2005 16:09:32 -0400
Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37])
	(authenticated bits=0)
	by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id
	j65JfWtX017067
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <avt@ietf.org>; Tue, 5 Jul 2005 15:41:35 -0400 (EDT)
Message-Id: <200507051941.j65JfWtX017067@carrierpigeon.cs.umd.edu>
From: "Moustafa Youssef" <moustafa@cs.umd.edu>
To: <avt@ietf.org>
Date: Tue, 5 Jul 2005 15:41:14 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] 1st CFP: 2nd IEEE Workshop on Dependability and Security in
	Sensor Networks and Systems
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                   First Call for Papers
       Second IEEE Workshop on Dependability and Security in
                    Sensor Networks and Systems
                            (DSSNS=922006)
                        http://www.dssns.org
                        In conjunction with
              2nd NASA/IEEE Systems and Software Week
        30th NASA/IEEE Software Engineering Workshop (SEW=922006)
                         April 24-28, 2006

Recently, there has been a growing interest in the potential use
of networked sensors in applications such as smart environments,=20
disaster management, combat field reconnaissance, and security=20
surveillance. While the initial view of the community was that=20
networked sensors will play a complementary role that enhances=20
the quality of these applications, recent research results have=20
encouraged practitioners to envision an increased reliance on sensor=20
networks and systems (SN&S) in such critical and sensitive applications.

Therefore to realize their potential, necessary dependability and=20
security (D&S) measures have to be incorporated in the design and=20
during the operation of SN&S. Dependability is usually specified=20
using attributes like reliability, survivability, safety,
maintainability,=20
and availability in presence of failure, while security is specified by=20
attributes like integrity, authenticity, confidentiality, and
availability=20
in presence of attacks. D&S services accomplish tasks for attack and
failure prevention, detection and response. The scope of D&S services
may
span the deployed sensors to command nodes and likely beyond. It also=20
involves D&S support at, and cross-cutting, the protocol stack layers=20
from physical to application.

Achieving dependability and security in SN&S will require
non-conventional=20
mechanisms due to many factors including: (1) sensors are significantly
constrained in the amount of available resources such as energy, storage

and computation; (2) sensors are expected to be deployed in very large
numbers in normal as well as harsh/hostile environments; (3) sensor
networks suffer from structural weakness and limited physical
protection, and (4) localization of impact is complicated due to the
un-tethered nature of SN&S and of the potential attackers. In addition,
D&S requirements may vary according to mission defined over a
multi-dimensional context, such as field of deployment (e.g., hostile
versus friendly), type of application (e.g., monitoring, tracking, data
collection), mode of operation (e.g., normal, exception, post-event
recovery), and time.

This workshop will foster a forum for discussing and presenting recent
research results on dependability and security in SN&S. Topics of
interest include, although not limited to, the following:

- Fault and intrusion-tolerant architectures, middleware and operational
models=20
- Robust routing, storage, and processing of sensed data
- D&S architectures, protocols and tools
- Vulnerabilities, attacks and countermeasures
- Monitoring and evaluation techniques
- Robust clustering techniques
- Self-awareness and context-awareness=20
- Resilient virtual infrastructures
- Autonomic and adaptive D&S support.
- Formal representation and verification of D&S properties
- Network inference support for D&S
- Quality of service provisioning
- Models, metrics, and measurements for D&S
- Privacy-aware D&S services
- Testbeds, simulation and visualization=20
- Agent-based D&S management=20
- SN&S  support for D&S in  larger information grids
- SN&S application development environments


Submission Guidelines
---------------------
For guidelines regarding paper submission, please refer to the
workshop=92s website (http://www.dssns.org). Papers should contain
original material and not be previously published, or currently
submitted for consideration elsewhere. The manuscript should not exceed
20 single-column double-space pages in PDF format, font size 11 or
larger. The first page should include title, authors' contact
information, abstract and five keywords.=20

Important Dates
----------------
Submission deadline:	November 7, 2004
Decision notification:	December 20, 2004
Final manuscript due:	January 20, 2005


The best paper will be recognized and selected papers will be invited to
a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks.=20

Workshop Co-Chairs
-------------------
Mohamed Eltoweissy
Virginia Tech, USA
E-mail: toweissy@vt.edu=20

Mohamed Younis
University of Maryland Baltimore County, USA
E-mail: younis@csee.umbc.edu=20

Publicity Co-Chairs
--------------------
Denis Gracanin
Virginia Tech, USA
E-mail: gracanin@vt.edu

Moustafa Youssef
University of Maryland at College Park, USA
E-mail: moustafa@cs.umd.edu=20

Program Committee
------------------
Farooq Anjum, Telcordia & U of Penn, USA
David Carman, Johns Hopkins Univ.=96 Applied Physics Lab, USA
Ing-Ray Chen, Virginia Tech, USA
M. Nazih Elderini, Alexandria Univ, Egypt
Sushil Jajodia, George Mason Univ., USA
Shivakant Mishra, Univ, of Colorado, USA
Peng Ning, North Carolina State U, USA
Stephan Olariu, Old Dominion Univ., USA
David Simplot-Ryl, Univ. Lille, INRIA Futurs, France
John A. Stankovic, University of Virginia, USA
Ivan Stojmenovic, Univ. of Ottawa, Canada
Cliff Wang, Army Research Office, USA
Stephen D. Wolthusen, Fraunhofer-IGD, Germany
Albert Zomaya, Univ. of Sydney, Australia


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



From avt-bounces@ietf.org Thu Jul 07 03:40:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqQzU-0004fM-OC; Thu, 07 Jul 2005 03:40:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQzT-0004f2-5x
	for avt@megatron.ietf.org; Thu, 07 Jul 2005 03:40:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07904
	for <avt@ietf.org>; Thu, 7 Jul 2005 03:40:09 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqRQa-0007Lc-BE
	for avt@ietf.org; Thu, 07 Jul 2005 04:08:14 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D9BEC149F
	for <avt@ietf.org>; Thu,  7 Jul 2005 09:40:07 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 7 Jul 2005 09:40:06 +0200
Received: from [147.214.34.71] ([147.214.34.71]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 7 Jul 2005 09:40:05 +0200
Message-ID: <42CCDC55.7010604@ericsson.com>
Date: Thu, 07 Jul 2005 09:40:05 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: multipart/mixed; boundary="------------050708030402000401010209"
X-OriginalArrivalTime: 07 Jul 2005 07:40:05.0995 (UTC)
	FILETIME=[17D64BB0:01C582C7]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e
Subject: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


This is a multi-part message in MIME format.
--------------050708030402000401010209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is relevant for AVT.

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

--------------050708030402000401010209
Content-Type: message/rfc822;
	name="I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt"
Content-Disposition: inline;
	filename="I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt"

X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by
	esealmw103.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:53:59 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C58264.7323E580"
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw105.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:49:29 +0200
Received: from esealmw128.eemea.ericsson.se ([130.100.184.163]) by
	esealmw126.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:53:58 +0200
Received: from mailgw1.ericsson.se ([193.180.251.59]) by
	esealmw128.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:53:57 +0200
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by
	mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id
	3C247450009; Wed,  6 Jul 2005 21:53:56 +0200 (CEST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by
	megatron.ietf.org with esmtp (Exim 4.32) id 1DqFup-0008Ld-Jk;
	Wed, 06 Jul 2005 15:50:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by
	megatron.ietf.org with esmtp (Exim 4.32) id 1DqFuH-0007zA-6x
	for i-d-announce@megatron.ietf.org; Wed, 06 Jul 2005 15:50:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org
	(8.9.1a/8.9.1a) with ESMTP id PAA10070 for
	<i-d-announce@ietf.org>; Wed, 6 Jul 2005 15:50:03 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with
	esmtp (Exim 4.43) id 1DqGLH-000862-MJ for i-d-announce@ietf.org;
	Wed, 06 Jul 2005 16:18:00 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id
	1DqFuE-000884-48 for i-d-announce@ietf.org;
	Wed, 06 Jul 2005 15:50:02 -0400
Return-Path: <i-d-announce-bounces@ietf.org>
X-OriginalArrivalTime: 06 Jul 2005 19:53:57.0726 (UTC)
	FILETIME=[72617FE0:01C58264]
Errors-To: i-d-announce-bounces@ietf.org
X-Spam-Score: 0.4 (/)
List-Post: <mailto:i-d-announce@ietf.org>
List-Id: i-d-announce.ietf.org
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-Brightmail-Tracker: AAAAAA==
Content-class: urn:content-classes:message
Subject: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt 
Date: Wed, 6 Jul 2005 21:50:02 +0200
Message-ID: <E1DqFuE-000884-48@newodin.ietf.org>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt 
Thread-Index: AcWCZHM8cveeT6CIQaqBia9mxT7Rog==
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
From: <Internet-Drafts@ietf.org>
Sender: <i-d-announce-bounces@ietf.org>
To: <i-d-announce@ietf.org>
Reply-To: <internet-drafts@ietf.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C58264.7323E580
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C58264.7323E580"


------_=_NextPart_002_01C58264.7323E580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.


	Title		: RTP Payload Format for Video Codec 1 (VC-1)
	Author(s)	: A. Klemets
	Filename	: draft-klemets-avt-rtp-vc1-00.txt
	Pages		: 21
	Date		: 2005-7-6
=09
   This memo specifies an RTP payload format for encapsulating Video=20
   Codec 1 (VC-1) compressed bit streams, as defined by the proposed=20
   Society of Motion Picture and Television Engineers (SMPTE) standard,=20
   SMPTE 421M.  SMPTE is the main standardizing body in the motion=20
   imaging industry and the proposed SMPTE 421M standard defines a=20
   compressed video bit stream format and decoding process for=20
   television.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-klemets-avt-rtp-vc1-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


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-klemets-avt-rtp-vc1-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-klemets-avt-rtp-vc1-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_002_01C58264.7323E580
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.84">
<TITLE>I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : RTP Payload Format for =
Video Codec 1 (VC-1)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : A. Klemets<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-klemets-avt-rtp-vc1-00.txt<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 21<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2005-7-6<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp; This memo specifies an RTP payload format for encapsulating =
Video<BR>
&nbsp;&nbsp; Codec 1 (VC-1) compressed bit streams, as defined by the =
proposed<BR>
&nbsp;&nbsp; Society of Motion Picture and Television Engineers (SMPTE) =
standard,<BR>
&nbsp;&nbsp; SMPTE 421M.&nbsp; SMPTE is the main standardizing body in =
the motion<BR>
&nbsp;&nbsp; imaging industry and the proposed SMPTE 421M standard =
defines a<BR>
&nbsp;&nbsp; compressed video bit stream format and decoding process =
for<BR>
&nbsp;&nbsp; television.<BR>
<BR>
A URL for this Internet-Draft is:<BR>
<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-klemets-avt-rtp-vc1-00.=
txt">http://www.ietf.org/internet-drafts/draft-klemets-avt-rtp-vc1-00.txt=
</A><BR>
<BR>
To remove yourself from the I-D Announcement list, send a message to<BR>
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message.&nbsp;<BR>
You can also visit <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1=
.ietf.org/mailman/listinfo/I-D-announce</A><BR>
to change your subscription settings.<BR>
<BR>
<BR>
Internet-Drafts are also available by anonymous FTP. Login with the =
username<BR>
&quot;anonymous&quot; and a password of your e-mail address. After =
logging in,<BR>
type &quot;cd internet-drafts&quot; and then<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-klemets-avt-rtp-vc1-00.txt&quot;.<BR>
<BR>
A list of Internet-Drafts directories can be found in<BR>
<A =
HREF=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A><BR>
or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A><BR>
<BR>
<BR>
Internet-Drafts can also be obtained by e-mail.<BR>
<BR>
Send a message to:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailserv@ietf.org.<BR>
In the body type:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-klemets-avt-rtp-vc1-00.txt&quot;.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document =
in<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using =
the &quot;mpack&quot; utility.&nbsp; To use this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command =
&quot;ENCODING mime&quot; before the &quot;FILE&quot;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the =
response(s), you will need &quot;munpack&quot; or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail =
reader.&nbsp; Different MIME-compliant mail readers<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior, =
especially when dealing with<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME =
messages (i.e. documents which have been split<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), =
so check your local documentation on<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these =
messages.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Below is the data which will enable a MIME compliant mail reader<BR>
implementation to automatically retrieve the ASCII version of the<BR>
Internet-Draft.<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C58264.7323E580--

------_=_NextPart_001_01C58264.7323E580
Content-Type: application/octet-stream;
	name="ATT501586.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT501586.TXT
Content-Disposition: attachment;
	filename="ATT501586.TXT"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS03LTYxMjI5MDYuSS1EQGlldGYub3JnPg0KDQpFTkNP
RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2xlbWV0cy1hdnQtcnRwLXZj
MS0wMC50eHQNCg==

------_=_NextPart_001_01C58264.7323E580
Content-Type: text/plain; charset="us-ascii";
	name="draft-klemets-avt-rtp-vc1-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-klemets-avt-rtp-vc1-00.txt
Content-Disposition: attachment;
	filename="draft-klemets-avt-rtp-vc1-00.txt"
Content-Transfer-Encoding: base64

RklMRSBERUxFVEVEDQotLS0tLS0tLS0tLS0NCg0KV2FybmluZyENCg0KVGhlIGF0dGFjaGVkIGZp
bGUgZHJhZnQta2xlbWV0cy1hdnQtcnRwLXZjMS0wMC5VUkwgaGFzIG5vdCBiZWVuIGRlbGl2ZXJl
ZC4NCg0KVGhlIHJlYXNvbiBpcyBkdWUgdG8gdGhlIEZJTEUgRklMVEVSPSAqLnVybCBvbiBtYWls
c2VydmVyIEVTRUFMTVcxMjguDQoNClBsZWFzZSBjb250YWN0IElUIFNlcnZpY2UgRGVzayBpZiB5
b3UgaGF2ZSBmdXJ0aGVyIHF1ZXN0aW9ucy4NCg0KSFA=

------_=_NextPart_001_01C58264.7323E580
Content-Type: text/plain;
	name="ATT501587.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT501587.txt
Content-Disposition: attachment;
	filename="ATT501587.txt"
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C58264.7323E580--


--------------050708030402000401010209
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------050708030402000401010209--




From avt-bounces@ietf.org Thu Jul 07 06:43:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqTqz-0007c0-W6; Thu, 07 Jul 2005 06:43:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTqx-0007ay-1B
	for avt@megatron.ietf.org; Thu, 07 Jul 2005 06:43:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21525
	for <avt@ietf.org>; Thu, 7 Jul 2005 06:43:31 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.201])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqUI5-0005dz-Hi
	for avt@ietf.org; Thu, 07 Jul 2005 07:11:39 -0400
Received: by wproxy.gmail.com with SMTP id i18so171871wra
	for <avt@ietf.org>; Thu, 07 Jul 2005 03:43:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=MtLdHouSR9VZuNMq100TLiZ62QQ77LlnD7VmnOYQidiyagMWecQ/tff0sS6Kp+H1rz0ofQz7zVl5WfGnArfIfSxHE+G4mqTyidWEh8R6hPFqOoWo6Omeh3mYVpvmHaQXkWqoaDL7hWcYfSRJKlJSvyHXB6Wi6swnAg7LemTFkK8=
Received: by 10.54.39.29 with SMTP id m29mr555851wrm;
	Thu, 07 Jul 2005 03:43:19 -0700 (PDT)
Received: by 10.54.63.20 with HTTP; Thu, 7 Jul 2005 03:43:19 -0700 (PDT)
Message-ID: <2729632a0507070343273a7d0@mail.gmail.com>
Date: Thu, 7 Jul 2005 03:43:19 -0700
From: <skillzero@gmail.com>
To: avt@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] RTCP for synchronization
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: skillzero@gmail.com
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I have a few questions RTCP sender/receiver reports for synchronization:

1. Section 6.1 of RFC 3550 indicates that an RR packet must be sent
instead of an SR packet if no data has been sent yet. The problem for
me is that I need to establish the NTP/RTP timing relationship before
I start playing audio. Otherwise, the receiver would either need to
start playing out-of-sync then later correct when it receives an SR
(glitch in the audio) or it would need to wait until it has received
an SR to start playing (initial samples dropped). I'm playing
prerecorded music so either option has noticeable effects.

Is there a specific reason an SR isn't legal for a soon-to-be sender?
Is there a better way to handle this, other than doing something like
sending silence packet(s) first such that an SR would be legal?

2. My receiving clients were previously also RTP senders so they were
sending and receiving RTCP SR's and RR's and this allowed me to
calculate  an accurate, absolute time (figure 2 in RFC 3550) when an
audio sample should be presented so all clients played in-sync. My
receiving clients no longer send RTP data and therefore no longer send
SR's or receive RR's to determine the round-trip time.

Is it possible with RTP/RTCP for non-senders to determine an accurate,
absolute presentation time (at least with respect to other receivers
of this RTP stream)? I can get close by using the NTP/RTP relationship
from the SR combined with the RTP timestamp offset estimate I
maintain, but since this RTP timestamp offset is only an estimate
(jitter, etc. affect it), it doesn't play sample-accurate between
clients; there is a slight reverb effect when the speakers are next to
each other.

The documents I've read so far all seem to use a separate protocol
(MBUS, NTP, etc.) to either publish the playout delay or synchronize
clocks. It seems like RTP has all the facilities to do this via SR/RR
packets, but it doesn't seem to be allowed by the spec for my
situation. Or I just misunderstand it, which is actually quite likely
:)

Thoughts?

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



From avt-bounces@ietf.org Thu Jul 07 14:47:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqbPY-0002rX-BG; Thu, 07 Jul 2005 14:47:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqbPW-0002pz-CD; Thu, 07 Jul 2005 14:47:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07574;
	Thu, 7 Jul 2005 14:47:44 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dqbqi-0005zA-43; Thu, 07 Jul 2005 15:15:55 -0400
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j67Ilbsw019684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 7 Jul 2005 14:47:37 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1])
	by cnr.cs.columbia.edu (8.13.3/8.13.3) with ESMTP id j67Ilb38087690;
	Thu, 7 Jul 2005 14:47:37 -0400 (EDT)
	(envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost)
	by cnr.cs.columbia.edu (8.13.3/8.13.3/Submit) id j67Ilbvg087687;
	Thu, 7 Jul 2005 14:47:37 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17101.30921.48827.630095@cnr.cs.columbia.edu>
Date: Thu, 7 Jul 2005 14:47:37 -0400
To: lazzaro <lazzaro@eecs.berkeley.edu>
In-Reply-To: <D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu>
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU>
	<D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org, avt@ietf.org
Subject: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over TLS submitted.
	Ready for WGLC? 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On Thursday, July 7 2005, "lazzaro" wrote to "mmusic@ietf.org" saying:

>  From this I-D:
> 
>     This document does not define any mechanism for securely transporting
>     RTP and RTCP packets over a connection-oriented channel.  There was
>     no consensus in the working group as to whether it would be better to
>     send Secure RTP packets [22] over a connection-oriented transport
>     [23], or whether it would be better to send standard unsecured RTP
>     packets over TLS using the mechanisms described in this document.
>     The group consensus was to wait until a use-case requiring secure
>     connection-oriented RTP was presented.
> 
> ---
> 
> I agree this accurately represents the discussion that went on in the
> working groups.
> 
> But, I thought it would be good to excerpt it and post it, to remind
> everyone that this is the decision that was made.  Given the lead time
> of the IETF process, it's a decision we'll all be living with for the next
> few years (at least).  If there's a group change of heart on the issue
> that is about to happen, having it happen now saves the community
> one cycle through the standards process.

I agree it's worth considering.

I also noticed that the recent AVT recharter contained the bullet point:

  - to provide a framing mechanism for RTP over TCP and TLS

Was inserting TLS just someone's "this seems like a good idea" as part of
describing draft-ietf-avt-rtp-framing-contrans for the charter, or did was
this decision actually made at some point?

My own implementation of TCP/TLS (developed alongside the draft) actually
implements TCP/TLS/RTP/AVP, so I'd certainly be inclined to lean that way.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

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



From avt-bounces@ietf.org Thu Jul 07 16:01:22 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqcYk-0007vS-8x; Thu, 07 Jul 2005 16:01:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqcYj-0007v4-0H; Thu, 07 Jul 2005 16:01:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15921;
	Thu, 7 Jul 2005 16:01:18 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dqczv-0006K4-EQ; Thu, 07 Jul 2005 16:29:30 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73])
	(authenticated bits=0)
	by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id
	j67K1FkX000161
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 7 Jul 2005 13:01:16 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2E2A5716-791F-4C40-9583-13F95C325B3F@eecs.berkeley.edu>
Content-Transfer-Encoding: 7bit
From: lazzaro <lazzaro@eecs.berkeley.edu>
Date: Thu, 7 Jul 2005 13:01:48 -0700
To: mmusic@ietf.org
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
Subject: [AVT] MMUSIC stage and studio requirements I-D ...
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi everyone,

         I just sent an new individual I-D submission
off to Internet-Drafts, that is targeted to MMUSIC:

----

Requirements for a Stage and Studio Multimedia Framework
  <draft-lazzaro-mmusic-stage-studio-requirements-00.txt>

                                 Abstract

Is the IETF multimedia stack appropriate for use in the digital
audio equipment found in recording studios and concert halls?
To help answer this question, this memo lists the requirements
for a session management framework for stage and studio
devices.

Download URL for an advance copy:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-sands.txt

----

Some background may be helpful.  RTP MIDI has many
potential applications.  Many are WAN-oriented, and SIP
and RTSP as is will work well for these.  The RTP MIDI
I-D includes interoperability advice for those apps.

The application described in the above abstract --
networking together professional audio equipment in
recording studios and concert stages -- is a "networking
in the small" problem (the network spans the rooms of
a recording studio or concert venue) and has unique
requirements.

MMUSIC may be the right place to design a framework
for session management for this application.

Or, maybe not -- maybe a new custom protocol done by
an audio-centric standards body is more appropriate,
free from our legacy-compatibility constraints.

Or, maybe there is room for both types of protocols,
as the potential devices span from the very simple
(powered by 8-bit micros) to very complex (expensive
multiprocessor implementations of mixing consoles).

I decided the best way to start the discussion on this
topic was to write a list of requirements for the domain
as seen by the authors.  Thus this I-D.  Even if the work of
doing the framework is not appropriate for MMUSIC,
MMUSIC may be the right place to host the discussion
of the requirements for the application.  If the WG agrees,
then elevating this I-D to WG item would be the way to
express this agreement.

I won't be in Paris, but if the chairs wish to hold a
discussion there, I'd be happy to make up slides to
guide their presentation.

Finally, AVT'ers should note this is an MMUSIC
I-D -- I CC'd this initial posting to both lists, but
discussion should occur on MMUSIC.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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



From avt-bounces@ietf.org Thu Jul 07 16:43:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqdDY-0005Zh-C8; Thu, 07 Jul 2005 16:43:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqdDV-0005Xj-0U
	for avt@megatron.ietf.org; Thu, 07 Jul 2005 16:43:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03651
	for <avt@ietf.org>; Thu, 7 Jul 2005 16:43:26 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqdej-0006nA-Ss
	for avt@ietf.org; Thu, 07 Jul 2005 17:11:39 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 07 Jul 2005 13:43:15 -0700
X-IronPort-AV: i="3.93,270,1115017200"; 
	d="scan'208,217"; a="196972567:sNHT61607516"
Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com
	[171.70.93.77])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j67KhB6r006819;
	Thu, 7 Jul 2005 13:43:13 -0700 (PDT)
Received: from klantz-w2k02.cisco.com ([128.107.171.159]) by
	vtg-um-e2k6.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 7 Jul 2005 13:43:11 -0700
Message-Id: <6.2.1.2.2.20050707134148.0304a328@vtg-um-e2k6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 07 Jul 2005 13:43:08 -0700
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
From: Keith Lantz <klantz@cisco.com>
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
In-Reply-To: <42CCDC55.7010604@ericsson.com>
References: <42CCDC55.7010604@ericsson.com>
Mime-Version: 1.0
X-OriginalArrivalTime: 07 Jul 2005 20:43:11.0345 (UTC)
	FILETIME=[7D49BE10:01C58334]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0239909235=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--===============0239909235==
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Indeed...<br><br>
I don't suppose anyone can provide a copy of SMPTE 421M? It doesn't
appear to be available (yet) from smpte.org.<br><br>
Thx, Keith<br><br>
At 12:40 AM 7/7/2005, Magnus Westerlund wrote:<br>
<blockquote type=cite class=cite cite="">This is relevant for
AVT.<br><br>
Cheers<br><br>
Magnus Westerlund<br><br>
Multimedia Technologies, Ericsson Research EAB/TVA/A<br>
----------------------------------------------------------------------<br>
Ericsson
AB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| Phone +46 8 4048287<br>
Torshamsgatan
23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
Fax&nbsp;&nbsp; +46 8 7575550<br>
S-164 80 Stockholm, Sweden | mailto:
magnus.westerlund@ericsson.com<br><br>
<br>
X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0<br>
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
esealmw103.eemea.ericsson.se with Microsoft<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:53:59 +0200<br>
MIME-Version: 1.0<br>
Content-Type: multipart/mixed;
boundary=&quot;----_=_NextPart_001_01C58264.7323E580&quot;<br>
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
esealmw105.eemea.ericsson.se with Microsoft<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:49:29 +0200<br>
Received: from esealmw128.eemea.ericsson.se ([130.100.184.163]) by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
esealmw126.eemea.ericsson.se with Microsoft<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:53:58 +0200<br>
Received: from mailgw1.ericsson.se ([193.180.251.59]) by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
esealmw128.eemea.ericsson.se with Microsoft<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 21:53:57 +0200<br>
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
3C247450009; Wed,&nbsp; 6 Jul 2005 21:53:56 +0200 (CEST)<br>
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
megatron.ietf.org with esmtp (Exim 4.32) id 1DqFup-0008Ld-Jk;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Wed, 06
Jul 2005 15:50:39 -0400<br>
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
megatron.ietf.org with esmtp (Exim 4.32) id 1DqFuH-0007zA-6x<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>for
i-d-announce@megatron.ietf.org; Wed, 06 Jul 2005 15:50:05 -0400<br>
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
(8.9.1a/8.9.1a) with ESMTP id PAA10070 for<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
&lt;i-d-announce@ietf.org&gt;; Wed, 6 Jul 2005 15:50:03 -0400 (EDT)<br>
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org
with<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>esmtp
(Exim 4.43) id 1DqGLH-000862-MJ for i-d-announce@ietf.org;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Wed, 06
Jul 2005 16:18:00 -0400<br>
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
1DqFuE-000884-48 for i-d-announce@ietf.org;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Wed, 06
Jul 2005 15:50:02 -0400<br>
Return-Path: &lt;i-d-announce-bounces@ietf.org&gt;<br>
X-OriginalArrivalTime: 06 Jul 2005 19:53:57.0726 (UTC)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
FILETIME=[72617FE0:01C58264]<br>
Errors-To: i-d-announce-bounces@ietf.org<br>
X-Spam-Score: 0.4 (/)<br>
List-Post:
&lt;<a href="mailto:i-d-announce@ietf.org" eudora="autourl">
mailto:i-d-announce@ietf.org</a>&gt;<br>
List-Id: i-d-announce.ietf.org<br>
X-BeenThere: i-d-announce@ietf.org<br>
X-Mailman-Version: 2.1.5<br>
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be<br>
X-Brightmail-Tracker: AAAAAA==<br>
Content-class: urn:content-classes:message<br>
Subject: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt <br>
Date: Wed, 6 Jul 2005 21:50:02 +0200<br>
Message-ID: &lt;E1DqFuE-000884-48@newodin.ietf.org&gt;<br>
X-MS-Has-Attach: yes<br>
X-MS-TNEF-Correlator: <br>
Thread-Topic: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt <br>
Thread-Index: AcWCZHM8cveeT6CIQaqBia9mxT7Rog==<br>
List-Help:
&lt;<a href="mailto:i-d-announce-request@ietf.org%3Fsubject=help" eudora="autourl">
mailto:i-d-announce-request@ietf.org?subject=help</a>&gt;<br>
List-Subscribe:
&lt;<a href="https://www1.ietf.org/mailman/listinfo/i-d-announce" eudora="autourl">
https://www1.ietf.org/mailman/listinfo/i-d-announce</a>&gt;,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
&lt;<a href="mailto:i-d-announce-request@ietf.org%3Fsubject=subscribe" eudora="autourl">
mailto:i-d-announce-request@ietf.org?subject=subscribe</a>&gt;<br>
List-Unsubscribe:
&lt;<a href="https://www1.ietf.org/mailman/listinfo/i-d-announce" eudora="autourl">
https://www1.ietf.org/mailman/listinfo/i-d-announce</a>&gt;,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>
&lt;<a href="mailto:i-d-announce-request@ietf.org%3Fsubject=unsubscribe" eudora="autourl">
mailto:i-d-announce-request@ietf.org?subject=unsubscribe</a>&gt;<br>
From: &lt;Internet-Drafts@ietf.org&gt;<br>
Sender: &lt;i-d-announce-bounces@ietf.org&gt;<br>
To: &lt;i-d-announce@ietf.org&gt;<br>
Reply-To: &lt;internet-drafts@ietf.org&gt;<br><br>
<font size=2>A New Internet-Draft is available from the on-line
Internet-Drafts directories.<br><br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : RTP
Payload Format for Video Codec 1 (VC-1)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : A. Klemets<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
draft-klemets-avt-rtp-vc1-00.txt<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
21<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :
2005-7-6<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&nbsp;&nbsp; This memo specifies an RTP payload format for encapsulating
Video<br>
&nbsp;&nbsp; Codec 1 (VC-1) compressed bit streams, as defined by the
proposed<br>
&nbsp;&nbsp; Society of Motion Picture and Television Engineers (SMPTE)
standard,<br>
&nbsp;&nbsp; SMPTE 421M.&nbsp; SMPTE is the main standardizing body in
the motion<br>
&nbsp;&nbsp; imaging industry and the proposed SMPTE 421M standard
defines a<br>
&nbsp;&nbsp; compressed video bit stream format and decoding process
for<br>
&nbsp;&nbsp; television.<br><br>
A URL for this Internet-Draft is:<br>
<a href="http://www.ietf.org/internet-drafts/draft-klemets-avt-rtp-vc1-00.txt">
http://www.ietf.org/internet-drafts/draft-klemets-avt-rtp-vc1-00.txt</a>
<br><br>
To remove yourself from the I-D Announcement list, send a message to<br>
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message. <br>
You can also visit
<a href="https://www1.ietf.org/mailman/listinfo/I-D-announce">
https://www1.ietf.org/mailman/listinfo/I-D-announce</a><br>
to change your subscription settings.<br><br>
<br>
Internet-Drafts are also available by anonymous FTP. Login with the
username<br>
&quot;anonymous&quot; and a password of your e-mail address. After
logging in,<br>
type &quot;cd internet-drafts&quot; and then<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get
draft-klemets-avt-rtp-vc1-00.txt&quot;.<br><br>
A list of Internet-Drafts directories can be found in<br>
<a href="http://www.ietf.org/shadow.html">
http://www.ietf.org/shadow.html</a><br>
or
<a href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">
ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a><br><br>
<br>
Internet-Drafts can also be obtained by e-mail.<br><br>
Send a message to:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailserv@ietf.org.<br>
In the body type:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE
/internet-drafts/draft-klemets-avt-rtp-vc1-00.txt&quot;.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document
in<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using the
&quot;mpack&quot; utility.&nbsp; To use this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command
&quot;ENCODING mime&quot; before the &quot;FILE&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the
response(s), you will need &quot;munpack&quot; or<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail
reader.&nbsp; Different MIME-compliant mail readers<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior,
especially when dealing with<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME
messages (i.e. documents which have been split<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), so
check your local documentation on<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these
messages.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
Below is the data which will enable a MIME compliant mail reader<br>
implementation to automatically retrieve the ASCII version of the<br>
Internet-Draft.<br>
</font><br><br>
<br>
_______________________________________________<br>
Audio/Video Transport Working Group<br>
avt@ietf.org<br>
<a href="https://www1.ietf.org/mailman/listinfo/avt" eudora="autourl">
https://www1.ietf.org/mailman/listinfo/avt</a></blockquote></body>
</html>


--===============0239909235==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0239909235==--



From avt-bounces@ietf.org Thu Jul 07 23:50:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqjsL-000887-QV; Thu, 07 Jul 2005 23:50:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqjsJ-00083P-6V; Thu, 07 Jul 2005 23:50:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01151;
	Thu, 7 Jul 2005 23:50:00 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DqkJb-0004Yd-OU; Fri, 08 Jul 2005 00:18:17 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73])
	(authenticated bits=0)
	by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id
	j683nwnf004674
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Thu, 7 Jul 2005 20:49:59 -0700 (PDT)
In-Reply-To: <011101c58367$438113d0$1101a8c0@shigpfhx45cdn7>
References: <2E2A5716-791F-4C40-9583-13F95C325B3F@eecs.berkeley.edu>
	<011101c58367$438113d0$1101a8c0@shigpfhx45cdn7>
Mime-Version: 1.0 (Apple Message framework v730)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D8806FEA-46D7-454D-AD43-F769EED4FD3F@eecs.berkeley.edu>
Content-Transfer-Encoding: 7bit
From: lazzaro <lazzaro@eecs.berkeley.edu>
Date: Thu, 7 Jul 2005 20:50:31 -0700
To: mmusic@ietf.org, avt@ietf.org
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: Shigeru Aoki <shig@center.jfn.co.jp>
Subject: [AVT] Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


On Jul 7, 2005, at 7:46 PM, Shigeru Aoki wrote:
> Have you checked the AES (Audio Engineering Society) standard  
> before your submission?
> The AES is the international organization of standardizing the  
> studio or stage (generally referred to as "professional") audio. As  
> far as I read your draft, you'd better take a look at the Internet  
> Audio Delivery System WG in the AES.

Yes I did check.  Here is the meeting report for the
Internet Audio Delivery System WG at the
San Francisco AES meeting last fall:

http://www.aes.org/standards/b_reports/b_meeting-reports/aes117- 
sc-02-14-report.cfm

The meeting report doesn't seem to describe a
group whose ongoing work is a close match for
a project to do a session management framework
for IETF protocols.  Also, the report says the
WG has no new projects and no new business
apart from AES-X074, and is slated to be
folded into another group soon.  Their charter
is written in an open-ended way, indeed it
it would cover most of AVT's audio work.  But
in practice the group doesn't seem to be doing
that sort of Internet standards work.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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



From avt-bounces@ietf.org Fri Jul 08 03:12:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqn22-0004fI-Nd; Fri, 08 Jul 2005 03:12:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqn21-0004fA-7B; Fri, 08 Jul 2005 03:12:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04660;
	Fri, 8 Jul 2005 03:12:16 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DqnTM-0006m3-4V; Fri, 08 Jul 2005 03:40:32 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 18006117C;
	Fri,  8 Jul 2005 09:12:10 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 8 Jul 2005 09:12:09 +0200
Received: from [147.214.34.71] ([147.214.34.71]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 8 Jul 2005 09:12:09 +0200
Message-ID: <42CE2749.70907@ericsson.com>
Date: Fri, 08 Jul 2005 09:12:09 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
Subject: Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over TLS
	submitted.Ready for WGLC?
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU><D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu>
	<17101.30921.48827.630095@cnr.cs.columbia.edu>
In-Reply-To: <17101.30921.48827.630095@cnr.cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Jul 2005 07:12:09.0528 (UTC)
	FILETIME=[5AFF7B80:01C5838C]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: lazzaro <lazzaro@eecs.berkeley.edu>, mmusic@ietf.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Jonathan,

Can you please remind where and when the decision was taken to not 
define TCP/TLS/RTP/AVP? All I find is some loose discussion without 
conclusion about the topic, but nothing I can interpret as an WG 
consensus on this.

I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF. I 
would also consider if TCP/TLS/RTP/SAVP is a good idea or not. I would 
consider TCP/TLS/RTP/SAVP a possibility in cases that requires a secure 
TCP/TLS connection, for example due to end point authentication, which 
however is a gateway to an SRTP session. If that is relevant or not is 
another matter.

I also agree with Lazzaro that with the current IETF lead time the only 
reasonable way of providing for future use cases the market wants to 
select it to have it ready. I don't want to be the part blocking actual 
deployment of security. Thus I think we should consider both 
TCP/RTP/SAVP and TCP/TLS/RTP/AVP.

As I see it TCP/RTP/SAVP and TCP/TLS/RTP/AVP have somewhat different 
security properties. TLS provides a secured transport channel with 
possibility to end-point authentication. The SRTP based solution 
provides instead group security and can be done without a trusted 
gateway. So they definitely are applicable in different use cases.

Jonathan Lennox wrote:
> I also noticed that the recent AVT recharter contained the bullet point:
> 
>   - to provide a framing mechanism for RTP over TCP and TLS
> 
> Was inserting TLS just someone's "this seems like a good idea" as part of
> describing draft-ietf-avt-rtp-framing-contrans for the charter, or did was
> this decision actually made at some point?

Again doing some searching in the archives I find that this formulation 
was part of the proposed charter update I sent out 2003-09-02. It is 
probably something we who wrote it felt was an good idea and reflected 
our understanding of what was going to happen.

I would interpret such that we are allowed and expected to do what the 
charter says. However if we do have motivation why we wouldn't, we 
probably can get away without doing the work.

My conclusion is that we need to discuss this topic again.

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 avt-bounces@ietf.org Fri Jul 08 05:58:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqpd1-0002Fw-9r; Fri, 08 Jul 2005 05:58:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqhFv-0001hv-SG
	for avt@megatron.ietf.org; Thu, 07 Jul 2005 21:02:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21632
	for <avt@ietf.org>; Thu, 7 Jul 2005 21:02:13 -0400 (EDT)
Received: from mail3.microsoft.com ([131.107.3.123])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqhhD-0006Jf-P6
	for avt@ietf.org; Thu, 07 Jul 2005 21:30:28 -0400
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 7 Jul 2005 18:02:05 -0700
Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by
	mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 7 Jul 2005 18:02:05 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com
	([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 18:02:03 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
	([157.54.12.88]) by
	win-imc-01.wingroup.windeploy.ntdev.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 18:02:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Thu, 7 Jul 2005 18:01:59 -0700
Message-ID: <9ED672B9D1A64C489291BE0FB822217D0B24CBA1@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
thread-index: AcWDNNZjYNuJPiqdSTiVGvq8vQiWwgAILkXw
From: "Anders Klemets" <anderskl@windows.microsoft.com>
To: "Keith Lantz" <klantz@cisco.com>
X-OriginalArrivalTime: 08 Jul 2005 01:02:04.0117 (UTC)
	FILETIME=[A78AA850:01C58358]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
X-Mailman-Approved-At: Fri, 08 Jul 2005 05:58:38 -0400
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0276875135=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0276875135==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C58358.A62FA374"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58358.A62FA374
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SMPTE 421M is in Final Committee Draft status and is not yet publicly
available.  However, SMPTE members should be able to obtain a copy from
the members-only area on the SMPTE web site.  The spec is being
developed by Technology Committee C24 on Video Compression Technology.

=20

________________________________

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
Keith Lantz
Sent: Thursday, July 07, 2005 1:43 PM
To: Magnus Westerlund
Cc: IETF AVT WG
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]

=20

Indeed...

I don't suppose anyone can provide a copy of SMPTE 421M? It doesn't
appear to be available (yet) from smpte.org.

Thx, Keith




------_=_NextPart_001_01C58358.A62FA374
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>SMPTE 421M is in Final Committee =
Draft
status and is not yet publicly available. &nbsp;However, SMPTE members =
should
be able to obtain a copy from the members-only area on the SMPTE web =
site. &nbsp;The
spec is being developed by Technology Committee C24 on Video Compression
Technology.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] <b><span =
style=3D'font-weight:
bold'>On Behalf Of </span></b>Keith Lantz<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, July 07, =
2005 1:43
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Magnus Westerlund<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> IETF AVT WG<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [AVT] [Fwd: =
I-D
ACTION:draft-klemets-avt-rtp-vc1-00.txt]</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Indeed...<br>
<br>
I don't suppose anyone can provide a copy of SMPTE 421M? It doesn't =
appear to
be available (yet) from smpte.org.<br>
<br>
Thx, Keith<br>
<br>
<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C58358.A62FA374--


--===============0276875135==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0276875135==--




From avt-bounces@ietf.org Fri Jul 08 05:58:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqpd1-0002HS-S0; Fri, 08 Jul 2005 05:58:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqitU-0002E1-HP
	for avt@megatron.ietf.org; Thu, 07 Jul 2005 22:47:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28045
	for <avt@ietf.org>; Thu, 7 Jul 2005 22:47:09 -0400 (EDT)
Received: from ps46.suite2.arena.ne.jp ([210.153.23.2])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqjKi-0007i0-5r
	for avt@ietf.org; Thu, 07 Jul 2005 23:15:25 -0400
Received: (qmail 19189 invoked by SAV 20050707.053); 8 Jul 2005 11:46:33 +0900
Received: from unknown (HELO shigpfhx45cdn7) (210.150.180.211)
	by ps46.suite2.arena.ne.jp (210.153.23.166) with SMTP;
	8 Jul 2005 11:46:33 +0900
Message-ID: <011101c58367$438113d0$1101a8c0@shigpfhx45cdn7>
From: "Shigeru Aoki" <shig@center.jfn.co.jp>
To: "lazzaro" <lazzaro@eecs.berkeley.edu>, <mmusic@ietf.org>
References: <2E2A5716-791F-4C40-9583-13F95C325B3F@eecs.berkeley.edu>
Date: Fri, 8 Jul 2005 11:46:31 +0900
Organization: Japan FM Network
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="ISO-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 08 Jul 2005 05:58:38 -0400
Cc: avt@ietf.org
Subject: [AVT] Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hello Lazzaro,

Have you checked the AES (Audio Engineering Society) standard before your 
submission?
The AES is the international organization of standardizing the studio or stage 
(generally referred to as "professional") audio. As far as I read your draft, 
you'd better take a look at the Internet Audio Delivery System WG in the AES.

All the best,

Shigeru Aoki
Senior Technologist,
The Japan FM Network


----- Original Message ----- 
From: "lazzaro" <lazzaro@eecs.berkeley.edu>
To: <mmusic@ietf.org>
Cc: <avt@ietf.org>
Sent: Friday, July 08, 2005 5:01 AM
Subject: [MMUSIC] MMUSIC stage and studio requirements I-D ...


> Hi everyone,
>
>         I just sent an new individual I-D submission
> off to Internet-Drafts, that is targeted to MMUSIC:
>
> ----
>
> Requirements for a Stage and Studio Multimedia Framework
>  <draft-lazzaro-mmusic-stage-studio-requirements-00.txt>
>
>                                 Abstract
>
> Is the IETF multimedia stack appropriate for use in the digital
> audio equipment found in recording studios and concert halls?
> To help answer this question, this memo lists the requirements
> for a session management framework for stage and studio
> devices.
>
> Download URL for an advance copy:
>
> http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-sands.txt
>
> ----
>
> Some background may be helpful.  RTP MIDI has many
> potential applications.  Many are WAN-oriented, and SIP
> and RTSP as is will work well for these.  The RTP MIDI
> I-D includes interoperability advice for those apps.
>
> The application described in the above abstract --
> networking together professional audio equipment in
> recording studios and concert stages -- is a "networking
> in the small" problem (the network spans the rooms of
> a recording studio or concert venue) and has unique
> requirements.
>
> MMUSIC may be the right place to design a framework
> for session management for this application.
>
> Or, maybe not -- maybe a new custom protocol done by
> an audio-centric standards body is more appropriate,
> free from our legacy-compatibility constraints.
>
> Or, maybe there is room for both types of protocols,
> as the potential devices span from the very simple
> (powered by 8-bit micros) to very complex (expensive
> multiprocessor implementations of mixing consoles).
>
> I decided the best way to start the discussion on this
> topic was to write a list of requirements for the domain
> as seen by the authors.  Thus this I-D.  Even if the work of
> doing the framework is not appropriate for MMUSIC,
> MMUSIC may be the right place to host the discussion
> of the requirements for the application.  If the WG agrees,
> then elevating this I-D to WG item would be the way to
> express this agreement.
>
> I won't be in Paris, but if the chairs wish to hold a
> discussion there, I'd be happy to make up slides to
> guide their presentation.
>
> Finally, AVT'ers should note this is an MMUSIC
> I-D -- I CC'd this initial posting to both lists, but
> discussion should occur on MMUSIC.
>
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>
> 


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



From avt-bounces@ietf.org Fri Jul 08 08:26:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqrve-0005Sq-Ug; Fri, 08 Jul 2005 08:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqqOm-0003Oe-QF
	for avt@megatron.ietf.org; Fri, 08 Jul 2005 06:48:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19323
	for <avt@ietf.org>; Fri, 8 Jul 2005 06:47:58 -0400 (EDT)
Received: from ps46.suite2.arena.ne.jp ([210.153.23.2])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dqqq8-0002u0-Gd
	for avt@ietf.org; Fri, 08 Jul 2005 07:16:18 -0400
Received: (qmail 10434 invoked by SAV 20050708.005); 8 Jul 2005 19:47:55 +0900
Received: from unknown (HELO shigpfhx45cdn7) (210.150.180.211)
	by ps46.suite2.arena.ne.jp (210.153.23.166) with SMTP;
	8 Jul 2005 19:47:55 +0900
Message-ID: <003201c583aa$82fa7c20$1101a8c0@shigpfhx45cdn7>
From: "Shigeru Aoki" <shig@center.jfn.co.jp>
To: <mmusic@ietf.org>, <avt@ietf.org>
References: <2E2A5716-791F-4C40-9583-13F95C325B3F@eecs.berkeley.edu>
	<011101c58367$438113d0$1101a8c0@shigpfhx45cdn7>
	<D8806FEA-46D7-454D-AD43-F769EED4FD3F@eecs.berkeley.edu>
Date: Fri, 8 Jul 2005 19:48:01 +0900
Organization: Japan FM Network
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 08 Jul 2005 08:26:01 -0400
Cc: 
Subject: [AVT] Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

First of all, You should not include your matter into the AES-X074 since it has 
different intention from yours. Your requirements draft should be proposed to the 
WG for the discussion in the WG. if you would like to work for professional audio, 
you'd better propose to the AES too.

By the way, The WG has been moved to SC-02-14 from SC-06-04 already. The new 
report of the meeting which was held in this May will be posted soon.

Shig.

----- Original Message ----- 
From: "lazzaro" <lazzaro@eecs.berkeley.edu>
To: <mmusic@ietf.org>; <avt@ietf.org>
Cc: "Shigeru Aoki" <shig@center.jfn.co.jp>
Sent: Friday, July 08, 2005 12:50 PM
Subject: Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...


>
> On Jul 7, 2005, at 7:46 PM, Shigeru Aoki wrote:
>> Have you checked the AES (Audio Engineering Society) standard  before your
>> submission?
>> The AES is the international organization of standardizing the  studio or stage
>> (generally referred to as "professional") audio. As  far as I read your draft,
>> you'd better take a look at the Internet  Audio Delivery System WG in the AES.
>
> Yes I did check.  Here is the meeting report for the
> Internet Audio Delivery System WG at the
> San Francisco AES meeting last fall:
>
> http://www.aes.org/standards/b_reports/b_meeting-reports/aes117-
> sc-02-14-report.cfm
>
> The meeting report doesn't seem to describe a
> group whose ongoing work is a close match for
> a project to do a session management framework
> for IETF protocols.  Also, the report says the
> WG has no new projects and no new business
> apart from AES-X074, and is slated to be
> folded into another group soon.  Their charter
> is written in an open-ended way, indeed it
> it would cover most of AVT's audio work.  But
> in practice the group doesn't seem to be doing
> that sort of Internet standards work.
>
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>
>
>
>
>


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



From avt-bounces@ietf.org Fri Jul 08 08:26:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqrvf-0005TH-Nu; Fri, 08 Jul 2005 08:26:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqqTq-0004ta-3d
	for avt@megatron.ietf.org; Fri, 08 Jul 2005 06:53:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19654
	for <avt@ietf.org>; Fri, 8 Jul 2005 06:53:11 -0400 (EDT)
Received: from ns4.sony.co.jp ([137.153.0.44])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqqvB-0003Oo-GA
	for avt@ietf.org; Fri, 08 Jul 2005 07:21:31 -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 j68Ar9rc011668
	for <avt@ietf.org>; Fri, 8 Jul 2005 19:53:09 +0900 (JST)
Received: from jptkyxim02.jp.sony.com (jptkyxim02.jp.sony.com [43.15.17.88])
	by mail6.sony.co.jp (R8/Sony) with ESMTP id j68Ar82u011660
	for <avt@ietf.org>; Fri, 8 Jul 2005 19:53:08 +0900 (JST)
Received: from jptkyxwa03.jp.sony.com ([43.15.31.3]) by jptkyxim02.jp.sony.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 8 Jul 2005 19:53:08 +0900
Received: from [43.13.117.153] ([43.13.117.153]) by jptkyxwa03.jp.sony.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 8 Jul 2005 19:53:08 +0900
Mime-Version: 1.0 (Apple Message framework v721)
Content-Transfer-Encoding: 7bit
Message-Id: <3B54E6BB-BF62-43CB-A90F-E98C2BA38553@jp.sony.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: avt@ietf.org
From: Matthew Romaine <Matthew.Romaine@jp.sony.com>
Subject: [AVT] draft-ietf-avt-rtp-atrac-family-04
Date: Fri, 8 Jul 2005 19:51:35 +0900
X-Mailer: Apple Mail (2.721)
X-OriginalArrivalTime: 08 Jul 2005 10:53:08.0130 (UTC)
	FILETIME=[39BD9820:01C583AB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a15e98e3cfbc19675e9168ae498aa0df
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 08 Jul 2005 08:26:01 -0400
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


fellow avt'ers,

I have submitted draft -04 of our ATRAC family payload for your  
consideration, and enclosed it below incase the editors don't get  
around to submitting the link before the weekend.

The main changes are:

- removal of any auxiliary data features
- additional support for a new ATRAC codec -- ATRAC Advanced Lossless  
-- which supports multiplexed and multi-session streaming
- updated SDP sections to reflect support for the above mentioned new  
codec.

Would greatly appreciate comments so that presentation time at IETF  
63 can be used most effectively.  Incidentally, if things go well,  
you all may get to walk home with a free SDK for this codec :)

Have a great weekend,
Matt





Audio/Video Transport                                         M. Romaine
Internet-Draft                                               M. Hatanaka
Expires: December 3, 2005                                   J. Matsumoto
                                                                      
SONY
                                                                June  
2005


                   RTP Payload Format for ATRAC Family
                    draft-ietf-avt-rtp-atrac-family-04

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six  
months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on December 3, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2005).

Abstract

    This document describes an RTP payload format for efficient and
    flexible transporting of audio data encoded with the Adaptive
    TRansform Audio Codec (ATRAC) family of codecs.  Recent enhancements
    to the ATRAC family of codecs support high quality audio coding with
    multiple channels.  The RTP payload format as presented in this
    document also includes support for data fragmentation, elementary
    redundancy measures, and a variation on scalable streaming.



Romaine, et al.         Expires December 3, 2005                [Page 1]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
    2.   
Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Codec Specific  
Details . . . . . . . . . . . . . . . . . . . .  4
    4.  RTP Packetization and Transport of ATRAC-Family  
Streams  . . .  5
      4.1   ATRAC  
Frames . . . . . . . . . . . . . . . . . . . . . . .  5
      4.2   Concatenation of  
Frames  . . . . . . . . . . . . . . . . .  5
      4.3   Frame  
Fragmentation  . . . . . . . . . . . . . . . . . . .  5
      4.4   Transmission of Redundant  
Frames . . . . . . . . . . . . .  5
      4.5   Global Structure of Payload  
Format . . . . . . . . . . . .  6
      4.6   Scalable Lossless Streaming (High-Speed Transfer  
mode) . .  6
        4.6.1   Scalable Multiplexed  
Streaming . . . . . . . . . . . .  6
        4.6.2   Scalable Multi-Session  
Streaming . . . . . . . . . . .  7
    5.  Payload  
Format . . . . . . . . . . . . . . . . . . . . . . . .  7
      5.1   Usage of RTP Header  
Fields . . . . . . . . . . . . . . . .  7
      5.2   RTP Payload  
Structure  . . . . . . . . . . . . . . . . . .  8
        5.2.1   ATRAC Header  
Section . . . . . . . . . . . . . . . . .  8
        5.2.2   Redundant Data  
Section . . . . . . . . . . . . . . . .  8
        5.2.3   ATRAC Frames  
Section . . . . . . . . . . . . . . . . .  9
    6.  Packetization  
Examples . . . . . . . . . . . . . . . . . . . . 10
      6.1   Example Multi-frame  
Packet . . . . . . . . . . . . . . . . 10
      6.2   Example Fragmented ATRAC  
Frame . . . . . . . . . . . . . . 11
    7.  Payload Format  
Parameters  . . . . . . . . . . . . . . . . . . 12
      7.1   ATRAC3 MIME  
Registration . . . . . . . . . . . . . . . . . 13
      7.2   ATRAC-X MIME  
Registraion . . . . . . . . . . . . . . . . . 14
      7.3   ATRAC Advanced Lossless MIME  
Registration  . . . . . . . . 15
      7.4   Channel Mapping Configuration  
Table  . . . . . . . . . . . 17
      7.5   Mapping MIME Parameters into  
SDP . . . . . . . . . . . . . 18
        7.5.1   For MIME subtype  
ATRAC3  . . . . . . . . . . . . . . . 18
        7.5.2   For MIME subtype ATRAC- 
X . . . . . . . . . . . . . . . 19
        7.5.3   For MIME subtype ATRAC Advanced  
Lossless . . . . . . . 19
      7.6   Offer-Answer Model  
Considerations  . . . . . . . . . . . . 20
        7.6.1   For All Three MIME  
Subtypes  . . . . . . . . . . . . . 20
        7.6.2   For MIME subtype  
ATRAC3  . . . . . . . . . . . . . . . 20
        7.6.3   For MIME subtype ATRAC- 
X . . . . . . . . . . . . . . . 20
        7.6.4   For MIME subtype ATRAC Advanced  
Lossless . . . . . . . 21
      7.7   Usage of declarative  
SDP . . . . . . . . . . . . . . . . . 21
      7.8   Example SDP Session  
Descriptions . . . . . . . . . . . . . 22
      7.9   Example Offer-Answer  
Exchange  . . . . . . . . . . . . . . 23
    8.  IANA  
Considerations  . . . . . . . . . . . . . . . . . . . . . 24
    9.  Security  
Considerations  . . . . . . . . . . . . . . . . . . . 24
      9.1    
Confidentiality  . . . . . . . . . . . . . . . . . . . . . 25
      9.2    
Authentication . . . . . . . . . . . . . . . . . . . . . . 25
      9.3   Decoding  
Validation  . . . . . . . . . . . . . . . . . . . 25
    10.    
References . . . . . . . . . . . . . . . . . . . . . . . . . 25
      10.1  Normative  
References . . . . . . . . . . . . . . . . . . . 25
      10.2  Informative  
References . . . . . . . . . . . . . . . . . . 26



Romaine, et al.         Expires December 3, 2005                [Page 2]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


        Authors'  
Addresses . . . . . . . . . . . . . . . . . . . . . . 26
        Intellectual Property and Copyright  
Statements . . . . . . . . 28

















































Romaine, et al.         Expires December 3, 2005                [Page 3]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


1.  Introduction

    The ATRAC family of perceptual audio codecs are designed to address
    numerous needs for high-quality, low bit-rate audio transfer.  ATRAC
    technology can be found in many consumer and professional products
    and applications, including MD players, CD players, voice recorders,
    and mobile phones.  The need for real-time streaming of audio data
    has grown, and this document details our efforts in increasing the
    product and application space for the ATRAC family of codecs.

    Recent advances in ATRAC technology allow for multiple channels of
    audio to be encoded in customizable groupings.  This should allow  
for
    future expansions in scaled streaming.  To provide the greatest
    flexibility in streaming any one of the ATRAC family member codecs
    however, this payload format does not distinguish between the codecs
    on a packet level.

    This simplified payload format contains only the basic information
    needed to disassemble a packet of ATRAC audio in order to decode it.
    Timestamps are in sample units, with audio data currently encoded
    into frames of 512, 1024 or 2048 samples depending on the ATRAC
    version.  There is also basic support for fragmentation and
    redundancy, as ATRAC frames MAY exceed an MTU size of 1500 octets.

    Although streaming of multi-channel audio is supported depending on
    the ATRAC version used, all encoded audio for a given time period is
    contained within a single frame.  Therefore, there is no  
interleaving
    nor splitting of audio data on a per-channel basis to be concerned
    with.

2.  Conventions

    The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [4].

3.  Codec Specific Details

    Early versions of the ATRAC codec handled only two channels of audio
    at 44.1kHz sampling frequency, with typical bit-rates between 66kbps
    and 132kbps.  The latest version allows for a maximum 8 channels of
    audio, up to 96kHz in sampling frequency, and a lossless encoding
    option which can be transmitted in either a scalable (also known as
    High-Speed Transfer mode) or standard (aka Standard mode) format.
    The feasible bit-rate range has also expanded, allowing from a  
low of
    8kbps up to 1400kbps in lossy encoding modes.

    Depending on the version of ATRAC used, the sample-frame size is



Romaine, et al.         Expires December 3, 2005                [Page 4]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    either 512, 1024 or 2048 samples.  While the lossy and Standard mode
    lossless formats are encoded as sequential single audio frames,  
High-
    Speed Transfer mode lossless data comprises two layers -- a lossy
    base layer and an enhancement layer.

4.  RTP Packetization and Transport of ATRAC-Family Streams

4.1  ATRAC Frames

    For transportation of compressed audio data, ATRAC uses the concept
    of frames.  ATRAC frames are the smallest data unit for which timing
    information is attributed.  Frames are octect-aligned by definition.

4.2  Concatenation of Frames

    It is often possible to carry multiple frames in one RTP packet.
    This can be useful in audio, where on a LAN with a 1500 byte MTU, an
    average of 7 complete 64kbps ATRAC frames could be carried in a
    single RTP packet, as each ATRAC frame would be approximately 200
    bytes.  ATRAC frames may be of fixed or variable length.  To
    facilitate parsing in the case of multiple frames in one RTP packet,
    the size of each frame is made known to the receiver by carrying "in
    band" the frame size for each contained frame in an RTP packet.
    However, to simplify the implementation of RTP receivers, it is
    required that when multiple frames are carried in an RTP packet,  
each
    frame MUST be complete, i.e., the number of frames in an RTP packet
    MUST be integral.

4.3  Frame Fragmentation

    The ATRAC codec can handle very large frames.  As most IP networks
    have significantly smaller MTU sizes than the frame sizes ATRAC can
    handle, this payload format allows for the fragmentation of an ATRAC
    frame over multiple RTP packets.  However, to simplify the
    implementation of RTP receivers, an RTP packet SHALL either carry  
one
    or more complete ATRAC frames or a single fragment of one ATRAC
    frame.  In other words, RTP packets MUST NOT contain fragments of
    multiple ATRAC frames and MUST NOT contain a mix of complete and
    fragmented frames.

4.4  Transmission of Redundant Frames

    As RTP does not guarantee reliable transmission, receipt of data is
    not assured.  Loss of a packet can result in a "decoding gap" by the
    receiver.  One method to remedy this problem is to allow time- 
shifted
    copies of ATRAC frames to be sent along with current data.  For a
    modest cost in latency and implementation complexity, error
    resiliency to packet loss can be achieved.



Romaine, et al.         Expires December 3, 2005                [Page 5]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


4.5  Global Structure of Payload Format

    The RTP payload following the RTP header contains three octet- 
aligned
    data sections, of which the second MAY be empty:

    +------+--------------+--------------+--------------+
    |RTP   | ATRAC Header | Redundant    | ATRAC Frames |
    |Header| Section      | Data Section | Section      |
    +------+--------------+--------------+--------------+
            < ----------- RTP Packet Payload --------- >

    The first data section is the ATRAC Header, containing just one
    header with information for the whole packet.  The second section is
    for redundant ATRAC frames; this section MAY be empty.  The third
    section is where the encoded ATRAC frames are stored.  This may
    contain either a single fragment of one ATRAC frame, or one or more
    complete ATRAC frames.  The ATRAC Frames Section MUST NOT be empty.

    To benefit from ATRAC's High-Speed Transfer mode lossless encoding
    capability, the RTP payload can be split across two sessions, with
    one transmitting an essential base layer and the other transmitting
    enhancement data.  However in either case, the above structure still
    applies.

4.6  Scalable Lossless Streaming (High-Speed Transfer mode)

    As ATRAC supports a variation on scalable encoding, this payload
    format provides a mechanism for transmitting essential data (also
    referred to as the base layer) with its enhancement data in two ways
    -- multiplexed through one session or separated over two sessions.
    In either method, only the base layer is essential in producing  
audio
    data.  The enhancement layer carries the remaining audio data needed
    to decode lossless audio data.  So in situations of limited
    bandwidth, the sender may choose not to transmit enhancement data  
yet
    still provide a client with enough data to generate lossily-encoded
    audio through the base layer.

4.6.1  Scalable Multiplexed Streaming

    In multiplexed streaming, the base layer and enhancement layer are
    coupled together in each packet, utilizing only one session.  While
    the packet may begin with either layer type, the two layer types  
MUST
    interleave.

    +----------------+  +----------------+  +----------------+
    |Base|Enhancement|--|Base|Enhancement|--|Base|Enhancement| ...
    +----------------+  +----------------+  +----------------+
            N                   N+1                 N+2          :  
Packet



Romaine, et al.         Expires December 3, 2005                [Page 6]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


4.6.2  Scalable Multi-Session Streaming

    In multi-session streaming, the base layer and enhancement layer are
    sent over two seperate sessions, allowing clients with certain
    bandwidth limitations to receive just the base layer for decoding.
    While there may be alternative methods for synchronization of the
    layers, it is RECOMMENDED that the timestamp be used for
    synchronizing the base layer with its enhancement.  Applications can
    determine which sessions are paired together through use of the
    Session Description Protocol (SDP) (RFC 2327) [2].  Further details
    are discussed in the section titled "Usage of declarative SDP".

    Session 1:
    +------+  +------+  +------+  +------+
    | Base |--| Base |--| Base |--| Base | ...
    +------+  +------+  +------+  +------+
       N         N+1       N+2       N+3     : Packet

    Session 2:
    +-------------+  +-------------+  +-------------+
    | Enhancement |--| Enhancement |--| Enhancement | ...
    +-------------+  +-------------+  +-------------+
          N                N+1              N+2         : Packet


5.  Payload Format

5.1  Usage of RTP Header Fields

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          timestamp                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            synchronization source (SSRC) identifier           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           contributing source (CSRC) identifiers              |
      |                             .....                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Marker (M): 1 bit
    Set to zero as silence suppression is currently not used.

    Payload Type (PT): 7 bits
    The assignment of an RTP payload type for this packet format is
    outside the scope of this document; it is specified by the RTP



Romaine, et al.         Expires December 3, 2005                [Page 7]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    profile under which this payload format is used, or signaled
    dynamically out-of-band (e.g., using SDP).

    Timestamp: 32 bits
    A timestamp representing the sampling time of the first sample of  
the
    first ATRAC frame in the RTP packet.  When using SDP, the clock rate
    of the RTP timestamp MUST be expressed using the "rtpmap" attribute.
    For ATRAC3 the RTP timestamp rate MUST be 44100Hz.  For ATRAC-X the
    RTP timestamp rate is defined out-of-band.

5.2  RTP Payload Structure

5.2.1  ATRAC Header Section

    The ATRAC family payload header is one byte.

     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |C|FrgNo|NFrames|
    +-+-+-+-+-+-+-+-+

    Continuous flag (C): 1 bit
    Set to 1 if this is part of a fragmented packet.  The last packet in
    a series would have this bit set to 0.

    Fragment Number (FrgNo): 3 bits
    In the event of data fragmentation, this value is 1 for the first
    packet, and increases sequentially for the remaining fragmented data
    packets.

    Number of Frames (NFrames): 4 bits
    The number of frames in this packet.  This allows for a maximum  
of 16
    ATRAC-encoded audio frames per packet, with 0 indicating one frame.
    Each frame must be complete.  Only the first frame is allowed to be
    fragmented, in which case this MUST NOT be anything other than 0 for
    subsequent packets containing the fragmented frame.

5.2.2  Redundant Data Section

    The Redundant Data Section provides a rudimentary mechanism to
    compensate for occasional packet loss.  As every packet's timestamp
    corresponds to the first audio frame regardless of whether it is
    redundant or not, and because we know how many frames of audio each
    packet encapsulates, if two successive packets are successfully
    transmitted, we can calculate the number of redundant frames being
    sent.  The result gives the client a sense of how the server is
    responding to RTCP reports and to expand its buffer size if
    necessary.



Romaine, et al.         Expires December 3, 2005                [Page 8]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    As an example of using the Redundant Data Section, refer to  
Figure 1.
    In this example, the server has determined that for the next few
    number of packets, it should send the last two frames from the
    previous packet due to recent RTCP reports.  Thus, between packets N
    and N+1, there is a redundancy of two frames (which the client may
    choose to dispose of).  The benefit arises when packets N+2 and N+3
    do not arrive at all, after which eventually packet N+4 arrives with
    successive necessary audio frame data.  This field SHOULD NOT be  
used
    in packets containing fragmented data.

     |-Fr1-|-Fr2-|-Fr3-|                             Packet N,   TS=1
           |-Fr2-|-Fr3-|-Fr4-|                       Packet N+1, TS=2
                             |-Fr5-|-Fr6-|-Fr7-|     Packet N+4, TS=5


5.2.3  ATRAC Frames Section

    The ATRAC Frames Section contains an integer number of complete  
ATRAC
    frames or a single fragment of one ATRAC frame.  Each ATRAC frame is
    preceeded by a one-bit flag indicating the layer type and a Block
    Length field indicating the size in bytes of the ATRAC frame.  If
    more than one ATRAC frame is present, then the frames are
    concatenated into a contiguous string of bit-flag, Block Length, and
    ATRAC frame.  This section MUST NOT be empty.

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E|       Block Length          |         ATRAC frame            
|...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Layer Type Flag: 1 bit
    Set to 1 if the corresponding ATRAC frame is from an enhancement
    layer. 0 indicates a base layer encoded frame.

    Block length: 15 bits
    The byte length of encoded audio data for the following frame.  This
    is so that in the case of fragmentation, if only a subsequent packet
    is received, decoding can still occur. 15 bits allows for a maximum
    block length of 32,767 bytes.  If there are multiple frames in a
    packet, a block-length field exists before each frame data.

    ATRAC frame: The encoded ATRAC audio data.

5.2.3.1  Frame Fragmentation

    Each RTP packet SHALL contain either an integer number of ATRAC
    encoded audio frames (with a maximum of 16), or one ATRAC frame
    fragment.  In the former case, as many complete ATRAC frames as can



Romaine, et al.         Expires December 3, 2005                [Page 9]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    fit in a single path-MTU SHOULD be placed in an RTP packet.   
However,
    if even a single ATRAC frame will not fit into a complete RTP  
packet,
    the ATRAC frame SHOULD be fragmented.

    The start of a fragmented frame gets placed in its own RTP packet,
    its Continuous bit (C) set to one, and its Fragment Number (FragNo)
    set to one.  As the frame must be the only one in the packet, the
    Number of Frames field is zero.  Subsequent packets are to contain
    the remaining fragmented frame data, with the Fragment Number
    increasing sequentially and the Continuous bit (C) consistently set
    to one.  As subsequent packets do not contain any new frames, the
    Number of Frames field SHOULD be ignored.  The last packet of
    fragmented data MUST have the Continuous bit (C) set to zero.

    In addition to the Continuous bit and Fragment Number fields
    indicating fragmentation and a means to reorder the packets, the
    timestamp can be used to determine which packets go together.  Thus,
    packets containing related fragmented frames MUST have identical
    timestamps.

    In the event of fragmentation, the basic redundancy measures MUST  
NOT
    be used.  This means the Frame Offset field MUST be ignored.

6.  Packetization Examples

6.1  Example Multi-frame Packet

    Multiple encoded audio frames are combined into one packet.  Note  
how
    for this example, only base layer frames are sent redundantly, but
    are followed by interleaved base layer and enhancement layer frames.





















Romaine, et al.         Expires December 3, 2005               [Page 10]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          timestamp                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            synchronization source (SSRC) identifier           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           contributing source (CSRC) identifiers              |
      |                             .....                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|  0  |   5   |0|         Block Length        |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         (redundant)  base layer frame 1 data...               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|       Block Length          |(redundant) base layer frame 2 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    (cont.)  |0|   Block Length          |  base layer frame 3 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | (cont.) |1|       Block Length          |  enhancment frame 3 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|       Block Length          |     base layer frame 4...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



6.2  Example Fragmented ATRAC Frame

    The encoded audio data frame is split over three RTP packets.  The
    following points are highlighted in the example below:

    o  transition from one to zero of the Continuous bit (C)

    o  sequential increase in the Fragment Number



      Packet 1:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          timestamp                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            synchronization source (SSRC) identifier           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Romaine, et al.         Expires December 3, 2005               [Page 11]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


      |           contributing source (CSRC) identifiers              |
      |                             .....                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|  1  |   0   |1|        Block Length         |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     enhancement data...                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Packet 2:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          timestamp                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            synchronization source (SSRC) identifier           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           contributing source (CSRC) identifiers              |
      |                             .....                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|  2  |   0   |1|        Block Length         |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  ...more enhancement data...                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Packet 3:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          timestamp                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            synchronization source (SSRC) identifier           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           contributing source (CSRC) identifiers              |
      |                             .....                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|  3  |   0   |1|        Block Length         |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            ...the last of the enhancement data                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.  Payload Format Parameters

    Certain parameters will need to be defined before ATRAC family



Romaine, et al.         Expires December 3, 2005               [Page 12]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    encoded content can be streamed.  Other optional parameters may also
    be defined to take advantage of specific features relevant to  
certain
    ATRAC versions.  Parameters for ATRAC3, ATRAC-X, and ATRAC Advanced
    Lossless are defined here as part of the MIME subtype registration
    process.  A mapping of these parameters into the Session Description
    Protocol (SDP) (RFC 2327) [2] is also provided for applications that
    utilize SDP.

    The data format and parameters are specified for real-time transport
    in RTP.

7.1  ATRAC3 MIME Registration

    The MIME subtype for the Adaptive TRansform Codec version 3 (ATRAC3)
    is allocated from the Vendor tree since this codec is intended to be
    used with commercial products, and use of any ATRAC family codec
    requires a license from Sony Corporation, the vendor.

    Note, any unspecified parameter MUST be ignored by the receiver.

    Media Type name:  audio

    Media subtype name:  vnd.sony.atrac3

    Required parameters:

    baseLayer:  Indicates the encoded bit-rate for the audio data to be
    streamed.  Permissible values are 66, 105, and 132.

    Optional parameters:

    maxRedundantFrames:  The maximum number of redundant frames that may
    be sent during a session in any given packet under the redundant
    framing mechanism detailed in the draft.  Allowed values are  
integers
    in the range of 0 to 15, inclusive.  If this parameter is not  
used, a
    default of 15 MUST be assumed.

    maxptime: The maximum amount of media which can be encapsulated in
    each packet, expressed as time in milliseconds.  The time SHALL be
    calculated as the sum of the time the media present in the packet
    represents.  For frame based codecs, the time MUST be an integer
    multiple of the frame size.  If this parameter is not present, the
    sender MAY encapsulate a maximum of 16 encoded frames into one RTP
    packet.

    ptime:    see RFC 2327 [2]

    Encoding considerations: This type is defined for transfer via RTP



Romaine, et al.         Expires December 3, 2005               [Page 13]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    RFC 3550 [1].

    Security considerations:
    Please refer to section 7 of this draft.

    Public specifications:
    Please refer to section 7 of this draft.

    Macintosh file type code: none
    Object identifier or OID: none

    Person & email address to contact for further information:
    Mitsuyuki Hatanaka
    hatanaka@av.crl.sony.co.jp

    Intended usage: COMMON

    Author/Change controller:
    hatanaka@av.crl.sony.co.jp

7.2  ATRAC-X MIME Registraion

    The MIME subtype for the Adaptive TRansform Codec version X  
(ATRAC-X)
    is allocated from the Vendor tree since this codec is intended to be
    used with commercial products, and use of any ATRAC family codec
    requires a license from Sony Corporation, the vendor.

    Note, any unspecified parameter MUST be ignored by the receiver.

    Media Type name:  audio

    Media subtype name:  vnd.sony.atrac-x

    Required parameters:

    sampleRate:  Represents the sampling frequency in Hz of the original
    audio data.  Permissible values are 32000, 44100, 48000, 88200,
    96000.

    baseLayer:  Indicates the encoded bit-rate for the audio data to be
    streamed.  Permissible values are 48, 64, 96, 128, 160, 192, 256,  
and
    320.

    channelID:  Indicates the number of channels and channel layout
    according to the table in Section 5.3.  Note that this layout is
    different from that proposed in RFC 3551 [3].  However, as channelID
    = 0 defines an ambiguous channel layout, the channel mapping defined
    in Section 4.1 of [3] could be used.  Permissible values are 0,  
1, 2,



Romaine, et al.         Expires December 3, 2005               [Page 14]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    3, 4, 5, 6, 7.

    Optional parameters:

    maxRedundantFrames:  The maximum number of redundant frames that may
    be sent during a session in any given packet under the redundant
    framing mechanism detailed in the draft.  Allowed values are  
integers
    in the range 0 to 15, inclusive.  If this parameter is not used, a
    default of 15 MUST be assumed.

    delayMode:  Indicates a desire to use low-delay features, in which
    case the decoder will process received data accordingly based on  
this
    value.  Permissible values are 2 and 4.

    maxptime: The maximum amount of media which can be encapsulated in a
    payload packet, expressed as time in milliseconds.  The time is
    calculated as the sum of the time the media present in the packet
    represents.  The time MUST be a multiple of the frame size.  If this
    parameter is not present, the sender MAY encapsulate a maximum of 16
    encoded frames into one RTP packet.

    ptime:    see RFC 2327 [2]

    Encoding considerations: This type is defined for transfer via RTP
    (RFC 3550) [1].

    Security considerations:
    Please refer to section 7 of this draft.

    Public specifications:
    Please refer to section 7 of this draft.

    Macintosh file type code: none
    Object identifier or OID: none

    Person & email address to contact for further information:
    Mitsuyuki Hatanaka
    hatanaka@av.crl.sony.co.jp

    Intended usage: COMMON

    Author/Change controller:
    hatanaka@av.crl.sony.co.jp

7.3  ATRAC Advanced Lossless MIME Registration

    The MIME subtype for the Adaptive TRansform Codec Lossless version
    (ATRAC Advanced Lossless) is allocated from the Vendor tree since



Romaine, et al.         Expires December 3, 2005               [Page 15]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    this codec is intended to be used with commercial products, and use
    of any ATRAC family codec requires a license from Sony Corporation,
    the vendor.

    Note, any unspecified parameter MUST be ignored by the receiver.

    Media Type name:  audio

    Media subtype name:  vnd.sony.atrac-advanced-lossless

    Required parameters:

    sampleRate:  Represents the sampling frequency in Hz of the original
    audio data.  Permissible values are 32000, 44100, 48000, 88200,
    96000.

    baseLayer:  Indicates the encoded bit-rate for the base layer in
    High-Speed Transfer mode lossless encodings.  For Standard lossless
    mode this value MUST be 0.  Permissible values are 0, 48, 64, 66,  
96,
    105, 128, 132, 160, 192, 256, and 320.

    blockLength: Indicates the block length being used for Standard
    lossless mode.  When "baseLayer=0", this value MUST be one of either
    512, 1024, or 2048.  If the "baseLayer" parameter is not "0", this
    parameter MUST be ignored.

    channelID:  Indicates the number of channels and channel layout
    according to the table in Section 5.3.  Note that this layout is
    different from that proposed in RFC 3551 [3].  However, as channelID
    = 0 defines an ambiguous channel layout, the channel mapping defined
    in Section 4.1 of [3] could be used.  Permissible values are 0,  
1, 2,
    3, 4, 5, 6, 7.

    Optional parameters:

    maxRedundantFrames:  The maximum number of redundant frames that may
    be sent during a session in any given packet under the redundant
    framing mechanism detailed in the draft.  Allowed values are  
integers
    in the range 0 to 15, inclusive.  If this parameter is not used, a
    default of 15 MUST be assumed.

    maxptime: The maximum amount of media which can be encapsulated in a
    payload packet, expressed as time in milliseconds.  The time is
    calculated as the sum of the time the media present in the packet
    represents.  The time MUST be a multiple of the frame size.  If this
    parameter is not present, the sender MAY encapsulate a maximum of 16
    encoded frames into one RTP packet.




Romaine, et al.         Expires December 3, 2005               [Page 16]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    ptime:    see RFC 2327 [2]

    Encoding considerations: This type is defined for transfer via RTP
    (RFC 3550) [1].

    Security considerations:
    Please refer to section 7 of this draft.

    Public specifications:
    Please refer to section 7 of this draft.

    Macintosh file type code: none
    Object identifier or OID: none

    Person & email address to contact for further information:
    Mitsuyuki Hatanaka
    hatanaka@av.crl.sony.co.jp

    Intended usage: COMMON

    Author/Change controller:
    hatanaka@av.crl.sony.co.jp

7.4  Channel Mapping Configuration Table

    The following is a table explaining the mapping between the  
channelID
    as passed during SDP negotiations, and the speaker mapping the value
    represents.























Romaine, et al.         Expires December 3, 2005               [Page 17]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | channelID | Number of |  Default Speaker    |
                |           | Channels  |      Mapping        |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     0     |  max 64   |     undefined       |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     1     |     1     | front: center       |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     2     |     2     | front: left, right  |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     3     |     3     | front: left, right  |
                |           |           | front: center       |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     4     |     4     | front: left, right  |
                |           |           | front: center       |
                |           |           | rear: surround      |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     5     |    5+1    | front: left, right  |
                |           |           | front: center       |
                |           |           | rear: left, right   |
                |           |           | LFE                 |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     6     |    6+1    | front: left, right  |
                |           |           | front: center       |
                |           |           | rear: left, right   |
                |           |           | rear: center        |
                |           |           | LFE                 |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     7     |    7+1    | front: left, right  |
                |           |           | front: center       |
                |           |           | rear: left, right   |
                |           |           | side: left, right   |
                |           |           | LFE                 |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.5  Mapping MIME Parameters into SDP

    The information carried in the MIME media type specification has a
    specific mapping to fields in the Session Description Protocol (SDP)
    [2], which is commonly used to describe RTP sessions.  When SDP is
    used to specify sessions employing the ATRAC family of codecs, the
    following mapping rules according to the ATRAC codec apply:

7.5.1  For MIME subtype ATRAC3

    o  The MIME type ("audio") goes in SDP "m=" as the media name




Romaine, et al.         Expires December 3, 2005               [Page 18]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    o  The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
       the encoding name.  ATRAC3 supports only mono or stereo signals,
       so a corresponding number of channels SHALL also be included in
       this attribute.

    o  The "baseLayer" parameter goes in SDP "a=fmtp".  This parameter
       MUST be present. "maxRedundantFrames" may follow, but if no value
       is transmitted, the receiver SHOULD assume a default value of
       "15".

    o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
       "a=maxptime" attributes, respectively.


7.5.2  For MIME subtype ATRAC-X

    o  The MIME type ("audio") goes in SDP "m=" as the media name

    o  The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
       the encoding name.  This should be followed by the "sampleRate"
       (as the RTP clock rate), and then the actual number of channels
       regardless of the channelID parameter.

    o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
       "a=maxptime" attributes, respectively.

    o  Any remaining parameters go in the SDP "a=fmtp" attribute by
       copying them directly from the MIME media type string as a
       semicolon separated list of parameter=value pairs.  The
       "baseLayer" parameter must be the first entry on this line.   
It is
       recommened that the "channelID" parameter be the next entry.  The
       receiver MUST assume a default value of "15" for
       "maxRedundantFrames".


7.5.3  For MIME subtype ATRAC Advanced Lossless

    o  The MIME type ("audio") goes in SDP "m=" as the media name

    o  The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
       the encoding name.  This should be followed by the "sampleRate"
       (as the RTP clock rate), and then the actual number of channels
       regardless of the channelID parameter.

    o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
       "a=maxptime" attributes, respectively.





Romaine, et al.         Expires December 3, 2005               [Page 19]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    o  Any remaining parameters go in the SDP "a=fmtp" attribute by
       copying them directly from the MIME media type string as a
       semicolon separated list of parameter=value pairs.  The
       "baseLayer" parameter must be the first entry on this line.  If
       "baseLayer=0", the "blockLength" parameter MUST follow and be one
       of either 512, 1024, or 2048.  It is recommended that the
       "channelID" parameter be the next entry.  The receiver MUST  
assume
       a default value of "15" for "maxRedundantFrames".


7.6  Offer-Answer Model Considerations

    Some options for encoding and decoding ATRAC audio data will require
    either or both the sender and receiver to comply with certain
    specifications.  In order to establish an interoperable transmission
    framework, an Offer-Answer negotiation in SDP should observe the
    following considerations:

7.6.1  For All Three MIME Subtypes

    o  Each combination of the RTP payload transport format  
configuration
       parameters (baseLayer and blockLength, sampleRate, channelID) is
       unique in its bit-pattern and not compatible with any other
       combination.  When creating an offer in an application  
desiring to
       use the more advanced features (sample rates above 44100kHz, more
       than two channels), the offerer is RECOMMENDED to also offer a
       payload type containing only the lowest set of necessary
       requirements.  If multiple configurations are of interest to the
       application they may all be offered, however care should be taken
       not to offer too many payload types.

    o  The parameters "maxptime" and "ptime" will in most cases not
       affect interoperability, however the setting of the parameters  
can
       affect the performance of the application.  The SDP offer-answer
       handling of the "ptime" parameter is described in RFC3264.  The
       "maxptime" parameter MUST be handled in the same way.


7.6.2  For MIME subtype ATRAC3

    o  In response to an offer, downgraded subsets of "baseLayer" are
       possible.  However for best performance, we suggest the answer
       contain the highest possible values offered.


7.6.3  For MIME subtype ATRAC-X





Romaine, et al.         Expires December 3, 2005               [Page 20]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    o  When creating an offer with considerably high requirements (such
       as 8 channels at 96kHz), it is RECOMMENDED that the offer also
       contain a configuration with lower requirements (such as a stereo
       only option).  Although multiple alternative configurations  
may be
       offered, care should be taken not to offer too many payload  
types.

    o  In response to an offer, downgraded subsets of "sampleRate",
       "baseLayer", and "channelID" are possible.  For best performance,
       we suggest an answer SHALL NOT contain any values requiring
       further capabilities than the offer contains, but is RECOMMENDED
       to provide values as close as possible to those in the offer.

    o  The "maxRedundantFrames" is a suggested minimum.  This value MAY
       be increased in an answer (with a maximum of 15), but SHALL  
NOT be
       reduced.

    o  The optional parameter "delayMode" is non-negotiable.  If the
       Answerer cannot comply with the offered value, the session  
must be
       deemed inoperable.


7.6.4  For MIME subtype ATRAC Advanced Lossless

    o  When creating an offer with considerably high requirements (such
       as 8 channels at 96kHz), it is RECOMMENDED that the offer also
       contain a configuration with lower requirements (such as a stereo
       only option).  Although multiple alternative configurations  
may be
       offered, care should be taken not to offer too many payload  
types.

    o  In response to an offer, downgraded subsets of "sampleRate",
       "baseLayer", and "channelID" are possible.  For best performance,
       we suggest an answer SHALL NOT contain any values requiring
       further capabilities than the offer contains, but is RECOMMENDED
       to provide values as close as possible to those in the offer.

    o  There are no requirements when negotiating "blockLength", other
       than that both parties must be in agreement.

    o  The "maxRedundantFrames" is a suggested minimum.  This value MAY
       be increased in an answer (with a maximum of 15), but SHALL  
NOT be
       reduced.


7.7  Usage of declarative SDP

    In declarative usage, like SDP in RTSP [9] or SAP [10], the
    parameters SHALL be interpreted as follows:




Romaine, et al.         Expires December 3, 2005               [Page 21]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    o  The payload format configuration parameters (baseLayer,
       sampleRate, channelID) are all declarative and a participant MUST
       use the configuration(s) that is provided for the session.  More
       than one configuration may be provided if necessary by declaring
       multiple RTP payload types, however the number of types should be
       kept small.

    o  Any "maxptime" and "ptime" values should be selected with care to
       ensure that the session's participants can achieve reasonable
       performance.

    For transmission of scalable multi-session streaming of ATRAC
    Advanced Lossless content, section 6 of the Session Description
    Protocol (RFC 2327) [2] defines attributes for notifying  
applications
    of hierarchically encoded streams.  For multicast sessions, the base
    layer and enhancement layer are transmitted over seperate multicast
    groups, thus requiring multiple multicast addresses.  For this
    scenario, SDP slash notation as defined in RFC 2327 [2] for the "c="
    field should be followed.  For IP unicast addresses, it will be
    necessary to specify multiple transport ports.  This is done with
    slash notation in the "m=" field similarly defined in RFC 2327 [2].

7.8  Example SDP Session Descriptions

    Example usage of ATRAC-X with stereo at 44100Hz:

    m=audio 49120 RTP/AVP 99
    a=rtpmap:99 ATRAC-X/44100/2
    a=fmtp:99 baseLayer=128; channelID=2; delayMode=2
    a=maxptime:20

    Example usage of ATRAC-X with 5.1 setup at 48000Hz:

    m=audio 49120 RTP/AVP 99
    a=rtpmap:99 ATRAC-X/48000/6
    a=fmtp:99 baseLayer=320; channelID=5
    a=maxptime:30

    Example usage of ATRAC-Advanced-Lossless in Standard mode:

    m=audio 49200 RTP/AVP 99
    a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2
    a=maxptime:30

    Example usage of ATRAC-Advanced-Lossless in High-Speed mode (note
    slash notation for multiple port-pairings):




Romaine, et al.         Expires December 3, 2005               [Page 22]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    m=audio 49200/2 RTP/AVP 99
    a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/48000/2
    a=fmtp:99 baseLayer=128; blockLength=0; channelID=2
    a=maxptime:30

7.9  Example Offer-Answer Exchange

    The following Offer/Answer example shows how a desire to stream
    multi-channel content is turned down by the receiver, who answers
    with only the ability to receive stereo content:

    Offer:

    m=audio 49170 RTP/AVP 98 99
    a=rtpmap:98 ATRAC-X/44100/6
    a=fmtp:98 baseLayer=320; channelID=5
    a=rtpmap:99 ATRAC-X/44100/6
    a=fmtp:99 baseLayer=160; channelID=5

    Answer:

    m=audio 49170 RTP/AVP 99
    a=rtpmap:99 ATRAC-X/44100/2
    a=fmtp:99 baseLayer=160; channelID=2

    The following Offer/Answer example shows the receiver answering with
    a selection of supported parameters:

    Offer:

    m=audio 49170 RTP/AVP 97 98 99
    a=rtpmap:97 ATRAC-X/44100/2
    a=fmtp:97 baseLayer=128; channelID=2
    a=rtpmap:98 ATRAC-X/44100/6
    a=fmtp:98 baseLayer=128; channelID=5
    a=rtpmap:99 ATRAC-X/48000/6
    a=fmtp:99 baseLayer=320; channelID=5

    Answer:

    m=audio 49170 RTP/AVP 97 98
    a=rtpmap:97 ATRAC-X/44100/2
    a=fmtp:97 baseLayer=128; channelID=2
    a=rtpmap:98 ATRAC-X/44100/6
    a=fmtp:98 baseLayer=128; channelID=5

    The following Offer/Answer example shows an exchange in trying to
    resolve using ATRAC-Advanced-Lossless.  The offer contains three



Romaine, et al.         Expires December 3, 2005               [Page 23]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    options: multi-session High-Speed Transfer mode, multiplexed High-
    Speed Transfer mode, and Standard mode.

    Offer:

    m=audio 49170/2 RTP/AVP 97
    a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:97 baseLayer=64; blockLength=0; channelID=2
    m=audio 49170 RTP/AVP 98
    a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:98 baseLayer=256; blockLength=0; channelID=2
    m=audio 49170 RTP/AVP 99
    a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/48000/2
    a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2

    Answer:

    m=audio 49170/2 RTP/AVP 97
    a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:97 baseLayer=64; blockLength=0; channelID=2
    m=audio 49170 RTP/AVP 98
    a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
    a=fmtp:98 baseLayer=256; blockLength=0; channelID=2
    m=audio 0 RTP/AVP 99

    Note that payload format (encoding) names are commonly shown in  
upper
    case.  MIME subtypes are commonly shown in lower case.  These names
    are case-insensitive in both places.  Similarly, parameter names are
    case-insensitive both in MIME types and in the default mapping to  
the
    SDP a=fmtp attribute.

8.  IANA Considerations

    Two new MIME subtypes, for ATRAC3 and ATRAC-X, are requested to be
    registered (see Section 5).

9.  Security Considerations

    Certain security precautions may be desired to protect copyrighted
    material.  The payload format as described in this document is
    subject to the security considerations defined in RFC3550 [1] and  
any
    applicable profile, for example RFC 3551 [3].  This payload format
    however does not implement any security mechanisms of its own.
    External means, such as SRTP [5], MAY be used since the audio
    compression scheme follows an end-to-end model.

    Since the data transported is audio that is already encoded, the  
main
    security issues are confidentiality, integrity, and  
authentication of



Romaine, et al.         Expires December 3, 2005               [Page 24]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    the actual audio.

9.1  Confidentiality

    To ensure confidentiality of ATRAC encoded audio, the audio frames
    will have to be encrypted.  Encryption of the payload header,
    however, is not as neccessary, and in fact may not be preferrable if
    the information could be useful to some third party application.

    Because the audio compression scheme follows an end-to-end model,
    encryption may be performed after packet encapsulation.  As multi-
    channel transmissions are contained in single encoded audio frames,
    there is no concern for encryption affecting interleaving data.

9.2  Authentication

    Transmitted data may be tampered or altered due malicious attempts,
    such as man-in-the-middle attacks.  Such attacks may result in
    depacketization and/or decoding errors that could decimate audio
    quality.

    As this payload format does not include its own means for sender
    authentication and integrity protection, an external mechanism must
    be used.  It is RECOMMENDED, however, that the chosen mechanism
    protect more than just the audio data bits.  For example, to protect
    against a man-in-the-middle attack, the payload header and RTP  
header
    SHOULD be protected.

9.3  Decoding Validation

    Verification of the received encoded audio packets should be
    performed so as to ensure a minimal level of audio quality.  As a
    most primitive implementation, if the receiver calculates a packet
    size differing from the payload length based on data in the payload
    header fields, the receiver SHOULD discard the packet.

10.  References

10.1  Normative References

    [1]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobsen,
         "RTP: A Transport Protocol for Real-Time Applications",
         RFC 3550, STD 64, July 2003.

    [2]  Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

    [3]  Schulzrinne, H., "RTP Profile for Audio and Video Conferences



Romaine, et al.         Expires December 3, 2005               [Page 25]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


         with Minimal Control", RFC 3551, STD 65, July 2003.

    [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels, BCP 14", RFC 2119, March 1997.

10.2  Informative References

    [5]   Kerr, P., "RTP Payload Format for Vorbis Encoded Audio",
          October 2003.

    [6]   Sjoberg, J., "Real-Time Transport Protocol (RTP) Payload  
Format
          and File Storage Format for the Adaptive Multi-Rate (AMR) and
          Adpative Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267,
          June 2002.

    [7]   Baugher, M., Carrara, E., McGrew, D., Naslund, M., and  
Norrman,
          "The Secure Real Time Transport Protocol", July 2003.

    [8]   Rosenberg, J. and Schulzrinne, "An Offer/Answer Model with the
          Session Description Protocl (SDP)", RFC 3264, June 2002.

    [9]   Schulzrinne, H., Rao, and Lanphier, "Real Time Streaming
          Protocol (RTSP)", RFC 2326, April 1998.

    [10]  Handley, M., Perkins, and Whelan, "Session Announcement
          Protocol", RFC 2974, October 2000.


Authors' Addresses

    Matthew Romaine
    Sony Corporation, Japan
    6-7-35 Kitashinagawa
    Shinagawa-ku
    Tokyo  141-0001
    Japan

    Email: Matthew.Romaine@jp.sony.com













Romaine, et al.         Expires December 3, 2005               [Page 26]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


    Mitsuyuki Hatanaka
    Sony Corporation, Japan
    6-7-35 Kitashinagawa
    Shinagawa-ku
    Tokyo  141-0001
    Japan

    Email: hatanaka@av.crl.sony.co.jp


    Jun Matsumoto
    Sony Corporation, Japan
    6-7-35 Kitashinagawa
    Shinagawa-ku
    Tokyo  141-0001
    Japan

    Email: jun@av.crl.sony.co.jp

































Romaine, et al.         Expires December 3, 2005               [Page 27]

Internet-Draft     RTP Payload Format for ATRAC Family         June 2005


Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be  
claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.   
Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the  
use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR  
repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Disclaimer of Validity

    This document and the information contained herein are provided  
on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

    Copyright (C) The Internet Society (2005).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.


Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.




Romaine, et al.         Expires December 3, 2005               [Page 28]


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



From avt-bounces@ietf.org Fri Jul 08 10:06:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqtUm-00082d-2a; Fri, 08 Jul 2005 10:06:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqtUk-00082G-9p; Fri, 08 Jul 2005 10:06:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04067;
	Fri, 8 Jul 2005 10:06:20 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dqtw8-0001vJ-Cb; Fri, 08 Jul 2005 10:34:41 -0400
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j68E65sw010969
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 8 Jul 2005 10:06:13 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1])
	by cnr.cs.columbia.edu (8.13.3/8.13.3) with ESMTP id j68E65SM008064;
	Fri, 8 Jul 2005 10:06:05 -0400 (EDT)
	(envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost)
	by cnr.cs.columbia.edu (8.13.3/8.13.3/Submit) id j68E64cZ008061;
	Fri, 8 Jul 2005 10:06:04 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17102.34892.865008.753397@cnr.cs.columbia.edu>
Date: Fri, 8 Jul 2005 10:06:04 -0400
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over TLS
	submitted.Ready for WGLC?
In-Reply-To: <42CE2749.70907@ericsson.com>
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU>
	<D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu>
	<17101.30921.48827.630095@cnr.cs.columbia.edu>
	<42CE2749.70907@ericsson.com>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: lazzaro <lazzaro@eecs.berkeley.edu>, mmusic@ietf.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On Friday, July 8 2005, "Magnus Westerlund" wrote to "Jonathan Lennox, lazzaro, mmusic@ietf.org, avt@ietf.org" saying:

> Hi Jonathan,
> 
> Can you please remind where and when the decision was taken to not 
> define TCP/TLS/RTP/AVP? All I find is some loose discussion without 
> conclusion about the topic, but nothing I can interpret as an WG 
> consensus on this.

It was at the MMusic meeting in San Diego (August 2004), following my
initial presentation of comedia-tls.  Here's the relevant paragraph from the
minutes:

    An open issue is that this defines only TCP/TLS, not TCP/TLS/RTP/AVP.
    Similarly, nothing defines TCP/RTP/SAVP. What should be the preferred
    way of doing secure connection-oriented RTP? Steve Casner suggested
    that it might be appropriate to wait until there is a use case for
    SRTP over connection oriented media, rather than trying to specify it
    now.

As I recall, Steve's comment got a rough nodding of heads.  So I wouldn't
say that a decision was explicitly taken not to define this, so much as that
no decision was taken *to* define it.

> I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF.

TCP/TLS/RTP/AVP, yes.  I'm not sure what the use-case is for
TCP/TLS/RTP/AVPF -- I thought most of the motivation for AVPF was for
bandwidth adaptation and improved delivery reliablity, both of which seem to
be redundant for something transmitted over TCP.

> I would also consider if TCP/TLS/RTP/SAVP is a good idea or not. I would
> consider TCP/TLS/RTP/SAVP a possibility in cases that requires a secure
> TCP/TLS connection, for example due to end point authentication, which
> however is a gateway to an SRTP session. If that is relevant or not is
> another matter.

I'm dubious about sending Secure RTP over TLS -- I think it would need to be
pretty strongly motivated with real use-cases.

For both these cases, their motivations are significantly stronger if you're
envisioning implementing a UDP<->TCP<->UDP tunnel scenario.  Is that what
you're thinking of?

> I also agree with Lazzaro that with the current IETF lead time the only 
> reasonable way of providing for future use cases the market wants to 
> select it to have it ready. I don't want to be the part blocking actual 
> deployment of security. Thus I think we should consider both 
> TCP/RTP/SAVP and TCP/TLS/RTP/AVP.

Fair enough.

> As I see it TCP/RTP/SAVP and TCP/TLS/RTP/AVP have somewhat different 
> security properties. TLS provides a secured transport channel with 
> possibility to end-point authentication. The SRTP based solution 
> provides instead group security and can be done without a trusted 
> gateway. So they definitely are applicable in different use cases.

I'm not sure what you mean by a "trusted gateway", and I'm not sure how
useful group security is for a point-to-point connection-oriented protocol,
again unless you're envisioning tunneling.

(Would it be worthwhile to restrict this discussion just to the avt list?)

-- 
Jonathan Lennox
lennox@cs.columbia.edu

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



From avt-bounces@ietf.org Fri Jul 08 10:35:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqtwk-0007HW-Lv; Fri, 08 Jul 2005 10:35:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqtwi-0007Gu-Kd
	for avt@megatron.ietf.org; Fri, 08 Jul 2005 10:35:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07008
	for <avt@ietf.org>; Fri, 8 Jul 2005 10:35:12 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DquO4-0003QP-Ht
	for avt@ietf.org; Fri, 08 Jul 2005 11:03:34 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j68EYtW01661; Fri, 8 Jul 2005 10:34:56 -0400 (EDT)
Received: from [127.0.0.1] (acart256.ca.nortel.com [47.130.17.125]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id MRAFR2RN; Fri, 8 Jul 2005 10:34:56 -0400
Message-ID: <42CE8F0B.5040205@nortel.com>
Date: Fri, 08 Jul 2005 10:34:51 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Tom Taylor <taylor@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: 7bit
Cc: scott.petrack@edial.com, hgs@cs.columbia.edu
Subject: [AVT] draft-ietf-avt-rfc2833bisdata-02.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I have submitted another update of the 2833bis data event draft.  This 
update includes the following changes:

1. Changed the V.8 bis event scheme as I proposed in a previous E-mail, 
so that the first and second segments of the signals are reported as 
separate events.  While I was at it, I streamlined the description of 
V.8 bis operation, mainly because the previous description had 
inaccuracies and it didn't seem appropriate to add the complexity 
necessary to tell the complete and correct story.

2. Added a section on handling of congestion for each application.

3. Added the V.32/V.32bis calling and called pattern events agreed in 
earlier discussion, along with a general description of the modem 
startup sequence.

4. For text messaging, deleted mention of Q.23 but noted the DTMF text 
terminal application, which is now described in the main 2833bis 
document along with DTMF events.

5. Added the XCIMark event for text messaging, as agreed in previous 
discussion.

6. Truncated the description of V.18 but added a description of the XCI 
signal and use of XCIMark, as agreed in previous discussion.

7. Ensured it was clear in the second example of section 4 that the 
voice content covered the same content as the events for the same period.

8. Updated the event registry in Table 9 according to the changes 
described in the previous items of this note.

9. Added references for V.32 and V.32 bis, and updated the references 
for CLEARMODE and text (RFC 4103).

10. Updated Scott Petrack's affiliation.


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



From avt-bounces@ietf.org Fri Jul 08 12:33:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqvnJ-00034f-47; Fri, 08 Jul 2005 12:33:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DqvnI-00034a-Gp
	for avt@megatron.ietf.org; Fri, 08 Jul 2005 12:33:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26256
	for <avt@ietf.org>; Fri, 8 Jul 2005 12:33:38 -0400 (EDT)
Received: from mail120.messagelabs.com ([216.82.255.211])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqwEc-0004T4-PR
	for avt@ietf.org; Fri, 08 Jul 2005 13:02:01 -0400
X-VirusChecked: Checked
X-Env-Sender: gash@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1120840402!3339395!1
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [192.128.167.69]
Received: (qmail 15588 invoked from network); 8 Jul 2005 16:33:23 -0000
Received: from almso1.att.com (HELO almso1.proxy.att.com) (192.128.167.69)
	by server-9.tower-120.messagelabs.com with SMTP;
	8 Jul 2005 16:33:23 -0000
Received: from attrh3i.attrh.att.com ([135.38.62.9])
	by almso1.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id
	j68GX7Px011244 for <avt@ietf.org>; Fri, 8 Jul 2005 12:33:22 -0400
Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by
	attrh3i.attrh.att.com (7.2.052)
	id 42BED27600262564 for avt@ietf.org; Fri, 8 Jul 2005 12:33:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 8 Jul 2005 11:33:22 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE668@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-01.txt 
Thread-Index: AcWD0YbHU77AD7LDTN2AdZ1EHqnoVgAAEz7A
From: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
To: "IETF AVT WG" <avt@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
Subject: [AVT] RE: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-01.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi All,

Please review and comment on the (significantly) updated draft 'Protocol
Extensions for Header Compression over MPLS'
(http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol
-01.txt).

Note that a work item and milestone were recently added to the AVT
charter on this work:

"- in collaboration with the MPLS and ROHC WGs, to develop a solution
for header compression of RTP across MPLS networks that avoid
decompression and compression at each MPLS node.
...
Dec 05 Submit any extensions for RTP HC on MPLS networks for Proposed
Standard"=20

The updated I-D responds to comments on the AVT list from Lars-Erik
Jonsson and Colin Perkins:

http://www1.ietf.org/mail-archive/web/avt/current/msg05408.html
http://www1.ietf.org/mail-archive/web/avt/current/msg05419.html
http://www1.ietf.org/mail-archive/web/avt/current/msg05428.html
http://www1.ietf.org/mail-archive/web/avt/current/msg05433.html
http://www1.ietf.org/mail-archive/web/avt/current/msg05530.html

The main changes are as follows:

1. Lars-Erik's suggested outline is used, in particular:
   - Section 2 'Terminology' is added
   - Section 3 'Header Compression over MPLS Protocol Overview' is added
   - Section 4 'Protocol Specifications' is reorganized
2. Pseudowire (PW) setup and header compression session configuration
are covered in Sections 3.1 and 4.1.  In particular, the PW Interface
Parameters Sub-TLV is used to signal header compression session setup
and header compression parameter negotiation, such as described for
header-compression-over-PPP mechanisms [RFC3241, RFC3544].
3. Encapsulation of header compressed packets is covered in Sections 3.2
and 4.2.  See in particular Figure 3 illustrating 'Header Compression
over MPLS Media Stream Transport'.
4. A PW type has been assigned to each header compression scheme, as
discussed in Section 4.1 and [IANA]
(http://ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt)
.

Once again, please review and comment on the updated draft.  It will be
good to have some discussion on the list in anticipation of proposing
this as an AVT WG document at the IETF-63/AVT meeting.

Thanks,
Jerry

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf Of
Internet-Drafts@ietf.org
Sent: Friday, July 08, 2005 10:50 AM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-ash-avt-hc-over-mpls-protocol-01.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Protocol Extensions for Header Compression
over MPLS
	Author(s)	: J. Ash, et al.
	Filename	: draft-ash-avt-hc-over-mpls-protocol-01.txt
	Pages		: 17
	Date		: 2005-7-8
=09
VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS
   Labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an
   MPLS VPN, the packet header is typically 48 bytes, while the voice
   payload is often no more than 30 bytes, for example. Header
   compression can significantly reduce the overhead through various
   compression mechanisms.  MPLS is used to route header-compressed (HC)
   packets over an MPLS LSP without compression/decompression cycles at
   each router.  Such an HC over MPLS capability increases the bandwidth
   efficiency as well as processing scalability of the maximum number of
   simultaneous compressed flows that use HC at each router.  MPLS
   pseudowires are used to transport the HC context and other control
   messages between the ingress and egress MPLS label switched router
   (LSR), and the pseudowires define a point to point instance of each
   HC session at the header decompressor.  Standard HC methods (e.g.,
   ECRTP, ROHC, etc.) are re-used to determine the context.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-avt-hc-over-mpls-protocol-
01.txt

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



From avt-bounces@ietf.org Fri Jul 08 13:49:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqwyv-0006HP-0x; Fri, 08 Jul 2005 13:49:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqwys-0006H7-9G
	for avt@megatron.ietf.org; Fri, 08 Jul 2005 13:49:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01025
	for <avt@ietf.org>; Fri, 8 Jul 2005 13:49:40 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DqxQH-0007jM-Th for avt@ietf.org; Fri, 08 Jul 2005 14:18:03 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 08 Jul 2005 10:49:29 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j68HnPVX025334;
	Fri, 8 Jul 2005 10:49:26 -0700 (PDT)
Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com
	[10.32.245.152])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j68HmMSW027762;
	Fri, 8 Jul 2005 10:48:23 -0700
In-Reply-To: <9ED672B9D1A64C489291BE0FB822217D0B24CBA1@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <9ED672B9D1A64C489291BE0FB822217D0B24CBA1@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <9DEAF4F4-5286-46D5-B2CF-D43304BE9904@cisco.com>
Content-Transfer-Encoding: 7bit
From: David R Oran <oran@cisco.com>
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Fri, 8 Jul 2005 13:49:22 -0400
To: Anders Klemets <anderskl@windows.microsoft.com>
X-Mailer: Apple Mail (2.730)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1120844903.754359"; x:"432200"; a:"rsa-sha1"; b:"nofws:856";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"W6CU5QuJs+3sO+WkJpRFzZQ9WfV0qyuLld9pH7UqWjhvKSybuDFfj7ticRgta+nANwSabKSV"
	"YOOn/cZdqRFMTTzlwqNDm5mYwGK/ljfnQM2lovNMUkEdRaWz0A3msDiJLvgad8jOe4TKUrRyKbQ"
	"WHAz5U9el59982mykJcbCb+s="; c:"From: David R Oran <oran@cisco.com>";
	c:"Subject: Re: [AVT] [Fwd: I-D
	ACTION:draft-klemets-avt-rtp-vc1-00.txt" "]";
	c:"Date: Fri, 8 Jul 2005 13:49:22 -0400"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Perhaps it would be wise for AVT to wait to discuss this draft until  
the codec spec is publically avaible?

Any idea when this will happen?


On Jul 7, 2005, at 9:01 PM, Anders Klemets wrote:

> SMPTE 421M is in Final Committee Draft status and is not yet  
> publicly available.  However, SMPTE members should be able to  
> obtain a copy from the members-only area on the SMPTE web site.   
> The spec is being developed by Technology Committee C24 on Video  
> Compression Technology.
>
>
>
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf  
> Of Keith Lantz
> Sent: Thursday, July 07, 2005 1:43 PM
> To: Magnus Westerlund
> Cc: IETF AVT WG
> Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
>
>
>
> Indeed...
>
> I don't suppose anyone can provide a copy of SMPTE 421M? It doesn't  
> appear to be available (yet) from smpte.org.
>
> Thx, Keith
>
>
> _______________________________________________
> 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 avt-bounces@ietf.org Fri Jul 08 15:50:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqyro-0007GS-DA; Fri, 08 Jul 2005 15:50:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DqyrT-00078n-ID; Fri, 08 Jul 2005 15:50:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11702;
	Fri, 8 Jul 2005 15:50:09 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DqzIs-0004VF-Ig; Fri, 08 Jul 2005 16:18:31 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DqyrK-0002r8-0k; Fri, 08 Jul 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DqyrK-0002r8-0k@newodin.ietf.org>
Date: Fri, 08 Jul 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-04.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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 ATRAC Family
	Author(s)	: M. Romaine, et al.
	Filename	: draft-ietf-avt-rtp-atrac-family-04.txt
	Pages		: 28
	Date		: 2005-7-8
	
This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Codec (ATRAC) family of codecs.  Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, elementary
   redundancy measures, and a variation on scalable streaming.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-atrac-family-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-rtp-atrac-family-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: <2005-7-8124217.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-atrac-family-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-atrac-family-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-8124217.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Fri Jul 08 16:39:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dqzd0-0007OG-Ju; Fri, 08 Jul 2005 16:39:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqzd0-0007OB-2v
	for avt@megatron.ietf.org; Fri, 08 Jul 2005 16:39:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26510
	for <avt@ietf.org>; Fri, 8 Jul 2005 16:39:16 -0400 (EDT)
Received: from mail3.microsoft.com ([131.107.3.123])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr04R-00028v-JB
	for avt@ietf.org; Fri, 08 Jul 2005 17:07:40 -0400
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 8 Jul 2005 13:39:07 -0700
Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by
	mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 8 Jul 2005 13:39:07 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com
	([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 13:39:07 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
	([157.54.12.88]) by
	win-imc-02.wingroup.windeploy.ntdev.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 13:39:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Fri, 8 Jul 2005 13:38:58 -0700
Message-ID: <9ED672B9D1A64C489291BE0FB822217D0B24D1A6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
thread-index: AcWD5W/L3hSAT2BBQaiCnaec5q91PwAFHqsg
From: "Anders Klemets" <anderskl@windows.microsoft.com>
To: "IETF AVT WG" <avt@ietf.org>
X-OriginalArrivalTime: 08 Jul 2005 20:39:07.0201 (UTC)
	FILETIME=[162E1310:01C583FD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: quoted-printable
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

If memory serves me right, AVT began considering RTP payload formats for
AVC and MPEG-4 before those specs were publicly available, so there is
precedence for this.

I can't say for sure when SMPTE 421M will be published, but the spec
needs to reach Draft Standard status first.  If I understand things
correctly, once a spec reaches Draft Standard status, they only allow
editorial changes, and specs are then approved for publication in
relatively short order.

I think it is possible that SMPTE C24 will decide to have a ballot about
whether or not to elevate the VC-1 spec to Draft Standard status, at
their meeting next week.  I will post something on this mailing list
once I learn more about the progression of the spec.

Anders

-----Original Message-----
From: David R Oran [mailto:oran@cisco.com]=20
Sent: Friday, July 08, 2005 10:49 AM
To: Anders Klemets
Cc: Keith Lantz; IETF AVT WG
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]

Perhaps it would be wise for AVT to wait to discuss this draft until =20
the codec spec is publically avaible?

Any idea when this will happen?



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



From avt-bounces@ietf.org Fri Jul 08 19:40:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dr2S0-0001yR-LS; Fri, 08 Jul 2005 19:40:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dr2Ry-0001s1-2h; Fri, 08 Jul 2005 19:40:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17212;
	Fri, 8 Jul 2005 19:40:03 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dr2tQ-0002fZ-25; Fri, 08 Jul 2005 20:08:30 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73])
	(authenticated bits=0)
	by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id
	j68NdvBn015189
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Fri, 8 Jul 2005 16:39:58 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0D2BA9C7-09B9-4177-A45B-0D2ABD1FB81E@eecs.berkeley.edu>
Content-Transfer-Encoding: 7bit
From: lazzaro <lazzaro@eecs.berkeley.edu>
Date: Fri, 8 Jul 2005 16:40:32 -0700
To: mmusic@ietf.org, avt@ietf.org
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: Shigeru Aoki <shig@center.jfn.co.jp>
Subject: [AVT] Re: [MMUSIC] MMUSIC stage and studio requirements I-D ...
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


Shigeru Aoki" <shig at center.jfn.co.jp> writes:
> First of all, You should not include your matter into the AES-X074  
> since it has different intention from yours. Your requirements  
> draft should be proposed to the WG for the discussion in the WG. if  
> you would like to work for professional audio, you'd better propose  
> to the AES too.

I think it is premature.

MMUSIC first has to decide if it has interest in
the topic, and in particular, if it is open to
considering extensions to the transport protocols
over which it owns change control (RTSP and SDP)
to support requirements that this I-D may suggest.

I am expecting significant MMUSIC opposition to the
concept, given the changes some of the proposed
requirements would mandate (MMUSIC folk: read
the I-D for details).

However, If there is MMUSIC interest, then I think
its time to contact AES and the MMA and let
them know of the new IETF work starting.

It takes exceptional circumstances for the
IETF to open a standardization collaboration
with another body. A recent example is 3GPP:

http://www.3gpp.org/tb/Other/IETF.htm

Instead, the way the IETF would prefer to work
in this case is for individuals that participate in
the AES standards process to participate in
MMUSIC, and lend their expertise to the effort
in that way.  This is fair because the MMA and
SMPTE could also participate in the same way,
as MIDI and SMPTE video streams could also
be managed by a stage and studio RTSP.  Whereas
a 4-way standards collaboration would be hopeless.

And so, our initial AES contact would be an
invitation to join in our effort, with the hopes
that the AES would adopt our final documents
as standards without change.  If there was not
AES interest in working this way, my guess the
IETF would decide to drop the effort, and I would
hand off responsibility for RTP MIDI session
management protocols for stage and studio work
(which is my personal reason for proposing this
I-D) to the MMA and end my leadership role.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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



From avt-bounces@ietf.org Sat Jul 09 12:45:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DrIRx-0000Fx-29; Sat, 09 Jul 2005 12:45:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dquy5-0006yZ-43; Fri, 08 Jul 2005 11:40:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22295;
	Fri, 8 Jul 2005 11:40:42 -0400 (EDT)
Received: from bbcr.uwaterloo.ca ([129.97.34.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DqvPS-0001t5-Jn; Fri, 08 Jul 2005 12:09:05 -0400
Received: from Casablanca (casablanca.uwaterloo.ca [129.97.34.146])
	(authenticated bits=0)
	by bbcr.uwaterloo.ca (8.13.4/8.13.4) with ESMTP id j68Fe3lL003754;
	Fri, 8 Jul 2005 11:40:16 -0400 (EDT)
Message-Id: <200507081540.j68Fe3lL003754@bbcr.uwaterloo.ca>
From: "Youssef Iraqi" <iraqi@bbcr.uwaterloo.ca>
To: <iraqi@bbcr.uwaterloo.ca>
Date: Fri, 8 Jul 2005 11:39:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWD00xsCQDrUg4GRROXsu4ssWnD/A==
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
	milter-greylist-2.0 (bbcr.uwaterloo.ca [129.97.34.2]);
	Fri, 08 Jul 2005 11:40:19 -0400 (EDT)
X-Miltered: at aeacus with ID 42CE9E78.002 by Joe's j-chkmail
	(http://j-chkmail.ensmp.fr)!
X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on localhost
X-Virus-Status: Clean
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 09 Jul 2005 12:45:07 -0400
Cc: 
Subject: [AVT] CFP: IEEE HWN-RMQ'06
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

[Apologies if you receive multiple copies of this CFP,=20
but please forward to anyone you believe may be interested -- thanks!]

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CALL FOR =
PAPERS

=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=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
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 First IEEE International Workshop on
Heterogeneous Wireless Networks: Resource Management and QoS
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
(HWN-RMQ=9206)
http://www.ieee-ccnc.org/2006/conf_program/hwn-rmq_workshop/index.htm
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In conjunction =
with
IEEE Consumer Communications and Networking Conference (CCNC=9206)
=A0=A0=A0=A0=A0=A0=A0=A0 Las Vegas, Nevada, USA, 7-10 January 2006
=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=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

Scope

The fourth generation (4G) of wireless communications is expected to
integrate a potentially large number of different heterogeneous wireless
technologies in what could be considered a huge step forward towards
universal wireless access and omnipresent computing through seamless
mobility. Even though 4G standard is currently not defined, there are =
many
current outlooks that delineate the vision of the new wireless =
technologies.
Based on the emergent trends of mobile communication, 4G will have =
larger
bandwidth, higher data rates, smoother and quicker handoff and will =
focus on
guaranteeing faultless service and seamless handoff across a multitude =
of
wireless networks. The key concept is integrating the 4G capabilities =
with
all of the existing mobile technologies. Special maneuvers will be =
necessary
amongst different access systems in terms of horizontal (intra-system) =
and
vertical (inter-system) handoff as well as seamless mobility, Quality of
Service (QoS), dependability and security.

In this workshop, we solicit high quality papers from leading =
researchers
that present state-of-the-art research in heterogeneous wireless =
networks
dealing with resource management techniques and QoS provisioning.


Topics of Interest
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
Topics of interest include, but are not limited to:
- Interworking with 2.5G, 3G, and other wireless networks
- QoS provisioning for heterogeneous wireless networks
- End-to-End QoS Architectures
- Location, Mobility and Handoff Management
- Seamless vertical handoff techniques between different wireless =
networks
- Network selection criteria
- Resource management/allocation=20
- Bandwidth adaptation=20
- Power control and management=20
- Load, admission, and flow control=20
- Architecture design alternatives for heterogeneous wireless networks
- Performance analysis and experimentation of heterogeneous wireless
networks
- Pricing and billing issues
- Security techniques and methods for heterogeneous wireless networks=20
- Heterogeneous wireless networks applications and measurements
- Simulation study of heterogeneous wireless networks
- Scalability of heterogeneous wireless networks
- Implementation and testbed experiments
- Standardization activities for heterogeneous wireless networks
- Heterogeneous multi-hop wireless networks

Important Dates=20

- Paper =
submission:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 15 =
August=A0=A0=A0 2005
- Notification of acceptance: =A0=A0=A0=A0=A0=A0=A0 15 September 2005
- Final Paper submission: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 14 =
October=A0=A0 2005


Paper Submissions
=A0
Submitted papers must represent original material that is not currently
under review in any other conference or journal, and has not been =
previously
published. Paper length should not exceed five-page technical paper
manuscript. Please see author information page for submission guidelines =
at
CCNC=9206 website (http://www.ieee-ccnc.org). Papers should be submitted =
in a
.pdf format through EDAS at http://edas.info/Paper.cgi?c=3D4602. =
Submissions
should include a cover page with authors' names, affiliations, fax and
telephone numbers and e-mail addresses. All accepted papers will be
published in the conference proceedings. At least one author of accepted
papers is required to register at the full registration rate.


Workshop Co-Chairs:

- Name=A0=A0=A0=A0=A0=A0=A0Nidal =
Nasser=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0     Mieso Denko
- E-mail=A0=A0=A0=A0=A0nasser@cis.uoguelph.ca=A0=A0=A0     =
denko@cis.uoguelph.ca
- URL=A0=A0http://www.cis.uoguelph.ca/~nasser=A0 =
http://www.cis.uoguelph.ca/~denko
- Affiliation=A0=A0=A0University of Guelph, Guelph, Canada


Publicity Chair:
Youssef Iraqi=20
University of Waterloo, Canada
iraqi@bbcr.uwaterloo.ca=20
http://bcr2.uwaterloo.ca/~iraqi/=20

Technical Program Committee (In progress)

- Khalid Al-Begain=A0=A0=A0=A0=A0 University of =
Glamorgan=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  UK
- Hakim Badis=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 University of Paris-Sud =
XI=A0=A0=A0=A0=A0=A0=A0=A0=A0  France=20
- Tarek Bejaoui=A0=A0=A0=A0=A0=A0=A0=A0 University of Paris-Sud =
XI=A0=A0=A0=A0=A0=A0=A0=A0=A0  France=20
- Jiannong Cao=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hong Kong Polytechnic =
University=A0=A0=A0  Hong Kong
- Soumaya Cherkaoui=A0=A0=A0=A0 University of Sherbrooke =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  Canada=20
- Yuh-Shyan Chen=A0=A0=A0=A0=A0=A0=A0 National Chung Cheng University =
=A0=A0=A0  Taiwan=20
- Javier Gozalvez=A0=A0=A0=A0=A0=A0 University Miguel =
Hernandez=A0=A0=A0=A0=A0=A0=A0=A0  Spain
- Christian Hartmann=A0=A0=A0 Technische Universitat =
Munchen=A0=A0=A0=A0=A0  Germany=20
- Youssef Iraqi=A0=A0=A0=A0=A0=A0=A0=A0 University of Waterloo =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  Canada=20
- Anup Kumar=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 University of Louisville =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  USA=20
- Wei Li=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The University of =
Toledo=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  USA=20
- Jelena Misic=A0=A0=A0=A0=A0=A0=A0=A0=A0 University of Manitoba =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  Canada=20
- Mohamed Ould-Khaoua=A0  University of Glasgow =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  UK=20
- Burkhard Stiller=A0 =A0=A0=A0 University of Zurich and ETH Zurich=A0 =
Switzerland=20
- Abd-Elhamid M. Taha=A0=A0 Queen's =
University=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Canada=20
- Ljiljana Trajkovic =A0=A0 Simon Fraser University =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Canada=20
- Duc A. Tran=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 University of Dayton =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 USA=20
- Shahrokh Valaee =A0=A0=A0=A0=A0 University of =
Toronto=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Canada
- Quanhong Wang=A0=A0=A0=A0=A0=A0=A0=A0 Queen's =
University=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0  Canada=20
- Kui Wu=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 University of =
Victoria =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Canada=20
- Jingyuan Zhang=A0=A0=A0=A0=A0=A0=A0 The University of =
Alabama=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 USA=20
- Weihua Zhuang=A0=A0=A0=A0=A0=A0=A0=A0 University of Waterloo =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Canada=20











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



From avt-bounces@ietf.org Sun Jul 10 06:18:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DrYtN-0007uj-C0; Sun, 10 Jul 2005 06:18:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DrYlJ-00051F-Ie; Sun, 10 Jul 2005 06:10:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21480;
	Sun, 10 Jul 2005 06:10:10 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DrZD4-0000YD-Ol; Sun, 10 Jul 2005 06:38:56 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61876
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DrYl2-0000hV-Q3; Sun, 10 Jul 2005 11:09:56 +0100
In-Reply-To: <17102.34892.865008.753397@cnr.cs.columbia.edu>
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU>
	<D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu>
	<17101.30921.48827.630095@cnr.cs.columbia.edu>
	<42CE2749.70907@ericsson.com>
	<17102.34892.865008.753397@cnr.cs.columbia.edu>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <580534F1-F812-4A7D-BBDA-4AA7B900C34B@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over TLS
	submitted.Ready for WGLC?
Date: Sun, 10 Jul 2005 11:09:52 +0100
To: Jonathan Lennox <lennox@cs.columbia.edu>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 10 Jul 2005 06:18:31 -0400
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>,
	IETF MMUSIC working group <mmusic@ietf.org>,
	lazzaro Lazzaro <lazzaro@eecs.berkeley.edu>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

[avt list bcc'd -- discussion on mmusic]

On 8 Jul 2005, at 15:06, Jonathan Lennox wrote:
> On Friday, July 8 2005, "Magnus Westerlund" wrote:
>> Can you please remind where and when the decision was taken to not
>> define TCP/TLS/RTP/AVP? All I find is some loose discussion without
>> conclusion about the topic, but nothing I can interpret as an WG
>> consensus on this.
>
> It was at the MMusic meeting in San Diego (August 2004), following my
> initial presentation of comedia-tls.  Here's the relevant paragraph  
> from the
> minutes:
>
>     An open issue is that this defines only TCP/TLS, not TCP/TLS/ 
> RTP/AVP.
>     Similarly, nothing defines TCP/RTP/SAVP. What should be the  
> preferred
>     way of doing secure connection-oriented RTP? Steve Casner  
> suggested
>     that it might be appropriate to wait until there is a use case for
>     SRTP over connection oriented media, rather than trying to  
> specify it
>     now.
>
> As I recall, Steve's comment got a rough nodding of heads.  So I  
> wouldn't
> say that a decision was explicitly taken not to define this, so  
> much as that
> no decision was taken *to* define it.
>
>> I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF.
>
> TCP/TLS/RTP/AVP, yes.  I'm not sure what the use-case is for
> TCP/TLS/RTP/AVPF -- I thought most of the motivation for AVPF was for
> bandwidth adaptation and improved delivery reliablity, both of  
> which seem to
> be redundant for something transmitted over TCP.

As an additional factor in the discussion, I note that the comedia- 
tls draft is normatively referenced by the MRCPv2 spec, which is  
nearing completion. I don't want to prevent useful additions to the  
comedia-tls draft, but we shouldn't add features with only  
theoretical usefulness if doing so will significantly delay a draft  
with present needs.

Colin


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



From avt-bounces@ietf.org Sun Jul 10 06:33:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DrZ8H-0003Yn-Pp; Sun, 10 Jul 2005 06:33:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DrZ8G-0003Wb-FX
	for avt@megatron.ietf.org; Sun, 10 Jul 2005 06:33:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22195
	for <avt@ietf.org>; Sun, 10 Jul 2005 06:33:53 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrZa3-0001FM-0l
	for avt@ietf.org; Sun, 10 Jul 2005 07:02:39 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61921
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DrZ87-0001yO-6L; Sun, 10 Jul 2005 11:33:47 +0100
In-Reply-To: <9ED672B9D1A64C489291BE0FB822217D0B24D1A6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <9ED672B9D1A64C489291BE0FB822217D0B24D1A6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FE645C36-9535-47EE-A947-FE214FEBE606@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Sun, 10 Jul 2005 11:33:42 +0100
To: Anders Klemets <anderskl@windows.microsoft.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Anders, Dave,

This is an individual draft at present, so I don't see a problem.  
However, the working group would need access to the specification (or  
to sufficient details for us to conduct a meaningful review) before  
accepting this as a work item.

In any case, I'd certainly encourage SMPTE to make the details of the  
codec available for review before its definition is made final, in  
case there are unexpected features that make transport of the codec  
in RTP difficult.

Colin



On 8 Jul 2005, at 21:38, Anders Klemets wrote:
> If memory serves me right, AVT began considering RTP payload  
> formats for
> AVC and MPEG-4 before those specs were publicly available, so there is
> precedence for this.
>
> I can't say for sure when SMPTE 421M will be published, but the spec
> needs to reach Draft Standard status first.  If I understand things
> correctly, once a spec reaches Draft Standard status, they only allow
> editorial changes, and specs are then approved for publication in
> relatively short order.
>
> I think it is possible that SMPTE C24 will decide to have a ballot  
> about
> whether or not to elevate the VC-1 spec to Draft Standard status, at
> their meeting next week.  I will post something on this mailing list
> once I learn more about the progression of the spec.
>
> Anders
>
> -----Original Message-----
> From: David R Oran [mailto:oran@cisco.com]
> Sent: Friday, July 08, 2005 10:49 AM
> To: Anders Klemets
> Cc: Keith Lantz; IETF AVT WG
> Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
>
> Perhaps it would be wise for AVT to wait to discuss this draft until
> the codec spec is publically avaible?
>
> Any idea when this will happen?
>
>
>
> _______________________________________________
> 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 avt-bounces@ietf.org Sun Jul 10 07:47:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DraHX-0004lO-Qf; Sun, 10 Jul 2005 07:47:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DraHW-0004lJ-MK
	for avt@megatron.ietf.org; Sun, 10 Jul 2005 07:47:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25801
	for <avt@ietf.org>; Sun, 10 Jul 2005 07:47:33 -0400 (EDT)
Received: from mout01.kundenservices.net ([81.169.163.77])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrajJ-0003tW-Bz
	for avt@ietf.org; Sun, 10 Jul 2005 08:16:17 -0400
Received: from smtp20.kundenservices.net ([81.169.163.79])
	by mout01.kundenservices.net with esmtp (Exim 4.41)
	id 1DraHH-0003yp-F8; Sun, 10 Jul 2005 13:47:19 +0200
Received: from stewe.org ([81.169.171.175] helo=gurke)
	by smtp20.kundenservices.net with esmtpa (Exim 4.44)
	id 1DraHH-0004ph-6F; Sun, 10 Jul 2005 13:47:19 +0200
From: "Stephan Wenger" <stewe@stewe.org>
To: "'Anders Klemets'" <anderskl@windows.microsoft.com>,
	"'IETF AVT WG'" <avt@ietf.org>
Subject: RE: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Sun, 10 Jul 2005 14:47:05 +0300
Message-ID: <000301c58545$18a9dc70$1a01a8c0@gurke>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <9ED672B9D1A64C489291BE0FB822217D0B24D1A6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Anders,
Minor correction: at least the H.264/AVC working drafts were publicly
available from even before the forming of JVT.=20
Regards,
Stephan

-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of =
Anders
Klemets
Sent: Freitag, 8. Juli 2005 23:39
To: IETF AVT WG
Subject: RE: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]

If memory serves me right, AVT began considering RTP payload formats for
AVC and MPEG-4 before those specs were publicly available, so there is
precedence for this.

I can't say for sure when SMPTE 421M will be published, but the spec
needs to reach Draft Standard status first.  If I understand things
correctly, once a spec reaches Draft Standard status, they only allow
editorial changes, and specs are then approved for publication in
relatively short order.

I think it is possible that SMPTE C24 will decide to have a ballot about
whether or not to elevate the VC-1 spec to Draft Standard status, at
their meeting next week.  I will post something on this mailing list
once I learn more about the progression of the spec.

Anders

-----Original Message-----
From: David R Oran [mailto:oran@cisco.com]=20
Sent: Friday, July 08, 2005 10:49 AM
To: Anders Klemets
Cc: Keith Lantz; IETF AVT WG
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]

Perhaps it would be wise for AVT to wait to discuss this draft until =20
the codec spec is publically avaible?

Any idea when this will happen?



_______________________________________________
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 avt-bounces@ietf.org Sun Jul 10 07:57:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DraQi-0007Dr-8H; Sun, 10 Jul 2005 07:57:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DraQg-0007Az-Lw
	for avt@megatron.ietf.org; Sun, 10 Jul 2005 07:57:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26111
	for <avt@ietf.org>; Sun, 10 Jul 2005 07:57:01 -0400 (EDT)
Received: from relay1.mail.vrmd.de ([81.28.232.18])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrasS-0004A7-RG
	for avt@ietf.org; Sun, 10 Jul 2005 08:25:46 -0400
Received: from [87.78.9.184] (helo=[192.168.1.23])
	by vm8.bln2.vrmd.de with asmtp (Exim 4.41) id 1DraQD-0003Sa-Ol
	for avt@ietf.org; Sun, 10 Jul 2005 13:56:34 +0200
Mime-Version: 1.0 (Apple Message framework v730)
References: <000301c58545$18a9dc70$1a01a8c0@gurke>
X-Priority: 3 (Normal)
Message-Id: <36174852-EA01-451D-882B-33860BB83052@let.de>
From: Marc Manthey <marc@let.de>
Subject: Fwd: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Sun, 10 Jul 2005 13:56:38 +0200
To: IETF AVT WG <avt@ietf.org>
X-Mailer: Apple Mail (2.730)
X-Relay-User: marc@let.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0709854148=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


--===============0709854148==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-955479694;
	protocol="application/pkcs7-signature"


--Apple-Mail-9-955479694
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Begin forwarded message:
> I will post something on this mailing list
> once I learn more about the progression of the spec.

good  idea,

have agreat day

marc
-- 
"In a world without walls or fences, who needs Windows and Gates?"
  www.let.de     www.cuseeme.de          www.applehelpers.com





--Apple-Mail-9-955479694
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHHzCCA0kw
ggKyoAMCAQICDgpqAAEAAntSGyw2RRVxMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQ
MA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50
ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIu
ZGUwHhcNMDUwNTA5MTQzMjQ4WhcNMDYwNTA5MTQzMjQ4WjBAMQswCQYDVQQGEwJERTEVMBMGA1UE
AxMMTWFyYyBNYW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAvwCjxxISYuhol4fmTuqlvYN3JOLxcceKV3T8OzmBqQVkbKvmkqh+d5ue
O+Dz4ZD9sYKbvbAcQmfLqra94of91kM20oPlAalNcSNe8HUEDEVb4GHdqPVwmaVK9jJ5BUPDMheq
W5TR5X/ATEfQU7oCZSI/7+h9Ww3anbUXIZeCCOMCAwEAAaOByDCBxTAMBgNVHRMBAf8EAjAAMA4G
A1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9n
dWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cu
dHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzBBNkEwMDAxMDAwMjdCNTIxQjJD
MzY0NTE1NzE/MA0GCSqGSIb3DQEBBAUAA4GBAE94N6LMW8iv8HvV9RC77acqqCw4JyLYB6pcgTK9
bpEYxkdggTJRUnCMzz8TOOzVvfA2mzEmwoKDnMYUFugAxdLbFPuxsw4aJ9vMZPdppz28nBDdx1jt
lmoJvm3fogTLCGfhWyrd68/tqneYNf540iiXPkp9bwVs8qvQFyEUa8Y8MIIDzjCCAzegAwIBAgIP
AJn2AAAAAtbxQYHMGpdhMA0GCSqGSIb3DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMH
SGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl
Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xh
c3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDUw
MjA0MTY0ODQ3WhcNMDYwMjA0MTY0ODQ3WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEAxMMTWFyYyBN
YW50aGV5MRowGAYJKoZIhvcNAQkBFgttYXJjQGxldC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBANL2cTdJD0oNKje7z4466yUIRX8DJbmjCZBMLtnmHiEqMrpK2rQps8Gcmp3ueB+d
o7lGwU7YH3m676a5XhyvcaYwmu1C2gLfBiOzbijbZLP95vP0Aowf9HyuO6iTS42el73q+6MKCY8h
O1px1R1blj9cxFeGfFXiG8Oz2QOi7sfJHB+Vp9WVU8ZI1I8NibF/wAN8HzZSdbKkEArGarBCYZ8J
Em9C7UZpxc3fx61PePP/z5j4GeQVt+iI5FzBMlg0T7W5X16D0yQuLQb2ajeYJhstFC0KrbO+v9eV
WnOsXzOYo+PkPH4O6tOKyX14GFITKYWTwyU6It03XrO/lAvn80kCAwEAAaOByDCBxTAMBgNVHRMB
Af8EAjAAMA4GA1UdDwEB/wQEAwIF4DAzBglghkgBhvhCAQgEJhYkaHR0cDovL3d3dy50cnVzdGNl
bnRlci5kZS9ndWlkZWxpbmVzMBEGCWCGSAGG+EIBAQQEAwIFoDBdBglghkgBhvhCAQMEUBZOaHR0
cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dpLzk5RjYwMDAwMDAw
MkQ2RjE0MTgxQ0MxQTk3NjE/MA0GCSqGSIb3DQEBBAUAA4GBAF3ZoITTnsH5RDnrDWReZJPv9WUF
yGPjjKIUHQlGeEg+JY4T5b8SrHJGkyxyoc2dj3E5G7iJ173mz5IK42YizLRNCcw3gZcSJQl8SqiL
L7VN/xdOZfbZKFhDStraQXghJ9tvoD5CNzFKblW71W0iv2f1R7GPwR+lKB9S5ZejZj+CMYIDoTCC
A50CAQEwgc8wgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1i
dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3Jr
cyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJKoZIhvcNAQkB
FhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZQIOCmoAAQACe1IbLDZFFXEwCQYFKw4DAhoFAKCC
AicwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzEwMTE1NjQw
WjAjBgkqhkiG9w0BCQQxFgQUpwyLUo4kVw2Xc5InXBBEhjZuUMMwgeEGCSsGAQQBgjcQBDGB0zCB
0DCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxOjA4
BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgx
IjAgBgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp
ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AmfYAAAAC1vFBgcwal2EwgeMGCyqGSIb3DQEJEAILMYHT
oIHQMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6
MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i
SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2Vy
dGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUCDwCZ9gAAAALW8UGBzBqXYTANBgkqhkiG9w0BAQEFAASB
gGSnFB6WzHKhBCC8s33vSwVWztximUDQajj7z4QbbNULHfIPNcm1pock3PejjGk1iFkrDAB8wRAB
ntDME7/DX1zTHYEqsGXvxiohHTExkFTrKS7F8y9PK4PDRNW8HvFmcPonm9jL07vh9GBJyPmKpdjO
xbgZotbiE9CtKkIERLV5AAAAAAAA

--Apple-Mail-9-955479694--


--===============0709854148==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0709854148==--




From avt-bounces@ietf.org Sun Jul 10 15:30:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DrhVv-0005Dm-U7; Sun, 10 Jul 2005 15:30:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DrhVu-0005Dd-0K
	for avt@megatron.ietf.org; Sun, 10 Jul 2005 15:30:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20369
	for <avt@ietf.org>; Sun, 10 Jul 2005 15:30:52 -0400 (EDT)
Received: from mail3.microsoft.com ([131.107.3.123])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drhxl-000351-0M
	for avt@ietf.org; Sun, 10 Jul 2005 15:59:41 -0400
Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 10 Jul 2005 12:30:41 -0700
Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by
	mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 10 Jul 2005 12:30:41 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com
	([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jul 2005 12:30:40 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com
	([157.54.12.88]) by
	win-imc-02.wingroup.windeploy.ntdev.microsoft.com with
	Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jul 2005 12:30:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Sun, 10 Jul 2005 12:30:39 -0700
Message-ID: <9ED672B9D1A64C489291BE0FB822217D0B24D689@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
thread-index: AcWFOvMl/uxF14NMTHyRicHkW7hfMAAQfcxg
From: "Anders Klemets" <anderskl@windows.microsoft.com>
To: "Colin Perkins" <csp@csperkins.org>
X-OriginalArrivalTime: 10 Jul 2005 19:30:41.0062 (UTC)
	FILETIME=[DB8E7C60:01C58585]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: quoted-printable
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Could clarify what the rules are, since my intent is obviously to make
this an official AVT work item? =20

I think I have included plenty of information about VC-1 in the
Internet-Draft to explain why I made certain choices the design of the
RTP payload format.  In fact, more information than you will find in
many other RTP payload format specs.

My intent was to include enough information that someone who does not
have any prior knowledge of VC-1 can read the Internet-Draft and conduct
a meaningful review.

For those who still want to study the VC-1 spec anyway, they can get
access to the latest version by joining SMPTE C24.  Unlike, for example,
the ISO MPEG-4 committee, SMPTE allows individual membership.  I think
the fee is around $135, which is significantly cheaper than the fee
charged by IETF for attending only a single meeting.

Compare this against other RTP payload formats that are currently AVT
work items, such as ATRAC.  Check out the references section of the
ATRAC Internet-Draft.  I see no reference, normative or otherwise, to
the ATRAC spec.  The only mention of how to obtain the spec, that I am
able to find, is a sentence that says that the use of ATRAC requires a
license from the vendor.

If that is the minimal documentation standard that AVT RTP payload
format specs are expected to meet, I think you will find that the VC-1
RTP payload format spec not only meets it, but also exceeds it.

I think that at this point, I think it would be more productive if
people who are interested in reviewing the VC-1 Internet Draft would
start doing so, and send me feedback.  If something is unclear, I should
be able to add additional clarifying text. =20

Technical comments are of course welcome too.  I will try to summarize
all of them in my slides for the Paris AVT meeting, and incorporate
agreed upon changes after the meeting.

Thanks,

Anders

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]=20
Sent: Sunday, July 10, 2005 3:34 AM
To: Anders Klemets
Cc: IETF AVT WG
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]

Anders, Dave,

This is an individual draft at present, so I don't see a problem. =20
However, the working group would need access to the specification (or =20
to sufficient details for us to conduct a meaningful review) before =20
accepting this as a work item.

In any case, I'd certainly encourage SMPTE to make the details of the =20
codec available for review before its definition is made final, in =20
case there are unexpected features that make transport of the codec =20
in RTP difficult.

Colin


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



From avt-bounces@ietf.org Sun Jul 10 16:39:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Driae-0002r5-Ox; Sun, 10 Jul 2005 16:39:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Driab-0002r0-RM
	for avt@megatron.ietf.org; Sun, 10 Jul 2005 16:39:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23484
	for <avt@ietf.org>; Sun, 10 Jul 2005 16:39:47 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drj2T-0005VJ-FP
	for avt@ietf.org; Sun, 10 Jul 2005 17:08:37 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63689
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DriaR-0001ED-Qu; Sun, 10 Jul 2005 21:39:40 +0100
In-Reply-To: <9ED672B9D1A64C489291BE0FB822217D0B24D689@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: <9ED672B9D1A64C489291BE0FB822217D0B24D689@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <265C0001-A003-455A-869A-48B5CE4E2BCA@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
Date: Sun, 10 Jul 2005 21:39:35 +0100
To: "Anders Klemets" <anderskl@windows.microsoft.com>
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Anders,

As I mentioned, the working group would need access to the  
specification (or
to sufficient details for us to conduct a meaningful review).  I  
haven't had chance to review the draft in detail yet, so I can't  
comment on whether this condition is fulfilled, but from what you say  
below it sounds like it may be. Certainly we have produced RTP  
payload formats for SMPTE defined formats in the past, so I don't  
forsee a problem once the specification is published.

In any case, none of this affects the present review of the draft,  
since it's currently an individual submission.

Colin



On 10 Jul 2005, at 20:30, Anders Klemets wrote:
> Could clarify what the rules are, since my intent is obviously to make
> this an official AVT work item?
>
> I think I have included plenty of information about VC-1 in the
> Internet-Draft to explain why I made certain choices the design of the
> RTP payload format.  In fact, more information than you will find in
> many other RTP payload format specs.
>
> My intent was to include enough information that someone who does not
> have any prior knowledge of VC-1 can read the Internet-Draft and  
> conduct
> a meaningful review.
>
> For those who still want to study the VC-1 spec anyway, they can get
> access to the latest version by joining SMPTE C24.  Unlike, for  
> example,
> the ISO MPEG-4 committee, SMPTE allows individual membership.  I think
> the fee is around $135, which is significantly cheaper than the fee
> charged by IETF for attending only a single meeting.
>
> Compare this against other RTP payload formats that are currently AVT
> work items, such as ATRAC.  Check out the references section of the
> ATRAC Internet-Draft.  I see no reference, normative or otherwise, to
> the ATRAC spec.  The only mention of how to obtain the spec, that I am
> able to find, is a sentence that says that the use of ATRAC requires a
> license from the vendor.
>
> If that is the minimal documentation standard that AVT RTP payload
> format specs are expected to meet, I think you will find that the VC-1
> RTP payload format spec not only meets it, but also exceeds it.
>
> I think that at this point, I think it would be more productive if
> people who are interested in reviewing the VC-1 Internet Draft would
> start doing so, and send me feedback.  If something is unclear, I  
> should
> be able to add additional clarifying text.
>
> Technical comments are of course welcome too.  I will try to summarize
> all of them in my slides for the Paris AVT meeting, and incorporate
> agreed upon changes after the meeting.
>
> Thanks,
>
> Anders
>
> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Sunday, July 10, 2005 3:34 AM
> To: Anders Klemets
> Cc: IETF AVT WG
> Subject: Re: [AVT] [Fwd: I-D ACTION:draft-klemets-avt-rtp-vc1-00.txt]
>
> Anders, Dave,
>
> This is an individual draft at present, so I don't see a problem.
> However, the working group would need access to the specification (or
> to sufficient details for us to conduct a meaningful review) before
> accepting this as a work item.
>
> In any case, I'd certainly encourage SMPTE to make the details of the
> codec available for review before its definition is made final, in
> case there are unexpected features that make transport of the codec
> in RTP difficult.
>
> Colin
>
>


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



From avt-bounces@ietf.org Mon Jul 11 04:57:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dru6u-0004NQ-0x; Mon, 11 Jul 2005 04:57:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DrcUa-0007NO-I8; Sun, 10 Jul 2005 10:09:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03519;
	Sun, 10 Jul 2005 10:09:08 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DrcwJ-0000UJ-Hn; Sun, 10 Jul 2005 10:37:54 -0400
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6AE8isw019090
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 10 Jul 2005 10:08:45 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1])
	by cnr.cs.columbia.edu (8.13.3/8.13.3) with ESMTP id j6AE8iLB053444;
	Sun, 10 Jul 2005 10:08:44 -0400 (EDT)
	(envelope-from lennox@cnr.cs.columbia.edu)
Received: (from lennox@localhost)
	by cnr.cs.columbia.edu (8.13.3/8.13.3/Submit) id j6AE8ea8053441;
	Sun, 10 Jul 2005 10:08:40 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17105.11240.703298.801389@cnr.cs.columbia.edu>
Date: Sun, 10 Jul 2005 10:08:40 -0400
To: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over TLS
	submitted.Ready for WGLC?
In-Reply-To: <580534F1-F812-4A7D-BBDA-4AA7B900C34B@csperkins.org>
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU>
	<D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu>
	<17101.30921.48827.630095@cnr.cs.columbia.edu>
	<42CE2749.70907@ericsson.com>
	<17102.34892.865008.753397@cnr.cs.columbia.edu>
	<580534F1-F812-4A7D-BBDA-4AA7B900C34B@csperkins.org>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0,
	__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 11 Jul 2005 04:57:54 -0400
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>,
	IETF MMUSIC working group <mmusic@ietf.org>,
	lazzaro Lazzaro <lazzaro@eecs.berkeley.edu>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On Sunday, July 10 2005, "Colin Perkins" wrote to "Jonathan Lennox, Magnus Westerlund, IETF MMUSIC working group, lazzaro Lazzaro" saying:

> [avt list bcc'd -- discussion on mmusic]

(And again, since I'm discussing a draft that would presumably be handled in
avt.)

> As an additional factor in the discussion, I note that the comedia- 
> tls draft is normatively referenced by the MRCPv2 spec, which is  
> nearing completion. I don't want to prevent useful additions to the  
> comedia-tls draft, but we shouldn't add features with only  
> theoretical usefulness if doing so will significantly delay a draft  
> with present needs.

Oh, yes, definitely -- a definition of 'TCP/TLS/RTP/AVP' should be in a
separate draft from 'TCP/TLS', just as 'TCP/RTP/AVP' is separate from
'TCP'.

I imagine that AVT would probably be a better home for this latter draft,
since a) it's extending draft-ietf-avt-rtp-framing-contrans, and b) it's in
the avt charter.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

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



From avt-bounces@ietf.org Mon Jul 11 05:45:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Druqq-0005IJ-Ci; Mon, 11 Jul 2005 05:45:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Druqp-0005IB-6T; Mon, 11 Jul 2005 05:45:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25710;
	Mon, 11 Jul 2005 05:45:20 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DrvIn-0006L7-JR; Mon, 11 Jul 2005 06:14:18 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 41A0C1247;
	Mon, 11 Jul 2005 11:45:19 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 11 Jul 2005 11:45:18 +0200
Received: from [147.214.34.34] ([147.214.34.34]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 11 Jul 2005 11:45:18 +0200
Message-ID: <42D23FAD.1080103@ericsson.com>
Date: Mon, 11 Jul 2005 11:45:17 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
Subject: Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over
	TLSsubmitted.Ready for WGLC?
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU><D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu><17101.30921.48827.630095@cnr.cs.columbia.edu><42CE2749.70907@ericsson.com>
	<17102.34892.865008.753397@cnr.cs.columbia.edu>
In-Reply-To: <17102.34892.865008.753397@cnr.cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jul 2005 09:45:18.0175 (UTC)
	FILETIME=[3F18FEF0:01C585FD]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: 7bit
Cc: lazzaro <lazzaro@eecs.berkeley.edu>, mmusic@ietf.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Jonathan Lennox wrote:
> 
>>I am in favor of defining both TCP/TLS/RTP/AVP and TCP/TLS/RTP/AVPF.
> 
> 
> TCP/TLS/RTP/AVP, yes.  I'm not sure what the use-case is for
> TCP/TLS/RTP/AVPF -- I thought most of the motivation for AVPF was for
> bandwidth adaptation and improved delivery reliablity, both of which seem to
> be redundant for something transmitted over TCP.

There are definitely motivation why also AVPF should be included. First 
of all AVPF provides a generic mechanism that can be used for sending 
feedback messages. In certain cases these feedback messages have nothing 
to do with either delivery reliability or bandwidth adaptation. This 
will definitely become evident when the new draft 
(draft-wenger-avt-avpf-ccm-00.txt) on codec commands becomes available. 
This draft contains feedback that are related to usage of video mixers 
(MCUs) as an example.

The other motivation are these use cases that contains mixers or media 
focus performing replication to form a multiparty conference. There 
several independent unicast connection are connected. In these scenario 
it is not unlikely that some could use TCP/TLS while others uses UDP. 
Thus the need to have the same profile but with different transports.

> 
> 
>>I would also consider if TCP/TLS/RTP/SAVP is a good idea or not. I would
>>consider TCP/TLS/RTP/SAVP a possibility in cases that requires a secure
>>TCP/TLS connection, for example due to end point authentication, which
>>however is a gateway to an SRTP session. If that is relevant or not is
>>another matter.
> 
> 
> I'm dubious about sending Secure RTP over TLS -- I think it would need to be
> pretty strongly motivated with real use-cases.

Again I think the motivation are gateways or other type of bridging 
between different transport formats while still there is a need to use 
the same profile in both transport domains.

However it might be that for this use case TCP/RTP/SAVP is more useful. 
Including TLS would only provide end-point authentication.

> 
> For both these cases, their motivations are significantly stronger if you're
> envisioning implementing a UDP<->TCP<->UDP tunnel scenario.  Is that what
> you're thinking of?

Yes, but primarily the case of mixer translators between a UDP domain 
and some users connected using TCP.

> 
>>As I see it TCP/RTP/SAVP and TCP/TLS/RTP/AVP have somewhat different 
>>security properties. TLS provides a secured transport channel with 
>>possibility to end-point authentication. The SRTP based solution 
>>provides instead group security and can be done without a trusted 
>>gateway. So they definitely are applicable in different use cases.
> 
> 
> I'm not sure what you mean by a "trusted gateway", and I'm not sure how
> useful group security is for a point-to-point connection-oriented protocol,
> again unless you're envisioning tunneling.
> 

IF you are having a UDP multicast session and you like to connect but 
can only use TCP then you need a translator. That translator will be 
required to be trusted if it is going to perform the following operation:
IP/UDP/RTP/SAVP -> IP/TCP/TLS/AVP
In addition to be trusted to receive, decrypt and handle the media it 
must also be trusted to correctly authenticate the end-point connecting 
over TLS.

If you instead performed a TCP encapsulation operation the translator 
could be untrusted.

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 avt-bounces@ietf.org Mon Jul 11 08:03:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Drx0Q-00082y-No; Mon, 11 Jul 2005 08:03:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Drwry-00067i-0A; Mon, 11 Jul 2005 07:54:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03420;
	Mon, 11 Jul 2005 07:54:40 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DrxJw-0003Ek-Fr; Mon, 11 Jul 2005 08:23:38 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0314516C6;
	Mon, 11 Jul 2005 13:54:28 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 11 Jul 2005 13:54:27 +0200
Received: from [147.214.34.34] ([147.214.34.34]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 11 Jul 2005 13:54:27 +0200
Message-ID: <42D25DF3.1000904@ericsson.com>
Date: Mon, 11 Jul 2005 13:54:27 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
Subject: Re: [AVT] Re: [MMUSIC] RE: Draft -04 of Comedia over
	TLSsubmitted.Ready for WGLC?
References: <20050707160632.05BB8693M1@mxtreme1.EECS.Berkeley.EDU><D64BDA5A-D7C6-4A24-AAC3-CF4D58C9D5CE@eecs.berkeley.edu><17101.30921.48827.630095@cnr.cs.columbia.edu><42CE2749.70907@ericsson.com><17102.34892.865008.753397@cnr.cs.columbia.edu><580534F1-F812-4A7D-BBDA-4AA7B900C34B@csperkins.org>
	<17105.11240.703298.801389@cnr.cs.columbia.edu>
In-Reply-To: <17105.11240.703298.801389@cnr.cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jul 2005 11:54:27.0828 (UTC)
	FILETIME=[4A403340:01C5860F]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 11 Jul 2005 08:03:25 -0400
Cc: lazzaro Lazzaro <lazzaro@eecs.berkeley.edu>,
	Colin Perkins <csp@csperkins.org>,
	IETF MMUSIC working group <mmusic@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

Yes, we shouldn't create undue delays for other specifications. However 
we shouldn't create unnecissarily many drafts either. However it might 
be best if someone could write a new draft on registering the RTP 
related ones.

TCP/RTP/AVPF
TCP/RTP/SAVP
TCP/RTP/SAVPF
TCP/TLS/RTP/AVP
TCP/TLS/RTP/AVPF

I think all of these should be useful. I will not press my case when it 
comes to TCP/TLS/RTP/SAVP(F).

cheers

Magnus


Jonathan Lennox wrote:
> On Sunday, July 10 2005, "Colin Perkins" wrote to "Jonathan Lennox, Magnus Westerlund, IETF MMUSIC working group, lazzaro Lazzaro" saying:
> 
> 
>>[avt list bcc'd -- discussion on mmusic]
> 
> 
> (And again, since I'm discussing a draft that would presumably be handled in
> avt.)
> 
> 
>>As an additional factor in the discussion, I note that the comedia- 
>>tls draft is normatively referenced by the MRCPv2 spec, which is  
>>nearing completion. I don't want to prevent useful additions to the  
>>comedia-tls draft, but we shouldn't add features with only  
>>theoretical usefulness if doing so will significantly delay a draft  
>>with present needs.
> 
> 
> Oh, yes, definitely -- a definition of 'TCP/TLS/RTP/AVP' should be in a
> separate draft from 'TCP/TLS', just as 'TCP/RTP/AVP' is separate from
> 'TCP'.
> 
> I imagine that AVT would probably be a better home for this latter draft,
> since a) it's extending draft-ietf-avt-rtp-framing-contrans, and b) it's in
> the avt charter.
> 


-- 

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 avt-bounces@ietf.org Mon Jul 11 15:50:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ds4IK-000647-Bd; Mon, 11 Jul 2005 15:50:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ds4I0-0005td-Dl; Mon, 11 Jul 2005 15:50:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15609;
	Mon, 11 Jul 2005 15:50:02 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Ds4k2-0006Sc-JZ; Mon, 11 Jul 2005 16:19:03 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1Ds4Hx-0001R7-K8; Mon, 11 Jul 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Ds4Hx-0001R7-K8@newodin.ietf.org>
Date: Mon, 11 Jul 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2833bisdata-02.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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		: Definition of Events For Modem, FAX, and Text
                          Telephony Signals
	Author(s)	: H. Schulzrinne, et al.
	Filename	: draft-ietf-avt-rfc2833bisdata-02.txt
	Pages		: 46
	Date		: 2005-7-11
	
This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-09)
   to add event codes for modem, FAX, and text telephony signals when
   carried in the telephony event RTP payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisdata-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rfc2833bisdata-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-rfc2833bisdata-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: <2005-7-11105712.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rfc2833bisdata-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rfc2833bisdata-02.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-11105712.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Tue Jul 12 19:52:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DsUYE-0007qT-1R; Tue, 12 Jul 2005 19:52:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUYC-0007qJ-HP
	for avt@megatron.ietf.org; Tue, 12 Jul 2005 19:52:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08880
	for <avt@ietf.org>; Tue, 12 Jul 2005 19:52:29 -0400 (EDT)
Received: from carrierpigeon.cs.umd.edu ([128.8.129.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsV0V-0004uG-6c
	for avt@ietf.org; Tue, 12 Jul 2005 20:21:47 -0400
Received: from MINDLAP2 (bay2-13.dial.umd.edu [128.8.22.77])
	(authenticated bits=0)
	by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id
	j6CNpufJ024546
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <avt@ietf.org>; Tue, 12 Jul 2005 19:52:20 -0400 (EDT)
Message-Id: <200507122352.j6CNpufJ024546@carrierpigeon.cs.umd.edu>
From: "Moustafa Youssef" <moustafa@cs.umd.edu>
To: <avt@ietf.org>
Date: Tue, 12 Jul 2005 19:51:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] 2nd CFP: 2nd IEEE Workshop on Dependability and Security in
	Sensor Networks and Systems
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                   Second Call for Papers
       Second IEEE Workshop on Dependability and Security in
                    Sensor Networks and Systems
                            (DSSNS'2006)
                        http://www.dssns.org
                        In conjunction with
              2nd NASA/IEEE Systems and Software Week
        30th NASA/IEEE Software Engineering Workshop (SEW'2006)
            Columbia, Maryland, USA ~ April 24-28, 2006

Recently, there has been a growing interest in the potential use
of networked sensors in applications such as smart environments,=20
disaster management, combat field reconnaissance, and security=20
surveillance. While the initial view of the community was that=20
networked sensors will play a complementary role that enhances=20
the quality of these applications, recent research results have=20
encouraged practitioners to envision an increased reliance on sensor=20
networks and systems (SN&S) in such critical and sensitive applications.

Therefore to realize their potential, necessary dependability and=20
security (D&S) measures have to be incorporated in the design and=20
during the operation of SN&S. Dependability is usually specified=20
using attributes like reliability, survivability, safety,
maintainability,=20
and availability in presence of failure, while security is specified by=20
attributes like integrity, authenticity, confidentiality, and
availability=20
in presence of attacks. D&S services accomplish tasks for attack and
failure prevention, detection and response. The scope of D&S services
may
span the deployed sensors to command nodes and likely beyond. It also=20
involves D&S support at, and cross-cutting, the protocol stack layers=20
from physical to application.

Achieving dependability and security in SN&S will require
non-conventional=20
mechanisms due to many factors including: (1) sensors are significantly
constrained in the amount of available resources such as energy, storage

and computation; (2) sensors are expected to be deployed in very large=20
numbers in normal as well as harsh/hostile environments; (3) sensor=20
networks suffer from structural weakness and limited physical
protection,=20
and (4) localization of impact is complicated due to the un-tethered
nature=20
of SN&S and of the potential attackers. In addition, D&S requirements
may=20
vary according to mission defined over a multi-dimensional context, such

as field of deployment (e.g., hostile versus friendly), type of=20
application (e.g., monitoring, tracking, data collection), mode of=20
operation (e.g., normal, exception, post-event recovery), and time.

This workshop will foster a forum for discussing and presenting recent=20
research results on dependability and security in SN&S. Topics of
interest=20
include, although not limited to, the following:

- Fault and intrusion-tolerant architectures, middleware and operational
models=20
- Robust routing, storage, and processing of sensed data
- D&S architectures, protocols and tools
- Vulnerabilities, attacks and countermeasures
- Monitoring and evaluation techniques
- Robust clustering techniques
- Self-awareness and context-awareness=20
- Resilient virtual infrastructures
- Autonomic and adaptive D&S support.
- Formal representation and verification of D&S properties
- Network inference support for D&S
- Quality of service provisioning
- Models, metrics, and measurements for D&S
- Privacy-aware D&S services
- Testbeds, simulation and visualization=20
- Agent-based D&S management=20
- SN&S  support for D&S in  larger information grids
- SN&S application development environments


Submission Guidelines
---------------------
For guidelines regarding paper submission, please refer to the
workshop=92s=20
website (http://www.dssns.org). Papers should contain original material=20
and not be previously published, or currently submitted for
consideration=20
elsewhere. The manuscript should not exceed 20 single-column
double-space=20
pages in PDF format, font size 11 or larger. The first page should
include=20
title, authors' contact information, abstract and five keywords.=20

Important Dates
----------------
Submission deadline:	November 7, 2005
Decision notification:	December 20, 2005
Final manuscript due:	January 20, 2006


The best paper will be recognized and selected papers will be invited to

a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks.=20

Workshop Co-Chairs
-------------------
Mohamed Eltoweissy
Virginia Tech, USA
E-mail: toweissy@vt.edu=20

Mohamed Younis
University of Maryland Baltimore County, USA
E-mail: younis@csee.umbc.edu=20

Publicity Co-Chairs
--------------------
Denis Gracanin
Virginia Tech, USA
E-mail: gracanin@vt.edu

Moustafa Youssef
University of Maryland at College Park, USA
E-mail: moustafa@cs.umd.edu=20

Program Committee
------------------
Farooq Anjum, Telcordia & U. of Penn, USA
David Carman, Johns Hopkins U.=96 Applied Physics Lab, USA
Ing-Ray Chen, Virginia Tech, USA
M. Nazih Elderini, Alexandria U, Egypt
Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA
Sushil Jajodia, George Mason U., USA
Shivakant Mishra, U. of Colorado, USA
Peng Ning, North Carolina State U., USA
Cristina Nita-Rotaru, Purdue U., USA
Stephan Olariu, Old Dominion U., USA
David Simplot-Ryl, U. Lille, INRIA Futurs, France
Mani B. Srivastava, U. of California =96 Los Angeles, USA
John A. Stankovic, U. of Virginia, USA
Ivan Stojmenovic, U. of Ottawa, Canada
Gene Tsudik, U. of California-Irvine, USA
Cliff Wang, Army Research Office, USA
Stephen D. Wolthusen, Fraunhofer-IGD, Germany
Albert Zomaya, U. of Sydney, Australia


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



From avt-bounces@ietf.org Wed Jul 13 10:50:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DsiZE-0007bu-JV; Wed, 13 Jul 2005 10:50:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DsiYm-0007ER-35; Wed, 13 Jul 2005 10:50:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13132;
	Wed, 13 Jul 2005 10:50:02 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dsj1B-0003Jo-E0; Wed, 13 Jul 2005 11:19:26 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DsiYk-0000zu-3k; Wed, 13 Jul 2005 10:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DsiYk-0000zu-3k@newodin.ietf.org>
Date: Wed, 13 Jul 2005 10:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc3555bis-00.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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		: MIME Type Registration of RTP Payload Formats
	Author(s)	: S. Casner, P. Hoschka
	Filename	: draft-ietf-avt-rfc3555bis-00.txt
	Pages		: 41
	Date		: 2005-7-13
	
     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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3555bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rfc3555bis-00.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-rfc3555bis-00.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: <2005-7-13102254.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rfc3555bis-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-avt-rfc3555bis-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-13102254.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Wed Jul 13 13:45:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DslI8-00028b-6f; Wed, 13 Jul 2005 13:45:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DslI6-00027q-Bu
	for avt@megatron.ietf.org; Wed, 13 Jul 2005 13:45:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06464
	for <avt@ietf.org>; Wed, 13 Jul 2005 13:44:59 -0400 (EDT)
Received: from mx.cbeyond.net ([66.180.96.58] helo=mx.cbeyond.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DslkV-0004i8-C2
	for avt@ietf.org; Wed, 13 Jul 2005 14:14:26 -0400
Received: from [64.238.103.215] (port=1644 helo=telws116)
	by mx.cbeyond.com with asmtp (Exim 4.34) id 1DslHz-0003tk-TI
	for avt@ietf.org; Wed, 13 Jul 2005 13:44:56 -0400
From: "Alan Clark" <alan.d.clark@telchemy.com>
To: "Avt@Ietf. Org" <avt@ietf.org>
Date: Wed, 13 Jul 2005 13:44:55 -0400
Message-ID: <BGEKJNNFCPJKLLMMDMELCEJDHJAA.alan.d.clark@telchemy.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Subject: [AVT] RTCP XR - "high resolution metrics" draft 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


A new I-D has been submitted and is now available in the Internet Drafts
database

http://www.ietf.org/internet-drafts/draft-clark-avt-rtcpxr-bis-00.txt

This is an extended version of the draft informally presented by Amy
Pendleton at the last AVT meeting.

The draft describes a high resolution VoIP metrics block that aligns fairly
closely with other work in this area.  Existing RTCP XR VoIP metrics may not
provide the granularity needed for some backbone VoIP services and hence
this draft is a useful complement to RFC3611.  In addition, jitter metrics
have been included - one of which is a percentile based metric (i.e. what
proportion of packets arrived within a threshold jitter level).  The draft
also allows the algorithm used for call quality calculation to be reported,
and provides a more detailed set of payload related data.

Alan Clark
Telchemy


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



From avt-bounces@ietf.org Thu Jul 14 03:24:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dsy4o-00018O-MK; Thu, 14 Jul 2005 03:24:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsy4n-00018H-2n
	for avt@megatron.ietf.org; Thu, 14 Jul 2005 03:24:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12471
	for <avt@ietf.org>; Thu, 14 Jul 2005 03:24:07 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsyXL-0003kC-Gf
	for avt@ietf.org; Thu, 14 Jul 2005 03:53:40 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	A75E14F000A
	for <avt@ietf.org>; Thu, 14 Jul 2005 09:23:51 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Jul 2005 09:23:50 +0200
Received: from [147.214.34.34] ([147.214.34.34]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Jul 2005 09:23:50 +0200
Message-ID: <42D61304.9060901@ericsson.com>
Date: Thu, 14 Jul 2005 09:23:48 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: multipart/mixed; boundary="------------020003050500090207040300"
X-OriginalArrivalTime: 14 Jul 2005 07:23:50.0466 (UTC)
	FILETIME=[FB44A220:01C58844]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8
Subject: [AVT] [Fwd: I-D
	ACTION:draft-alexander-rtp-payload-for-ecn-probing-01.txt]
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


This is a multi-part message in MIME format.
--------------020003050500090207040300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

This draft seem to relate to AVT.

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

--------------020003050500090207040300
Content-Type: message/rfc822;
	name="I-D ACTION:draft-alexander-rtp-payload-for-ecn-probing-01.txt"
Content-Disposition: inline; filename="I-D
	ACTION:draft-alexander-rtp-payload-for-ecn-probing-01.txt"

X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by
	esealmw103.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:20:20 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C587E8.4A619A00"
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw115.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:20:19 +0200
Received: from esealmw128.eemea.ericsson.se ([130.100.184.163]) by
	esealmw126.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:20:19 +0200
Received: from mailgw1.ericsson.se ([193.180.251.59]) by
	esealmw128.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:20:18 +0200
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by
	mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id
	D1BE24F5; Wed, 13 Jul 2005 22:20:16 +0200 (CEST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by
	megatron.ietf.org with esmtp (Exim 4.32) id 1DsnFt-0003Qw-4J;
	Wed, 13 Jul 2005 15:50:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by
	megatron.ietf.org with esmtp (Exim 4.32) id 1DsnF9-0003Ac-T0
	for i-d-announce@megatron.ietf.org; Wed, 13 Jul 2005 15:50:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org
	(8.9.1a/8.9.1a) with ESMTP id PAA15536 for
	<i-d-announce@ietf.org>; Wed, 13 Jul 2005 15:50:06 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with
	esmtp (Exim 4.43) id 1DsnhY-0000NG-4G for i-d-announce@ietf.org;
	Wed, 13 Jul 2005 16:19:30 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id
	1DsnF4-0003Zx-5G for i-d-announce@ietf.org;
	Wed, 13 Jul 2005 15:50:02 -0400
Return-Path: <i-d-announce-bounces@ietf.org>
X-OriginalArrivalTime: 13 Jul 2005 20:20:18.0480 (UTC)
	FILETIME=[4979AB00:01C587E8]
Errors-To: i-d-announce-bounces@ietf.org
X-Spam-Score: 0.4 (/)
List-Post: <mailto:i-d-announce@ietf.org>
List-Id: i-d-announce.ietf.org
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-Brightmail-Tracker: AAAAAA==
Content-class: urn:content-classes:message
Subject: I-D ACTION:draft-alexander-rtp-payload-for-ecn-probing-01.txt 
Date: Wed, 13 Jul 2005 21:50:02 +0200
Message-ID: <E1DsnF4-0003Zx-5G@newodin.ietf.org>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-alexander-rtp-payload-for-ecn-probing-01.txt 
Thread-Index: AcWH6EqJ35lCM7wiQSajcmWnv/zB4g==
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
From: <Internet-Drafts@ietf.org>
Sender: <i-d-announce-bounces@ietf.org>
To: <i-d-announce@ietf.org>
Reply-To: <internet-drafts@ietf.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C587E8.4A619A00
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C587E8.4A619A00"


------_=_NextPart_002_01C587E8.4A619A00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.


	Title		: RTP Payload Format for ECN Probing
	Author(s)	: C. Alexander, J. Babiarz
	Filename	: draft-alexander-rtp-payload-for-ecn-probing-01.txt
	Pages		: 17
	Date		: 2005-7-13
=09
This memo defines a Real Time Transport Protocol (RTP) payload format
   for use when probing for congestion using Explicit Congestion
   Detection (ECN).  This payload format is intended for use with the
   probing mechanisms described in draft "Real-time ECN Use Cases".
   While defined in terms of the specific application of admission
   control, it is desirable to overlay this format with other probing
   mechanisms so as to reduce the number of probing packet formats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-alexander-rtp-payload-for-ecn-p=
robing-01.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


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-alexander-rtp-payload-for-ecn-probing-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-alexander-rtp-payload-for-ecn-probing-01.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_002_01C587E8.4A619A00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.84">
<TITLE>I-D ACTION:draft-alexander-rtp-payload-for-ecn-probing-01.txt =
</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : RTP Payload Format for ECN =
Probing<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : C. Alexander, J. =
Babiarz<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-alexander-rtp-payload-for-ecn-probing-01.txt<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 17<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2005-7-13<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
This memo defines a Real Time Transport Protocol (RTP) payload =
format<BR>
&nbsp;&nbsp; for use when probing for congestion using Explicit =
Congestion<BR>
&nbsp;&nbsp; Detection (ECN).&nbsp; This payload format is intended for =
use with the<BR>
&nbsp;&nbsp; probing mechanisms described in draft &quot;Real-time ECN =
Use Cases&quot;.<BR>
&nbsp;&nbsp; While defined in terms of the specific application of =
admission<BR>
&nbsp;&nbsp; control, it is desirable to overlay this format with other =
probing<BR>
&nbsp;&nbsp; mechanisms so as to reduce the number of probing packet =
formats.<BR>
<BR>
A URL for this Internet-Draft is:<BR>
<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-alexander-rtp-payload-f=
or-ecn-probing-01.txt">http://www.ietf.org/internet-drafts/draft-alexande=
r-rtp-payload-for-ecn-probing-01.txt</A><BR>
<BR>
To remove yourself from the I-D Announcement list, send a message to<BR>
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message.&nbsp;<BR>
You can also visit <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1=
.ietf.org/mailman/listinfo/I-D-announce</A><BR>
to change your subscription settings.<BR>
<BR>
<BR>
Internet-Drafts are also available by anonymous FTP. Login with the =
username<BR>
&quot;anonymous&quot; and a password of your e-mail address. After =
logging in,<BR>
type &quot;cd internet-drafts&quot; and then<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-alexander-rtp-payload-for-ecn-probing-01.txt&quot;.<BR>
<BR>
A list of Internet-Drafts directories can be found in<BR>
<A =
HREF=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A><BR>
or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A><BR>
<BR>
<BR>
Internet-Drafts can also be obtained by e-mail.<BR>
<BR>
Send a message to:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailserv@ietf.org.<BR>
In the body type:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-alexander-rtp-payload-for-ecn-probing-01.txt&quot;=
.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document =
in<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using =
the &quot;mpack&quot; utility.&nbsp; To use this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command =
&quot;ENCODING mime&quot; before the &quot;FILE&quot;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the =
response(s), you will need &quot;munpack&quot; or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail =
reader.&nbsp; Different MIME-compliant mail readers<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior, =
especially when dealing with<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME =
messages (i.e. documents which have been split<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), =
so check your local documentation on<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these =
messages.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Below is the data which will enable a MIME compliant mail reader<BR>
implementation to automatically retrieve the ASCII version of the<BR>
Internet-Draft.<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C587E8.4A619A00--

------_=_NextPart_001_01C587E8.4A619A00
Content-Type: application/octet-stream;
	name="ATT822913.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT822913.TXT
Content-Disposition: attachment;
	filename="ATT822913.TXT"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS03LTEzMTI1NDMwLkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFsZXhhbmRlci1ydHAtcGF5
bG9hZC1mb3ItZWNuLXByb2JpbmctMDEudHh0DQo=

------_=_NextPart_001_01C587E8.4A619A00
Content-Type: text/plain; charset="us-ascii";
	name="draft-alexander-rtp-payload-for-ecn-probing-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-alexander-rtp-payload-for-ecn-probing-01.txt
Content-Disposition: attachment;
	filename="draft-alexander-rtp-payload-for-ecn-probing-01.txt"
Content-Transfer-Encoding: base64

RklMRSBERUxFVEVEDQotLS0tLS0tLS0tLS0NCg0KV2FybmluZyENCg0KVGhlIGF0dGFjaGVkIGZp
bGUgZHJhZnQtYWxleGFuZGVyLXJ0cC1wYXlsb2FkLWZvci1lY24tcHJvYmluZy0wMS5VUkwgaGFz
IG5vdCBiZWVuIGRlbGl2ZXJlZC4NCg0KVGhlIHJlYXNvbiBpcyBkdWUgdG8gdGhlIEZJTEUgRklM
VEVSPSAqLnVybCBvbiBtYWlsc2VydmVyIEVTRUFMTVcxMjcuDQoNClBsZWFzZSBjb250YWN0IElU
IFNlcnZpY2UgRGVzayBpZiB5b3UgaGF2ZSBmdXJ0aGVyIHF1ZXN0aW9ucy4NCg0KSFA=

------_=_NextPart_001_01C587E8.4A619A00
Content-Type: text/plain;
	name="ATT822914.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT822914.txt
Content-Disposition: attachment;
	filename="ATT822914.txt"
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C587E8.4A619A00--


--------------020003050500090207040300
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------020003050500090207040300--




From avt-bounces@ietf.org Thu Jul 14 03:28:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dsy8Z-00020C-GS; Thu, 14 Jul 2005 03:28:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsy8W-0001ux-Sb
	for avt@megatron.ietf.org; Thu, 14 Jul 2005 03:28:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12763
	for <avt@ietf.org>; Thu, 14 Jul 2005 03:27:59 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsyb4-0003tq-5O
	for avt@ietf.org; Thu, 14 Jul 2005 03:57:32 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA767798
	for <avt@ietf.org>; Thu, 14 Jul 2005 09:27:06 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Jul 2005 09:27:05 +0200
Received: from [147.214.34.34] ([147.214.34.34]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Jul 2005 09:27:05 +0200
Message-ID: <42D613C9.10107@ericsson.com>
Date: Thu, 14 Jul 2005 09:27:05 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: multipart/mixed; boundary="------------070806040201040507070802"
X-OriginalArrivalTime: 14 Jul 2005 07:27:05.0653 (UTC)
	FILETIME=[6F9BCE50:01C58845]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 1.4 (+)
X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b
Subject: [AVT] [Fwd: I-D ACTION:draft-wenger-avt-avpf-ccm-00.txt]
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


This is a multi-part message in MIME format.
--------------070806040201040507070802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I would like to make everybody in AVT aware of this draft. It proposes 
solutions to the codec control that has previously been discussed a 
number of times. The latest input in the debate was Andrea Basso's draft 
about requirements. We will discuss it and its open issues in Paris.

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

--------------070806040201040507070802
Content-Type: message/rfc822;
	name="I-D ACTION:draft-wenger-avt-avpf-ccm-00.txt"
Content-Disposition: inline;
	filename="I-D ACTION:draft-wenger-avt-avpf-ccm-00.txt"

X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from esealmw112.eemea.ericsson.se ([153.88.200.3]) by
	esealmw103.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:39:08 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C587EA.EAB8BE00"
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw112.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:39:08 +0200
Received: from esealmw127.eemea.ericsson.se ([130.100.184.162]) by
	esealmw126.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:39:08 +0200
Received: from mailgw1.ericsson.se ([193.180.251.59]) by
	esealmw127.eemea.ericsson.se with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 13 Jul 2005 22:39:07 +0200
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by
	mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id
	6D27950F; Wed, 13 Jul 2005 22:39:06 +0200 (CEST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by
	megatron.ietf.org with esmtp (Exim 4.32) id 1DsnFV-0003KN-Fq;
	Wed, 13 Jul 2005 15:50:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by
	megatron.ietf.org with esmtp (Exim 4.32) id 1DsnF7-00035y-A5
	for i-d-announce@megatron.ietf.org; Wed, 13 Jul 2005 15:50:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org
	(8.9.1a/8.9.1a) with ESMTP id PAA15494 for
	<i-d-announce@ietf.org>; Wed, 13 Jul 2005 15:50:03 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with
	esmtp (Exim 4.43) id 1DsnhX-0000Mp-KA for i-d-announce@ietf.org;
	Wed, 13 Jul 2005 16:19:28 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id
	1DsnF3-0003YU-Kv for i-d-announce@ietf.org;
	Wed, 13 Jul 2005 15:50:01 -0400
Return-Path: <i-d-announce-bounces@ietf.org>
X-OriginalArrivalTime: 13 Jul 2005 20:39:07.0287 (UTC)
	FILETIME=[EA4BF270:01C587EA]
Errors-To: i-d-announce-bounces@ietf.org
X-Spam-Score: 0.4 (/)
List-Post: <mailto:i-d-announce@ietf.org>
List-Id: i-d-announce.ietf.org
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-Brightmail-Tracker: AAAAAA==
Content-class: urn:content-classes:message
Subject: I-D ACTION:draft-wenger-avt-avpf-ccm-00.txt 
Date: Wed, 13 Jul 2005 21:50:01 +0200
Message-ID: <E1DsnF3-0003YU-Kv@newodin.ietf.org>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-wenger-avt-avpf-ccm-00.txt 
Thread-Index: AcWH6usznmLgA89uRwmgVVi/Grc9Mw==
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
From: <Internet-Drafts@ietf.org>
Sender: <i-d-announce-bounces@ietf.org>
To: <i-d-announce@ietf.org>
Reply-To: <internet-drafts@ietf.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C587EA.EAB8BE00
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C587EA.EAB8BE00"


------_=_NextPart_002_01C587EA.EAB8BE00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.


	Title		: Codec Control Messages in the Audio-Visual
                          Profile with Feedback (AVPF)
	Author(s)	: S. Wenger, et al.
	Filename	: draft-wenger-avt-avpf-ccm-00.txt
	Pages		: 34
	Date		: 2005-7-13
=09
   This document specifies a few extensions to the messages defined in
   the Audio-Visual Profile with Feedback (AVPF).  They are useful
   primarily in conversational multimedia scenarios where centralized
   multipoint functionalities are in use. However some are also usable
   in smaller multicast environments and point-to-point calls. The
   extensions discussed are Full Intra Request, Freeze Request,
   Temporary Maximum Media Bit-rate and Temporal Spatial Tradeoff.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wenger-avt-avpf-ccm-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


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-wenger-avt-avpf-ccm-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
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-wenger-avt-avpf-ccm-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_002_01C587EA.EAB8BE00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.84">
<TITLE>I-D ACTION:draft-wenger-avt-avpf-ccm-00.txt </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Codec Control Messages in =
the Audio-Visual<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Profile with Feedback (AVPF)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : S. Wenger, et al.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-wenger-avt-avpf-ccm-00.txt<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 34<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2005-7-13<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp; This document specifies a few extensions to the messages =
defined in<BR>
&nbsp;&nbsp; the Audio-Visual Profile with Feedback (AVPF).&nbsp; They =
are useful<BR>
&nbsp;&nbsp; primarily in conversational multimedia scenarios where =
centralized<BR>
&nbsp;&nbsp; multipoint functionalities are in use. However some are =
also usable<BR>
&nbsp;&nbsp; in smaller multicast environments and point-to-point calls. =
The<BR>
&nbsp;&nbsp; extensions discussed are Full Intra Request, Freeze =
Request,<BR>
&nbsp;&nbsp; Temporary Maximum Media Bit-rate and Temporal Spatial =
Tradeoff.<BR>
<BR>
A URL for this Internet-Draft is:<BR>
<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-wenger-avt-avpf-ccm-00.=
txt">http://www.ietf.org/internet-drafts/draft-wenger-avt-avpf-ccm-00.txt=
</A><BR>
<BR>
To remove yourself from the I-D Announcement list, send a message to<BR>
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message.&nbsp;<BR>
You can also visit <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1=
.ietf.org/mailman/listinfo/I-D-announce</A><BR>
to change your subscription settings.<BR>
<BR>
<BR>
Internet-Drafts are also available by anonymous FTP. Login with the =
username<BR>
&quot;anonymous&quot; and a password of your e-mail address. After =
logging in,<BR>
type &quot;cd internet-drafts&quot; and then<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-wenger-avt-avpf-ccm-00.txt&quot;.<BR>
<BR>
A list of Internet-Drafts directories can be found in<BR>
<A =
HREF=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A><BR>
or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A><BR>
<BR>
<BR>
Internet-Drafts can also be obtained by e-mail.<BR>
<BR>
Send a message to:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailserv@ietf.org.<BR>
In the body type:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
/internet-drafts/draft-wenger-avt-avpf-ccm-00.txt&quot;.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document =
in<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using =
the &quot;mpack&quot; utility.&nbsp; To use this<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command =
&quot;ENCODING mime&quot; before the &quot;FILE&quot;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the =
response(s), you will need &quot;munpack&quot; or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail =
reader.&nbsp; Different MIME-compliant mail readers<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior, =
especially when dealing with<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME =
messages (i.e. documents which have been split<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), =
so check your local documentation on<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these =
messages.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
Below is the data which will enable a MIME compliant mail reader<BR>
implementation to automatically retrieve the ASCII version of the<BR>
Internet-Draft.<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C587EA.EAB8BE00--

------_=_NextPart_001_01C587EA.EAB8BE00
Content-Type: application/octet-stream;
	name="ATT823125.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT823125.TXT
Content-Disposition: attachment;
	filename="ATT823125.TXT"
Content-Transfer-Encoding: base64

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNS03LTEzMTEwODEzLkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdlbmdlci1hdnQtYXZwZi1j
Y20tMDAudHh0DQo=

------_=_NextPart_001_01C587EA.EAB8BE00
Content-Type: text/plain; charset="us-ascii";
	name="draft-wenger-avt-avpf-ccm-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-wenger-avt-avpf-ccm-00.txt
Content-Disposition: attachment;
	filename="draft-wenger-avt-avpf-ccm-00.txt"
Content-Transfer-Encoding: base64

RklMRSBERUxFVEVEDQotLS0tLS0tLS0tLS0NCg0KV2FybmluZyENCg0KVGhlIGF0dGFjaGVkIGZp
bGUgZHJhZnQtd2VuZ2VyLWF2dC1hdnBmLWNjbS0wMC5VUkwgaGFzIG5vdCBiZWVuIGRlbGl2ZXJl
ZC4NCg0KVGhlIHJlYXNvbiBpcyBkdWUgdG8gdGhlIEZJTEUgRklMVEVSPSAqLnVybCBvbiBtYWls
c2VydmVyIEVTRUFMTVcxMjcuDQoNClBsZWFzZSBjb250YWN0IElUIFNlcnZpY2UgRGVzayBpZiB5
b3UgaGF2ZSBmdXJ0aGVyIHF1ZXN0aW9ucy4NCg0KSFA=

------_=_NextPart_001_01C587EA.EAB8BE00
Content-Type: text/plain;
	name="ATT823126.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT823126.txt
Content-Disposition: attachment;
	filename="ATT823126.txt"
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C587EA.EAB8BE00--


--------------070806040201040507070802
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------070806040201040507070802--




From avt-bounces@ietf.org Thu Jul 14 03:42:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DsyMp-0002Sv-KN; Thu, 14 Jul 2005 03:42:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DsyMn-0002Sn-T9; Thu, 14 Jul 2005 03:42:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13837;
	Thu, 14 Jul 2005 03:42:44 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DsypN-0004g7-7l; Thu, 14 Jul 2005 04:12:17 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 93B77B83; 
	Thu, 14 Jul 2005 09:42:28 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Jul 2005 09:42:28 +0200
Received: from [147.214.34.34] ([147.214.34.34]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 14 Jul 2005 09:42:27 +0200
Message-ID: <42D61763.20704@ericsson.com>
Date: Thu, 14 Jul 2005 09:42:27 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>, rmt@ietf.org
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jul 2005 07:42:27.0958 (UTC)
	FILETIME=[95586160:01C58847]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: Stephan.Wenger@nokia.com
Subject: [AVT] Proposed FEC Streaming Framework
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tsvwg@ietf.org
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

All,

The below messge was sent to TSVWG. If you have comments on this please 
respond to us author or the TSVWG.

/Magnus Westerlund

-----

A few of us have been working on a framework for FEC protection of
streaming media, based on some work done recently in 3GPP and making use
of the FEC Building Block defined by RMT (so that the framework is not
specific to a particular FEC code).

This proposal is described in
http://www.ietf.org/internet-drafts/draft-watson-tsvwg-fec-sf-00.txt.
Although intended primarily for streaming, it is not specific to RTP,
defining instead an FEC protection layer above UDP, which can protect a
set of several UDP flows.

Since the proposal is not specific to either multicast or RTP, we are
bringing it first to TSVWG, rather than RMT or AVT. It will be discussed
at the Paris meeting, so please put it on your reading list.

The questions for the TSVWG are (at least):
1) is the objective of extending the RMT FEC Building Block framework to
streaming a good one ?
2) is this a good approach to that objective ?
3) what is the relationship with the ULP work in AVT ?
4) whether the proposal should best be progressed in AVT (where there is
streaming expertise), in RMT (where there is FEC expertise) or in TSVWG
?

Regards,

Mark Watson
Digital Fountain



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



From avt-bounces@ietf.org Thu Jul 14 14:42:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dt8ez-0006P9-F4; Thu, 14 Jul 2005 14:42:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8ey-0006P4-BJ
	for avt@megatron.ietf.org; Thu, 14 Jul 2005 14:42:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08109
	for <avt@ietf.org>; Thu, 14 Jul 2005 14:42:10 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt97c-00068b-J4
	for avt@ietf.org; Thu, 14 Jul 2005 15:11:49 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62082
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1Dt8en-00082b-J4 for avt@ietf.org; Thu, 14 Jul 2005 19:42:01 +0100
Mime-Version: 1.0 (Apple Message framework v733)
Content-Transfer-Encoding: 7bit
Message-Id: <D8539E1A-9D23-415E-A96A-FEACE29503FB@csperkins.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: IETF AVT WG <avt@ietf.org>
From: Colin Perkins <csp@csperkins.org>
Date: Thu, 14 Jul 2005 19:41:58 +0100
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Subject: [AVT] IPR rules - read before submitting a draft
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Folks,

A reminder that the boilerplate text required at the start of all  
internet drafts has changed recently. You MUST ensure all drafts you  
submit conform to the terms in RFC 3978, otherwise the secretariat  
will reject your submission. Specifically:

  * All Internet-Drafts must have on the first page an intellectual  
property
rights (IPR) statement that says:


By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.

If you are using xml2rfc, this can be accomplished by updating the
'ipr' attribute in the 'rfc' element to refer to 3978. See
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr for
more information.

  * All Internet-Drafts must include the following statement:

Copyright (C) The Internet Society (2005).


  * All Internet-Drafts must include the following statement:

This document is subject to the rights, licenses
and restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.


  * All Internet-Drafts must include the following statement:

This document and the information contained herein
are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.


Colin

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



From avt-bounces@ietf.org Thu Jul 14 15:52:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dt9lI-0000Ip-08; Thu, 14 Jul 2005 15:52:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dt9iu-0007k4-Rp; Thu, 14 Jul 2005 15:50:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13791;
	Thu, 14 Jul 2005 15:50:18 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DtABN-0008Qq-3m; Thu, 14 Jul 2005 16:19:48 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1Dt9id-0006Ev-Et; Thu, 14 Jul 2005 15:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Dt9id-0006Ev-Et@newodin.ietf.org>
Date: Thu, 14 Jul 2005 15:50:03 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-xr-mib-02.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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 Control Protocol Extended Reports (RTCP
                          XR) VoIP Metrics Management Information Base
	Author(s)	: A. Clark, A. Pendleton
	Filename	: draft-ietf-avt-rtcp-xr-mib-02.txt
	Pages		: 46
	Date		: 2005-7-14
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing Real-Time Transport 
   Control Protocol Extended Reports (RTCP XR) VoIP Metrics (RFC3611).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-xr-mib-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rtcp-xr-mib-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-rtcp-xr-mib-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: <2005-7-14124246.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtcp-xr-mib-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-xr-mib-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-14124246.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Fri Jul 15 04:39:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DtLjd-0001tx-E4; Fri, 15 Jul 2005 04:39:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLjb-0001te-8y
	for avt@megatron.ietf.org; Fri, 15 Jul 2005 04:39:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14878
	for <avt@ietf.org>; Fri, 15 Jul 2005 04:39:48 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtMCM-0006qk-Sn
	for avt@ietf.org; Fri, 15 Jul 2005 05:09:36 -0400
Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63069
	helo=[192.168.0.2])
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DtLjQ-0008Eo-G9 for avt@ietf.org; Fri, 15 Jul 2005 09:39:40 +0100
Mime-Version: 1.0 (Apple Message framework v733)
References: <E1DsQlW-0000SZ-GN@newodin.ietf.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CF09DF85-959F-4C83-832D-CE430179D1F9@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Date: Fri, 15 Jul 2005 09:39:35 +0100
To: IETF AVT WG <avt@ietf.org>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: [AVT] Fwd: I-D ACTION:draft-perkins-avt-uncomp-video-ext-00.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Begin forwarded message:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>     Title        : RTP Payload Format for Uncompressed Video:
>                           Additional Colour Sampling Modes
>     Author(s)    : C. Perkins
>     Filename    : draft-perkins-avt-uncomp-video-ext-00.txt
>     Pages        : 5
>     Date        : 2005-7-12
>
>    This memo extends the RTP Payload Format for Uncompressed Video to
>    support additional RGB sampling modes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-avt-uncomp-video- 
> ext-00.txt

This is a strawman proposal for some extensions to the uncompressed  
video format. Comments welcome.

Colin

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



From avt-bounces@ietf.org Fri Jul 15 08:04:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DtOvt-0004I5-Tn; Fri, 15 Jul 2005 08:04:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOvr-0004I0-4W
	for avt@megatron.ietf.org; Fri, 15 Jul 2005 08:04:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28888
	for <avt@ietf.org>; Fri, 15 Jul 2005 08:04:41 -0400 (EDT)
Received: from ranger.electric.net ([216.129.90.29])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtPOc-0005vQ-6x
	for avt@ietf.org; Fri, 15 Jul 2005 08:34:29 -0400
Received: from root by ranger.electric.net with emc1-ok (Exim 4.24)
	id 1DtOvG-0008DD-UQ for avt@ietf.org; Fri, 15 Jul 2005 05:04:06 -0700
Received: by emcmailer; Fri, Jul 15 2005 05:04:06 -0700
Received: from [64.69.103.254] (helo=mailhost.newtecamerica.com)
	by ranger.electric.net with esmtp (Exim 4.24) id 1DtOvF-0008Cq-V6
	for avt@ietf.org; Fri, 15 Jul 2005 05:04:05 -0700
Received: from [192.168.16.28] ([192.168.16.28])
	by mailhost.newtecamerica.com; Fri, 15 Jul 2005 08:03:58 -0500
Message-ID: <42D7A62C.7000004@newtecamerica.com>
Date: Fri, 15 Jul 2005 08:03:56 -0400
From: Girish Chandran <gchandran@newtecamerica.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Checker-Version: GEE Whiz 2.0 b1624
X-Spam-Score: 0.00/4.00
X-Spam-Flag: NO
X-Spam-Checker-Version: GEE Whiz 2.0 b1624
X-Spam-Score: 0.00/4.00
X-Virus-Status: Scanned by VirusSMART (s)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 7bit
Subject: [AVT] Re: avt Digest, Vol 15, Issue 16
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Pro-MPEG forum has also done some work on FEC for streamed media.


Girish Chandran

avt-request@ietf.org wrote:

>Send avt mailing list submissions to
>	avt@ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www1.ietf.org/mailman/listinfo/avt
>or, via email, send a message with subject or body 'help' to
>	avt-request@ietf.org
>
>You can reach the person managing the list at
>	avt-owner@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of avt digest..."
>
>
>Today's Topics:
>
>   1. Proposed FEC Streaming Framework (Magnus Westerlund)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 14 Jul 2005 09:42:27 +0200
>From: Magnus Westerlund <magnus.westerlund@ericsson.com>
>Subject: [AVT] Proposed FEC Streaming Framework
>To: IETF AVT WG <avt@ietf.org>, rmt@ietf.org
>Cc: Stephan.Wenger@nokia.com
>Message-ID: <42D61763.20704@ericsson.com>
>Content-Type: text/plain; charset=iso-8859-1; format=flowed
>
>All,
>
>The below messge was sent to TSVWG. If you have comments on this please 
>respond to us author or the TSVWG.
>
>/Magnus Westerlund
>
>-----
>
>A few of us have been working on a framework for FEC protection of
>streaming media, based on some work done recently in 3GPP and making use
>of the FEC Building Block defined by RMT (so that the framework is not
>specific to a particular FEC code).
>
>This proposal is described in
>http://www.ietf.org/internet-drafts/draft-watson-tsvwg-fec-sf-00.txt.
>Although intended primarily for streaming, it is not specific to RTP,
>defining instead an FEC protection layer above UDP, which can protect a
>set of several UDP flows.
>
>Since the proposal is not specific to either multicast or RTP, we are
>bringing it first to TSVWG, rather than RMT or AVT. It will be discussed
>at the Paris meeting, so please put it on your reading list.
>
>The questions for the TSVWG are (at least):
>1) is the objective of extending the RMT FEC Building Block framework to
>streaming a good one ?
>2) is this a good approach to that objective ?
>3) what is the relationship with the ULP work in AVT ?
>4) whether the proposal should best be progressed in AVT (where there is
>streaming expertise), in RMT (where there is FEC expertise) or in TSVWG
>?
>
>Regards,
>
>Mark Watson
>Digital Fountain
>
>
>
>
>
>------------------------------
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>
>
>End of avt Digest, Vol 15, Issue 16
>***********************************
>
>
>  
>





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



From avt-bounces@ietf.org Fri Jul 15 08:19:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DtP9h-0003JD-SZ; Fri, 15 Jul 2005 08:19:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DtP9g-0003Fc-7b
	for avt@megatron.ietf.org; Fri, 15 Jul 2005 08:19:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29937
	for <avt@ietf.org>; Fri, 15 Jul 2005 08:18:58 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtPcT-0006Ru-Vv
	for avt@ietf.org; Fri, 15 Jul 2005 08:48:47 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 89052B15; 
	Fri, 15 Jul 2005 14:18:46 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Jul 2005 14:18:46 +0200
Received: from [147.214.34.34] ([147.214.34.34]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 15 Jul 2005 14:18:46 +0200
Message-ID: <42D7A9A5.7000704@ericsson.com>
Date: Fri, 15 Jul 2005 14:18:45 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Girish Chandran <gchandran@newtecamerica.com>, IETF AVT WG <avt@ietf.org>
Subject: Re: [AVT] Re: avt Digest, Vol 15, Issue 16 was Proposed FEC Streaming
	Framework
References: <42D7A62C.7000004@newtecamerica.com>
In-Reply-To: <42D7A62C.7000004@newtecamerica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Jul 2005 12:18:46.0177 (UTC)
	FILETIME=[59259910:01C58937]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Girish Chandran wrote:
> Pro-MPEG forum has also done some work on FEC for streamed media.
> 
> 
> Girish Chandran

Hi,

Thanks for the notice, could you please provide a more complete 
reference. Preferable an link to the document(s) that specify this 
solution?

I would also like to ask you all kindly that receives the mails per 
digest. When responding, please change the subject to what the relevant 
email you are responding to had.

Thanks

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 avt-bounces@ietf.org Fri Jul 15 16:20:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DtWfd-0007yt-BG; Fri, 15 Jul 2005 16:20:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWfc-0007ve-4e
	for avt@megatron.ietf.org; Fri, 15 Jul 2005 16:20:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22681
	for <avt@ietf.org>; Fri, 15 Jul 2005 16:20:22 -0400 (EDT)
Received: from visor.electric.net ([216.129.90.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtX8O-0003kK-5W
	for avt@ietf.org; Fri, 15 Jul 2005 16:50:15 -0400
Received: from root by visor.electric.net with emc1-ok (Exim 4.24)
	id 1DtWfQ-0001fN-Tf for avt@ietf.org; Fri, 15 Jul 2005 13:20:16 -0700
Received: by emcmailer; Fri, Jul 15 2005 13:20:16 -0700
Received: from [64.69.103.254] (helo=mailhost.newtecamerica.com)
	by visor.electric.net with esmtp (Exim 4.24) id 1DtWfP-0001ex-UB
	for avt@ietf.org; Fri, 15 Jul 2005 13:20:15 -0700
Received: from [192.168.16.28] ([192.168.16.28])
	by mailhost.newtecamerica.com; Fri, 15 Jul 2005 16:19:51 -0500
Message-ID: <42D81A65.5060207@newtecamerica.com>
Date: Fri, 15 Jul 2005 16:19:49 -0400
From: Girish Chandran <gchandran@newtecamerica.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <42D7A62C.7000004@newtecamerica.com>
	<42D7A9A5.7000704@ericsson.com>
In-Reply-To: <42D7A9A5.7000704@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Flag: NO
X-Spam-Checker-Version: GEE Whiz 2.0 b1624
X-Spam-Score: 0.00/4.00
X-Spam-Flag: NO
X-Spam-Checker-Version: GEE Whiz 2.0 b1624
X-Spam-Score: 0.00/4.00
X-Virus-Status: Scanned by VirusSMART (s)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: IETF AVT WG <avt@ietf.org>
Subject: [AVT] Proposed FEC Streaming Framework
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hello Magnus,

Here is a reference.

http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf

It may also be useful to look at some of the other codes of practice for 
transport of MPEG over IP.

http://www.pro-mpeg.org under the publications tab.

Girish Chandran

Newtec America, Inc.
1055 Washington Blvd.
Stamford, CT 06901
USA
Tel: 203.323.0042
www.newtecamerica.com


Magnus Westerlund wrote:

> Girish Chandran wrote:
>
>> Pro-MPEG forum has also done some work on FEC for streamed media.
>>
>>
>> Girish Chandran
>
>
> Hi,
>
> Thanks for the notice, could you please provide a more complete 
> reference. Preferable an link to the document(s) that specify this 
> solution?
>
> I would also like to ask you all kindly that receives the mails per 
> digest. When responding, please change the subject to what the 
> relevant email you are responding to had.
>
> Thanks
>
> 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 avt-bounces@ietf.org Sat Jul 16 18:54:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DtvYY-0005S8-0c; Sat, 16 Jul 2005 18:54:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvYV-0005Rx-VU
	for avt@megatron.ietf.org; Sat, 16 Jul 2005 18:54:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07270
	for <avt@ietf.org>; Sat, 16 Jul 2005 18:54:44 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com
	([24.199.146.6] helo=berlin.arid.us ident=system)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtw1Z-0006L6-C2
	for avt@ietf.org; Sat, 16 Jul 2005 19:24:52 -0400
Received: from madrid (madrid.arid.us [192.168.1.10])
	by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6GMsOSA004550;
	Sat, 16 Jul 2005 18:54:24 -0400
Message-Id: <200507162254.j6GMsOSA004550@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Vladimir Ulybin'" <Vladimir@audiocodes.com>,
	"'Colin Perkins'" <csp@csperkins.org>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Sat, 16 Jul 2005 18:53:28 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6011A059D@aclmsg.corp.audiocodes.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3A=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

I apologize that I missed much of this discussion while I was traveling.

The bottom line on this, though, is that T.38 over RTP should use whatever
mechanisms are defined in the IETF for redundancy or FEC.  This might
include RFC 2198, RFC 2733, or other tools that come along.  It's also
expected that this will be the means by which security is provided for fax
(SRTP).

Is there a problem you see that is specific to fax?  Timing is certainly an
issue, but the delay should be no worse than UDPTL.  However, if there is a
flaw somewhere, we should fix it sooner than later.

Paul


> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Vladimir Ulybin
> Sent: Monday, July 04, 2005 5:59 AM
> To: Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> On my suggestion from 3 Jul 2005, at 15:44:
> >> I think we may use for RTP sequence number the same rules of
> >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> >> primary IFP packet and do not increment SN if a fax packet is
> >> repeated.
> 
> Colin Perkins wrote:
> > Not if you wish to be compatible with RTP: RTP requires the sequence
> > numbers to be unique.
> 
> 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550 as a
> basic RTP protocol to be used for encapsulation.
> 2. The RFC 3550 does not define the packet repetition, also does not use
> SHOULD or MUST for sequence number advances (in contrast to RFC 2833bis
> were the MUST is used).
> 3. Different RTP sequence numbers assigned to the same fax signal state
> or the same binary data cannot be considered as unique.
> 4. I try to find a more reliable transport for T.38 over RTP. The blind
> assignment of new sequence numbers for ALL packets is full compatible
> with RFC 3550, but highly reduces the reliability of fax relay, because
> gateways may not repeat fax packets.
> 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> only problem of packet repetition with the same SN is a distorted RTCP
> statistics. In absence of other ways this violation is better than to
> loose connection during fax relay.
> 
> Regards,
> Vladimir Ulybin
> 
> _______________________________________________
> 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 avt-bounces@ietf.org Sun Jul 17 02:06:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Du2Hs-0004ds-Dv; Sun, 17 Jul 2005 02:06:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Du2Ho-0004dk-H6
	for avt@megatron.ietf.org; Sun, 17 Jul 2005 02:06:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28569
	for <avt@ietf.org>; Sun, 17 Jul 2005 02:05:56 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2ku-0002Mb-5g
	for avt@ietf.org; Sun, 17 Jul 2005 02:36:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Sun, 17 Jul 2005 09:06:05 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E3BA@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIA==
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Paul,

Finally, for resending of T.38 packets over RTP, Colin suggested us to
use FEC per RFC 2733 or new retransmission protocol. Both ways present
optional features which may not be supported by gateways.

Basic configuration for T.38 over RTP is a basic RFC 3550 plus
redundancy per RFC 2198.

This configuration has limited capabilities vs. T.38 UDPTL to improve
reliability of fax transport, if gateways do not resend =
(=3D=3Dduplicate)
fax packets, refer to explanation that I done in previous e-mails.

The other open issue for T.38 over RTP is the time stamps for redundant
fax packets. The T.38 implementations are not dependant on time stamps.
So, the time offset fields required per RFC 2198 for redundant fax
payloads are absolutely usefulness. There is no problem to ignore these
fields on receiving, but transmitting accurate offsets requires
additional resources in gateways.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Sunday, July 17, 2005 1:53 AM
To: Vladimir Ulybin; 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

I apologize that I missed much of this discussion while I was traveling.

The bottom line on this, though, is that T.38 over RTP should use
whatever
mechanisms are defined in the IETF for redundancy or FEC.  This might
include RFC 2198, RFC 2733, or other tools that come along.  It's also
expected that this will be the means by which security is provided for
fax
(SRTP).

Is there a problem you see that is specific to fax?  Timing is certainly
an
issue, but the delay should be no worse than UDPTL.  However, if there
is a
flaw somewhere, we should fix it sooner than later.

Paul


> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Vladimir Ulybin
> Sent: Monday, July 04, 2005 5:59 AM
> To: Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> On my suggestion from 3 Jul 2005, at 15:44:
> >> I think we may use for RTP sequence number the same rules of
> >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> >> primary IFP packet and do not increment SN if a fax packet is
> >> repeated.
>=20
> Colin Perkins wrote:
> > Not if you wish to be compatible with RTP: RTP requires the sequence
> > numbers to be unique.
>=20
> 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550 as
a
> basic RTP protocol to be used for encapsulation.
> 2. The RFC 3550 does not define the packet repetition, also does not
use
> SHOULD or MUST for sequence number advances (in contrast to RFC
2833bis
> were the MUST is used).
> 3. Different RTP sequence numbers assigned to the same fax signal
state
> or the same binary data cannot be considered as unique.
> 4. I try to find a more reliable transport for T.38 over RTP. The
blind
> assignment of new sequence numbers for ALL packets is full compatible
> with RFC 3550, but highly reduces the reliability of fax relay,
because
> gateways may not repeat fax packets.
> 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> only problem of packet repetition with the same SN is a distorted RTCP
> statistics. In absence of other ways this violation is better than to
> loose connection during fax relay.
>=20
> Regards,
> Vladimir Ulybin
>=20
> _______________________________________________
> 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 avt-bounces@ietf.org Sun Jul 17 02:12:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Du2MI-0006Xb-Da; Sun, 17 Jul 2005 02:10:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Du2MF-0006Vp-Ua
	for avt@megatron.ietf.org; Sun, 17 Jul 2005 02:10:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03008
	for <avt@ietf.org>; Sun, 17 Jul 2005 02:10:34 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2pQ-0002Z5-9Q
	for avt@ietf.org; Sun, 17 Jul 2005 02:40:44 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Sun, 17 Jul 2005 09:11:02 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E3C4@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAACp4ng
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Sorry for type mistake:

Instead of
"Both ways present optional features which may not be supported by
gateways."

Should be
"Both ways present optional features which possibly are not supported by
gateways."

Vladimir Ulybin


-----Original Message-----
From: Vladimir Ulybin=20
Sent: Sunday, July 17, 2005 9:06 AM
To: 'Paul E. Jones'; 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Paul,

Finally, for resending of T.38 packets over RTP, Colin suggested us to
use FEC per RFC 2733 or new retransmission protocol. Both ways present
optional features which may not be supported by gateways.

Basic configuration for T.38 over RTP is a basic RFC 3550 plus
redundancy per RFC 2198.

This configuration has limited capabilities vs. T.38 UDPTL to improve
reliability of fax transport, if gateways do not resend =
(=3D=3Dduplicate)
fax packets, refer to explanation that I done in previous e-mails.

The other open issue for T.38 over RTP is the time stamps for redundant
fax packets. The T.38 implementations are not dependant on time stamps.
So, the time offset fields required per RFC 2198 for redundant fax
payloads are absolutely usefulness. There is no problem to ignore these
fields on receiving, but transmitting accurate offsets requires
additional resources in gateways.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Sunday, July 17, 2005 1:53 AM
To: Vladimir Ulybin; 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

I apologize that I missed much of this discussion while I was traveling.

The bottom line on this, though, is that T.38 over RTP should use
whatever
mechanisms are defined in the IETF for redundancy or FEC.  This might
include RFC 2198, RFC 2733, or other tools that come along.  It's also
expected that this will be the means by which security is provided for
fax
(SRTP).

Is there a problem you see that is specific to fax?  Timing is certainly
an
issue, but the delay should be no worse than UDPTL.  However, if there
is a
flaw somewhere, we should fix it sooner than later.

Paul


> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> Vladimir Ulybin
> Sent: Monday, July 04, 2005 5:59 AM
> To: Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> On my suggestion from 3 Jul 2005, at 15:44:
> >> I think we may use for RTP sequence number the same rules of
> >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> >> primary IFP packet and do not increment SN if a fax packet is
> >> repeated.
>=20
> Colin Perkins wrote:
> > Not if you wish to be compatible with RTP: RTP requires the sequence
> > numbers to be unique.
>=20
> 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550 as
a
> basic RTP protocol to be used for encapsulation.
> 2. The RFC 3550 does not define the packet repetition, also does not
use
> SHOULD or MUST for sequence number advances (in contrast to RFC
2833bis
> were the MUST is used).
> 3. Different RTP sequence numbers assigned to the same fax signal
state
> or the same binary data cannot be considered as unique.
> 4. I try to find a more reliable transport for T.38 over RTP. The
blind
> assignment of new sequence numbers for ALL packets is full compatible
> with RFC 3550, but highly reduces the reliability of fax relay,
because
> gateways may not repeat fax packets.
> 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> only problem of packet repetition with the same SN is a distorted RTCP
> statistics. In absence of other ways this violation is better than to
> loose connection during fax relay.
>=20
> Regards,
> Vladimir Ulybin
>=20
> _______________________________________________
> 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 avt-bounces@ietf.org Sun Jul 17 23:16:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuM7S-0000Nf-W2; Sun, 17 Jul 2005 23:16:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuM7P-0000NZ-BP
	for avt@megatron.ietf.org; Sun, 17 Jul 2005 23:16:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13575
	for <avt@ietf.org>; Sun, 17 Jul 2005 23:16:32 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com
	([24.199.146.6] helo=berlin.arid.us ident=system)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuMak-0002cg-T6
	for avt@ietf.org; Sun, 17 Jul 2005 23:46:55 -0400
Received: from madrid (madrid.arid.us [192.168.1.10])
	by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6I3GISA017672;
	Sun, 17 Jul 2005 23:16:18 -0400
Message-Id: <200507180316.j6I3GISA017672@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Vladimir Ulybin'" <Vladimir@audiocodes.com>,
	"'Colin Perkins'" <csp@csperkins.org>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Sun, 17 Jul 2005 23:17:08 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E3BA@aclmsg.corp.audiocodes.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAAuyJ8A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

T.38 (2004) addresses the transport of T.38 over RTP and does not say that
RFC 2198 is the basic configuration.  Both RFC 2198 and RFC 2733 are
suggested as possible choices for protecting the media stream.

While T.38 data may not have the same kind of timing as, say, an audio
codec, the fact that it is placed into a media stream means it needs a
clock.  The draft I wrote suggests the use of an 8000hz clock or one that
matches the primary audio codec.  In any case, the timing information would
be meaningful.  In theory, one would not play out packets so quickly that a
redundant piece of information received one or two packets later would be
too old to be useful.

In any case, you are certainly free to use RFC 2198 or RFC 2733.  Most
people I've talked to prefer RFC 2198, simply because of the computational
complexity introduced by RFC 2733.  With that said, I've certainly not
talked to every GW maker in the world ;-)

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Sunday, July 17, 2005 2:06 AM
> To: Paul E. Jones; Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Paul,
> 
> Finally, for resending of T.38 packets over RTP, Colin suggested us to
> use FEC per RFC 2733 or new retransmission protocol. Both ways present
> optional features which may not be supported by gateways.
> 
> Basic configuration for T.38 over RTP is a basic RFC 3550 plus
> redundancy per RFC 2198.
> 
> This configuration has limited capabilities vs. T.38 UDPTL to improve
> reliability of fax transport, if gateways do not resend (==duplicate)
> fax packets, refer to explanation that I done in previous e-mails.
> 
> The other open issue for T.38 over RTP is the time stamps for redundant
> fax packets. The T.38 implementations are not dependant on time stamps.
> So, the time offset fields required per RFC 2198 for redundant fax
> payloads are absolutely usefulness. There is no problem to ignore these
> fields on receiving, but transmitting accurate offsets requires
> additional resources in gateways.
> 
> Regards,
> Vladimir Ulybin
> 
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Sunday, July 17, 2005 1:53 AM
> To: Vladimir Ulybin; 'Colin Perkins'
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Vladimir,
> 
> I apologize that I missed much of this discussion while I was traveling.
> 
> The bottom line on this, though, is that T.38 over RTP should use
> whatever
> mechanisms are defined in the IETF for redundancy or FEC.  This might
> include RFC 2198, RFC 2733, or other tools that come along.  It's also
> expected that this will be the means by which security is provided for
> fax
> (SRTP).
> 
> Is there a problem you see that is specific to fax?  Timing is certainly
> an
> issue, but the delay should be no worse than UDPTL.  However, if there
> is a
> flaw somewhere, we should fix it sooner than later.
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> > Vladimir Ulybin
> > Sent: Monday, July 04, 2005 5:59 AM
> > To: Colin Perkins
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > On my suggestion from 3 Jul 2005, at 15:44:
> > >> I think we may use for RTP sequence number the same rules of
> > >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every new
> > >> primary IFP packet and do not increment SN if a fax packet is
> > >> repeated.
> >
> > Colin Perkins wrote:
> > > Not if you wish to be compatible with RTP: RTP requires the sequence
> > > numbers to be unique.
> >
> > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550 as
> a
> > basic RTP protocol to be used for encapsulation.
> > 2. The RFC 3550 does not define the packet repetition, also does not
> use
> > SHOULD or MUST for sequence number advances (in contrast to RFC
> 2833bis
> > were the MUST is used).
> > 3. Different RTP sequence numbers assigned to the same fax signal
> state
> > or the same binary data cannot be considered as unique.
> > 4. I try to find a more reliable transport for T.38 over RTP. The
> blind
> > assignment of new sequence numbers for ALL packets is full compatible
> > with RFC 3550, but highly reduces the reliability of fax relay,
> because
> > gateways may not repeat fax packets.
> > 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> > only problem of packet repetition with the same SN is a distorted RTCP
> > statistics. In absence of other ways this violation is better than to
> > loose connection during fax relay.
> >
> > Regards,
> > Vladimir Ulybin
> >
> > _______________________________________________
> > 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 avt-bounces@ietf.org Mon Jul 18 02:38:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuPGe-0007vO-Kc; Mon, 18 Jul 2005 02:38:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPGd-0007vI-IE
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 02:38:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14204
	for <avt@ietf.org>; Mon, 18 Jul 2005 02:38:18 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuPjy-00060F-4W
	for avt@ietf.org; Mon, 18 Jul 2005 03:08:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Mon, 18 Jul 2005 09:38:21 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E6D6@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAAuyJ8AAASU3nA=
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Paul,

The term "basic configuration" for RFC 3550 plus redundancy per RFC 2198
should be replaced on "typical configuration". I assumed the same as
you, that most gateways support this.

As for the time stamps for redundant fax packets, the theory case given
is not relevant for T.38.
1. The ITU-T T.38 itself does not uses any time stamps both for
redundant and primary packets. T.38 gateways transmitting fax signals
should care about compatibility with T.30 but not with time stamps
received from a remote gateway. The only important things are the
content of fax packets and the real-time of receiving.
2. We say about new feature of T.38 over RTP which is to be added to
existing (=3D=3Dworking) T.38 UDPTL.

My suggestion is to reserve (zero) time stamps for redundant packets
when sending T.38 over RTP.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Monday, July 18, 2005 6:17 AM
To: Vladimir Ulybin; 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

T.38 (2004) addresses the transport of T.38 over RTP and does not say
that
RFC 2198 is the basic configuration.  Both RFC 2198 and RFC 2733 are
suggested as possible choices for protecting the media stream.

While T.38 data may not have the same kind of timing as, say, an audio
codec, the fact that it is placed into a media stream means it needs a
clock.  The draft I wrote suggests the use of an 8000hz clock or one
that
matches the primary audio codec.  In any case, the timing information
would
be meaningful.  In theory, one would not play out packets so quickly
that a
redundant piece of information received one or two packets later would
be
too old to be useful.

In any case, you are certainly free to use RFC 2198 or RFC 2733.  Most
people I've talked to prefer RFC 2198, simply because of the
computational
complexity introduced by RFC 2733.  With that said, I've certainly not
talked to every GW maker in the world ;-)

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Sunday, July 17, 2005 2:06 AM
> To: Paul E. Jones; Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Paul,
>=20
> Finally, for resending of T.38 packets over RTP, Colin suggested us to
> use FEC per RFC 2733 or new retransmission protocol. Both ways present
> optional features which may not be supported by gateways.
>=20
> Basic configuration for T.38 over RTP is a basic RFC 3550 plus
> redundancy per RFC 2198.
>=20
> This configuration has limited capabilities vs. T.38 UDPTL to improve
> reliability of fax transport, if gateways do not resend =
(=3D=3Dduplicate)
> fax packets, refer to explanation that I done in previous e-mails.
>=20
> The other open issue for T.38 over RTP is the time stamps for
redundant
> fax packets. The T.38 implementations are not dependant on time
stamps.
> So, the time offset fields required per RFC 2198 for redundant fax
> payloads are absolutely usefulness. There is no problem to ignore
these
> fields on receiving, but transmitting accurate offsets requires
> additional resources in gateways.
>=20
> Regards,
> Vladimir Ulybin
>=20
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Sunday, July 17, 2005 1:53 AM
> To: Vladimir Ulybin; 'Colin Perkins'
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Vladimir,
>=20
> I apologize that I missed much of this discussion while I was
traveling.
>=20
> The bottom line on this, though, is that T.38 over RTP should use
> whatever
> mechanisms are defined in the IETF for redundancy or FEC.  This might
> include RFC 2198, RFC 2733, or other tools that come along.  It's also
> expected that this will be the means by which security is provided for
> fax
> (SRTP).
>=20
> Is there a problem you see that is specific to fax?  Timing is
certainly
> an
> issue, but the delay should be no worse than UDPTL.  However, if there
> is a
> flaw somewhere, we should fix it sooner than later.
>=20
> Paul
>=20
>=20
> > -----Original Message-----
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
Of
> > Vladimir Ulybin
> > Sent: Monday, July 04, 2005 5:59 AM
> > To: Colin Perkins
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > On my suggestion from 3 Jul 2005, at 15:44:
> > >> I think we may use for RTP sequence number the same rules of
> > >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every
new
> > >> primary IFP packet and do not increment SN if a fax packet is
> > >> repeated.
> >
> > Colin Perkins wrote:
> > > Not if you wish to be compatible with RTP: RTP requires the
sequence
> > > numbers to be unique.
> >
> > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550
as
> a
> > basic RTP protocol to be used for encapsulation.
> > 2. The RFC 3550 does not define the packet repetition, also does not
> use
> > SHOULD or MUST for sequence number advances (in contrast to RFC
> 2833bis
> > were the MUST is used).
> > 3. Different RTP sequence numbers assigned to the same fax signal
> state
> > or the same binary data cannot be considered as unique.
> > 4. I try to find a more reliable transport for T.38 over RTP. The
> blind
> > assignment of new sequence numbers for ALL packets is full
compatible
> > with RFC 3550, but highly reduces the reliability of fax relay,
> because
> > gateways may not repeat fax packets.
> > 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> > only problem of packet repetition with the same SN is a distorted
RTCP
> > statistics. In absence of other ways this violation is better than
to
> > loose connection during fax relay.
> >
> > Regards,
> > Vladimir Ulybin
> >
> > _______________________________________________
> > 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 avt-bounces@ietf.org Mon Jul 18 03:24:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuPyz-0007Na-GY; Mon, 18 Jul 2005 03:24:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIHE-0003hF-QD
	for avt@megatron.ietf.org; Fri, 15 Jul 2005 00:58:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09176
	for <avt@ietf.org>; Fri, 15 Jul 2005 00:58:17 -0400 (EDT)
Received: from cgpsrv2.cis.mcmaster.ca ([130.113.64.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtIjx-00080f-El
	for avt@ietf.org; Fri, 15 Jul 2005 01:28:03 -0400
Received: from [130.113.23.184] (account kholaia@univmail.cis.mcmaster.ca)
	by cgpsrv2.cis.mcmaster.ca (CommuniGate Pro WebUser 4.1.8)
	with HTTP id 98626113 for avt@ietf.org; Fri, 15 Jul 2005 00:58:15 -0400
From: "A. Kholaif" <kholaia@univmail.cis.mcmaster.ca>
To: avt@ietf.org
X-Mailer: CommuniGate Pro WebUser Interface v.4.1.8
Date: Fri, 15 Jul 2005 00:58:15 -0400
Message-ID: <web-98626113@cgpsrv2.cis.mcmaster.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 18 Jul 2005 03:24:06 -0400
Subject: [AVT] Questions regrading VoIP, RTP, and SDP
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

I've got a technical question. In current basic/standard RTP
implementations, if IP-based devices normally receive RTP packets every
20ms, would they be happy if packets with twice the voice payload
started arriving every 40ms instead? and does this require any
additional mid-call SDP re-negotiations?

Also, does SDP allows for negotiating and specifying different values
of the packetization interval <ptime> for the upstream and downstream
legs of the same RTP audio connection? In other words, is it possible
for an IP phone to send audio RTP packets every 40 ms while receiving
audio packets every 20 ms?

Ahmad 


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



From avt-bounces@ietf.org Mon Jul 18 04:43:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuRDz-0008VW-Ni; Mon, 18 Jul 2005 04:43:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRDx-0008Ut-J5
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 04:43:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22848
	for <avt@ietf.org>; Mon, 18 Jul 2005 04:43:39 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuRhJ-0006Y2-Oz
	for avt@ietf.org; Mon, 18 Jul 2005 05:14:04 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Jul 2005 10:43:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C58B74.C9F5E9B2"
Date: Mon, 18 Jul 2005 10:43:36 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1014FD822@ftrdmel1.rd.francetelecom.fr>
X-MS-Has-Attach: yes
Thread-Topic: I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Thread-Index: AcWIu+sT9OzB4XJ1T7uPgfEp+JjVNgCt1Luw
From: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
To: "zzx-IETF-AVT" <avt@ietf.org>
X-OriginalArrivalTime: 18 Jul 2005 08:43:36.0227 (UTC)
	FILETIME=[C974CF30:01C58B74]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Subject: [AVT] TR: I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58B74.C9F5E9B2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I posted a -01 update of the RTP payload format for the future scalable =
and wideband extension of G.729 audio codec.

The major update is a simplification of the payload format. The payload =
header is no more optional and hence the (tricky) acknowledgement =
procedure has been removed. I added more spec on the MBS part.
The implementation should be now much easier.

Note that the ITU-T standardization of the codec is on schedule, it =
should be delivered at the end of 2005.

Comments are welcome.

Aurelien

-----Message d'origine-----
De : i-d-announce-bounces@ietf.org =
[mailto:i-d-announce-bounces@ietf.org] De la part de =
Internet-Drafts@ietf.org
Envoy=E9 : jeudi 14 juillet 2005 21:50
=C0 : i-d-announce@ietf.org
Objet : I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.


	Title		: RTP payload format for the future scalable and
                          wideband extension of G.729 audio codec
	Author(s)	: A. Sollaud
	Filename	: draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
	Pages		: 15
	Date		: 2005-7-14
=09
This document specifies a real-time transport protocol (RTP) payload
   format to be used for the future scalable and wideband extension of
   the International Telecommunication Union (ITU-T) G.729 audio codec.
   A media type registration is included for this payload format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-wb-ex=
t-01.txt


------_=_NextPart_001_01C58B74.C9F5E9B2
Content-Type: application/octet-stream;
	name="draft-sollaud-avt-rtp-g729-scal-wb-ext-01.URL"
Content-Description: draft-sollaud-avt-rtp-g729-scal-wb-ext-01.URL
Content-Disposition: attachment;
	filename="draft-sollaud-avt-rtp-g729-scal-wb-ext-01.URL"
Content-Transfer-Encoding: base64

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1zb2xsYXVkLWF2dC1ydHAtZzcyOS1zY2FsLXdiLWV4dC0wMS50eHQNCg==

------_=_NextPart_001_01C58B74.C9F5E9B2
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------_=_NextPart_001_01C58B74.C9F5E9B2--




From avt-bounces@ietf.org Mon Jul 18 04:50:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuRKM-0002Vq-RT; Mon, 18 Jul 2005 04:50:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRKL-0002Vl-O7
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 04:50:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23397
	for <avt@ietf.org>; Mon, 18 Jul 2005 04:50:15 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuRni-0007AJ-6X
	for avt@ietf.org; Mon, 18 Jul 2005 05:20:40 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 282B912D5
	for <avt@ietf.org>; Mon, 18 Jul 2005 10:50:12 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Jul 2005 10:50:11 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Jul 2005 10:50:11 +0200
Message-ID: <42DB6D41.5040109@ericsson.com>
Date: Mon, 18 Jul 2005 10:50:09 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Subject: [AVT] AVT meeting in Paris (IETF 63): Agenda Requests
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jul 2005 08:50:11.0431 (UTC)
	FILETIME=[B5042770:01C58B75]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi AVTers,

A reminder that those who haven't requested agenda time should do that 
Today.

Me and Colin has requested two slots for a total of 4.5 hours of meeting
time. We do not yet know when these slots will occur as scheduling is
ongoing. Please watch for the official schedule mails on the IETF
announcement list.

We chairs has already planned to use some of the AVT meeting time to
discuss the issue of media types registration for RTP payload formats.

So if you want time for discussing your issues in AVT. Then you are
required to request time. These request shall contain the below
information. Any agenda time request shall be sent to BOTH chairs before
the 24.00 CET the 18th of July.

A. Presentation Title:

B. Name of presenter:

C. Draft Reference(s):

D. Requested amount of time in minutes:

Cheers

Magnus Westerlund
AVT chair


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

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



From avt-bounces@ietf.org Mon Jul 18 07:28:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuTnR-0001VX-15; Mon, 18 Jul 2005 07:28:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuTnP-0001VS-0a
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 07:28:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02014
	for <avt@ietf.org>; Mon, 18 Jul 2005 07:28:26 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuUGn-0000dP-Qu
	for avt@ietf.org; Mon, 18 Jul 2005 07:58:51 -0400
Received: from csperkins.demon.co.uk ([193.237.26.84]:60749)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DuTn1-0001pj-FV; Mon, 18 Jul 2005 12:28:04 +0100
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E6D6@aclmsg.corp.audiocodes.com>
References: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E6D6@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BF3B4C34-CDBB-46A2-918F-4747D13A85BB@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Mon, 18 Jul 2005 12:27:51 +0100
To: "Vladimir Ulybin" <Vladimir@audiocodes.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit
Cc: "Paul E. Jones" <paulej@packetizer.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 18 Jul 2005, at 07:38, Vladimir Ulybin wrote:
> The term "basic configuration" for RFC 3550 plus redundancy per RFC  
> 2198
> should be replaced on "typical configuration". I assumed the same as
> you, that most gateways support this.
>
> As for the time stamps for redundant fax packets, the theory case  
> given
> is not relevant for T.38.
> 1. The ITU-T T.38 itself does not uses any time stamps both for
> redundant and primary packets. T.38 gateways transmitting fax signals
> should care about compatibility with T.30 but not with time stamps
> received from a remote gateway. The only important things are the
> content of fax packets and the real-time of receiving.
> 2. We say about new feature of T.38 over RTP which is to be added to
> existing (==working) T.38 UDPTL.
>
> My suggestion is to reserve (zero) time stamps for redundant packets
> when sending T.38 over RTP.

Which will break any conformant RTP implementation...  The timestamps  
may well be redundant for this particular media format, but they are  
trivial to calculate and required by RTP.

We well understand that, in many cases, it's possible to develop a  
more optimised format for a particular media type or application  
scenario. The value of the RTP standard comes not because it's always  
the optimal solution, but because it's an acceptable solution which  
everyone can implement, to gain economies of scale and increased  
interoperability across a range of problem domains. Adjustments of  
the type you suggest are often locally beneficial, but frequently  
harmful to overall interoperability and implementation complexity.

Colin

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



From avt-bounces@ietf.org Mon Jul 18 11:52:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuXum-00071j-KI; Mon, 18 Jul 2005 11:52:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXuk-00071b-Ip
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 11:52:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23245
	for <avt@ietf.org>; Mon, 18 Jul 2005 11:52:16 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuYOC-0002OC-ST
	for avt@ietf.org; Mon, 18 Jul 2005 12:22:45 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 18 Jul 2005 08:52:08 -0700
X-IronPort-AV: i="3.93,297,1115017200"; 
	d="scan'208"; a="198943354:sNHT26753252"
Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com
	[171.70.93.77])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6IFq66p009217;
	Mon, 18 Jul 2005 08:52:07 -0700 (PDT)
Received: from klantz-w2k02.cisco.com ([10.82.216.174]) by
	vtg-um-e2k6.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 18 Jul 2005 08:52:06 -0700
Message-Id: <6.2.1.2.2.20050718085026.03160368@vtg-um-e2k6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 18 Jul 2005 08:51:58 -0700
To: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
From: Keith Lantz <klantz@cisco.com>
Subject: Re: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1014FD822@ftrdmel1.rd.franc
	etelecom.fr>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1014FD822@ftrdmel1.rd.francetelecom.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-OriginalArrivalTime: 18 Jul 2005 15:52:06.0322 (UTC)
	FILETIME=[A5DDF920:01C58BB0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA23245
Cc: zzx-IETF-AVT <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Per the earlier "debate" on this list re VC-1, could you distribute or=20
otherwise point people at the current draft for the "G.729X" spec? (Unlik=
e=20
SMPTE, I've never heard anyone object to distribution of an ITU draft.)

Thx, Keith

At 01:43 AM 7/18/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
>Hi,
>
>I posted a -01 update of the RTP payload format for the future scalable=20
>and wideband extension of G.729 audio codec.
>
>The major update is a simplification of the payload format. The payload=20
>header is no more optional and hence the (tricky) acknowledgement=20
>procedure has been removed. I added more spec on the MBS part.
>The implementation should be now much easier.
>
>Note that the ITU-T standardization of the codec is on schedule, it shou=
ld=20
>be delivered at the end of 2005.
>
>Comments are welcome.
>
>Aurelien
>
>-----Message d'origine-----
>De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org=
]=20
>De la part de Internet-Drafts@ietf.org
>Envoy=E9 : jeudi 14 juillet 2005 21:50
>=C0 : i-d-announce@ietf.org
>Objet : I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts=20
>directories.
>
>
>         Title           : RTP payload format for the future scalable an=
d
>                           wideband extension of G.729 audio codec
>         Author(s)       : A. Sollaud
>         Filename        : draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>         Pages           : 15
>         Date            : 2005-7-14
>
>This document specifies a real-time transport protocol (RTP) payload
>    format to be used for the future scalable and wideband extension of
>    the International Telecommunication Union (ITU-T) G.729 audio codec.
>    A media type registration is included for this payload format.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-wb-e=
xt-01.txt
>
>

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



From avt-bounces@ietf.org Mon Jul 18 14:54:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Duakp-00028M-Lo; Mon, 18 Jul 2005 14:54:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Duako-00028H-D8
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 14:54:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05310
	for <avt@ietf.org>; Mon, 18 Jul 2005 14:54:13 -0400 (EDT)
Received: from dns.packetdesign.com ([65.192.41.10]
	helo=mailman.packetdesign.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DubEH-0004Ml-2F
	for avt@ietf.org; Mon, 18 Jul 2005 15:24: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
	j6IIrWa2095747; Mon, 18 Jul 2005 11:53:37 -0700 (PDT)
	(envelope-from casner@acm.org)
Date: Mon, 18 Jul 2005 11:53:24 -0700 (PDT)
From: Stephen Casner <casner@acm.org>
To: IETF AVT WG <avt@ietf.org>
In-Reply-To: <42DB6D41.5040109@ericsson.com>
Message-ID: <20050718113904.W5140@oak.packetdesign.com>
References: <42DB6D41.5040109@ericsson.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: [AVT] Media types registration (was: AVT meeting in Paris (IETF
 63): Agenda Requests)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On Mon, 18 Jul 2005, Magnus Westerlund wrote:

> We chairs has already planned to use some of the AVT meeting time to
> discuss the issue of media types registration for RTP payload formats.

I won't be in Paris to join in this discussion, but I am fully in
agreement with Magnus and Colin that the media types registration
process should remain as it is with RTP types as part of the MIME
registry.

Since the registration template is being modified by
draft-freed-media-type-reg-04.txt to include a new "Restrictions on
usage" field, I have submitted an update to RFC 3555 to revise the
method for registering RTP payload type names accordingly.  This is
draft-ietf-avt-rfc3555bis-00.txt.  The "Changes from RFC 3555" section
states:

    This document updates RFC 3555 to conform to the revised MIME type
    registration procedures in [2].  Whereas RFC 3555 required the
    encoding considerations to specify transfer via RTP, that is now
    specified under restrictions on usage.  This document also adds a
    new Section 2.1 to clarify the requirements for sharing a MIME
    type among RTP and non-RTP transfer methods.

The section 2.1 says:

    The same MIME type MUST NOT be shared for RTP and non-RTP
    (file-based) transfer methods unless the data format is the same
    for both methods.  The data format is considered to be same if the
    file format is equivalent to a concatenated sequence of payloads
    from RTP packets not including the RTP header or any
    payload-format header.

    The file format MAY include a magic number or other header at the
    start of the file that is not included when the data is
    transferred via RTP.

    A second requirement for sharing a MIME type is that the sets of
    required parameters must be the same for both methods.

    For cases where the data format or required parameters cannot be
    the same for RTP and non-RTP transfer methods, then the data
    formats MUST be registered as separate types.  It is RECOMMENDED
    that the type names be related, such as by using a common root
    plus a suffix.

I think this is all consistent with the way we have been operating in
AVT for some time.  However, the second of those paragraphs may be
controversial outside AVT.

                                                        -- Steve

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



From avt-bounces@ietf.org Mon Jul 18 16:02:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dubp9-0003UM-HH; Mon, 18 Jul 2005 16:02:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dubp6-0003UC-Hr
	for avt@megatron.ietf.org; Mon, 18 Jul 2005 16:02:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13249
	for <avt@ietf.org>; Mon, 18 Jul 2005 16:02:42 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com
	([24.199.146.6] helo=berlin.arid.us ident=system)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DucIa-0007hJ-UO
	for avt@ietf.org; Mon, 18 Jul 2005 16:33:13 -0400
Received: from madrid (madrid.arid.us [192.168.1.10])
	by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6IK2XSA023539;
	Mon, 18 Jul 2005 16:02:33 -0400
Message-Id: <200507182002.j6IK2XSA023539@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Vladimir Ulybin'" <Vladimir@audiocodes.com>,
	"'Colin Perkins'" <csp@csperkins.org>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Mon, 18 Jul 2005 16:02:27 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E6D6@aclmsg.corp.audiocodes.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAAuyJ8AAASU3nAAHppKkA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

Why use 0? Why not use the relevant offset from the clock time used in the
primary payload, as is done for audio?  Consistency is as important as many
other things.

Paul

> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Monday, July 18, 2005 2:38 AM
> To: Paul E. Jones; Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Paul,
> 
> The term "basic configuration" for RFC 3550 plus redundancy per RFC 2198
> should be replaced on "typical configuration". I assumed the same as
> you, that most gateways support this.
> 
> As for the time stamps for redundant fax packets, the theory case given
> is not relevant for T.38.
> 1. The ITU-T T.38 itself does not uses any time stamps both for
> redundant and primary packets. T.38 gateways transmitting fax signals
> should care about compatibility with T.30 but not with time stamps
> received from a remote gateway. The only important things are the
> content of fax packets and the real-time of receiving.
> 2. We say about new feature of T.38 over RTP which is to be added to
> existing (==working) T.38 UDPTL.
> 
> My suggestion is to reserve (zero) time stamps for redundant packets
> when sending T.38 over RTP.
> 
> Regards,
> Vladimir Ulybin
> 
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Monday, July 18, 2005 6:17 AM
> To: Vladimir Ulybin; 'Colin Perkins'
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Vladimir,
> 
> T.38 (2004) addresses the transport of T.38 over RTP and does not say
> that
> RFC 2198 is the basic configuration.  Both RFC 2198 and RFC 2733 are
> suggested as possible choices for protecting the media stream.
> 
> While T.38 data may not have the same kind of timing as, say, an audio
> codec, the fact that it is placed into a media stream means it needs a
> clock.  The draft I wrote suggests the use of an 8000hz clock or one
> that
> matches the primary audio codec.  In any case, the timing information
> would
> be meaningful.  In theory, one would not play out packets so quickly
> that a
> redundant piece of information received one or two packets later would
> be
> too old to be useful.
> 
> In any case, you are certainly free to use RFC 2198 or RFC 2733.  Most
> people I've talked to prefer RFC 2198, simply because of the
> computational
> complexity introduced by RFC 2733.  With that said, I've certainly not
> talked to every GW maker in the world ;-)
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> > Sent: Sunday, July 17, 2005 2:06 AM
> > To: Paul E. Jones; Colin Perkins
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Paul,
> >
> > Finally, for resending of T.38 packets over RTP, Colin suggested us to
> > use FEC per RFC 2733 or new retransmission protocol. Both ways present
> > optional features which may not be supported by gateways.
> >
> > Basic configuration for T.38 over RTP is a basic RFC 3550 plus
> > redundancy per RFC 2198.
> >
> > This configuration has limited capabilities vs. T.38 UDPTL to improve
> > reliability of fax transport, if gateways do not resend (==duplicate)
> > fax packets, refer to explanation that I done in previous e-mails.
> >
> > The other open issue for T.38 over RTP is the time stamps for
> redundant
> > fax packets. The T.38 implementations are not dependant on time
> stamps.
> > So, the time offset fields required per RFC 2198 for redundant fax
> > payloads are absolutely usefulness. There is no problem to ignore
> these
> > fields on receiving, but transmitting accurate offsets requires
> > additional resources in gateways.
> >
> > Regards,
> > Vladimir Ulybin
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > Sent: Sunday, July 17, 2005 1:53 AM
> > To: Vladimir Ulybin; 'Colin Perkins'
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Vladimir,
> >
> > I apologize that I missed much of this discussion while I was
> traveling.
> >
> > The bottom line on this, though, is that T.38 over RTP should use
> > whatever
> > mechanisms are defined in the IETF for redundancy or FEC.  This might
> > include RFC 2198, RFC 2733, or other tools that come along.  It's also
> > expected that this will be the means by which security is provided for
> > fax
> > (SRTP).
> >
> > Is there a problem you see that is specific to fax?  Timing is
> certainly
> > an
> > issue, but the delay should be no worse than UDPTL.  However, if there
> > is a
> > flaw somewhere, we should fix it sooner than later.
> >
> > Paul
> >
> >
> > > -----Original Message-----
> > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
> Of
> > > Vladimir Ulybin
> > > Sent: Monday, July 04, 2005 5:59 AM
> > > To: Colin Perkins
> > > Cc: avt@ietf.org
> > > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> > >
> > > On my suggestion from 3 Jul 2005, at 15:44:
> > > >> I think we may use for RTP sequence number the same rules of
> > > >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every
> new
> > > >> primary IFP packet and do not increment SN if a fax packet is
> > > >> repeated.
> > >
> > > Colin Perkins wrote:
> > > > Not if you wish to be compatible with RTP: RTP requires the
> sequence
> > > > numbers to be unique.
> > >
> > > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550
> as
> > a
> > > basic RTP protocol to be used for encapsulation.
> > > 2. The RFC 3550 does not define the packet repetition, also does not
> > use
> > > SHOULD or MUST for sequence number advances (in contrast to RFC
> > 2833bis
> > > were the MUST is used).
> > > 3. Different RTP sequence numbers assigned to the same fax signal
> > state
> > > or the same binary data cannot be considered as unique.
> > > 4. I try to find a more reliable transport for T.38 over RTP. The
> > blind
> > > assignment of new sequence numbers for ALL packets is full
> compatible
> > > with RFC 3550, but highly reduces the reliability of fax relay,
> > because
> > > gateways may not repeat fax packets.
> > > 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt the
> > > only problem of packet repetition with the same SN is a distorted
> RTCP
> > > statistics. In absence of other ways this violation is better than
> to
> > > loose connection during fax relay.
> > >
> > > Regards,
> > > Vladimir Ulybin
> > >
> > > _______________________________________________
> > > 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 avt-bounces@ietf.org Mon Jul 18 18:50:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DueRp-0002ai-4R; Mon, 18 Jul 2005 18:50:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DueR4-0002Nh-IU; Mon, 18 Jul 2005 18:50:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06986;
	Mon, 18 Jul 2005 18:50:02 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DueuW-0000r5-Ta; Mon, 18 Jul 2005 19:20:34 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DueR0-0008CJ-7h; Mon, 18 Jul 2005 18:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DueR0-0008CJ-7h@newodin.ietf.org>
Date: Mon, 18 Jul 2005 18:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-tfrc-profile-04.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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 Profile for TCP Friendly Rate Control
	Author(s)	: L. Gharai
	Filename	: draft-ietf-avt-tfrc-profile-04.txt
	Pages		: 13
	Date		: 2005-7-18
	
This memo specifies a profile called "RTP/AVPCC" for the use of the
   real-time transport protocol (RTP) and its associated control
   protocol, RTCP, with the TCP Friendly Rate Control (TFRC).  TFRC is
   an equation based congestion control scheme for unicast flows
   operating in a best effort Internet environment.  This profile
   provides RTP flows with the mechanism to use congestion control in
   best effort IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-tfrc-profile-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-tfrc-profile-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: <2005-7-18160836.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-tfrc-profile-04.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-avt-tfrc-profile-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-18160836.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Tue Jul 19 02:40:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dullu-0003Hs-GQ; Tue, 19 Jul 2005 02:40:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dulls-0003Hd-TE
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 02:40:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14021
	for <avt@ietf.org>; Tue, 19 Jul 2005 02:40:03 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DumFQ-0006bf-3W
	for avt@ietf.org; Tue, 19 Jul 2005 03:10:38 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Tue, 19 Jul 2005 09:40:13 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E9A2@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAAuyJ8AAASU3nAAHppKkAATWKKA
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Paul,

1. Zero is a simplest solution. The RFC 3550 allow the same time stamp
for several consecutive packets. So, when these packets will be
transmitted as redundant one relative to the other, the time offsets per
RFC 2198 will be zero. It means that receiving gateway should handle
correctly zero time offsets in RFC 2198 headers.

2. The computation of redundant packet time offset relative to primary
packet can be applied for synchronous operation like audio or
t4-non-ECM-data having a fixed time interval between packets. But, for
asynchronous packet stream, which is typical for T.30 control and ECM
fax, such approach cannot be used.

Why I opened this issue?

Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
packets ready for transmission to IP. To enable new feature of T.38 over
RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
DSP/gateway. The obstacle is in time stamp offsets of redundant packets.
We all (fax engineers) know that these offsets are not required at T.38
packet receivers. But accurate transmission of those per RFC 2198
requires deep re-writing of working and verified module(s) plus
additional allocation of RedundancyLevel*NofChannels timestamps.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Monday, July 18, 2005 11:02 PM
To: Vladimir Ulybin; 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Why use 0? Why not use the relevant offset from the clock time used in
the
primary payload, as is done for audio?  Consistency is as important as
many
other things.

Paul

> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Monday, July 18, 2005 2:38 AM
> To: Paul E. Jones; Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Paul,
>=20
> The term "basic configuration" for RFC 3550 plus redundancy per RFC
2198
> should be replaced on "typical configuration". I assumed the same as
> you, that most gateways support this.
>=20
> As for the time stamps for redundant fax packets, the theory case
given
> is not relevant for T.38.
> 1. The ITU-T T.38 itself does not uses any time stamps both for
> redundant and primary packets. T.38 gateways transmitting fax signals
> should care about compatibility with T.30 but not with time stamps
> received from a remote gateway. The only important things are the
> content of fax packets and the real-time of receiving.
> 2. We say about new feature of T.38 over RTP which is to be added to
> existing (=3D=3Dworking) T.38 UDPTL.
>=20
> My suggestion is to reserve (zero) time stamps for redundant packets
> when sending T.38 over RTP.
>=20
> Regards,
> Vladimir Ulybin
>=20
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Monday, July 18, 2005 6:17 AM
> To: Vladimir Ulybin; 'Colin Perkins'
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Vladimir,
>=20
> T.38 (2004) addresses the transport of T.38 over RTP and does not say
> that
> RFC 2198 is the basic configuration.  Both RFC 2198 and RFC 2733 are
> suggested as possible choices for protecting the media stream.
>=20
> While T.38 data may not have the same kind of timing as, say, an audio
> codec, the fact that it is placed into a media stream means it needs a
> clock.  The draft I wrote suggests the use of an 8000hz clock or one
> that
> matches the primary audio codec.  In any case, the timing information
> would
> be meaningful.  In theory, one would not play out packets so quickly
> that a
> redundant piece of information received one or two packets later would
> be
> too old to be useful.
>=20
> In any case, you are certainly free to use RFC 2198 or RFC 2733.  Most
> people I've talked to prefer RFC 2198, simply because of the
> computational
> complexity introduced by RFC 2733.  With that said, I've certainly not
> talked to every GW maker in the world ;-)
>=20
> Paul
>=20
>=20
> > -----Original Message-----
> > From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> > Sent: Sunday, July 17, 2005 2:06 AM
> > To: Paul E. Jones; Colin Perkins
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Paul,
> >
> > Finally, for resending of T.38 packets over RTP, Colin suggested us
to
> > use FEC per RFC 2733 or new retransmission protocol. Both ways
present
> > optional features which may not be supported by gateways.
> >
> > Basic configuration for T.38 over RTP is a basic RFC 3550 plus
> > redundancy per RFC 2198.
> >
> > This configuration has limited capabilities vs. T.38 UDPTL to
improve
> > reliability of fax transport, if gateways do not resend
(=3D=3Dduplicate)
> > fax packets, refer to explanation that I done in previous e-mails.
> >
> > The other open issue for T.38 over RTP is the time stamps for
> redundant
> > fax packets. The T.38 implementations are not dependant on time
> stamps.
> > So, the time offset fields required per RFC 2198 for redundant fax
> > payloads are absolutely usefulness. There is no problem to ignore
> these
> > fields on receiving, but transmitting accurate offsets requires
> > additional resources in gateways.
> >
> > Regards,
> > Vladimir Ulybin
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > Sent: Sunday, July 17, 2005 1:53 AM
> > To: Vladimir Ulybin; 'Colin Perkins'
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Vladimir,
> >
> > I apologize that I missed much of this discussion while I was
> traveling.
> >
> > The bottom line on this, though, is that T.38 over RTP should use
> > whatever
> > mechanisms are defined in the IETF for redundancy or FEC.  This
might
> > include RFC 2198, RFC 2733, or other tools that come along.  It's
also
> > expected that this will be the means by which security is provided
for
> > fax
> > (SRTP).
> >
> > Is there a problem you see that is specific to fax?  Timing is
> certainly
> > an
> > issue, but the delay should be no worse than UDPTL.  However, if
there
> > is a
> > flaw somewhere, we should fix it sooner than later.
> >
> > Paul
> >
> >
> > > -----Original Message-----
> > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
> Of
> > > Vladimir Ulybin
> > > Sent: Monday, July 04, 2005 5:59 AM
> > > To: Colin Perkins
> > > Cc: avt@ietf.org
> > > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> > >
> > > On my suggestion from 3 Jul 2005, at 15:44:
> > > >> I think we may use for RTP sequence number the same rules of
> > > >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every
> new
> > > >> primary IFP packet and do not increment SN if a fax packet is
> > > >> repeated.
> > >
> > > Colin Perkins wrote:
> > > > Not if you wish to be compatible with RTP: RTP requires the
> sequence
> > > > numbers to be unique.
> > >
> > > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550
> as
> > a
> > > basic RTP protocol to be used for encapsulation.
> > > 2. The RFC 3550 does not define the packet repetition, also does
not
> > use
> > > SHOULD or MUST for sequence number advances (in contrast to RFC
> > 2833bis
> > > were the MUST is used).
> > > 3. Different RTP sequence numbers assigned to the same fax signal
> > state
> > > or the same binary data cannot be considered as unique.
> > > 4. I try to find a more reliable transport for T.38 over RTP. The
> > blind
> > > assignment of new sequence numbers for ALL packets is full
> compatible
> > > with RFC 3550, but highly reduces the reliability of fax relay,
> > because
> > > gateways may not repeat fax packets.
> > > 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt
the
> > > only problem of packet repetition with the same SN is a distorted
> RTCP
> > > statistics. In absence of other ways this violation is better than
> to
> > > loose connection during fax relay.
> > >
> > > Regards,
> > > Vladimir Ulybin
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/avt
>=20



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



From avt-bounces@ietf.org Tue Jul 19 05:36:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DuoWs-0000No-2A; Tue, 19 Jul 2005 05:36:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuoWq-0000Ng-MH
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 05:36:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24914
	for <avt@ietf.org>; Tue, 19 Jul 2005 05:36:42 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dup0S-0005IT-5Y
	for avt@ietf.org; Tue, 19 Jul 2005 06:07:20 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 19 Jul 2005 11:36:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Date: Tue, 19 Jul 2005 11:36:12 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1015500EE@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Thread-Index: AcWLsKUClrHJs8BISOemzS8RpExwfQAkk3RA
From: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
To: "Keith Lantz" <klantz@cisco.com>
X-OriginalArrivalTime: 19 Jul 2005 09:36:13.0800 (UTC)
	FILETIME=[4DEDF680:01C58C45]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: quoted-printable
Cc: zzx-IETF-AVT <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi

This codec is discussed in the Study Group 16 / Question 10 of the =
ITU-T, about maintenance and extension of existing voice coding standard =
(here G.729).
The reports and work documents are not publicly available, you have to =
be a member.

The background information presented in Section 2 of the draft is drawn =
from the Terms of Reference of the codec and should hopefully be enough =
"to conduct a meaningful review" ((c)Colin).
The payload format is independent from the algorithmic details of the =
codec, and hence from the final candidate chosen as the standard. The =
useful information is provided in the draft: sampling rate, bit rates, =
embedded scheme...

Aurelien

-----Message d'origine-----
De : Keith Lantz [mailto:klantz@cisco.com]=20
Envoy=E9 : lundi 18 juillet 2005 17:52
=C0 : SOLLAUD Aurelien RD-TECH-LAN
Cc : zzx-IETF-AVT
Objet : Re: [AVT] TR: I-D =
ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt=20

Per the earlier "debate" on this list re VC-1, could you distribute or =
otherwise point people at the current draft for the "G.729X" spec? =
(Unlike SMPTE, I've never heard anyone object to distribution of an ITU =
draft.)

Thx, Keith

At 01:43 AM 7/18/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
>Hi,
>
>I posted a -01 update of the RTP payload format for the future scalable =

>and wideband extension of G.729 audio codec.
>
>The major update is a simplification of the payload format. The payload =

>header is no more optional and hence the (tricky) acknowledgement=20
>procedure has been removed. I added more spec on the MBS part.
>The implementation should be now much easier.
>
>Note that the ITU-T standardization of the codec is on schedule, it=20
>should be delivered at the end of 2005.
>
>Comments are welcome.
>
>Aurelien
>
>-----Message d'origine-----
>De : i-d-announce-bounces@ietf.org=20
>[mailto:i-d-announce-bounces@ietf.org]
>De la part de Internet-Drafts@ietf.org
>Envoy=E9 : jeudi 14 juillet 2005 21:50
>=C0 : i-d-announce@ietf.org
>Objet : I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts=20
>directories.
>
>
>         Title           : RTP payload format for the future scalable =
and
>                           wideband extension of G.729 audio codec
>         Author(s)       : A. Sollaud
>         Filename        : =
draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>         Pages           : 15
>         Date            : 2005-7-14
>
>This document specifies a real-time transport protocol (RTP) payload
>    format to be used for the future scalable and wideband extension of
>    the International Telecommunication Union (ITU-T) G.729 audio =
codec.
>    A media type registration is included for this payload format.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-wb-
>ext-01.txt
>
>

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



From avt-bounces@ietf.org Tue Jul 19 07:07:31 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dupwh-0000X0-Nx; Tue, 19 Jul 2005 07:07:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dupwf-0000Wt-52
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 07:07:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01573
	for <avt@ietf.org>; Tue, 19 Jul 2005 07:07:26 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuqQG-0000vZ-DL
	for avt@ietf.org; Tue, 19 Jul 2005 07:38:05 -0400
Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:62216)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DupwT-00067U-Ii; Tue, 19 Jul 2005 12:07:17 +0100
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E9A2@aclmsg.corp.audiocodes.com>
References: <79B4F738DDD4EF4F85A4641A0FE5EFD60126E9A2@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5F071796-1BC9-45AC-BA3C-C5F6DA646444@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Tue, 19 Jul 2005 12:07:14 +0100
To: Vladimir Ulybin <Vladimir@audiocodes.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: "Paul E. Jones" <paulej@packetizer.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote:
> 1. Zero is a simplest solution. The RFC 3550 allow the same time stamp
> for several consecutive packets. So, when these packets will be
> transmitted as redundant one relative to the other, the time  
> offsets per
> RFC 2198 will be zero. It means that receiving gateway should handle
> correctly zero time offsets in RFC 2198 headers.

No, since it will treat the data as being a redundant copy of the  
packet in which it is sent. If you use an offset of zero, there's no  
way to correctly place the data at the right time instant in the  
playout buffer.

> 2. The computation of redundant packet time offset relative to primary
> packet can be applied for synchronous operation like audio or
> t4-non-ECM-data having a fixed time interval between packets. But, for
> asynchronous packet stream, which is typical for T.30 control and ECM
> fax, such approach cannot be used.

Correct - this is why RFC 2198 has an explicit timestamp for the  
redundancy offset.

> Why I opened this issue?
>
> Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
> packets ready for transmission to IP. To enable new feature of T.38  
> over
> RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
> DSP/gateway. The obstacle is in time stamp offsets of redundant  
> packets.
> We all (fax engineers) know that these offsets are not required at  
> T.38
> packet receivers. But accurate transmission of those per RFC 2198
> requires deep re-writing of working and verified module(s) plus
> additional allocation of RedundancyLevel*NofChannels timestamps.

Correct - this is required for robust operation over an unreliable  
packet network that may disrupt media timing.

There are two cases:

1) There is a constant mapping from sequence number to timestamp. In  
this case, you can trivially calculate the timestamp and need no  
extra storage. The media timing can be reconstructed using either the  
sequence number or timestamp, and transporting both is essentially a  
waste of bandwidth for this application. In this case, you treat the  
extra bits on the wire as an "RTP tax" needed for interoperability,  
but don't need to store the extra data in the gateway.

2) There is not a constant mapping from sequence number to timestamp.  
This case requires you to store the extra timestamps for inclusion in  
RFC 2198 redundancy headers, however that extra information is  
required by the receiver to manage a playout buffer, since a playout  
buffer managed by sequence number only is not sufficient to  
reconstruct media timing.

Colin

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



From avt-bounces@ietf.org Tue Jul 19 08:24:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dur9L-0006Tu-Ed; Tue, 19 Jul 2005 08:24:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dur9K-0006Tp-Q6
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 08:24:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08396
	for <avt@ietf.org>; Tue, 19 Jul 2005 08:24:37 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Durcw-0004Tq-VS
	for avt@ietf.org; Tue, 19 Jul 2005 08:55:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Tue, 19 Jul 2005 15:24:55 +0300
Message-ID: <EF8DFB1B64FF0A43AB00555B8E2717B101D7A613@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWAdVcEdc3rCQYPRKiN3Atvb0ZodgAALpjwAniuk3AADKWiIAAuyJ8AAASU3nAAHppKkAATWKKAAAjY1nA=
From: "Oren Peleg" <OrenP@audiocodes.com>
To: "Vladimir Ulybin" <Vladimir@audiocodes.com>,
	"Paul E. Jones" <paulej@packetizer.com>,
	"Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I would like to suggest the following:

Since Timestamp is profile specific, the T.38 RTP profile draft
(currently draft-jones-avt-audio-t38-05.txt) will add a special case of
Timestamp manipulation which will be used for redundant control packet
transmission (similar to the End packet of the RFC 2833 event). At this
special case the timestamp that will be used at the redundant packets
will be the same as the timestamp of the original packet. The number of
redundant packets will be determined via SDP using a special parameter.

Oren P.

-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
Vladimir Ulybin
Sent: Tuesday, July 19, 2005 9:40 AM
To: Paul E. Jones; Colin Perkins
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Paul,

1. Zero is a simplest solution. The RFC 3550 allow the same time stamp
for several consecutive packets. So, when these packets will be
transmitted as redundant one relative to the other, the time offsets per
RFC 2198 will be zero. It means that receiving gateway should handle
correctly zero time offsets in RFC 2198 headers.

2. The computation of redundant packet time offset relative to primary
packet can be applied for synchronous operation like audio or
t4-non-ECM-data having a fixed time interval between packets. But, for
asynchronous packet stream, which is typical for T.30 control and ECM
fax, such approach cannot be used.

Why I opened this issue?

Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
packets ready for transmission to IP. To enable new feature of T.38 over
RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
DSP/gateway. The obstacle is in time stamp offsets of redundant packets.
We all (fax engineers) know that these offsets are not required at T.38
packet receivers. But accurate transmission of those per RFC 2198
requires deep re-writing of working and verified module(s) plus
additional allocation of RedundancyLevel*NofChannels timestamps.

Regards,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Monday, July 18, 2005 11:02 PM
To: Vladimir Ulybin; 'Colin Perkins'
Cc: avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Why use 0? Why not use the relevant offset from the clock time used in
the
primary payload, as is done for audio?  Consistency is as important as
many
other things.

Paul

> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Monday, July 18, 2005 2:38 AM
> To: Paul E. Jones; Colin Perkins
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Paul,
>=20
> The term "basic configuration" for RFC 3550 plus redundancy per RFC
2198
> should be replaced on "typical configuration". I assumed the same as
> you, that most gateways support this.
>=20
> As for the time stamps for redundant fax packets, the theory case
given
> is not relevant for T.38.
> 1. The ITU-T T.38 itself does not uses any time stamps both for
> redundant and primary packets. T.38 gateways transmitting fax signals
> should care about compatibility with T.30 but not with time stamps
> received from a remote gateway. The only important things are the
> content of fax packets and the real-time of receiving.
> 2. We say about new feature of T.38 over RTP which is to be added to
> existing (=3D=3Dworking) T.38 UDPTL.
>=20
> My suggestion is to reserve (zero) time stamps for redundant packets
> when sending T.38 over RTP.
>=20
> Regards,
> Vladimir Ulybin
>=20
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Monday, July 18, 2005 6:17 AM
> To: Vladimir Ulybin; 'Colin Perkins'
> Cc: avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Vladimir,
>=20
> T.38 (2004) addresses the transport of T.38 over RTP and does not say
> that
> RFC 2198 is the basic configuration.  Both RFC 2198 and RFC 2733 are
> suggested as possible choices for protecting the media stream.
>=20
> While T.38 data may not have the same kind of timing as, say, an audio
> codec, the fact that it is placed into a media stream means it needs a
> clock.  The draft I wrote suggests the use of an 8000hz clock or one
> that
> matches the primary audio codec.  In any case, the timing information
> would
> be meaningful.  In theory, one would not play out packets so quickly
> that a
> redundant piece of information received one or two packets later would
> be
> too old to be useful.
>=20
> In any case, you are certainly free to use RFC 2198 or RFC 2733.  Most
> people I've talked to prefer RFC 2198, simply because of the
> computational
> complexity introduced by RFC 2733.  With that said, I've certainly not
> talked to every GW maker in the world ;-)
>=20
> Paul
>=20
>=20
> > -----Original Message-----
> > From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> > Sent: Sunday, July 17, 2005 2:06 AM
> > To: Paul E. Jones; Colin Perkins
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Paul,
> >
> > Finally, for resending of T.38 packets over RTP, Colin suggested us
to
> > use FEC per RFC 2733 or new retransmission protocol. Both ways
present
> > optional features which may not be supported by gateways.
> >
> > Basic configuration for T.38 over RTP is a basic RFC 3550 plus
> > redundancy per RFC 2198.
> >
> > This configuration has limited capabilities vs. T.38 UDPTL to
improve
> > reliability of fax transport, if gateways do not resend
(=3D=3Dduplicate)
> > fax packets, refer to explanation that I done in previous e-mails.
> >
> > The other open issue for T.38 over RTP is the time stamps for
> redundant
> > fax packets. The T.38 implementations are not dependant on time
> stamps.
> > So, the time offset fields required per RFC 2198 for redundant fax
> > payloads are absolutely usefulness. There is no problem to ignore
> these
> > fields on receiving, but transmitting accurate offsets requires
> > additional resources in gateways.
> >
> > Regards,
> > Vladimir Ulybin
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> > Sent: Sunday, July 17, 2005 1:53 AM
> > To: Vladimir Ulybin; 'Colin Perkins'
> > Cc: avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Vladimir,
> >
> > I apologize that I missed much of this discussion while I was
> traveling.
> >
> > The bottom line on this, though, is that T.38 over RTP should use
> > whatever
> > mechanisms are defined in the IETF for redundancy or FEC.  This
might
> > include RFC 2198, RFC 2733, or other tools that come along.  It's
also
> > expected that this will be the means by which security is provided
for
> > fax
> > (SRTP).
> >
> > Is there a problem you see that is specific to fax?  Timing is
> certainly
> > an
> > issue, but the delay should be no worse than UDPTL.  However, if
there
> > is a
> > flaw somewhere, we should fix it sooner than later.
> >
> > Paul
> >
> >
> > > -----Original Message-----
> > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf
> Of
> > > Vladimir Ulybin
> > > Sent: Monday, July 04, 2005 5:59 AM
> > > To: Colin Perkins
> > > Cc: avt@ietf.org
> > > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> > >
> > > On my suggestion from 3 Jul 2005, at 15:44:
> > > >> I think we may use for RTP sequence number the same rules of
> > > >> incrementing as for T.38 UDPTL SN, i.e. increment SN per every
> new
> > > >> primary IFP packet and do not increment SN if a fax packet is
> > > >> repeated.
> > >
> > > Colin Perkins wrote:
> > > > Not if you wish to be compatible with RTP: RTP requires the
> sequence
> > > > numbers to be unique.
> > >
> > > 1. The current T.38 Rec. defining T.38 over RTP refers to RFC 3550
> as
> > a
> > > basic RTP protocol to be used for encapsulation.
> > > 2. The RFC 3550 does not define the packet repetition, also does
not
> > use
> > > SHOULD or MUST for sequence number advances (in contrast to RFC
> > 2833bis
> > > were the MUST is used).
> > > 3. Different RTP sequence numbers assigned to the same fax signal
> > state
> > > or the same binary data cannot be considered as unique.
> > > 4. I try to find a more reliable transport for T.38 over RTP. The
> > blind
> > > assignment of new sequence numbers for ALL packets is full
> compatible
> > > with RFC 3550, but highly reduces the reliability of fax relay,
> > because
> > > gateways may not repeat fax packets.
> > > 5. As I understand from draft-ietf-avt-rtp-retransmission-11.txt
the
> > > only problem of packet repetition with the same SN is a distorted
> RTCP
> > > statistics. In absence of other ways this violation is better than
> to
> > > loose connection during fax relay.
> > >
> > > Regards,
> > > Vladimir Ulybin
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/avt
>=20



_______________________________________________
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 avt-bounces@ietf.org Tue Jul 19 08:33:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DurIJ-0000Uo-UI; Tue, 19 Jul 2005 08:33:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DurII-0000Uj-P5
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 08:33:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09069
	for <avt@ietf.org>; Tue, 19 Jul 2005 08:33:53 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Durlv-0004pL-Hs
	for avt@ietf.org; Tue, 19 Jul 2005 09:04:32 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7E36BF48; 
	Tue, 19 Jul 2005 14:33:40 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 19 Jul 2005 14:33:39 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 19 Jul 2005 14:33:39 +0200
Message-ID: <42DCF323.9030408@ericsson.com>
Date: Tue, 19 Jul 2005 14:33:39 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Jul 2005 12:33:39.0545 (UTC)
	FILETIME=[1749BC90:01C58C5E]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 2.0 (++)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Content-Transfer-Encoding: 7bit
Cc: Colin Perkins <csp@csperkins.org>
Subject: [AVT] Preliminary AVT agenda
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

Below you will find a preliminary AVT agenda. It is based on the latest 
draft meeting agenda and the days and times are not yet certain to be 
correct. Do NOT plan your travel based on them.

If you find any issues or have corrections please send them as soon as 
possible to us chairs. Due to that we only received 3 out of the 4.5 
hours requested we will be need to concentrate on the most important 
issues. If you haven't requested agenda time yet, it will be difficult 
to make time in the agenda but please send a request so that we can 
discuss it.

Cheers

Magnus

-------------------------------------

Audio/Video Transport Working Group

CHAIRS: Colin Perkins     <csp@csperkins.org>
         Magnus Westerlund <magnus.westerlund@ericsson.com>

Tuesday, 2 August 2005, 10:30-12:30
====================================

Introduction and Status Update                                 (Chairs)
                                                                 10 min
    Under development:
          draft-ietf-avt-mime-h224-02
          draft-ietf-avt-profile-savpf-02
          draft-ietf-avt-rtcpssm-09
          draft-ietf-avt-rfc2032-bis-06
          draft-ietf-avt-rfc2190-to-historic-03
          draft-ietf-avt-rfc2429-bis-05
          draft-ietf-avt-rfc2833bis-09
          draft-ietf-avt-rfc2833biscas-00
          draft-ietf-avt-rfc2833bisdata-02
          draft-ietf-avt-rfc3555bis-00
          draft-ietf-avt-rtcp-xr-mib-02
          draft-ietf-avt-rtp-amr-bis-01
          draft-ietf-avt-rtp-atrac-family-04
          draft-ietf-avt-rtp-jpeg2000-08
          draft-ietf-avt-rtp-jpeg2000-beam-01
          draft-ietf-avt-rtp-midi-format-10
          draft-ietf-avt-rtp-midi-guidelines-10
          draft-ietf-avt-rtp-no-op-00
          draft-ietf-avt-rtp-vmr-wb-extension-00
          draft-ietf-avt-tfrc-profile-04
          draft-ietf-avt-ulp-11

          draft-ietf-avt-rfc3119bis-03 (Expired)
          draft-finlayson-avt-mpa-robust-interoperability-01 (Expired)
          draft-ietf-avt-uxp-07 (Expired)
          draft-ietf-avt-variable-rate-audio-00     (Expired)

    AD or IESG Evaluation
          draft-ietf-avt-audio-t140c-00
          draft-ietf-avt-rtp-retransmission-11
          draft-ietf-avt-rtp-framing-contrans-05
          draft-ietf-avt-rtp-vmr-wb-10
          draft-ietf-avt-3gpp-timed-text-15
          draft-ietf-avt-rtp-ac3-07
          draft-ietf-avt-rtp-amrwbplus-06
          draft-jones-avt-audio-t38-05
          draft-garudadri-avt-3gpp2-mime-02
          draft-lim-mpeg4-mime-03

    RFC Editor:
          draft-ietf-avt-hc-mpls-reqs-03
          draft-ietf-avt-rtcp-feedback-11
          draft-burmeister-avt-rtcp-feedback-sim-06
          draft-ietf-avt-rtp-bv-03
          draft-ietf-avt-tcrtp-08
          draft-ietf-avt-uncomp-video-06

    Published RFCs
          draft-ietf-avt-rtp-clearmode-05      -> RFC 4040
          draft-ietf-avt-rtp-dsr-codecs-03     -> RFC 4060
          draft-ietf-avt-text-red-05           -> RFC 4102
          draft-ietf-avt-rfc2793bis-09         -> RFC 4103

    Individual drafts with AVT relation
          draft-ash-avt-hc-over-mpls-protocol-01
          draft-clark-avt-rtcpxr-bis-00
          draft-even-avt-rfc3047-bis-01
          draft-feiten-avt-bsacmode-for-rfc3640-00
          draft-kerr-avt-vorbis-rtp-04
          draft-klemets-avt-rtp-vc1-00
          draft-koren-avt-ecrtp-reorder-00
          draft-lennox-avt-app-sharing-00
          draft-lkchoi-avt-iptvdbs-req-00
          draft-perkins-avt-uncomp-video-ext-00
          draft-singer-rtp-hdrext-00
          draft-singer-smpte-rtp-01
          draft-sollaud-avt-rtp-g729-scal-wb-ext-01
          draft-stirbu-avt-lrdp-00
          draft-vitali-ietf-avt-mdc-lc-00
          draft-wenger-avt-avpf-ccm-00
          draft-xie-avt-compact-bundle-evrc-00
          draft-xie-avt-rtp-anti-shadow-01

Compact Bundled RTP Format for EVRC Speech                         (Xie)
    draft-xie-avt-compact-bundle-evrc-00                           15 min

RTP Payload Format for Video Codec 1 (VC-1)                    (Klemets)
    draft-klemets-avt-rtp-vc1-00                                   15 min

Update of ITU G.722.1 payload format                              (Even)
    draft-even-avt-rfc3047-bis-01                                  10 min

RTP Payload Format for ECN Probing                            (Alexander)
    draft-alexander-rtp-payload-for-ecn-probing-01                 10 min
    draft-babiarz-tsvwg-rtecn-04
    draft-alexander-rtecn-use-cases-00
    draft-alexander-congestion-status-preconditions-00

Protocol Extensions for Header Compression over MPLS               (Ash)
    draft-ash-avt-hc-over-mpls-protocol-01                         15 min

RTP Profile for TCP Friendly Rate Control                       (Gharai)
    draft-ietf-avt-tfrc-profile-04                                 15 min

Strategies for Streaming Media Applications Using TFRC          (Phelan)
    draft-ietf-dccp-tfrc-media-00                                  15 min

FEC streaming framework                                         (Watson)
    draft-watson-tsvwg-fec-sf-00                                   15 min



Wednesday, 3 August 2005, 9:00-10:00
====================================

RTCP XR VoIP Metrics Management Information Base                 (Clark)
    draft-avt-rtcp-xr-mib-02                                       10 min

RTCP XR - New Parameter Extensions                               (Clark)
    draft-clark-avt-rtcpxr-bis-00                                  10 min

Open issues with Codec Control Messages in AVPF                 (Wenger)
    draft-wenger-avt-avpf-ccm-00                                   15 min

Media Type Discussion                                           (chairs)
    draft-ietf-avt-rfc3555bis-00                                   15 min
    draft-freed-media-type-reg-04
    Mailing list discussion

RTCP Extensions for SSM sessions with unicast feedback             (Ott)
    draft-ietf-avt-rtcpssm-09                                      10 min


-- 

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 avt-bounces@ietf.org Tue Jul 19 08:45:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DurTu-0003st-HE; Tue, 19 Jul 2005 08:45:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DurTm-0003fR-Dz
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 08:45:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09768
	for <avt@ietf.org>; Tue, 19 Jul 2005 08:45:44 -0400 (EDT)
Received: from fra-del-04.spheriq.net ([195.46.51.100])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DurxP-0005Cf-7w
	for avt@ietf.org; Tue, 19 Jul 2005 09:16:23 -0400
Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131])
	by fra-del-04.spheriq.net with ESMTP id j6JCjJAV016812
	for <avt@ietf.org>; Tue, 19 Jul 2005 12:45:19 GMT
Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38])
	by fra-out-03.spheriq.net with ESMTP id j6JCjIt9007358
	for <avt@ietf.org>; Tue, 19 Jul 2005 12:45:18 GMT
Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35])
	by fra-cus-02.spheriq.net with ESMTP id j6JCjHOo012830
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <avt@ietf.org>; Tue, 19 Jul 2005 12:45:17 GMT
Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9])
	by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0F3FDDA42
	for <avt@ietf.org>; Tue, 19 Jul 2005 12:45:17 +0000 (GMT)
Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012)
	id BB978478BA; Tue, 19 Jul 2005 12:47:19 +0000 (GMT)
Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1])
	by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 75F66759AF
	for <avt@ietf.org>; Tue, 19 Jul 2005 12:47:19 +0000 (UTC)
Received: from mail1.agr.st.com (mail1.agr.st.com [164.130.4.71])
	by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9E4D9478C3
	for <avt@ietf.org>; Tue, 19 Jul 2005 12:47:18 +0000 (GMT)
Received: from [10.50.13.70] (ws2586.agr.st.com [10.50.13.70])
	by mail1.agr.st.com (MOS 3.4.4-GR)
	with ESMTP id BNO01925 (AUTH "andrea vitali");
	Tue, 19 Jul 2005 14:45:10 +0200 (CEST)
Message-ID: <42DCF5D5.5020400@st.com>
Date: Tue, 19 Jul 2005 14:45:09 +0200
From: Andrea Lorenzo VITALI <andrea.vitali@st.com>
Organization: STMicroelectronics
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en,ru,zh
MIME-Version: 1.0
To: avt@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-O-General-Status: No
X-O-Spam1-Status: Not Scanned
X-O-Spam2-Status: Not Scanned
X-O-URL-Status: Not Scanned
X-O-Virus1-Status: No
X-O-Virus2-Status: Not Scanned
X-O-Virus3-Status: No
X-O-Virus4-Status: No
X-O-Virus5-Status: Not Scanned
X-O-Image-Status: Not Scanned
X-O-Attach-Status: Not Scanned
X-SpheriQ-Ver: 2.2.3
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Subject: [AVT] Multiple Description / Layered video coding,
	draft-vitali-ietf-avt-mdc-lc-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Dear AVTers,

We have recently submitted a new internet draft on Standard-compatible Multiple 
Description and Layered video coding (MDC/LC). The goal is to allow a graceful 
degradation of the application quality with increasing packet loss rate and 
decreasing bandwidth/throughput on the network.

You can find the draft at:
   ftp://ftp.ietf.org/internet-drafts/draft-vitali-ietf-avt-mdc-lc-00.txt

In the proposed scheme, descriptions/layers are created and merged in the pixel
domain as follows:


            +--> filter     --> enc/dec --> upsampler -->+
            |    & downsampler              & filter     |
            |                                            |
   video -->o--> filter     --> enc/dec --> upsampler -->sum --> video
   input    :    & downsampler              & filter     :       output
            :                                            :
            +---> ...       --> ...     --> ...       -->+


This scheme covers video balanced MD, unbalanced MD, wavelet layered 
decomposition, etc. Audio is still an open issue.

In the draft we propose to use SDP to describe how descriptions/layers are
created and how they can be merged.

Descriptions/layers are compressed using existing codecs: MPEG-2, H.264...
Bitstreams are sent according to existing standards, i.e. the usual RTP/UDP.

We are looking forward to hearing feedbacks on this.

   Andrea Vitali

-- 
  ______________________________________________________________

   Andrea VITALI                            andrea.vitali@st.com

   tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
   fax (+39) 039 603 6129

   STMicroelectronics
   Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
   20041 Agrate Brianza (MI) ITALY
  ______________________________________________________________


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



From avt-bounces@ietf.org Tue Jul 19 10:45:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DutM0-0007kv-AF; Tue, 19 Jul 2005 10:45:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DutLy-0007jz-9u
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 10:45:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19800
	for <avt@ietf.org>; Tue, 19 Jul 2005 10:45:47 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dutpa-0001mr-Vs
	for avt@ietf.org; Tue, 19 Jul 2005 11:16:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Tue, 19 Jul 2005 17:45:50 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EB68@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWMUiCVnmTzfjJsQhmV+LeSb9/XIgAGgaLw
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: quoted-printable
Cc: "Paul E. Jones" <paulej@packetizer.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Colin,

I think that the use of timestamps together with sequence numbers for
building T.38 packet recovery buffer is not a good way. For T.38
INDICATOR packets it is acceptable but for DATA packets this way may
cause a lot of problems for packet recovery during data transfer.

It is much easy and reliable to use RTP sequence number as the only base
for ordering T.38 packets arrived over RTP. In this case, timestamps of
redundant payloads may be ignored without any problems.

Let consider an option to update the "draft-jones-avt-audio-t38-05.txt"
or write a new draft for T.38 over RTP.

I think the problems opened in our discussions=20
- repetition of T.38 packets and=20
- excessive complexity of T.38 over RTP caused by timestamps
(non-required by T.38)
are general for different vendors.

Regards,
Vladimir Ulybin


-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]=20
Sent: Tuesday, July 19, 2005 2:07 PM
To: Vladimir Ulybin
Cc: Paul E. Jones; avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote:
> 1. Zero is a simplest solution. The RFC 3550 allow the same time stamp
> for several consecutive packets. So, when these packets will be
> transmitted as redundant one relative to the other, the time =20
> offsets per
> RFC 2198 will be zero. It means that receiving gateway should handle
> correctly zero time offsets in RFC 2198 headers.

No, since it will treat the data as being a redundant copy of the =20
packet in which it is sent. If you use an offset of zero, there's no =20
way to correctly place the data at the right time instant in the =20
playout buffer.

> 2. The computation of redundant packet time offset relative to primary
> packet can be applied for synchronous operation like audio or
> t4-non-ECM-data having a fixed time interval between packets. But, for
> asynchronous packet stream, which is typical for T.30 control and ECM
> fax, such approach cannot be used.

Correct - this is why RFC 2198 has an explicit timestamp for the =20
redundancy offset.

> Why I opened this issue?
>
> Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
> packets ready for transmission to IP. To enable new feature of T.38 =20
> over
> RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
> DSP/gateway. The obstacle is in time stamp offsets of redundant =20
> packets.
> We all (fax engineers) know that these offsets are not required at =20
> T.38
> packet receivers. But accurate transmission of those per RFC 2198
> requires deep re-writing of working and verified module(s) plus
> additional allocation of RedundancyLevel*NofChannels timestamps.

Correct - this is required for robust operation over an unreliable =20
packet network that may disrupt media timing.

There are two cases:

1) There is a constant mapping from sequence number to timestamp. In =20
this case, you can trivially calculate the timestamp and need no =20
extra storage. The media timing can be reconstructed using either the =20
sequence number or timestamp, and transporting both is essentially a =20
waste of bandwidth for this application. In this case, you treat the =20
extra bits on the wire as an "RTP tax" needed for interoperability, =20
but don't need to store the extra data in the gateway.

2) There is not a constant mapping from sequence number to timestamp. =20
This case requires you to store the extra timestamps for inclusion in =20
RFC 2198 redundancy headers, however that extra information is =20
required by the receiver to manage a playout buffer, since a playout =20
buffer managed by sequence number only is not sufficient to =20
reconstruct media timing.

Colin

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



From avt-bounces@ietf.org Tue Jul 19 11:01:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DutbQ-00051s-Kh; Tue, 19 Jul 2005 11:01:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DutbM-00051l-Et
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 11:01:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23473
	for <avt@ietf.org>; Tue, 19 Jul 2005 11:01:42 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duu4x-0003I7-Lt
	for avt@ietf.org; Tue, 19 Jul 2005 11:32:23 -0400
Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:64631)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1Dutb9-0003Pe-CD; Tue, 19 Jul 2005 16:01:31 +0100
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EB68@aclmsg.corp.audiocodes.com>
References: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EB68@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F6123E50-FB90-4937-8EAF-45A0DB7AAA44@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Tue, 19 Jul 2005 16:01:27 +0100
To: Vladimir Ulybin <Vladimir@audiocodes.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Content-Transfer-Encoding: 7bit
Cc: "Paul E. Jones" <paulej@packetizer.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

Use of timestamps to reconstruct media timing is an essential feature  
of RTP. We will not standardise an RTP payload format which does not  
use them, since that would be incompatible with the rest of RTP, and  
would break the playout model used by RTP applications.  RTP is a  
general purpose transport protocol for real-time traffic -- it is not  
appropriate to optimise it for this niche application, at the expense  
incompatibility with other use cases.

If you do not wish to use timestamps in your application, I suggest  
you use T.38 over UDPTL instead of over RTP. When implementing T.38  
over RTP, using timestamps is mandatory (as with all other RTP  
payload formats).

Colin



On 19 Jul 2005, at 15:45, Vladimir Ulybin wrote:
> Colin,
>
> I think that the use of timestamps together with sequence numbers for
> building T.38 packet recovery buffer is not a good way. For T.38
> INDICATOR packets it is acceptable but for DATA packets this way may
> cause a lot of problems for packet recovery during data transfer.
>
> It is much easy and reliable to use RTP sequence number as the only  
> base
> for ordering T.38 packets arrived over RTP. In this case,  
> timestamps of
> redundant payloads may be ignored without any problems.
>
> Let consider an option to update the "draft-jones-avt-audio- 
> t38-05.txt"
> or write a new draft for T.38 over RTP.
>
> I think the problems opened in our discussions
> - repetition of T.38 packets and
> - excessive complexity of T.38 over RTP caused by timestamps
> (non-required by T.38)
> are general for different vendors.
>
> Regards,
> Vladimir Ulybin
>
>
> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Tuesday, July 19, 2005 2:07 PM
> To: Vladimir Ulybin
> Cc: Paul E. Jones; avt@ietf.org
> Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
>
> On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote:
>
>> 1. Zero is a simplest solution. The RFC 3550 allow the same time  
>> stamp
>> for several consecutive packets. So, when these packets will be
>> transmitted as redundant one relative to the other, the time
>> offsets per
>> RFC 2198 will be zero. It means that receiving gateway should handle
>> correctly zero time offsets in RFC 2198 headers.
>>
>
> No, since it will treat the data as being a redundant copy of the
> packet in which it is sent. If you use an offset of zero, there's no
> way to correctly place the data at the right time instant in the
> playout buffer.
>
>
>> 2. The computation of redundant packet time offset relative to  
>> primary
>> packet can be applied for synchronous operation like audio or
>> t4-non-ECM-data having a fixed time interval between packets. But,  
>> for
>> asynchronous packet stream, which is typical for T.30 control and ECM
>> fax, such approach cannot be used.
>>
>
> Correct - this is why RFC 2198 has an explicit timestamp for the
> redundancy offset.
>
>
>> Why I opened this issue?
>>
>> Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
>> packets ready for transmission to IP. To enable new feature of T.38
>> over
>> RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
>> DSP/gateway. The obstacle is in time stamp offsets of redundant
>> packets.
>> We all (fax engineers) know that these offsets are not required at
>> T.38
>> packet receivers. But accurate transmission of those per RFC 2198
>> requires deep re-writing of working and verified module(s) plus
>> additional allocation of RedundancyLevel*NofChannels timestamps.
>>
>
> Correct - this is required for robust operation over an unreliable
> packet network that may disrupt media timing.
>
> There are two cases:
>
> 1) There is a constant mapping from sequence number to timestamp. In
> this case, you can trivially calculate the timestamp and need no
> extra storage. The media timing can be reconstructed using either the
> sequence number or timestamp, and transporting both is essentially a
> waste of bandwidth for this application. In this case, you treat the
> extra bits on the wire as an "RTP tax" needed for interoperability,
> but don't need to store the extra data in the gateway.
>
> 2) There is not a constant mapping from sequence number to timestamp.
> This case requires you to store the extra timestamps for inclusion in
> RFC 2198 redundancy headers, however that extra information is
> required by the receiver to manage a playout buffer, since a playout
> buffer managed by sequence number only is not sufficient to
> reconstruct media timing.
>
> Colin
>
> _______________________________________________
> 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 avt-bounces@ietf.org Wed Jul 20 03:07:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dv8fx-0002lO-E2; Wed, 20 Jul 2005 03:07:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv8fu-0002kk-NL
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 03:07:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09055
	for <avt@ietf.org>; Wed, 20 Jul 2005 03:07:24 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv99g-0002gy-C5
	for avt@ietf.org; Wed, 20 Jul 2005 03:38:13 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Wed, 20 Jul 2005 10:07:31 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EC59@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWMctt4VS/Xi7r/TgiIQ9A2a7t+pwAhFQsQ
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Colin,

Unfortunately, T.38 over UDPTL has no secure capability. This is why we
need T.38 over RTP.

The discussion was very useful for understanding possible
interoperability problems of T.38 over RTP and correcting the
implementation concept.

Thank you very much!

Vladimir Ulybin

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]=20
Sent: Tuesday, July 19, 2005 6:01 PM
To: Vladimir Ulybin
Cc: Paul E. Jones; avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Use of timestamps to reconstruct media timing is an essential feature =20
of RTP. We will not standardise an RTP payload format which does not =20
use them, since that would be incompatible with the rest of RTP, and =20
would break the playout model used by RTP applications.  RTP is a =20
general purpose transport protocol for real-time traffic -- it is not =20
appropriate to optimise it for this niche application, at the expense =20
incompatibility with other use cases.

If you do not wish to use timestamps in your application, I suggest =20
you use T.38 over UDPTL instead of over RTP. When implementing T.38 =20
over RTP, using timestamps is mandatory (as with all other RTP =20
payload formats).

Colin



On 19 Jul 2005, at 15:45, Vladimir Ulybin wrote:
> Colin,
>
> I think that the use of timestamps together with sequence numbers for
> building T.38 packet recovery buffer is not a good way. For T.38
> INDICATOR packets it is acceptable but for DATA packets this way may
> cause a lot of problems for packet recovery during data transfer.
>
> It is much easy and reliable to use RTP sequence number as the only =20
> base
> for ordering T.38 packets arrived over RTP. In this case, =20
> timestamps of
> redundant payloads may be ignored without any problems.
>
> Let consider an option to update the "draft-jones-avt-audio-=20
> t38-05.txt"
> or write a new draft for T.38 over RTP.
>
> I think the problems opened in our discussions
> - repetition of T.38 packets and
> - excessive complexity of T.38 over RTP caused by timestamps
> (non-required by T.38)
> are general for different vendors.
>
> Regards,
> Vladimir Ulybin
>
>
> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Tuesday, July 19, 2005 2:07 PM
> To: Vladimir Ulybin
> Cc: Paul E. Jones; avt@ietf.org
> Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
>
> On 19 Jul 2005, at 07:40, Vladimir Ulybin wrote:
>
>> 1. Zero is a simplest solution. The RFC 3550 allow the same time =20
>> stamp
>> for several consecutive packets. So, when these packets will be
>> transmitted as redundant one relative to the other, the time
>> offsets per
>> RFC 2198 will be zero. It means that receiving gateway should handle
>> correctly zero time offsets in RFC 2198 headers.
>>
>
> No, since it will treat the data as being a redundant copy of the
> packet in which it is sent. If you use an offset of zero, there's no
> way to correctly place the data at the right time instant in the
> playout buffer.
>
>
>> 2. The computation of redundant packet time offset relative to =20
>> primary
>> packet can be applied for synchronous operation like audio or
>> t4-non-ECM-data having a fixed time interval between packets. But, =20
>> for
>> asynchronous packet stream, which is typical for T.30 control and ECM
>> fax, such approach cannot be used.
>>
>
> Correct - this is why RFC 2198 has an explicit timestamp for the
> redundancy offset.
>
>
>> Why I opened this issue?
>>
>> Assume a T.38 module of DSP/gateway which delivers the T.38 UDPTL
>> packets ready for transmission to IP. To enable new feature of T.38
>> over
>> RTP, it is easy to convert T.38 UDPTL into RFC 2198 at output of
>> DSP/gateway. The obstacle is in time stamp offsets of redundant
>> packets.
>> We all (fax engineers) know that these offsets are not required at
>> T.38
>> packet receivers. But accurate transmission of those per RFC 2198
>> requires deep re-writing of working and verified module(s) plus
>> additional allocation of RedundancyLevel*NofChannels timestamps.
>>
>
> Correct - this is required for robust operation over an unreliable
> packet network that may disrupt media timing.
>
> There are two cases:
>
> 1) There is a constant mapping from sequence number to timestamp. In
> this case, you can trivially calculate the timestamp and need no
> extra storage. The media timing can be reconstructed using either the
> sequence number or timestamp, and transporting both is essentially a
> waste of bandwidth for this application. In this case, you treat the
> extra bits on the wire as an "RTP tax" needed for interoperability,
> but don't need to store the extra data in the gateway.
>
> 2) There is not a constant mapping from sequence number to timestamp.
> This case requires you to store the extra timestamps for inclusion in
> RFC 2198 redundancy headers, however that extra information is
> required by the receiver to manage a playout buffer, since a playout
> buffer managed by sequence number only is not sufficient to
> reconstruct media timing.
>
> Colin
>
> _______________________________________________
> 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 avt-bounces@ietf.org Wed Jul 20 03:48:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dv9K1-0006kS-9G; Wed, 20 Jul 2005 03:48:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv9K0-0006kN-BV
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 03:48:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13398
	for <avt@ietf.org>; Wed, 20 Jul 2005 03:48:50 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv9nn-0005JT-CQ
	for avt@ietf.org; Wed, 20 Jul 2005 04:19:39 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3E925C53; 
	Wed, 20 Jul 2005 09:48:44 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 20 Jul 2005 09:48:43 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 20 Jul 2005 09:48:43 +0200
Message-ID: <42DE01DA.8080405@ericsson.com>
Date: Wed, 20 Jul 2005 09:48:42 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vladimir Ulybin <Vladimir@audiocodes.com>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
References: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EB68@aclmsg.corp.audiocodes.com>
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126EB68@aclmsg.corp.audiocodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jul 2005 07:48:43.0249 (UTC)
	FILETIME=[7383BE10:01C58CFF]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
Cc: "Paul E. Jones" <paulej@packetizer.com>, Colin Perkins <csp@csperkins.org>,
	avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

I think a lot of the problems you are having is based on the fact you 
are using RFC 2198 for something it wasn't designed for. It was designed 
and works as intended for audio payloads that relies on a single data 
block (ADU) per timestamp. The formats that fulfill this can for 
synchronization and detecting duplicates rely solely on timestamp. It 
uses the RTP timestamp primarily to detect when discontinuous 
transmissions occur. RFC 2198 doesn't have full sequence number recovery 
due to the fact that it wasn't needed for all the audio payloads one was 
considering to use. Also the solution RFC 2198 employs aren't suitable 
at all when the payloads become larger than half of the MTU.

If you want sequence number recovery, less hassle with timestamps and 
so: Use RFC 2733 FEC resolves these issue. Or rather the updated version 
as RFC 2733 has some issues. Unfortunately we haven't finished this 
update yet, but we are getting close.

Vladimir Ulybin wrote:
> Let consider an option to update the "draft-jones-avt-audio-t38-05.txt"
> or write a new draft for T.38 over RTP.

This is an ITU defined RTP payload format. I agree that it has issues 
and some of them could have been avoided if ITU had involved AVT in the 
loop earlier when it was under proposal. However it is ITU that has 
change control of it.

> 
> I think the problems opened in our discussions 
> - repetition of T.38 packets and 

If you are using RTP you have certain rules to follow. These involve the 
fact that packets can't be repeated using the same RTP sequence number. 
This requires solution like the RTP Retransmission format or the use of 
2733 FEC.

> - excessive complexity of T.38 over RTP caused by timestamps
> (non-required by T.38)

As Colin says RTP timestamps must be set in RTP. However one can make 
them simple to only indicate time of transmission. This would be simpler 
if people hadn't insisted on making it go over the same RTP session as 
audio. FAX isn't audio and it shouldn't be handled the same way as audio 
packets. Thus it should go in its own RTP session where it can be given 
somewhat different treatment. Yes, audio/t38 should in fact be image/t38 
or possibly application/t38.

Then as I said, stop using RFC 2198 and your timestamp issues mostly 
goes away.


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 avt-bounces@ietf.org Wed Jul 20 05:16:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvAgx-0000Ht-2G; Wed, 20 Jul 2005 05:16:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvAgu-0000Hj-Oz
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 05:16:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23784
	for <avt@ietf.org>; Wed, 20 Jul 2005 05:16:34 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvBAi-00025R-9I
	for avt@ietf.org; Wed, 20 Jul 2005 05:47:25 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6C631047;
	Wed, 20 Jul 2005 11:16:32 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 20 Jul 2005 11:16:32 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 20 Jul 2005 11:16:31 +0200
Message-ID: <42DE166E.4020706@ericsson.com>
Date: Wed, 20 Jul 2005 11:16:30 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>, Adam Li <adamli@hyervision.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jul 2005 09:16:31.0679 (UTC)
	FILETIME=[B7BE5CF0:01C58D0B]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [AVT] Comments on draft-ietf-avt-ulp-11
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Adam,

I have reviewed the updated draft and have a couple of comments. 
Unfortunately I don't think the draft is ready for publication, but it 
is getting close. I will also send comments on the FEC grouping draft to 
MMUSIC.

1. Section 7.3, SSRC:

    SSRC: The SSRC value will generally be the same as the SSRC value of
    the media stream it protects.

I think generally here is a bit unclear. Based on what is written 
elsewhere in the draft this is in fact a SHALL. So I would suggest that 
you change the sentence to:

    SSRC: The SSRC value SHALL be the same as the SSRC value of
    the media stream it protects.

2. Section 10: The examples:

I think the mask listing could be improved in the examples. Instead of

mask:      61440 [with Packet 8, 9, 10, and 11 marked]

I think one should discuss the bit level:

mask:      61440 [with bits (Pkt Seq nr.) 1(8), 2(9), (3)10, and 4(11) 
marked]

3. Section 11. I think we need to split out the congestion related 
discussion into its own Congestion Control section. There is also need 
to add some text here regarding RTP and profiles.


Congestion Control

    Another issue with the use of FEC is its impact on network
    congestion. In many situations, the packet loss in the network is
    induced by congestions. In such scenarios, adding FEC when
    encountering increasing network losses should be avoided. If it is
    used on a widespread basis, this can result in increased congestion
    and eventual congestion collapse. The applications may include
    stronger protections while at the same time reduce the bandwidth for
    the payload packets. In any event, implementations MUST NOT
    substantially increase the total amount of bandwidth in use
    (including the payload and the FEC) as network losses increase.

    The general congestion control considerations for transporting RTP
    data apply, see RTP [3] and any applicable RTP profile like AVP [9].
    An additional requirement if best-effort service is being used is:
    users of this payload format MUST monitor packet loss to ensure that
    the packet loss rate is within acceptable parameters.  Packet loss is
    considered acceptable if a TCP flow across the same network path, and
    experiencing the same network conditions, would achieve an average
    throughput, measured on a reasonable timescale, that is not less than
    the RTP flow is achieving.  This condition can be satisfied by
    implementing congestion control mechanisms to adapt the transmission
    rate (or the number of layers subscribed for a layered multicast
    session), or by arranging for a receiver to leave the session if the
    loss rate is unacceptably high.


4. The MIME registration must be updated to reflect what has been agreed 
so far in discussions with the MIME people. I have below one updated 
registration. Please note that I have added the rate parameter as it is 
now needed.

12. MIME Registrations

    Four new MIME sub-types as described in this section are to be
    registered with IANA. This registration is done using the
    template defined in [freed] and following RFC 3555 [RFC3555].


12.1. Registration of audio/ulpfec

    MIME media type name: audio

    MIME subtype name: ulpfec

    Required parameters: none

    Rate: The RTP timestamp rate which is used to mark the time of
    transmission of the FEC packet in separate stream. In cases it is
    sent as redundant data to another stream the rate SHALL be the same
    as the primary encoding it is used to protect. When used in a
    separate stream the rate SHALL be larger than 1000 Hz to provide
    sufficient resolution to RTCP operations. The selected rate MAY be
    any value above 1000 Hz but is RECOMMENDED to match the rate of the
    media this stream protects.


    Optional parameters: none

    Encoding considerations: This media type is framed (see section 4.8
    in [freed]) and contains binary data.

    Restrictions on usage:
         This media type depends on RTP framing, and hence is only
         defined for transfer via RTP [3]. Transport within other framing
         protocols SHALL NOT be defined as this is a robustness mechanism
         for RTP.

    Security considerations: the same security considerations apply to
    these MIME registrations as to the payloads for them, as detailed in
    RFC xxxx.

    Interoperability considerations: none

    Published specification: RFC xxxx.

    Applications which use this media type: Audio and video streaming
    tools which seek to improve resiliency to loss by sending additional
    data with the media stream.

    Additional information: none

    Person & email address to contact for further information:
       Adam Li adamli@hyervision.com
       IETF Audio/Video Transport Working Group

    Intended usage: COMMON

    Author:
       Adam Li adamli@hyervision.com

    Change controller:
       IETF Audio/Video Transport Working Group delegated from the
       IESG.


Informative references:

[freed] Freed, N. and J. Klensin, "Media Type Specifications and
      Registration Procedures", draft-freed-media-type-reg-04, April
      2005.

[rfc3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 
Payload Formats", RFC 3555, July 2003.

5. Section 13.2:

I think the usage of the ULP as redundant data is underspecified.

13.2. FEC as Redundant Encoding

    When the FEC stream is being sent as a secondary codec in the
    redundant encoding format, this must be signaled through SDP. To do
    this, the procedures defined in RFC 2198 [5] are used to signal the
    use of redundant encoding. The FEC payload type is indicated in the
    same fashion as any other secondary codec. The FEC MUST protect only
    the main codec.

    Because the FEC data is sent in the same packets as the protected
    payload, the ULP header of the FEC packets is not used. The FEC data
    is associated with the protected payload by being bundled in the
    same stream.

I would start with the last sentence of the first paragraph:
"The FEC MUST protect only the main codec." How is that possible? Should 
the FEC encoding engine create a virtual packet only containing the 
primary payload? The FEC mechanism defined protects complete packets, 
thus I think for simplicity one should protect the complete packet, 
including any FEC redundant payload parts of already sent packets.

Secondly, "Because the FEC data is sent in the same packets as the 
protected payload, the ULP header of the FEC packets is not used." How 
will it be possible to not have the ULP header?

6. Section 14. This section is missing an Offer/Answer consideration 
section. To my eye this would not be a long section however to show that 
it has been considered it is needed to be included.

If you like some help please ask me. However I don't have time to whip 
one together now.

7. The normative Reference list. I think it contains unnecessary 
references that are informative. Normative references are such 
references that are necessary to correctly implement this specification. 
  "Encode the binary data into a text string using BASE-64 [RFC3548]". 
Thus I think that reference 1, 2, 6, and 7 are not needed. In fact 
reference [7] is not used at all.


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 avt-bounces@ietf.org Wed Jul 20 05:50:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvBE2-0000zc-3D; Wed, 20 Jul 2005 05:50:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvBE0-0000zX-UU
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 05:50:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27200
	for <avt@ietf.org>; Wed, 20 Jul 2005 05:50:46 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvBhm-0004Wm-MB
	for avt@ietf.org; Wed, 20 Jul 2005 06:21:37 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Wed, 20 Jul 2005 12:50:57 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD60126ED58@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAA
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Content-Transfer-Encoding: quoted-printable
Cc: "Paul E. Jones" <paulej@packetizer.com>, Colin Perkins <csp@csperkins.org>,
	avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

You are right. The play out concept of RFC 2198 is problematic for fax
relay. Because, T.38 gateways do not play the buffers, but transmit
according to T.30 standard. Generally, the fax rates may be different at
two sides of communication, for example, 2400bps at calling fax side and
14400bps at answer fax side. Also T.30 control signals may have no
synchronization between gateways, but should be synchronized with near
fax machine.

The problem of timestamps is not only our (AudioCodes) problem but is
general for different vendors.

The packet buffer of a gateway receiving T.38 packets has no any time
mapping. The sequence number is the only ID of T.38 packet. Combining
sequence numbers with timestamps in packet recovery module is highly
problematic for interoperability (and from my point of view is wrong for
fax transfer).

Unfortunately, typical gateways do not support a complex protocol RFC
2733. So, we cannot use it as a basic for our implementation.

Thanks,
Vladimir Ulybin


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Wednesday, July 20, 2005 10:49 AM
To: Vladimir Ulybin
Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

Hi,

I think a lot of the problems you are having is based on the fact you=20
are using RFC 2198 for something it wasn't designed for. It was designed

and works as intended for audio payloads that relies on a single data=20
block (ADU) per timestamp. The formats that fulfill this can for=20
synchronization and detecting duplicates rely solely on timestamp. It=20
uses the RTP timestamp primarily to detect when discontinuous=20
transmissions occur. RFC 2198 doesn't have full sequence number recovery

due to the fact that it wasn't needed for all the audio payloads one was

considering to use. Also the solution RFC 2198 employs aren't suitable=20
at all when the payloads become larger than half of the MTU.

If you want sequence number recovery, less hassle with timestamps and=20
so: Use RFC 2733 FEC resolves these issue. Or rather the updated version

as RFC 2733 has some issues. Unfortunately we haven't finished this=20
update yet, but we are getting close.

Vladimir Ulybin wrote:
> Let consider an option to update the
"draft-jones-avt-audio-t38-05.txt"
> or write a new draft for T.38 over RTP.

This is an ITU defined RTP payload format. I agree that it has issues=20
and some of them could have been avoided if ITU had involved AVT in the=20
loop earlier when it was under proposal. However it is ITU that has=20
change control of it.

>=20
> I think the problems opened in our discussions=20
> - repetition of T.38 packets and=20

If you are using RTP you have certain rules to follow. These involve the

fact that packets can't be repeated using the same RTP sequence number.=20
This requires solution like the RTP Retransmission format or the use of=20
2733 FEC.

> - excessive complexity of T.38 over RTP caused by timestamps
> (non-required by T.38)

As Colin says RTP timestamps must be set in RTP. However one can make=20
them simple to only indicate time of transmission. This would be simpler

if people hadn't insisted on making it go over the same RTP session as=20
audio. FAX isn't audio and it shouldn't be handled the same way as audio

packets. Thus it should go in its own RTP session where it can be given=20
somewhat different treatment. Yes, audio/t38 should in fact be image/t38

or possibly application/t38.

Then as I said, stop using RFC 2198 and your timestamp issues mostly=20
goes away.


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 avt-bounces@ietf.org Wed Jul 20 08:07:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvDMP-0003GN-GX; Wed, 20 Jul 2005 08:07:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DuzYe-0004dg-2U
	for avt@megatron.ietf.org; Tue, 19 Jul 2005 17:23:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05449
	for <avt@ietf.org>; Tue, 19 Jul 2005 17:23:17 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv02J-0007CW-8o
	for avt@ietf.org; Tue, 19 Jul 2005 17:54:01 -0400
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j6JLLfx01426
	for <avt@ietf.org>; Tue, 19 Jul 2005 17:21:42 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 19 Jul 2005 16:23:05 -0500
Message-ID: <7A3E36B3528ED04A880178D337F30C9A0638DE56@zrc2hxm1.corp.nortel.com>
Thread-Topic: Requesting Comments: "RTP Payload Format for ECN Probing"
Thread-Index: AcWMqA1KULlL1SQTQRWD1Iyq2b8aGg==
From: "Corey Alexander" <coreya@nortel.com>
To: <avt@ietf.org>
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
X-Mailman-Approved-At: Wed, 20 Jul 2005 08:07:35 -0400
Subject: [AVT] Requesting Comments: "RTP Payload Format for ECN Probing"
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1642229006=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1642229006==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C58CA8.0DA7CE59"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58CA8.0DA7CE59
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greetings.  We are looking for feedback on the following draft:
http://www.ietf.org/internet-drafts/draft-alexander-rtp-payload-for-ecn-
probing-01.txt.  This draft has been submitted detailing a proposed RTP
payload format for use with probing during session establishment to
determine the measured congestion level of the path via a modified
Explicit Congestion Notification (ECN) bit marking mechanism.

The general problem we intend to solve here is one of admission control
based on the measured level of congestion along the network path.  As
background, draft
http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-04.txt
describes an ECN marking mechanism for real-time flows.  Draft
http://www.ietf.org/internet-drafts/draft-alexander-congestion-status-pr
econditions-00.txt describes a SIP precondition used to delay session
establishment until a congestion level within the network can be
determined.

The draft for which feedback is being requested describes an RTP payload
format used to probe for the measured level of congestion along the
network path via ECN markings in an RTP flow.  A general description of
the payload format's used is described in draft
http://www.ietf.org/internet-drafts/draft-alexander-rtecn-use-cases-00.t
xt.

We welcome and appreciate any comments/feedback.

Thank you,
Corey

Corey W. Alexander=20
Nortel


------_=_NextPart_001_01C58CA8.0DA7CE59
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7232.55">
<TITLE>Requesting Comments: &quot;RTP Payload Format for ECN =
Probing&quot;</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Greetings.&nbsp; We are looking for =
feedback on the following draft:</FONT> <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-alexander-rtp-payload-f=
or-ecn-probing-01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-alexander-rtp-payload-for-=
ecn-probing-01.txt</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial">.&nbsp; =
This draft has been submitted detailing a proposed RTP payload format =
for use with probing during session establishment to determine the =
measured congestion level of the path via a modified Explicit Congestion =
Notification (ECN) bit marking mechanism.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The general problem we intend to solve =
here is one of admission control based on the measured level of =
congestion along the network path.&nbsp; As background, draft</FONT> <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-04.=
txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-04.txt=
</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial"> describes an ECN marking =
mechanism for real-time flows.&nbsp; Draft</FONT> <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-alexander-congestion-st=
atus-preconditions-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-alexander-congestion-statu=
s-preconditions-00.txt</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial"> =
describes a SIP precondition used to delay session establishment until a =
congestion level within the network can be determined.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The draft for which feedback is being =
requested describes an RTP payload format used to probe for the measured =
level of congestion along the network path via ECN markings in an RTP =
flow.&nbsp; A general description of the payload format's used is =
described in draft</FONT> <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-alexander-rtecn-use-cas=
es-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-alexander-rtecn-use-cases-=
00.txt</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial">.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We welcome and appreciate any =
comments/feedback.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Corey</FONT>
</P>

<P><FONT COLOR=3D"#808000" SIZE=3D1 FACE=3D"Arial">Corey W. =
Alexander</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#808000" SIZE=3D1 FACE=3D"Arial">Nortel</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C58CA8.0DA7CE59--


--===============1642229006==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1642229006==--




From avt-bounces@ietf.org Wed Jul 20 08:51:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvE3J-0008Sf-Uh; Wed, 20 Jul 2005 08:51:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvE3E-0008Qx-6q
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 08:51:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12058
	for <avt@ietf.org>; Wed, 20 Jul 2005 08:51:50 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.207])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvEX3-00087e-69
	for avt@ietf.org; Wed, 20 Jul 2005 09:22:42 -0400
Received: by zproxy.gmail.com with SMTP id r28so1416599nza
	for <avt@ietf.org>; Wed, 20 Jul 2005 05:51:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=BEm9URlfbEN8MxU++WLW0d/Pd1ITK89NLLVnuwHTh664lY6cWrBPyBD6H0BErp2iDeXCRaXF9RG3a6euyo54ZMwrY2TIIfMsF5eMl4CIEW3LgXD3xK62Au/b+UdkEZ2UpQnewyEIMCmFZ3HKSDNGjXFkbH+TTninQeHK2SXC4lc=
Received: by 10.36.33.3 with SMTP id g3mr52436nzg;
	Wed, 20 Jul 2005 05:51:10 -0700 (PDT)
Received: by 10.36.103.5 with HTTP; Wed, 20 Jul 2005 05:51:09 -0700 (PDT)
Message-ID: <6e5aff67050720055118830878@mail.gmail.com>
Date: Wed, 20 Jul 2005 09:51:09 -0300
From: Alejandro Cabrera Obed <aco1967@gmail.com>
To: AVT Lista <avt@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 1.9 (+)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] MIME type registration: basic question
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Alejandro Cabrera Obed <aco1967@gmail.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Dear people,

I've been seen that all the the RTP payload formats for audio and
video need to define a MIME type registration, with type of media,
transport protocol and media format.

My question is this: why is it necessary the definition of a MIME type
in -for example- HDTV media sessions ??? Doesn't MIME refer to an
official Internet standard that specifies how messages must be
formatted so that they can be exchanged between different email
systems only (and for web too) ???

Thanks a lot !!!!

Alejandro

--=20
Alejandro Cabrera Obed
aco1967@gmail.com

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



From avt-bounces@ietf.org Wed Jul 20 09:13:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvEOd-0004na-Ra; Wed, 20 Jul 2005 09:13:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvEOb-0004mo-My
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 09:13:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13544
	for <avt@ietf.org>; Wed, 20 Jul 2005 09:13:56 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvEsQ-00018M-T3
	for avt@ietf.org; Wed, 20 Jul 2005 09:44:48 -0400
Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:58429)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DvEOC-0003IC-0Q; Wed, 20 Jul 2005 14:13:32 +0100
In-Reply-To: <6e5aff67050720055118830878@mail.gmail.com>
References: <6e5aff67050720055118830878@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <66BB6289-C54D-4FDD-8A0C-07EB33DEF7CA@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] MIME type registration: basic question
Date: Wed, 20 Jul 2005 14:13:28 +0100
To: Alejandro Cabrera Obed <aco1967@gmail.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: AVT Lista <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 20 Jul 2005, at 13:51, Alejandro Cabrera Obed wrote:
> I've been seen that all the the RTP payload formats for audio and
> video need to define a MIME type registration, with type of media,
> transport protocol and media format.
>
> My question is this: why is it necessary the definition of a MIME type
> in -for example- HDTV media sessions ??? Doesn't MIME refer to an
> official Internet standard that specifies how messages must be
> formatted so that they can be exchanged between different email
> systems only (and for web too) ???

A media type name is registered, so the format can be signalled in  
SDP.  SDP uses the same namespace as email, the web, and many other  
protocols, to identify media formats.

Colin

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



From avt-bounces@ietf.org Wed Jul 20 11:57:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvGxK-0005MJ-P2; Wed, 20 Jul 2005 11:57:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvGxJ-0005MD-9L
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 11:57:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04099
	for <avt@ietf.org>; Wed, 20 Jul 2005 11:57:54 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com
	([24.199.146.6] helo=berlin.arid.us ident=system)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvHR8-0005qG-Rg
	for avt@ietf.org; Wed, 20 Jul 2005 12:28:49 -0400
Received: from madrid (madrid.arid.us [192.168.1.10])
	by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6KFvZSA007287;
	Wed, 20 Jul 2005 11:57:35 -0400
Message-Id: <200507201557.j6KFvZSA007287@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>,
	"'Vladimir Ulybin'" <Vladimir@audiocodes.com>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Wed, 20 Jul 2005 11:57:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <42DE01DA.8080405@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWM/3ginhtPHsjKSS+JAd6QRPYvowAQpC7A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: 'Colin Perkins' <csp@csperkins.org>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Magnus, Vladimir,

> As Colin says RTP timestamps must be set in RTP. However one can make
> them simple to only indicate time of transmission. This would be simpler
> if people hadn't insisted on making it go over the same RTP session as
> audio. FAX isn't audio and it shouldn't be handled the same way as audio
> packets. Thus it should go in its own RTP session where it can be given
> somewhat different treatment. Yes, audio/t38 should in fact be image/t38
> or possibly application/t38.
> 
> Then as I said, stop using RFC 2198 and your timestamp issues mostly
> goes away.

One of the reasons for wanting to use audio/t38 stems from the fact that GWs
are transporting audio signals over IP, transitioning to fax, and then back
to audio mode again.  While fax isn't strictly audio, it arrives in the
audio path, just as DTMF and other audio signals do.  As such, there was the
desire to introduce audio/t38: it provides a pretty seamless means of
transitioning audio and fax.  The alternative is fairly messy signaling
exchanges and/or the allocation of additional UDP ports, just in case one
side initiates a fax transfer.  Lastly, transporting T.38 over RTP in this
way allows us to secure fax using SRTP with no more effort than the
underlying audio stream.

During the discussions held in regard to transporting T.38 over RTP, time
stamps were never regarded as something difficult to deal with.  The DSPs
are constantly sampling the circuit and there is an associated clock running
somewhere.  The fact that the timestamp does not have the same level of
importance for T.38 as they do for audio was not considered a reason to
change that running clock, the logic used to queue packets according to said
clock, or the protocols used to transmit the T.38 over RTP.

While T.38 is an application, it is also audio: one can hear the nasty
screechy noises.  The payload is just the representation of that audio and
there is a running clock associated with it.  Granted, the clock is "looser"
in many respects, but back in 1998 when the ITU decided to use UDPTL, many
argued that it should have used RTP instead.  Now the addition has been made
and (quite likely) a migration toward RTP for the benefits of security.  As
we do this, I would very much like to keep it consistent with RTP and look
at it no differently than an alternative representation of the audio, as we
do for information encoded with RFC 2833.

Paul



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



From avt-bounces@ietf.org Wed Jul 20 12:06:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvH5B-0007JL-7C; Wed, 20 Jul 2005 12:06:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvH59-0007JF-JG
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 12:06:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04638
	for <avt@ietf.org>; Wed, 20 Jul 2005 12:06:00 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com
	([24.199.146.6] helo=berlin.arid.us ident=system)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvHZ1-0006FZ-5Q
	for avt@ietf.org; Wed, 20 Jul 2005 12:36:55 -0400
Received: from madrid (madrid.arid.us [192.168.1.10])
	by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6KG5vSA007374;
	Wed, 20 Jul 2005 12:05:57 -0400
Message-Id: <200507201605.j6KG5vSA007374@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Vladimir Ulybin'" <Vladimir@audiocodes.com>,
	"'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Wed, 20 Jul 2005 12:06:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD60126ED58@aclmsg.corp.audiocodes.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAAAA4BYjA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Content-Transfer-Encoding: 7bit
Cc: 'Colin Perkins' <csp@csperkins.org>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

Forget RFC 2198 for a moment.  You're going to sample the audio, you will
extract T.30 information from that audio, you will form an RTP packet using
the time from the clock that is necessarily running.

As Packets arrive, you can do what you want with the timestamps, but they
can certainly be used for ordering packets if you want or they can be
largely ignored.

Now, if you add RFC 2198 to the picture, you are simply re-transmitting the
media from a previous packet in the current packet.  The timestamp was in
the previous packet and the current packet simply has an offset to it.  When
it arrives, you can determine the order of packets.  Isn't that all you
need?

Honestly, I do not see why this is causing such a problem.  I will not
disagree that an alternative (e.g., UDPTL) might be more fitting as it does
not have timestamps, but as Colin pointing out: it's an RTP tax.  But, you
get benefits with that tax, including security, RTCP, RTCP-XR, etc.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Hi,
> 
> You are right. The play out concept of RFC 2198 is problematic for fax
> relay. Because, T.38 gateways do not play the buffers, but transmit
> according to T.30 standard. Generally, the fax rates may be different at
> two sides of communication, for example, 2400bps at calling fax side and
> 14400bps at answer fax side. Also T.30 control signals may have no
> synchronization between gateways, but should be synchronized with near
> fax machine.
> 
> The problem of timestamps is not only our (AudioCodes) problem but is
> general for different vendors.
> 
> The packet buffer of a gateway receiving T.38 packets has no any time
> mapping. The sequence number is the only ID of T.38 packet. Combining
> sequence numbers with timestamps in packet recovery module is highly
> problematic for interoperability (and from my point of view is wrong for
> fax transfer).
> 
> Unfortunately, typical gateways do not support a complex protocol RFC
> 2733. So, we cannot use it as a basic for our implementation.
> 
> Thanks,
> Vladimir Ulybin
> 
> 
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Wednesday, July 20, 2005 10:49 AM
> To: Vladimir Ulybin
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Hi,
> 
> I think a lot of the problems you are having is based on the fact you
> are using RFC 2198 for something it wasn't designed for. It was designed
> 
> and works as intended for audio payloads that relies on a single data
> block (ADU) per timestamp. The formats that fulfill this can for
> synchronization and detecting duplicates rely solely on timestamp. It
> uses the RTP timestamp primarily to detect when discontinuous
> transmissions occur. RFC 2198 doesn't have full sequence number recovery
> 
> due to the fact that it wasn't needed for all the audio payloads one was
> 
> considering to use. Also the solution RFC 2198 employs aren't suitable
> at all when the payloads become larger than half of the MTU.
> 
> If you want sequence number recovery, less hassle with timestamps and
> so: Use RFC 2733 FEC resolves these issue. Or rather the updated version
> 
> as RFC 2733 has some issues. Unfortunately we haven't finished this
> update yet, but we are getting close.
> 
> Vladimir Ulybin wrote:
> > Let consider an option to update the
> "draft-jones-avt-audio-t38-05.txt"
> > or write a new draft for T.38 over RTP.
> 
> This is an ITU defined RTP payload format. I agree that it has issues
> and some of them could have been avoided if ITU had involved AVT in the
> loop earlier when it was under proposal. However it is ITU that has
> change control of it.
> 
> >
> > I think the problems opened in our discussions
> > - repetition of T.38 packets and
> 
> If you are using RTP you have certain rules to follow. These involve the
> 
> fact that packets can't be repeated using the same RTP sequence number.
> This requires solution like the RTP Retransmission format or the use of
> 2733 FEC.
> 
> > - excessive complexity of T.38 over RTP caused by timestamps
> > (non-required by T.38)
> 
> As Colin says RTP timestamps must be set in RTP. However one can make
> them simple to only indicate time of transmission. This would be simpler
> 
> if people hadn't insisted on making it go over the same RTP session as
> audio. FAX isn't audio and it shouldn't be handled the same way as audio
> 
> packets. Thus it should go in its own RTP session where it can be given
> somewhat different treatment. Yes, audio/t38 should in fact be image/t38
> 
> or possibly application/t38.
> 
> Then as I said, stop using RFC 2198 and your timestamp issues mostly
> goes away.
> 
> 
> 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 avt-bounces@ietf.org Wed Jul 20 12:40:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvHcF-0004lR-JR; Wed, 20 Jul 2005 12:40:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHcD-0004lD-6t
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 12:40:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07693
	for <avt@ietf.org>; Wed, 20 Jul 2005 12:40:10 -0400 (EDT)
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvI5z-00006Q-N2
	for avt@ietf.org; Wed, 20 Jul 2005 13:11:02 -0400
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com
	[47.129.230.97])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j6KGdkR00832; Wed, 20 Jul 2005 12:39:47 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Jul 2005 12:39:46 -0400
Message-ID: <183DD1B052A11A40B76125E42F1CBAAB04BACFC9@zcarhxm1.corp.nortel.com>
Thread-Topic: SRTCP key derivation
Thread-Index: AcV+FUV6HBMFW37sSWu/MwpHdvnY8APM2A7w
From: "Guoqiang Lu" <guoqian@nortel.com>
To: <avt@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: quoted-printable
Cc: mcgrew@cisco.com,
	=?iso-8859-1?Q?Mats_N=E4slund?= <mats.naslund@ericsson.com>
Subject: [AVT] SRTCP key derivation
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,
In RFC3711, section 4.3.2. SRTCP Key Derivation, it says:

"Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index ..."

My question is that SRTP index is a 48-bit quantity, should the SRTCP =
32-bit quantity "0 || SRTCP index" be patched with 16 leading zeros?

Thanks!

Guoqiang Lu
ESN: 39-36277
Phone: (613) 763-6277
guoqian@nortel.com
--------------------------
The contents of the this e-mail may be Nortel Confidential!=20


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



From avt-bounces@ietf.org Wed Jul 20 13:31:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvIQC-0007aa-HL; Wed, 20 Jul 2005 13:31:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvIQ6-0007RS-Do; Wed, 20 Jul 2005 13:31:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12669;
	Wed, 20 Jul 2005 13:31:43 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvIty-0003qK-UE; Wed, 20 Jul 2005 14:02:39 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1DvIQ3-0000KI-QG; Wed, 20 Jul 2005 13:31:43 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1DvIQ3-0000KI-QG@newodin.ietf.org>
Date: Wed, 20 Jul 2005 13:31:43 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: avt@ietf.org
Subject: [AVT] Last Call: 'RTP Payload Format for 3GPP Timed Text' to
 Proposed Standard 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg@ietf.org
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

The IESG has received a request from the Audio/Video Transport WG to consider 
the following document:

- 'RTP Payload Format for 3GPP Timed Text '
   <draft-ietf-avt-rtp-3gpp-timed-text-15.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-15.txt


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



From avt-bounces@ietf.org Wed Jul 20 15:15:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvK2u-0005xE-GW; Wed, 20 Jul 2005 15:15:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvK2t-0005x9-6N
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 15:15:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22579
	for <avt@ietf.org>; Wed, 20 Jul 2005 15:15:52 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvKWj-0002Ft-En
	for avt@ietf.org; Wed, 20 Jul 2005 15:46:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Wed, 20 Jul 2005 22:16:06 +0300
Message-ID: <EF8DFB1B64FF0A43AB00555B8E2717B101DE0108@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAAAA4BYjAABswugA==
From: "Oren Peleg" <OrenP@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Vladimir Ulybin" <Vladimir@audiocodes.com>,
	"Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Content-Transfer-Encoding: quoted-printable
Cc: Colin Perkins <csp@csperkins.org>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I would like to suggest the following:

Since Timestamp is profile specific, the T.38 RTP profile draft
(currently draft-jones-avt-audio-t38-05.txt) will add a special case of
Timestamp manipulation which will be used for redundant control packet
transmission (similar to the End packet of the RFC 2833 event). At this
special case the timestamp that will be used at the redundant packets
will be the same as the timestamp of the original packet. The number of
redundant packets will be determined via SDP using a special parameter.

Oren P.

-----Original Message-----
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
Paul E. Jones
Sent: Wednesday, July 20, 2005 7:06 PM
To: Vladimir Ulybin; 'Magnus Westerlund'
Cc: 'Colin Perkins'; avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Forget RFC 2198 for a moment.  You're going to sample the audio, you
will
extract T.30 information from that audio, you will form an RTP packet
using
the time from the clock that is necessarily running.

As Packets arrive, you can do what you want with the timestamps, but
they
can certainly be used for ordering packets if you want or they can be
largely ignored.

Now, if you add RFC 2198 to the picture, you are simply re-transmitting
the
media from a previous packet in the current packet.  The timestamp was
in
the previous packet and the current packet simply has an offset to it.
When
it arrives, you can determine the order of packets.  Isn't that all you
need?

Honestly, I do not see why this is causing such a problem.  I will not
disagree that an alternative (e.g., UDPTL) might be more fitting as it
does
not have timestamps, but as Colin pointing out: it's an RTP tax.  But,
you
get benefits with that tax, including security, RTCP, RTCP-XR, etc.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi,
>=20
> You are right. The play out concept of RFC 2198 is problematic for fax
> relay. Because, T.38 gateways do not play the buffers, but transmit
> according to T.30 standard. Generally, the fax rates may be different
at
> two sides of communication, for example, 2400bps at calling fax side
and
> 14400bps at answer fax side. Also T.30 control signals may have no
> synchronization between gateways, but should be synchronized with near
> fax machine.
>=20
> The problem of timestamps is not only our (AudioCodes) problem but is
> general for different vendors.
>=20
> The packet buffer of a gateway receiving T.38 packets has no any time
> mapping. The sequence number is the only ID of T.38 packet. Combining
> sequence numbers with timestamps in packet recovery module is highly
> problematic for interoperability (and from my point of view is wrong
for
> fax transfer).
>=20
> Unfortunately, typical gateways do not support a complex protocol RFC
> 2733. So, we cannot use it as a basic for our implementation.
>=20
> Thanks,
> Vladimir Ulybin
>=20
>=20
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Wednesday, July 20, 2005 10:49 AM
> To: Vladimir Ulybin
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi,
>=20
> I think a lot of the problems you are having is based on the fact you
> are using RFC 2198 for something it wasn't designed for. It was
designed
>=20
> and works as intended for audio payloads that relies on a single data
> block (ADU) per timestamp. The formats that fulfill this can for
> synchronization and detecting duplicates rely solely on timestamp. It
> uses the RTP timestamp primarily to detect when discontinuous
> transmissions occur. RFC 2198 doesn't have full sequence number
recovery
>=20
> due to the fact that it wasn't needed for all the audio payloads one
was
>=20
> considering to use. Also the solution RFC 2198 employs aren't suitable
> at all when the payloads become larger than half of the MTU.
>=20
> If you want sequence number recovery, less hassle with timestamps and
> so: Use RFC 2733 FEC resolves these issue. Or rather the updated
version
>=20
> as RFC 2733 has some issues. Unfortunately we haven't finished this
> update yet, but we are getting close.
>=20
> Vladimir Ulybin wrote:
> > Let consider an option to update the
> "draft-jones-avt-audio-t38-05.txt"
> > or write a new draft for T.38 over RTP.
>=20
> This is an ITU defined RTP payload format. I agree that it has issues
> and some of them could have been avoided if ITU had involved AVT in
the
> loop earlier when it was under proposal. However it is ITU that has
> change control of it.
>=20
> >
> > I think the problems opened in our discussions
> > - repetition of T.38 packets and
>=20
> If you are using RTP you have certain rules to follow. These involve
the
>=20
> fact that packets can't be repeated using the same RTP sequence
number.
> This requires solution like the RTP Retransmission format or the use
of
> 2733 FEC.
>=20
> > - excessive complexity of T.38 over RTP caused by timestamps
> > (non-required by T.38)
>=20
> As Colin says RTP timestamps must be set in RTP. However one can make
> them simple to only indicate time of transmission. This would be
simpler
>=20
> if people hadn't insisted on making it go over the same RTP session as
> audio. FAX isn't audio and it shouldn't be handled the same way as
audio
>=20
> packets. Thus it should go in its own RTP session where it can be
given
> somewhat different treatment. Yes, audio/t38 should in fact be
image/t38
>=20
> or possibly application/t38.
>=20
> Then as I said, stop using RFC 2198 and your timestamp issues mostly
> goes away.
>=20
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> 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

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



From avt-bounces@ietf.org Wed Jul 20 15:20:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvK73-0007GD-Dc; Wed, 20 Jul 2005 15:20:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvK71-0007Fr-Jp
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 15:20:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23064
	for <avt@ietf.org>; Wed, 20 Jul 2005 15:20:09 -0400 (EDT)
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvKar-0002UM-S0
	for avt@ietf.org; Wed, 20 Jul 2005 15:51:05 -0400
Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:61140)
	by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42)
	id 1DvK6n-0008P3-8i; Wed, 20 Jul 2005 20:19:57 +0100
In-Reply-To: <EF8DFB1B64FF0A43AB00555B8E2717B101DE0108@aclmsg.corp.audiocodes.com>
References: <EF8DFB1B64FF0A43AB00555B8E2717B101DE0108@aclmsg.corp.audiocodes.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3B0FC2D7-451E-4001-8F69-C2A43B460ED5@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
Date: Wed, 20 Jul 2005 20:19:48 +0100
To: "Oren Peleg" <OrenP@audiocodes.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: "Paul E. Jones" <paulej@packetizer.com>,
	Vladimir Ulybin <Vladimir@audiocodes.com>, avt@ietf.org,
	Magnus Westerlund <magnus.westerlund@ericsson.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

On 20 Jul 2005, at 20:16, Oren Peleg wrote:
> I would like to suggest the following:
>
> Since Timestamp is profile specific, the T.38 RTP profile draft
> (currently draft-jones-avt-audio-t38-05.txt) will add a special  
> case of
> Timestamp manipulation which will be used for redundant control packet
> transmission (similar to the End packet of the RFC 2833 event). At  
> this
> special case the timestamp that will be used at the redundant packets
> will be the same as the timestamp of the original packet. The  
> number of
> redundant packets will be determined via SDP using a special  
> parameter.

This is incompatible with all other uses of RFC 2198, and contrary to  
the RTP timing model.

Colin

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



From avt-bounces@ietf.org Wed Jul 20 15:50:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKai-0006GI-Hn; Wed, 20 Jul 2005 15:50:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKZy-0005uP-Og; Wed, 20 Jul 2005 15:50:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25132;
	Wed, 20 Jul 2005 15:50:04 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvL3p-0004JM-12; Wed, 20 Jul 2005 16:20:58 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DvKZu-0007ie-Dv; Wed, 20 Jul 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DvKZu-0007ie-Dv@newodin.ietf.org>
Date: Wed, 20 Jul 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-08.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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)	: S. Futemma, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-08.txt
	Pages		: 32
	Date		: 2005-7-20
	
This memo describes an RTP payload format for the ISO/IEC
   International Standard 15444-1 | ITU-T Rec. T.800, otherwise better
   known as: JPEG 2000.  JPEG 2000 features are considered and there are
   provisions in the design of this payload format.  JPEG 2000 is a
   truly scalable compression technology allowing applications to encode
   one way and decode many different ways.  Extending from a single
   image to a series of JPEG 2000 images, one has a JPEG 2000 video
   stream.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-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-rtp-jpeg2000-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: <2005-7-20115701.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-08.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-avt-rtp-jpeg2000-08.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-20115701.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Jul 20 15:51:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKaw-0006LK-Ib; Wed, 20 Jul 2005 15:51:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKZz-0005vL-Tf; Wed, 20 Jul 2005 15:50:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25141;
	Wed, 20 Jul 2005 15:50:05 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvL3p-0004JP-2i; Wed, 20 Jul 2005 16:20:59 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DvKZu-0007ii-Eo; Wed, 20 Jul 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DvKZu-0007ii-Eo@newodin.ietf.org>
Date: Wed, 20 Jul 2005 15:50:02 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-jpeg2000-beam-01.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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		: Enhanced Payload Format for Priority & Header
                          Processing RTP Payload Format for JPEG 2000
                          Video Streams BEAM extension
	Author(s)	: A. Leung, et al.
	Filename	: draft-ietf-avt-rtp-jpeg2000-beam-01.txt
	Pages		: 27
	Date		: 2005-7-20
	
This memo describes extended uses for payload header in RFCXXXY, An
   RTP Payload Format for JPEG 2000 Video, for better support of JPEG
   2000 features such as scalability and includes a main header recovery
   method.

   This memo MUST be accompanied with an implementation of RFCXXXY for a
   complete implementation.  RFCXXXY itself is a complete description of
   the payload header and signaling, this document only describes
   additional processing for the payload header.  There is an additional
   MIME and SDP marker signaling for implementations of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000-beam-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-beam-01.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-beam-01.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: <2005-7-20115930.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-jpeg2000-beam-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-rtp-jpeg2000-beam-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-20115930.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Jul 20 15:51:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKbX-0006fL-4G; Wed, 20 Jul 2005 15:51:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKa4-0005zA-DO; Wed, 20 Jul 2005 15:50:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25201;
	Wed, 20 Jul 2005 15:50:10 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvL3q-0004Kg-Q8; Wed, 20 Jul 2005 16:21:03 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DvKZw-0007ni-6d; Wed, 20 Jul 2005 15:50:04 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DvKZw-0007ni-6d@newodin.ietf.org>
Date: Wed, 20 Jul 2005 15:50:04 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-profile-savpf-02.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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		: Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)
	Author(s)	: J. Ott, E. Carrara
	Filename	: draft-ietf-avt-profile-savpf-02.txt
	Pages		: 16
	Date		: 2005-7-20
	
An RTP profile (SAVP) is defined for secure real-time
   communications, and another profile (AVPF) is specified to provide
   timely feedback from the receivers to a sender.  This memo defines
   the combination of both profiles to enable secure RTP
   communications with feedback.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-profile-savpf-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-profile-savpf-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: <2005-7-20142443.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-profile-savpf-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-avt-profile-savpf-02.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-20142443.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From avt-bounces@ietf.org Wed Jul 20 15:53:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKdL-0007d0-1V; Wed, 20 Jul 2005 15:53:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvKaM-0006AI-Py; Wed, 20 Jul 2005 15:50:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25377;
	Wed, 20 Jul 2005 15:50:28 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvL3q-0004KR-AP; Wed, 20 Jul 2005 16:21:02 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1DvKZv-0007mx-UC; Wed, 20 Jul 2005 15:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1DvKZv-0007mx-UC@newodin.ietf.org>
Date: Wed, 20 Jul 2005 15:50:03 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpssm-09.txt 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--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 Unicast Feedback
	Author(s)	: J. Chesterfield, et al.
	Filename	: draft-ietf-avt-rtcpssm-09.txt
	Pages		: 45
	Date		: 2005-7-20
	
This document specifies an extension 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 available or
   not desired. 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-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-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-rtcpssm-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: <2005-7-20135528.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtcpssm-09.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-avt-rtcpssm-09.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-7-20135528.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From avt-bounces@ietf.org Wed Jul 20 18:02:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvMeX-0006aF-8p; Wed, 20 Jul 2005 18:02:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvMeV-0006ZB-9g
	for avt@megatron.ietf.org; Wed, 20 Jul 2005 18:02:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20541
	for <avt@ietf.org>; Wed, 20 Jul 2005 18:02:51 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvN8O-0002kn-5k
	for avt@ietf.org; Wed, 20 Jul 2005 18:33:49 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Thu, 21 Jul 2005 01:03:01 +0300
Message-ID: <EF8DFB1B64FF0A43AB00555B8E2717B101DE0155@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWNYBuvHZjjj+ouTFKXoHGh0dAZAQAFioVw
From: "Oren Peleg" <OrenP@audiocodes.com>
To: "Colin Perkins" <csp@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: quoted-printable
Cc: "Paul E. Jones" <paulej@packetizer.com>,
	Vladimir Ulybin <Vladimir@audiocodes.com>, avt@ietf.org,
	Magnus Westerlund <magnus.westerlund@ericsson.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Also 2833, but still redundancy was managed within the profile. The T.38
draft may be extended to use a special mode of the RFC 2198, same as
done at 2833.

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]=20
Sent: Wednesday, July 20, 2005 10:20 PM
To: Oren Peleg
Cc: Paul E. Jones; Vladimir Ulybin; Magnus Westerlund; avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number

On 20 Jul 2005, at 20:16, Oren Peleg wrote:
> I would like to suggest the following:
>
> Since Timestamp is profile specific, the T.38 RTP profile draft
> (currently draft-jones-avt-audio-t38-05.txt) will add a special =20
> case of
> Timestamp manipulation which will be used for redundant control packet
> transmission (similar to the End packet of the RFC 2833 event). At =20
> this
> special case the timestamp that will be used at the redundant packets
> will be the same as the timestamp of the original packet. The =20
> number of
> redundant packets will be determined via SDP using a special =20
> parameter.

This is incompatible with all other uses of RFC 2198, and contrary to =20
the RTP timing model.

Colin

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



From avt-bounces@ietf.org Thu Jul 21 02:19:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvUPA-0007fF-Ft; Thu, 21 Jul 2005 02:19:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvUP9-0007fA-0B
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 02:19:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29746
	for <avt@ietf.org>; Thu, 21 Jul 2005 02:19:34 -0400 (EDT)
Received: from mx02.net.com ([134.56.3.132])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvUt6-0005bJ-SX
	for avt@ietf.org; Thu, 21 Jul 2005 02:50:34 -0400
Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13])
	by mx02.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id
	j6L6NGTL019134
	for <avt@ietf.org>; Wed, 20 Jul 2005 23:23:16 -0700 (PDT)
Received: from fmt-ex01.net.com (fmt-ex01.net.com [134.56.112.251])
	by mx01-int.net.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id
	j6L6FUOO013270
	for <avt@ietf.org>; Wed, 20 Jul 2005 23:15:30 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 20 Jul 2005 23:18:50 -0700
Message-ID: <E5CB8BF27E39374ABE7C56E1FF20497C49030A@fmt-ex01.net.com>
Thread-Topic: SRTP: question about MKI length
Thread-Index: AcWNvA+yiuUd4s1JTfyf1sLFpPAmSA==
From: "Usha Sharma" <Usha_Sharma@net.com>
To: <avt@ietf.org>
X-Spam-Status: No, hits=0.7 required=8.0 tests=AWL,HTML_50_60,HTML_MESSAGE 
	autolearn=no version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on fmt-spam02.net.com
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Subject: [AVT] SRTP: question about MKI length
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0980944936=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0980944936==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C58DBC.0FE0C5D1"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58DBC.0FE0C5D1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

There is no description in RFC 3711 for upper limit of MKI length and
range of MKI value. SDP (draft-ietf-mmusic-sdescriptions-11.txt) defines
that MKI value is a positive integer and MKI length could be up to 128
byte. Is it worthwhile to use such big MKI value for voice applications,
considering the bandwidth overhead introduced by it. What would be the
optimal value of MKI length for most applications?=20


------_=_NextPart_001_01C58DBC.0FE0C5D1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>There is no description in RFC 3711 for upper limit =
of MKI
length and range of MKI value. SDP =
(draft-ietf-mmusic-sdescriptions-11.txt) defines
that MKI value is a positive integer and MKI length could be up to 128 =
byte. Is
it worthwhile to use such big MKI value for voice applications, =
considering the
bandwidth overhead introduced by it. What would be the optimal value of =
MKI
length for most applications? <o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C58DBC.0FE0C5D1--


--===============0980944936==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0980944936==--




From avt-bounces@ietf.org Thu Jul 21 04:48:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvWje-0005iT-DJ; Thu, 21 Jul 2005 04:48:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvWjc-0005iO-Kh
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 04:48:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12769
	for <avt@ietf.org>; Thu, 21 Jul 2005 04:48:50 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvXDc-00075c-N7
	for avt@ietf.org; Thu, 21 Jul 2005 05:19:53 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B6C4C117D
	for <avt@ietf.org>; Thu, 21 Jul 2005 10:48:48 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 10:48:47 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 10:48:47 +0200
Message-ID: <42DF616F.2030105@ericsson.com>
Date: Thu, 21 Jul 2005 10:48:47 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jul 2005 08:48:47.0838 (UTC)
	FILETIME=[026E1FE0:01C58DD1]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Content-Transfer-Encoding: 7bit
Subject: [AVT] Updated preliminary AVT agenda
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

Please see below for the AVT agenda. The IETF WG scheduling agenda is 
not yet confirmed, thus this agenda is still preliminary.

Cheers

Magnus

-------

Audio/Video Transport Working Group

CHAIRS: Colin Perkins     <csp@csperkins.org>
         Magnus Westerlund <magnus.westerlund@ericsson.com>

Tuesday, 2 August 2005, 10:30-12:30
====================================

Introduction and Status Update                                 (Chairs)
                                                                 10 min
    Under development:
          draft-ietf-avt-mime-h224-02
          draft-ietf-avt-profile-savpf-02
          draft-ietf-avt-rtcpssm-09
          draft-ietf-avt-rfc2032-bis-06
          draft-ietf-avt-rfc2190-to-historic-03
          draft-ietf-avt-rfc2429-bis-05
          draft-ietf-avt-rfc2833bis-09
          draft-ietf-avt-rfc2833biscas-00
          draft-ietf-avt-rfc2833bisdata-02
          draft-ietf-avt-rfc3555bis-00
          draft-ietf-avt-rtcp-xr-mib-02
          draft-ietf-avt-rtp-amr-bis-01
          draft-ietf-avt-rtp-atrac-family-04
          draft-ietf-avt-rtp-jpeg2000-08
          draft-ietf-avt-rtp-jpeg2000-beam-01
          draft-ietf-avt-rtp-midi-format-10
          draft-ietf-avt-rtp-midi-guidelines-10
          draft-ietf-avt-rtp-no-op-00
          draft-ietf-avt-rtp-vmr-wb-extension-00
          draft-ietf-avt-tfrc-profile-04
          draft-ietf-avt-ulp-11

          draft-ietf-avt-rfc3119bis-03 (Expired)
          draft-finlayson-avt-mpa-robust-interoperability-01 (Expired)
          draft-ietf-avt-uxp-07 (Expired)
          draft-ietf-avt-variable-rate-audio-00     (Expired)

    AD or IESG Evaluation
          draft-ietf-avt-audio-t140c-00
          draft-ietf-avt-rtp-retransmission-11
          draft-ietf-avt-rtp-framing-contrans-05
          draft-ietf-avt-rtp-vmr-wb-10
          draft-ietf-avt-3gpp-timed-text-15
          draft-ietf-avt-rtp-ac3-07
          draft-ietf-avt-rtp-amrwbplus-06
          draft-jones-avt-audio-t38-05
          draft-garudadri-avt-3gpp2-mime-02
          draft-lim-mpeg4-mime-03

    RFC Editor:
          draft-ietf-avt-hc-mpls-reqs-03
          draft-ietf-avt-rtcp-feedback-11
          draft-burmeister-avt-rtcp-feedback-sim-06
          draft-ietf-avt-rtp-bv-03
          draft-ietf-avt-tcrtp-08
          draft-ietf-avt-uncomp-video-06

    Published RFCs
          draft-ietf-avt-rtp-clearmode-05      -> RFC 4040
          draft-ietf-avt-rtp-dsr-codecs-03     -> RFC 4060
          draft-ietf-avt-text-red-05           -> RFC 4102
          draft-ietf-avt-rfc2793bis-09         -> RFC 4103

    Individual drafts with AVT relation
          draft-ash-avt-hc-over-mpls-protocol-01
          draft-clark-avt-rtcpxr-bis-00
          draft-even-avt-rfc3047-bis-01
          draft-feiten-avt-bsacmode-for-rfc3640-00
          draft-kerr-avt-vorbis-rtp-04
          draft-klemets-avt-rtp-vc1-00
          draft-koren-avt-ecrtp-reorder-00
          draft-lennox-avt-app-sharing-00
          draft-lkchoi-avt-iptvdbs-req-00
          draft-perkins-avt-uncomp-video-ext-00
          draft-singer-rtp-hdrext-00
          draft-singer-smpte-rtp-01
          draft-sollaud-avt-rtp-g729-scal-wb-ext-01
          draft-stirbu-avt-lrdp-00
          draft-vitali-ietf-avt-mdc-lc-00
          draft-wenger-avt-avpf-ccm-00
          draft-xie-avt-compact-bundle-evrc-00
          draft-xie-avt-rtp-anti-shadow-01

Using the RTP Header Extension for SMTPE Timestamps		(Singer)
    draft-singer-rtp-hdrext-00					   5 min
    draft-singer-smpte-rtp-01

Compact Bundled RTP Format for EVRC Speech                         (Xie)
    draft-xie-avt-compact-bundle-evrc-00                           10 min

RTP Payload Format for Video Codec 1 (VC-1)                    (Klemets)
    draft-klemets-avt-rtp-vc1-00                                   15 min

Update of ITU G.722.1 payload format                              (Even)
    draft-even-avt-rfc3047-bis-01                                  10 min

RTP Payload Format for ECN Probing                            (Alexander)
    draft-alexander-rtp-payload-for-ecn-probing-01                 10 min
    draft-babiarz-tsvwg-rtecn-04
    draft-alexander-rtecn-use-cases-00
    draft-alexander-congestion-status-preconditions-00

Protocol Extensions for Header Compression over MPLS               (Ash)
    draft-ash-avt-hc-over-mpls-protocol-01                         15 min

RTP Profile for TCP Friendly Rate Control                       (Gharai)
    draft-ietf-avt-tfrc-profile-04                                 15 min

Strategies for Streaming Media Applications Using TFRC          (Phelan)
    draft-ietf-dccp-tfrc-media-00                                  15 min

FEC streaming framework                                         (Watson)
    draft-watson-tsvwg-fec-sf-00                                   15 min



Wednesday, 3 August 2005, 9:00-10:00
====================================

RTCP XR VoIP Metrics Management Information Base                 (Clark)
    draft-avt-rtcp-xr-mib-02                                       10 min

RTCP XR - New Parameter Extensions                               (Clark)
    draft-clark-avt-rtcpxr-bis-00                                  10 min

Open issues with Codec Control Messages in AVPF                 (Wenger)
    draft-wenger-avt-avpf-ccm-00                                   15 min

Media Type Discussion                                           (chairs)
    draft-ietf-avt-rfc3555bis-00                                   15 min
    draft-freed-media-type-reg-04
    Mailing list discussion

RTCP Extensions for SSM sessions with unicast feedback             (Ott)
    draft-ietf-avt-rtcpssm-09                                      10 min


-- 

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 avt-bounces@ietf.org Thu Jul 21 05:47:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvXe1-0003Vb-Im; Thu, 21 Jul 2005 05:47:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvXdz-0003VW-83
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 05:47:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15507
	for <avt@ietf.org>; Thu, 21 Jul 2005 05:47:05 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvY7t-0002BX-Qf
	for avt@ietf.org; Thu, 21 Jul 2005 06:18:08 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BAFAB1493;
	Thu, 21 Jul 2005 11:46:50 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 11:46:50 +0200
Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 11:46:50 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] SRTCP key derivation
Date: Thu, 21 Jul 2005 11:46:49 +0200
Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB020147B0D2@esealmw104.eemea.ericsson.se>
Thread-Topic: SRTCP key derivation
Thread-Index: AcV+FUV6HBMFW37sSWu/MwpHdvnY8APM2A7wACNnOJA=
From: "Karl Norrman (KI/EAB)" <karl.norrman@ericsson.com>
To: "Guoqiang Lu" <guoqian@nortel.com>
X-OriginalArrivalTime: 21 Jul 2005 09:46:50.0042 (UTC)
	FILETIME=[1DFC49A0:01C58DD9]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: quoted-printable
Cc: mcgrew@cisco.com, avt@ietf.org,
	=?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= <mats.naslund@ericsson.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hello!

The SRTCP index should not be padded with zeros to be 48 bits long.  =
This means
that, e.g., the labels will not be in the same octet position for SRTP =
and SRTCP.

Regards,
Karl

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of
> Guoqiang Lu
> Sent: den 20 juli 2005 18:40
> To: avt@ietf.org
> Cc: mcgrew@cisco.com; Mats N=E4slund (KI/EAB)
> Subject: [AVT] SRTCP key derivation
>=20
>=20
> Hi,
> In RFC3711, section 4.3.2. SRTCP Key Derivation, it says:
>=20
> "Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index ..."
>=20
> My question is that SRTP index is a 48-bit quantity, should=20
> the SRTCP 32-bit quantity "0 || SRTCP index" be patched with=20
> 16 leading zeros?
>=20
> Thanks!
>=20
> Guoqiang Lu
> ESN: 39-36277
> Phone: (613) 763-6277
> guoqian@nortel.com
> --------------------------
> The contents of the this e-mail may be Nortel Confidential!=20
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>=20

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



From avt-bounces@ietf.org Thu Jul 21 10:04:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvbfM-00009s-SB; Thu, 21 Jul 2005 10:04:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvbfK-00006k-Jb
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 10:04:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02233
	for <avt@ietf.org>; Thu, 21 Jul 2005 10:04:45 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dvc9N-0001sj-0X for avt@ietf.org; Thu, 21 Jul 2005 10:35:50 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 21 Jul 2005 07:04:36 -0700
X-IronPort-AV: i="3.93,308,1115017200"; 
	d="scan'208"; a="649881936:sNHT28244726"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6LE4Vul011436;
	Thu, 21 Jul 2005 07:04:31 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Jul 2005 07:04:37 -0700
Received: from [192.168.0.12] ([10.21.98.54]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 07:04:21 -0700
In-Reply-To: <E5CB8BF27E39374ABE7C56E1FF20497C49030A@fmt-ex01.net.com>
References: <E5CB8BF27E39374ABE7C56E1FF20497C49030A@fmt-ex01.net.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b916c5d197f279bd7f51b53c935b4ac4@cisco.com>
Content-Transfer-Encoding: 7bit
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [AVT] SRTP: question about MKI length
Date: Thu, 21 Jul 2005 07:04:34 -0700
To: "Usha Sharma" <Usha_Sharma@net.com>
X-Mailer: Apple Mail (2.622)
X-OriginalArrivalTime: 21 Jul 2005 14:04:21.0126 (UTC)
	FILETIME=[178C9A60:01C58DFD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

hi
   RFC 3711 assumes that the key management system will set the maximum 
length for the MKI.  The use of an MKI function is common in video 
broadcasting where a key gets rotated at rates that may be less than 
one second.  TV conditional access vendors operate proprietary systems 
that rotate the key according to application needs (there is really no 
cryptographic need to rotate a 128-bit AES counter-mode key until 2^64 
packets have been encrypted using it - a very long time).  The MKI was 
added for this application - and vendors in this industry use various 
sizes for the key index, particularly to convey a variety of key 
management information over a broadcast channel.

   In general, there is no need to use an MKI.  If there is, I would 
expect that a small, one-byte MKI would suffice to handle cases where 
key rotation might be useful.

Mark
On Jul 20, 2005, at 11:18 PM, Usha Sharma wrote:

> There is no description in RFC 3711 for upper limit of MKI length and 
> range of MKI value. SDP (draft-ietf-mmusic-sdescriptions-11.txt) 
> defines that MKI value is a positive integer and MKI length could be 
> up to 128 byte. Is it worthwhile to use such big MKI value for voice 
> applications, considering the bandwidth overhead introduced by it. 
> What would be the optimal value of MKI length for most applications?
> _______________________________________________
> 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 avt-bounces@ietf.org Thu Jul 21 10:31:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dvc52-0005GJ-TS; Thu, 21 Jul 2005 10:31:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc51-0005Fr-K1
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 10:31:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05533
	for <avt@ietf.org>; Thu, 21 Jul 2005 10:31:17 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvcZ3-0003he-Oy
	for avt@ietf.org; Thu, 21 Jul 2005 11:02:23 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	j6LETro7024260
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 21 Jul 2005 07:29:54 -0700 (PDT)
Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40])
	by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	j6LETpN2024009; Thu, 21 Jul 2005 07:29:51 -0700 (PDT)
Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by
	NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 07:29:51 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [AVT] SRTP: question about MKI length
Date: Thu, 21 Jul 2005 07:25:38 -0700
Message-ID: <AB6CA8B4C094AE43BED03A0D9FC1C55E07F1CD@NAEX06.na.qualcomm.com>
Thread-Topic: [AVT] SRTP: question about MKI length
Thread-Index: AcWN/X6koPuhztdEQjKj3eNusLoapAAApIkL
From: "Dondeti, Lakshminath" <ldondeti@qualcomm.com>
To: "Mark Baugher" <mbaugher@cisco.com>, "Usha Sharma" <Usha_Sharma@net.com>
X-OriginalArrivalTime: 21 Jul 2005 14:29:51.0268 (UTC)
	FILETIME=[A795BE40:01C58E00]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1288442388=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1288442388==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C58E00.A6BEEFEA"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C58E00.A6BEEFEA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Mark,

I am curious about using the MKI to convey "a variety of key management =
information."  Could you please elaborate?  I know of the MKI being used =
in 3GPP2 to send key management information also, but with the concern =
that the MKI field is not integrity protected.  If the MKI is used to =
send a key index, we know that no integrity protection is required, but =
if it is intended for sending arbitrary key management information, then =
perhaps integrity protecting that field would be necessary.

Thoughts?

thanks and regards,
Lakshminath


-----Original Message-----
From: avt-bounces@ietf.org on behalf of Mark Baugher
Sent: Thu 7/21/2005 7:04 AM
To: Usha Sharma
Cc: avt@ietf.org
Subject: Re: [AVT] SRTP: question about MKI length
=20
hi
   RFC 3711 assumes that the key management system will set the maximum=20
length for the MKI.  The use of an MKI function is common in video=20
broadcasting where a key gets rotated at rates that may be less than=20
one second.  TV conditional access vendors operate proprietary systems=20
that rotate the key according to application needs (there is really no=20
cryptographic need to rotate a 128-bit AES counter-mode key until 2^64=20
packets have been encrypted using it - a very long time).  The MKI was=20
added for this application - and vendors in this industry use various=20
sizes for the key index, particularly to convey a variety of key=20
management information over a broadcast channel.

   In general, there is no need to use an MKI.  If there is, I would=20
expect that a small, one-byte MKI would suffice to handle cases where=20
key rotation might be useful.

Mark
On Jul 20, 2005, at 11:18 PM, Usha Sharma wrote:

> There is no description in RFC 3711 for upper limit of MKI length and=20
> range of MKI value. SDP (draft-ietf-mmusic-sdescriptions-11.txt)=20
> defines that MKI value is a positive integer and MKI length could be=20
> up to 128 byte. Is it worthwhile to use such big MKI value for voice=20
> applications, considering the bandwidth overhead introduced by it.=20
> What would be the optimal value of MKI length for most applications?
> _______________________________________________
> 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_01C58E00.A6BEEFEA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: [AVT] SRTP: question about MKI length</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Mark,<BR>
<BR>
I am curious about using the MKI to convey &quot;a variety of key =
management information.&quot;&nbsp; Could you please elaborate?&nbsp; I =
know of the MKI being used in 3GPP2 to send key management information =
also, but with the concern that the MKI field is not integrity =
protected.&nbsp; If the MKI is used to send a key index, we know that no =
integrity protection is required, but if it is intended for sending =
arbitrary key management information, then perhaps integrity protecting =
that field would be necessary.<BR>
<BR>
Thoughts?<BR>
<BR>
thanks and regards,<BR>
Lakshminath<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: avt-bounces@ietf.org on behalf of Mark Baugher<BR>
Sent: Thu 7/21/2005 7:04 AM<BR>
To: Usha Sharma<BR>
Cc: avt@ietf.org<BR>
Subject: Re: [AVT] SRTP: question about MKI length<BR>
<BR>
hi<BR>
&nbsp;&nbsp; RFC 3711 assumes that the key management system will set =
the maximum<BR>
length for the MKI.&nbsp; The use of an MKI function is common in =
video<BR>
broadcasting where a key gets rotated at rates that may be less than<BR>
one second.&nbsp; TV conditional access vendors operate proprietary =
systems<BR>
that rotate the key according to application needs (there is really =
no<BR>
cryptographic need to rotate a 128-bit AES counter-mode key until =
2^64<BR>
packets have been encrypted using it - a very long time).&nbsp; The MKI =
was<BR>
added for this application - and vendors in this industry use =
various<BR>
sizes for the key index, particularly to convey a variety of key<BR>
management information over a broadcast channel.<BR>
<BR>
&nbsp;&nbsp; In general, there is no need to use an MKI.&nbsp; If there =
is, I would<BR>
expect that a small, one-byte MKI would suffice to handle cases =
where<BR>
key rotation might be useful.<BR>
<BR>
Mark<BR>
On Jul 20, 2005, at 11:18 PM, Usha Sharma wrote:<BR>
<BR>
&gt; There is no description in RFC 3711 for upper limit of MKI length =
and<BR>
&gt; range of MKI value. SDP =
(draft-ietf-mmusic-sdescriptions-11.txt)<BR>
&gt; defines that MKI value is a positive integer and MKI length could =
be<BR>
&gt; up to 128 byte. Is it worthwhile to use such big MKI value for =
voice<BR>
&gt; applications, considering the bandwidth overhead introduced by =
it.<BR>
&gt; What would be the optimal value of MKI length for most =
applications?<BR>
&gt; _______________________________________________<BR>
&gt; Audio/Video Transport Working Group<BR>
&gt; avt@ietf.org<BR>
&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/avt">https://www1.ietf.org=
/mailman/listinfo/avt</A><BR>
<BR>
_______________________________________________<BR>
Audio/Video Transport Working Group<BR>
avt@ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/avt">https://www1.ietf.org=
/mailman/listinfo/avt</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C58E00.A6BEEFEA--


--===============1288442388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1288442388==--




From avt-bounces@ietf.org Thu Jul 21 11:09:48 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvcgF-0005cO-V1; Thu, 21 Jul 2005 11:09:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcgF-0005cE-38
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 11:09:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08445
	for <avt@ietf.org>; Thu, 21 Jul 2005 11:09:41 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.ca.nortel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvdAE-0006HU-Hg
	for avt@ietf.org; Thu, 21 Jul 2005 11:40:47 -0400
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com
	[47.129.230.97])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	j6LF6lw13951; Thu, 21 Jul 2005 11:06:47 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] SRTCP key derivation
Date: Thu, 21 Jul 2005 11:08:10 -0400
Message-ID: <183DD1B052A11A40B76125E42F1CBAAB04C3304A@zcarhxm1.corp.nortel.com>
Thread-Topic: [AVT] SRTCP key derivation
Thread-Index: AcV+FUV6HBMFW37sSWu/MwpHdvnY8APM2A7wACNnOJAAC5oe4A==
From: "Guoqiang Lu" <guoqian@nortel.com>
To: "Karl Norrman \(KI/EAB\)" <karl.norrman@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: quoted-printable
Cc: mcgrew@cisco.com, avt@ietf.org,
	=?iso-8859-1?Q?Mats_N=E4slund_=28KI/EAB=29?= <mats.naslund@ericsson.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


>This means that, e.g., the labels will not be in the same octet =
position for SRTP and SRTCP.

This seems to contradict the reference implementation by David McGrew =
found in srtp.sourceforge.net: The SRTCP key was derived as:

 srtp_kdf_generate(&kdf, (uint64_t) label_rtcp_encryption,=20
		     tmp_key, cipher_get_key_length(srtp->rtcp_cipher));
While SRTCP key was derived as:

 srtp_kdf_generate(&kdf, (uint64_t) label_rtp_encryption,=20
		     tmp_key, cipher_get_key_length(srtp->rtp_cipher));

And within the srtp_kdf_generate() function, the label is always =
assigned to nonce.octet[7].

Thanks!

Guoqiang Lu
ESN: 39-36277
Phone: (613) 763-6277
guoqian@nortel.com
--------------------------
The contents of the this e-mail may be Nortel Confidential!=20


-----Original Message-----
From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com]=20
Sent: Thursday, July 21, 2005 5:47 AM
To: Lu, Guoqiang [CAR:9D40:EXCH]
Cc: mcgrew@cisco.com; Mats N=E4slund (KI/EAB); avt@ietf.org
Subject: RE: [AVT] SRTCP key derivation


Hello!

The SRTCP index should not be padded with zeros to be 48 bits long.  =
This means that, e.g., the labels will not be in the same octet position =
for SRTP and SRTCP.

Regards,
Karl

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of=20
> Guoqiang Lu
> Sent: den 20 juli 2005 18:40
> To: avt@ietf.org
> Cc: mcgrew@cisco.com; Mats N=E4slund (KI/EAB)
> Subject: [AVT] SRTCP key derivation
>=20
>=20
> Hi,
> In RFC3711, section 4.3.2. SRTCP Key Derivation, it says:
>=20
> "Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index ..."
>=20
> My question is that SRTP index is a 48-bit quantity, should
> the SRTCP 32-bit quantity "0 || SRTCP index" be patched with=20
> 16 leading zeros?
>=20
> Thanks!
>=20
> Guoqiang Lu
> ESN: 39-36277
> Phone: (613) 763-6277
> guoqian@nortel.com
> --------------------------
> The contents of the this e-mail may be Nortel Confidential!
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>=20


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



From avt-bounces@ietf.org Thu Jul 21 11:15:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvclX-0007ti-Fn; Thu, 21 Jul 2005 11:15:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvclW-0007nX-1W
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 11:15:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08904
	for <avt@ietf.org>; Thu, 21 Jul 2005 11:15:11 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvdFZ-0006em-7D for avt@ietf.org; Thu, 21 Jul 2005 11:46:17 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-1.cisco.com with ESMTP; 21 Jul 2005 08:15:04 -0700
X-IronPort-AV: i="3.93,308,1115017200"; 
	d="scan'208"; a="649899767:sNHT28955308"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6LFEsvF024956;
	Thu, 21 Jul 2005 08:14:58 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 21 Jul 2005 08:14:53 -0700
Received: from [192.168.0.12] ([10.21.98.54]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 21 Jul 2005 08:14:52 -0700
In-Reply-To: <AB6CA8B4C094AE43BED03A0D9FC1C55E07F1CD@NAEX06.na.qualcomm.com>
References: <AB6CA8B4C094AE43BED03A0D9FC1C55E07F1CD@NAEX06.na.qualcomm.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <43d4106148f238c7f8292a74cb5afe05@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: Mark Baugher <mbaugher@cisco.com>
Subject: Re: [AVT] SRTP: question about MKI length
Date: Thu, 21 Jul 2005 08:14:51 -0700
To: "Dondeti, Lakshminath" <ldondeti@qualcomm.com>
X-Mailer: Apple Mail (2.622)
X-OriginalArrivalTime: 21 Jul 2005 15:14:52.0266 (UTC)
	FILETIME=[F18154A0:01C58E06]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: quoted-printable
Cc: Usha Sharma <Usha_Sharma@net.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

hi Lakshminath,
    I heard from NDS (and also Nagra, I think) that they put as much key=20=

management information as they can into the broadcast stream, such as=20
an MPEG-2 Transport Stream.  Since they don't publish their key=20
management protocols, conditional access companies typically don't=20
explain why they do things.  But a couple of years ago, it was=20
announced in the press that a large satellite vendor gradually=20
downloaded code and re-programmed the conditional access system in the=20=

settop boxes of its entire customer base to disable unauthorized=20
receivers.  This was an NDS system if I recall correctly.  So, there=20
are shenanigans like that going on and probably the same sorts of key=20
management things that LKH and similar systems might do.

Mark
On Jul 21, 2005, at 7:25 AM, Dondeti, Lakshminath wrote:

> Hi Mark,
>
>  I am curious about using the MKI to convey "a variety of key=20
> management information."=A0 Could you please elaborate?=A0 I know of =
the=20
> MKI being used in 3GPP2 to send key management information also, but=20=

> with the concern that the MKI field is not integrity protected.=A0 If=20=

> the MKI is used to send a key index, we know that no integrity=20
> protection is required, but if it is intended for sending arbitrary=20
> key management information, then perhaps integrity protecting that=20
> field would be necessary.
>
>  Thoughts?
>
>  thanks and regards,
>  Lakshminath
>
>
>  -----Original Message-----
>  From: avt-bounces@ietf.org on behalf of Mark Baugher
>  Sent: Thu 7/21/2005 7:04 AM
>  To: Usha Sharma
>  Cc: avt@ietf.org
>  Subject: Re: [AVT] SRTP: question about MKI length
>
>  hi
>  =A0=A0 RFC 3711 assumes that the key management system will set the=20=

> maximum
>  length for the MKI.=A0 The use of an MKI function is common in video
>  broadcasting where a key gets rotated at rates that may be less than
>  one second.=A0 TV conditional access vendors operate proprietary =
systems
>  that rotate the key according to application needs (there is really =
no
>  cryptographic need to rotate a 128-bit AES counter-mode key until =
2^64
>  packets have been encrypted using it - a very long time).=A0 The MKI =
was
>  added for this application - and vendors in this industry use various
>  sizes for the key index, particularly to convey a variety of key
>  management information over a broadcast channel.
>
>  =A0=A0 In general, there is no need to use an MKI.=A0 If there is, I =
would
>  expect that a small, one-byte MKI would suffice to handle cases where
>  key rotation might be useful.
>
>  Mark
>  On Jul 20, 2005, at 11:18 PM, Usha Sharma wrote:
>
>  > There is no description in RFC 3711 for upper limit of MKI length=20=

> and
>  > range of MKI value. SDP (draft-ietf-mmusic-sdescriptions-11.txt)
>  > defines that MKI value is a positive integer and MKI length could =
be
>  > up to 128 byte. Is it worthwhile to use such big MKI value for =
voice
>  > applications, considering the bandwidth overhead introduced by it.
>  > What would be the optimal value of MKI length for most =
applications?
>  > _______________________________________________
>  > 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 avt-bounces@ietf.org Thu Jul 21 14:08:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvfSz-00055n-11; Thu, 21 Jul 2005 14:08:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfSx-0004z4-2Y
	for avt@megatron.ietf.org; Thu, 21 Jul 2005 14:08:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22553
	for <avt@ietf.org>; Thu, 21 Jul 2005 14:08:11 -0400 (EDT)
Received: from sonussf1.sonusnet.com ([208.45.178.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvfwy-0001nA-6e
	for avt@ietf.org; Thu, 21 Jul 2005 14:39:17 -0400
Received: from sonusmail03.sonusnet.com (sonusmail03.sonusnet.com
	[10.128.32.97])
	by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id j6LI7sjv012373; 
	Thu, 21 Jul 2005 14:07:54 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 21 Jul 2005 14:07:54 -0400
Message-ID: <A3863F3136CBC546A40A61BA9CBA9D9301E20D23@sonusmail03.sonusnet.com>
Thread-Topic: [AVT] Updated preliminary AVT agenda
Thread-Index: AcWN0bEe0O6ef0QoSaCH6EI/+eyE2gATLRwg
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>,
	"IETF AVT WG" <avt@ietf.org>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: 
Subject: [AVT] Strategies for Streaming Media Applications Using
	TCP-Friendly Rate Control
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2146986222=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--===============2146986222==
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

SGkgQWxsLA0KDQpUaGUgZHJhZnQgSSdtIHNjaGVkdWxlZCB0byBwcmVzZW50IGluIFBhcmlzICgi
U3RyYXRlZ2llcyBmb3IgU3RyZWFtaW5nIE1lZGlhIEFwcGxpY2F0aW9ucyBVc2luZyBUQ1AtRnJp
ZW5kbHkgUmF0ZSBDb250cm9sIiksIHdhcyB1bmZvcnR1bmF0ZWx5IHJlamVjdGVkIGJlY2F1c2Ug
b2Ygb2xkIGJvaWxlcnBsYXRlIGFuZCBkaWRuJ3QgZ2V0IGZpeGVkIGluIHRpbWUgZm9yIHRoZSBj
dXRvZmYgZGF0ZS4gIEV2ZW4gc28sIE1hZ251cyBhbmQgQ29saW4gaGF2ZSBncmFjaW91c2x5IGFs
bG93ZWQgbWUgdG8gcHJlc2VudCBhbnl3YXkuICBUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGF0IGh0
dHA6Ly93d3cucGhlbGFuLTQuY29tL2RjY3AvZHJhZnQtaWV0Zi1kY2NwLXRmcmMtbWVkaWEtMDAu
dHh0Lg0KDQpTb3JyeSBmb3IgYmVpbmcgc2xvcHB5LCBhbmQgdGhhbmtzIGFsbCBmb3IgcHV0dGlu
ZyB1cCB3aXRoIG1lIDotKS4NCg0KVG9tIFBoZWxhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+IEZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNA
aWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IFNlbnQ6IFRodXJz
ZGF5LCBKdWx5IDIxLCAyMDA1IDQ6NDkgQU0NCj4gVG86IElFVEYgQVZUIFdHDQo+IFN1YmplY3Q6
IFtBVlRdIFVwZGF0ZWQgcHJlbGltaW5hcnkgQVZUIGFnZW5kYQ0KPiANCj4gDQo+IEhpLA0KPiAN
Cj4gUGxlYXNlIHNlZSBiZWxvdyBmb3IgdGhlIEFWVCBhZ2VuZGEuIFRoZSBJRVRGIFdHIHNjaGVk
dWxpbmcgYWdlbmRhIGlzIA0KPiBub3QgeWV0IGNvbmZpcm1lZCwgdGh1cyB0aGlzIGFnZW5kYSBp
cyBzdGlsbCBwcmVsaW1pbmFyeS4NCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzDQo+IA0KPiAt
LS0tLS0tDQo+IA0KPiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgV29ya2luZyBHcm91cA0KPiANCj4g
Q0hBSVJTOiBDb2xpbiBQZXJraW5zICAgICA8Y3NwQGNzcGVya2lucy5vcmc+DQo+ICAgICAgICAg
IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQo+IA0K
PiBUdWVzZGF5LCAyIEF1Z3VzdCAyMDA1LCAxMDozMC0xMjozMA0KPiA9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0NCj4gDQo+IEludHJvZHVjdGlvbiBhbmQgU3RhdHVzIFVwZGF0
ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ICAoQ2hhaXJzKQ0KPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
PiAgICAxMCBtaW4NCj4gICAgIFVuZGVyIGRldmVsb3BtZW50Og0KPiAgICAgICAgICAgZHJhZnQt
aWV0Zi1hdnQtbWltZS1oMjI0LTAyDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1wcm9maWxl
LXNhdnBmLTAyDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydGNwc3NtLTA5DQo+ICAgICAg
ICAgICBkcmFmdC1pZXRmLWF2dC1yZmMyMDMyLWJpcy0wNg0KPiAgICAgICAgICAgZHJhZnQtaWV0
Zi1hdnQtcmZjMjE5MC10by1oaXN0b3JpYy0wMw0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQt
cmZjMjQyOS1iaXMtMDUNCj4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJmYzI4MzNiaXMtMDkN
Cj4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJmYzI4MzNiaXNjYXMtMDANCj4gICAgICAgICAg
IGRyYWZ0LWlldGYtYXZ0LXJmYzI4MzNiaXNkYXRhLTAyDQo+ICAgICAgICAgICBkcmFmdC1pZXRm
LWF2dC1yZmMzNTU1YmlzLTAwDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydGNwLXhyLW1p
Yi0wMg0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRwLWFtci1iaXMtMDENCj4gICAgICAg
ICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1hdHJhYy1mYW1pbHktMDQNCj4gICAgICAgICAgIGRyYWZ0
LWlldGYtYXZ0LXJ0cC1qcGVnMjAwMC0wOA0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRw
LWpwZWcyMDAwLWJlYW0tMDENCj4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1taWRpLWZv
cm1hdC0xMA0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRwLW1pZGktZ3VpZGVsaW5lcy0x
MA0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRwLW5vLW9wLTAwDQo+ICAgICAgICAgICBk
cmFmdC1pZXRmLWF2dC1ydHAtdm1yLXdiLWV4dGVuc2lvbi0wMA0KPiAgICAgICAgICAgZHJhZnQt
aWV0Zi1hdnQtdGZyYy1wcm9maWxlLTA0DQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC11bHAt
MTENCj4gDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1yZmMzMTE5YmlzLTAzIChFeHBpcmVk
KQ0KPiAgICAgICAgICAgZHJhZnQtZmlubGF5c29uLWF2dC1tcGEtcm9idXN0LWludGVyb3BlcmFi
aWxpdHktMDEgKEV4cGlyZWQpDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC11eHAtMDcgKEV4
cGlyZWQpDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC12YXJpYWJsZS1yYXRlLWF1ZGlvLTAw
ICAgICAoRXhwaXJlZCkNCj4gDQo+ICAgICBBRCBvciBJRVNHIEV2YWx1YXRpb24NCj4gICAgICAg
ICAgIGRyYWZ0LWlldGYtYXZ0LWF1ZGlvLXQxNDBjLTAwDQo+ICAgICAgICAgICBkcmFmdC1pZXRm
LWF2dC1ydHAtcmV0cmFuc21pc3Npb24tMTENCj4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0
cC1mcmFtaW5nLWNvbnRyYW5zLTA1DQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAtdm1y
LXdiLTEwDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC0zZ3BwLXRpbWVkLXRleHQtMTUNCj4g
ICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1hYzMtMDcNCj4gICAgICAgICAgIGRyYWZ0LWll
dGYtYXZ0LXJ0cC1hbXJ3YnBsdXMtMDYNCj4gICAgICAgICAgIGRyYWZ0LWpvbmVzLWF2dC1hdWRp
by10MzgtMDUNCj4gICAgICAgICAgIGRyYWZ0LWdhcnVkYWRyaS1hdnQtM2dwcDItbWltZS0wMg0K
PiAgICAgICAgICAgZHJhZnQtbGltLW1wZWc0LW1pbWUtMDMNCj4gDQo+ICAgICBSRkMgRWRpdG9y
Og0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtaGMtbXBscy1yZXFzLTAzDQo+ICAgICAgICAg
ICBkcmFmdC1pZXRmLWF2dC1ydGNwLWZlZWRiYWNrLTExDQo+ICAgICAgICAgICBkcmFmdC1idXJt
ZWlzdGVyLWF2dC1ydGNwLWZlZWRiYWNrLXNpbS0wNg0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1h
dnQtcnRwLWJ2LTAzDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC10Y3J0cC0wOA0KPiAgICAg
ICAgICAgZHJhZnQtaWV0Zi1hdnQtdW5jb21wLXZpZGVvLTA2DQo+IA0KPiAgICAgUHVibGlzaGVk
IFJGQ3MNCj4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1jbGVhcm1vZGUtMDUgICAgICAt
PiBSRkMgNDA0MA0KPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRwLWRzci1jb2RlY3MtMDMg
ICAgIC0+IFJGQyA0MDYwDQo+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC10ZXh0LXJlZC0wNSAg
ICAgICAgICAgLT4gUkZDIDQxMDINCj4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJmYzI3OTNi
aXMtMDkgICAgICAgICAtPiBSRkMgNDEwMw0KPiANCj4gICAgIEluZGl2aWR1YWwgZHJhZnRzIHdp
dGggQVZUIHJlbGF0aW9uDQo+ICAgICAgICAgICBkcmFmdC1hc2gtYXZ0LWhjLW92ZXItbXBscy1w
cm90b2NvbC0wMQ0KPiAgICAgICAgICAgZHJhZnQtY2xhcmstYXZ0LXJ0Y3B4ci1iaXMtMDANCj4g
ICAgICAgICAgIGRyYWZ0LWV2ZW4tYXZ0LXJmYzMwNDctYmlzLTAxDQo+ICAgICAgICAgICBkcmFm
dC1mZWl0ZW4tYXZ0LWJzYWNtb2RlLWZvci1yZmMzNjQwLTAwDQo+ICAgICAgICAgICBkcmFmdC1r
ZXJyLWF2dC12b3JiaXMtcnRwLTA0DQo+ICAgICAgICAgICBkcmFmdC1rbGVtZXRzLWF2dC1ydHAt
dmMxLTAwDQo+ICAgICAgICAgICBkcmFmdC1rb3Jlbi1hdnQtZWNydHAtcmVvcmRlci0wMA0KPiAg
ICAgICAgICAgZHJhZnQtbGVubm94LWF2dC1hcHAtc2hhcmluZy0wMA0KPiAgICAgICAgICAgZHJh
ZnQtbGtjaG9pLWF2dC1pcHR2ZGJzLXJlcS0wMA0KPiAgICAgICAgICAgZHJhZnQtcGVya2lucy1h
dnQtdW5jb21wLXZpZGVvLWV4dC0wMA0KPiAgICAgICAgICAgZHJhZnQtc2luZ2VyLXJ0cC1oZHJl
eHQtMDANCj4gICAgICAgICAgIGRyYWZ0LXNpbmdlci1zbXB0ZS1ydHAtMDENCj4gICAgICAgICAg
IGRyYWZ0LXNvbGxhdWQtYXZ0LXJ0cC1nNzI5LXNjYWwtd2ItZXh0LTAxDQo+ICAgICAgICAgICBk
cmFmdC1zdGlyYnUtYXZ0LWxyZHAtMDANCj4gICAgICAgICAgIGRyYWZ0LXZpdGFsaS1pZXRmLWF2
dC1tZGMtbGMtMDANCj4gICAgICAgICAgIGRyYWZ0LXdlbmdlci1hdnQtYXZwZi1jY20tMDANCj4g
ICAgICAgICAgIGRyYWZ0LXhpZS1hdnQtY29tcGFjdC1idW5kbGUtZXZyYy0wMA0KPiAgICAgICAg
ICAgZHJhZnQteGllLWF2dC1ydHAtYW50aS1zaGFkb3ctMDENCj4gDQo+IFVzaW5nIHRoZSBSVFAg
SGVhZGVyIEV4dGVuc2lvbiBmb3IgU01UUEUgVGltZXN0YW1wcwkJKFNpbmdlcikNCj4gICAgIGRy
YWZ0LXNpbmdlci1ydHAtaGRyZXh0LTAwCQkJCQ0KPiAJICAgNSBtaW4NCj4gICAgIGRyYWZ0LXNp
bmdlci1zbXB0ZS1ydHAtMDENCj4gDQo+IENvbXBhY3QgQnVuZGxlZCBSVFAgRm9ybWF0IGZvciBF
VlJDIFNwZWVjaCAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAgKFhpZSkNCj4gICAgIGRyYWZ0
LXhpZS1hdnQtY29tcGFjdC1idW5kbGUtZXZyYy0wMCAgICAgICAgICAgICAgICAgICAgICANCj4g
ICAgICAxMCBtaW4NCj4gDQo+IFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgVmlkZW8gQ29kZWMgMSAo
VkMtMSkgICAgICAgICAgICAgICAgICAgDQo+ICAoS2xlbWV0cykNCj4gICAgIGRyYWZ0LWtsZW1l
dHMtYXZ0LXJ0cC12YzEtMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gICAgICAx
NSBtaW4NCj4gDQo+IFVwZGF0ZSBvZiBJVFUgRy43MjIuMSBwYXlsb2FkIGZvcm1hdCAgICAgICAg
ICAgICAgICAgICAgICAgICAgDQo+ICAgICAoRXZlbikNCj4gICAgIGRyYWZ0LWV2ZW4tYXZ0LXJm
YzMwNDctYmlzLTAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gICAgICAxMCBtaW4N
Cj4gDQo+IFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRUNOIFByb2JpbmcgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgDQo+IChBbGV4YW5kZXIpDQo+ICAgICBkcmFmdC1hbGV4YW5kZXItcnRwLXBh
eWxvYWQtZm9yLWVjbi1wcm9iaW5nLTAxICAgICAgICAgICAgDQo+ICAgICAgMTAgbWluDQo+ICAg
ICBkcmFmdC1iYWJpYXJ6LXRzdndnLXJ0ZWNuLTA0DQo+ICAgICBkcmFmdC1hbGV4YW5kZXItcnRl
Y24tdXNlLWNhc2VzLTAwDQo+ICAgICBkcmFmdC1hbGV4YW5kZXItY29uZ2VzdGlvbi1zdGF0dXMt
cHJlY29uZGl0aW9ucy0wMA0KPiANCj4gUHJvdG9jb2wgRXh0ZW5zaW9ucyBmb3IgSGVhZGVyIENv
bXByZXNzaW9uIG92ZXIgTVBMUyAgICAgICAgICANCj4gICAgICAoQXNoKQ0KPiAgICAgZHJhZnQt
YXNoLWF2dC1oYy1vdmVyLW1wbHMtcHJvdG9jb2wtMDEgICAgICAgICAgICAgICAgICAgIA0KPiAg
ICAgIDE1IG1pbg0KPiANCj4gUlRQIFByb2ZpbGUgZm9yIFRDUCBGcmllbmRseSBSYXRlIENvbnRy
b2wgICAgICAgICAgICAgICAgICAgICANCj4gICAoR2hhcmFpKQ0KPiAgICAgZHJhZnQtaWV0Zi1h
dnQtdGZyYy1wcm9maWxlLTA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiAgICAgIDE1
IG1pbg0KPiANCj4gU3RyYXRlZ2llcyBmb3IgU3RyZWFtaW5nIE1lZGlhIEFwcGxpY2F0aW9ucyBV
c2luZyBURlJDICAgICAgICANCj4gICAoUGhlbGFuKQ0KPiAgICAgZHJhZnQtaWV0Zi1kY2NwLXRm
cmMtbWVkaWEtMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiAgICAgIDE1IG1pbg0K
PiANCj4gRkVDIHN0cmVhbWluZyBmcmFtZXdvcmsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCj4gICAoV2F0c29uKQ0KPiAgICAgZHJhZnQtd2F0c29uLXRzdndnLWZlYy1z
Zi0wMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiAgICAgIDE1IG1pbg0KPiANCj4g
DQo+IA0KPiBXZWRuZXNkYXksIDMgQXVndXN0IDIwMDUsIDk6MDAtMTA6MDANCj4gPT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IA0KPiBSVENQIFhSIFZvSVAgTWV0cmljcyBN
YW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgICAgICAgICAgICAgIA0KPiAgICAoQ2xhcmspDQo+
ICAgICBkcmFmdC1hdnQtcnRjcC14ci1taWItMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgDQo+ICAgICAgMTAgbWluDQo+IA0KPiBSVENQIFhSIC0gTmV3IFBhcmFtZXRlciBFeHRl
bnNpb25zICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiAgICAoQ2xhcmspDQo+ICAgICBk
cmFmdC1jbGFyay1hdnQtcnRjcHhyLWJpcy0wMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQo+ICAgICAgMTAgbWluDQo+IA0KPiBPcGVuIGlzc3VlcyB3aXRoIENvZGVjIENvbnRyb2wgTWVz
c2FnZXMgaW4gQVZQRiAgICAgICAgICAgICAgIA0KPiAgIChXZW5nZXIpDQo+ICAgICBkcmFmdC13
ZW5nZXItYXZ0LWF2cGYtY2NtLTAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ICAg
ICAgMTUgbWluDQo+IA0KPiBNZWRpYSBUeXBlIERpc2N1c3Npb24gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KPiAgIChjaGFpcnMpDQo+ICAgICBkcmFmdC1pZXRmLWF2
dC1yZmMzNTU1YmlzLTAwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAgMTUg
bWluDQo+ICAgICBkcmFmdC1mcmVlZC1tZWRpYS10eXBlLXJlZy0wNA0KPiAgICAgTWFpbGluZyBs
aXN0IGRpc2N1c3Npb24NCj4gDQo+IFJUQ1AgRXh0ZW5zaW9ucyBmb3IgU1NNIHNlc3Npb25zIHdp
dGggdW5pY2FzdCBmZWVkYmFjayAgICAgICAgDQo+ICAgICAgKE90dCkNCj4gICAgIGRyYWZ0LWll
dGYtYXZ0LXJ0Y3Bzc20tMDkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gICAg
ICAxMCBtaW4NCj4gDQo+IA0KPiAtLSANCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0KPiBN
dWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWQS9BDQo+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSArNDYgOCA0
MDQ4Mjg3DQo+IFRvcnNoYW1zZ2F0YW4gMjMgICAgICAgICAgIHwgRmF4ICAgKzQ2IDggNzU3NTU1
MA0KPiBTLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1
bmRAZXJpY3Nzb24uY29tDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgV29ya2luZyBHcm91cA0KPiBh
dnRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0
DQo+IA0K


--===============2146986222==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2146986222==--



From avt-bounces@ietf.org Fri Jul 22 05:24:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvtlE-0008Q4-8v; Fri, 22 Jul 2005 05:24:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dvfdw-0001WX-9J; Thu, 21 Jul 2005 14:19:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23854;
	Thu, 21 Jul 2005 14:19:35 -0400 (EDT)
Received: from orion.lrg.ufsc.br ([150.162.63.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dvg80-0002aq-As; Thu, 21 Jul 2005 14:50:41 -0400
Received: by orion.lrg.ufsc.br (Postfix, from userid 3002)
	id EDF95A2A3; Thu, 21 Jul 2005 16:20:44 -0400 (WST)
Received: from localhost (localhost [127.0.0.1])
	by orion.lrg.ufsc.br (Postfix) with ESMTP
	id 8EBFCDD6D; Thu, 21 Jul 2005 16:20:44 -0400 (WST)
Date: Thu, 21 Jul 2005 16:20:44 -0400 (WST)
From: Carlos Becker Westphall <westphal@lrg.ufsc.br>
To: ejiri@otrs.ts.fujitsu.co.jp, wagner@cs.ubc.ca, westphal@lrg.ufsc.br,
	stiller@tik.ee.ethz.ch, hellers@us.ibm.com, rboutaba@bbcr.uwaterloo.ca
In-Reply-To: <Pine.GSO.4.60.0507210200170.11425@venus>
Message-ID: <Pine.GSO.4.10.10507211610110.25261-100000@orion.lrg.ufsc.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606
Content-Transfer-Encoding: QUOTED-PRINTABLE
X-Mailman-Approved-At: Fri, 22 Jul 2005 05:24:02 -0400
Cc: mboned@network-services.uoregon.edu, manet@ietf.org, policy@ietf.org,
	cost263@fokus.gmd.de, sip@ietf.org, tcpp-announce@eece.unm.edu,
	mmb@ira.uka.de, aaa-wg@merit.edu, ifip_nm@bbcr.uwaterloo.ca,
	gsmp@ietf.org, confs-conferencesa@comsoc.org, rmt@lbl.gov,
	netnomics@listserver.tue.nl, seamoby@ietf.org, all@inf.ethz.ch,
	kuvs-elg@fokus.gmd.de, itc@i-teletraffic.org,
	snmpv3@lists.tislabs.com.cnri.reston.va.us,
	conf@colmar.uha.fr.cnri.reston.va.us, giga@tele.pitt.edu,
	itc@comsoc.org, mpls@uu.net, spects02@comp.leeds.ac.uk,
	liste_cfip@info.uqam.ca, avt@ietf.org, comswtc@ieee.org,
	enternet@bbn.com, issll@mercury.lcs.mit.edu,
	nemo@nal.motlabs.com.cnri.reston.va.us, cfp@mmlab.snu.ac.kr,
	KUVS-L@listserv.uni-heidelberg.de,
	dares-announcement@enst-bretagne.fr, arl@arl.wustl.edu,
	mmusic@ietf.org, multicomm@research.panasonic.com, RHDM@lip6.fr,
	kom-meeting@KOM.th-darmstadt.de.cnri.reston.va.us, tcgn@majordomo.ieee.org,
	TCPC.Mail@rome.ece.cornell.edu.cnri.reston.va.us,
	disman@dorothy.bmc.com, diffserv@ietf.org, nanog@merit.edu,
	pilc@grc.nasa.gov, Georg Carle <carle@fokus.gmd.de>,
	cnom@lrg.ufsc.br, xtp-relay@cs.concordia.ca, rm@openmash.org,
	sming@ops.ietf.org, all_ifi@ifi.unizh.ch, tcgn@ieee.org,
	tccc@comsoc.org, commsoft@ieee.org, news-announce-conferences@uunet.uu.net,
	ifip-tc6@informatik.rwth-aachen.de, itc@ieee.org, reres@laas.fr,
	dnac_2002@yahoo.fr,
	nichains@BXL.DG13.cec.eu.int.cnri.reston.va.us, cost264@lip6.fr,
	lacomsoc@lrg.ufsc.br, sigmetrics-bb@haven.epm.ornl.gov.cnri.reston.va.us,
	tik@tik.ee.ethz.ch, wiss-mitarb@ee.ethz.ch, int-serv@ISI.EDU,
	multicomm@comsoc.org, mobile-ip@sunroof.eng.sun.com,
	rmonmib@ietf.org, members@ngni.org,
	amlist@takilab.k.dendai.ac.jp, gi-fb3@fokus.gmd.de
Subject: [AVT] CFP - NOMS 2006 - 10th IEEE/IFIP Network Operations and
 Management Symposium (NOMS 2006)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

We apologize if you receive multiple copies of this CFP.


                 10th IEEE/IFIP
Network Operations and Management Symposium (NOMS 2006)

             http://www.noms2006.org

                 Call for Papers

           "Management of Integrated
     End-to-end Communications and Services"


The 10th IEEE/IFIP Network Operations and Management
Symposium (NOMS 2006) will be held 3-7 April 2006 in
the Vancouver Convention and Exhibition Center, Vancouver,
Canada. Held in even-numbered years since 1988, NOMS 2006
will follow the 18 year tradition of NOMS and IM as the
primary forum for technical exchange of the research,
standards, development, systems integration, service
provider, and user communities. NOMS 2006 will present
up-to-date approaches and technical solutions for
integrated systems and services including communication
networks, host systems, enterprise applications, service
oriented architectures, and delivery of management services.
The conference provides a peer-reviewed program of technical
sessions, application sessions, tutorials, posters,
application sessions, and panels as well as vendor exhibits.

Integrated systems and services require considerations for
today's multi-service and multi-domain environment of
heterogeneous technologies, service offerings, management
strategies, and business models. NOMS 2006 focuses on
integrated management that encompasses provisioning,
operation, and maintenance. This broad scope also calls
for an integrated approach to dependability, resilience,
quality-of-service, mobility management, and services
billing. In particular, these considerations include the
combination of wireless and wired networks and the
integration of all-IP communication systems.

NOMS 2006 will offer five types of sessions:
technical, application, poster, panel, and BoF. Technical
sessions present high-quality papers on the latest
research results in the network operations and management
area. Application sessions present papers focusing on the
experience of IT and telecommunications industries, such
as service providers, OSS vendors, and equipment
manufacturers. The scope here includes customer
requirements, management system implementations, and
business practices. Poster sessions provide an insight
into work-in-progress. Panel sessions focus on business
implications, market trends, and emerging applications
with panelists who are technology and business leaders.

Authors are invited to submit complete unpublished papers
that are not under review in any other conference or
journal in the following, or related topic areas:

Management Paradigms, Models and Architectures
* Self-managing networks (self-healing, self-optimizing,
  self-protecting and self-configuring)
* Integrated control and management
* Distributed and scalable management
* Policy and role based management
* Programmable, active, and adaptive mgmt
* Resilience and survivability
* "Plug-n-Play" component-based management
* Customer controlled and managed networks
* Proactive and reactive management

Operation and Management Functions
* Security management
* Mobility management
* End-to-end measurements
* Network and systems monitoring
* Alarm correlation and filtering
* Customer care and workforce management
* Process engineering for operators' service and
  network management
* Performance and fault management
* Configuration and accounting management
* Integration and testing of commercial off-the-shelf
  products
* Content hosting and delivery
* Path Protection and Restoration
* Internet service pricing, bandwidth trading,
  Service engineering, and Operational challenges
* Next generation operation support systems
* Service design and quality assurance
* Resource inventory, planning, and allocation
* Service discovery and service negotiation
* SLAs and business process management
* Quality-of-Service management
* Service portability/mobility (VHE)
* Transaction-oriented services and supply chain=20
  management
* "Soft" networks (Soft-switch, Parlay, 3GPP OSA, JAIN)
  and service switching
* Dynamic service requirements analysis
* Charging and accounting of integrated systems
  and services

Theories, Models, and Enabling Management Technologies
* Theory (control, optimization, economic, games, chaos,
  graph) for management
* Grid, middleware and peer-to-peer technologies
* Information models and Internet technologies
  (Web, XML, DEN, CIM)
* AI techniques (knowledge-based, intelligent agents,
  machine learning, neural networks,)
* Data warehousing, ontology, mining and statistical
  methods in management
* User interfaces and virtual reality in management
* Management of Emerging Networks and Services
* Converged networks and services
* Peer-to-peer and community networks
* Grids, grid services, and grid applications
* Ad hoc and self-configurable networks
* Multi-sensor and self-organizing networks
* Overlay networks, virtual topologies and VPN services
* Wireless broadband networks (2G, 2.5G, 3G, and beyond)
* High speed access, Wireless Local (WLANs) and Personal
  Area Networks (PANs)
* Optical networks (metropolitan, all optical, WDM,
  DWDM, optical IP)
* Video and broadband cable networks
* VoIP, VoD, FTTX networks, services, and protocols
  (IPv4, IPv6, H.323, SIP, RTP, RTCP, RTSP, MGCP, and QoS)
* Storage Area Networks (SAN) and ASPs server farms
* Web services and content delivery networks
* Smart homes and networked haptics
* Satellite and interplanetary networks
* e-World (e-health, e-commerce, e-business, and e-government)


Important Dates:
* Deadline for Technical Session Papers:          1 August 2005
* Deadline for Application Session Papers:    15 September 2005
* Deadline for Tutorials, Panels and Posters: 15 September 2005
* Notification of Acceptance:                  12 November 2005
* Final Camera Ready Papers Due:                1 February 2006


For more information on NOMS 2006, please contact one of the
two Program Co-chairs:

Joseph L. Hellerstein <hellers@us.ibm.com>, IBM, U.S.A.
Burkhard Stiller <stiller@tik.ee.ethz.ch>,
     University of Z=FCrich and ETH Z=FCrich, Switzerland



NOMS 2006 Poster Sessions
-------------------------

In addition to regular papers presented in technical sessions,
NOMS 2006 also offers poster sessions for more informal
interactions and presenting work in progress. Short papers
(4 pages long) can be submitted for consideration as poster
presentations. Posters will be selected from these short papers
and regular papers. You can submit your work selecting "Poster
session" in the NOMS 2006 submission system (JEMS) at
https://submissoes.sbc.org.br/noms2006. Further questions
related to posters must be addressed to the poster co-chairs:

Lisandro Zambenedetti Granville <granville@inf.ufrgs.br>,
       Federal University of Rio Grande do Sul
Nikos Anerousis <nikos@us.ibm.com>, IBM, U.S.A.
Kyung-Hyu Lee <khyulee@etri.re.kr>, ETRI, Korea

NOMS 2006 Application Sessions
------------------------------

The NOMS2006 Application Session submissions aim to encourage
discussions concerning experience, lessons-learned, business
cases, implementation examples, new applications, innovative
enterprises, and organizational impacts, in any of the detailed
topics found at http://www.noms2006.org.

Papers for the Application Sessions should be written in English.
The paper format should have a visual in the upper half of a
page and the explanatory text in the lower half (annotated
visuals). Paper submissions should consist of no more than
15 annotated visuals in PDF only. Detailed author instructions
are available on the author information page on the conference
web site. Further questions related to the application session
should be addressed to the application sessions co-chairs:

Joseph Betser <Joseph.Betser@aero.org>,
      The Aerospace Corporation, U.S.A.
Prosper Chemouil <prosper.chemouil@francetelecom.com>,
      France Telecom, France
Yoshiaki Kiriha <y-kiriha@ay.jp.nec.com>, NEC, Japan


NOMS 2006 Workshops
-------------------

Workshops on specialized topics will be held on the days before
and after the NOMS technical program. Contributions to these
workshops will be solicited and reviewed separately from those
for NOMS. A proposal to organize a half-day or full-day workshop
should contain the following information

  * A draft of the CFP (includes Title, description,
    topics and dates)
  * Why is the topic area important?
  * Likely contributors and target audience
  * Organizing committee
  * Plan for workshop advertising and publicity
  * Biography of the main organizer (100-200 words)

Deadline for submission is September 15, 2005.

For a point of reference, see the workshops held in conjunction
with IM 2005 at http://www.ieee-im.org/workshops.html. Workshop
proposals should be sent to one of the tutorial co-chairs:

Ehab Al-Shaer <ehab@cs.depaul.edu>, De Paul University, U.S.A.
Rolf Stadler <stadler@imit.kth.se>, KTH, Sweden

NOMS 2006 Tutorials
-------------------

NOMS 2006 will feature state-of-the-art tutorials from top experts
in their fields on the days before (April 3, 2006) and after
(April 7, 2006) the technical program. Topics cover every level
from introductory skills to highly advanced and address highly
important and relevant subject areas of Systems, Network, and
Service Management.
=20
To provide the best possible tutorial offerings, NOMS 2006
solicits proposals and ideas for half-day (3.5 hours) and
full-day (7 hours) tutorials.
Proposals will be evaluated by the NOMS 2006 Technical Program
Committee. Tutorial presenters will receive a honorarium. If you
are interested in presenting a tutorial at this conference or
have an idea for a tutorial you would like to see offered please
contact the Tutorial Chair:

Alexander Keller <alexk@us.ibm.com>, IBM, USA

Deadline for submitting Tutorial Proposals: 15 September 2005.

A proposal to present a tutorial should contain the following
information:

    * Tutorial Title
    * Full Name(s) and Affiliation(s) of the Instructor(s)
    * Outline and Extended Abstract (500-1000 words) detailing
      the importance of the subject and its relevance and
      benefits to NOMS 2006 attendees
    * Potential attendee profile
    * Biography of the Instructor (100-200 words)

If the tutorial or its earlier version has been given before,
please indicate the events, dates and contents.

--------------------------------------------------------------




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



From avt-bounces@ietf.org Fri Jul 22 05:24:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvtlE-0008QT-UF; Fri, 22 Jul 2005 05:24:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dvj2h-00009V-88; Thu, 21 Jul 2005 17:57:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16198;
	Thu, 21 Jul 2005 17:57:20 -0400 (EDT)
Received: from smtp2.dei.uc.pt ([193.137.203.231])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DvjWj-0002uD-7y; Thu, 21 Jul 2005 18:28:30 -0400
Received: from IBM9FDB04D90E9 (a83-132-28-5.cpe.netcabo.pt [83.132.28.5])
	by smtp2.dei.uc.pt (8.13.4/8.13.4) with ESMTP id j6LLX9on004259
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Thu, 21 Jul 2005 22:33:16 +0100
Message-Id: <200507212133.j6LLX9on004259@smtp2.dei.uc.pt>
From: "Edmundo Monteiro" <edmundo@dei.uc.pt>
To: "'Edmundo Monteiro'" <edmundo@dei.uc.pt>
Date: Thu, 21 Jul 2005 22:32:48 +0100
Organization: University of Coimbra
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_038D_01C58E44.7CD632E0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcWOO7baYROoNt0PSb+7e6b9NSiI+g==
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
X-UC-FCT-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt
	for more information
X-UC-FCT-DEI-SIC-MailScanner: Found to be clean
X-UC-FCT-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted),
	SpamAssassin (score=-0.876, required 3, BAYES_00 -2.60,
	MSGID_FROM_MTA_ID 1.72)
X-UC-FCT-DEI-SIC-MailScanner-From: edmundo@dei.uc.pt
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1338f4ee677fe822e4246c6560199c52
X-Mailman-Approved-At: Fri, 22 Jul 2005 05:24:02 -0400
Cc: 
Subject: [AVT] CFP Networking 2006
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_038D_01C58E44.7CD632E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sorry for multiple copies
-----

CALL FOR PAPERS Networking2006

2006 IFIP Networking Conference

Organised by
University of Coimbra,
Coimbra,
Portugal

15-19 May 2006
www.dei.uc.pt/Networking2006 

Networking 2006 will be organized by the University of Coimbra, Portugal. It
is the fifth event in a series of International Conferences on Networking,
sponsored by the IFIP Technical Committee on Communication Systems (TC 6).
Previous events were held in Paris (France) in 2000, Pisa (Italy) in 2002,
Athens (Greece) in 2004, and Waterloo (Canada) in 2005.

The main objectives of Networking 2006 are to bring together active and
proficient members of the networking community, from both academia and
industry, to discuss recent advances in this broad and fast-evolving field
of telecommunications, and to highlight key-issues, identify trends and
refresh vision in the field of telecommunications.

The conference objectives will be pursued through highly technical sessions
organized thematically, keynote talks, tutorials offered by invited experts,
as well as through workshops and panel discussions on hot topics. Plenary
sessions with keynote talks or panels will open or close the daily sessions.
The technical sessions will be structured into three tracks:
- Networking Technologies, Services and Protocols 
- Performance of Computer and Communication Networks 
- Mobile and Wireless Communications Systems 

Important dates:
- Full Paper Due: November 20, 2005
- Notification of Acceptance: February 1, 2006
- Final Version Due: February 28, 2006




------=_NextPart_000_038D_01C58E44.7CD632E0
Content-Type: application/pdf;
	name="Networking2006CFPv10.pdf"
Content-Disposition: attachment;
	filename="Networking2006CFPv10.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQNJeLjz9MNCjYgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgNTg2NjkvTyA4L0UgNTQ1
MTAvTiAxL1QgNTg1MDMvSCBbIDEwNTYgMjIyXT4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg
DQp4cmVmDQo2IDM4DQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDEyNzggMDAwMDAgbg0KMDAw
MDAwMTM1NCAwMDAwMCBuDQowMDAwMDAxNTM2IDAwMDAwIG4NCjAwMDAwMDE4MDkgMDAwMDAgbg0K
MDAwMDAwMjIzOSAwMDAwMCBuDQowMDAwMDAyOTYyIDAwMDAwIG4NCjAwMDAwMDI5OTYgMDAwMDAg
bg0KMDAwMDAwNTAxMCAwMDAwMCBuDQowMDAwMDA3MDk0IDAwMDAwIG4NCjAwMDAwMDcyNDggMDAw
MDAgbg0KMDAwMDAwOTEzOSAwMDAwMCBuDQowMDAwMDExMTU3IDAwMDAwIG4NCjAwMDAwMTEyODcg
MDAwMDAgbg0KMDAwMDAxMzM1NCAwMDAwMCBuDQowMDAwMDE1MzMzIDAwMDAwIG4NCjAwMDAwMTU1
MDIgMDAwMDAgbg0KMDAwMDAxNTg3NiAwMDAwMCBuDQowMDAwMDE4MDY2IDAwMDAwIG4NCjAwMDAw
MTk5MzYgMDAwMDAgbg0KMDAwMDAyMjYwNSAwMDAwMCBuDQowMDAwMDIyNzkzIDAwMDAwIG4NCjAw
MDAwMjMyMTEgMDAwMDAgbg0KMDAwMDAyNzkwMCAwMDAwMCBuDQowMDAwMDI4MDQzIDAwMDAwIG4N
CjAwMDAwMjgzMTEgMDAwMDAgbg0KMDAwMDA0NTM4NyAwMDAwMCBuDQowMDAwMDQ1NjE0IDAwMDAw
IG4NCjAwMDAwNDU4MzUgMDAwMDAgbg0KMDAwMDA0NjA3MyAwMDAwMCBuDQowMDAwMDUzMTQ1IDAw
MDAwIG4NCjAwMDAwNTMzNzQgMDAwMDAgbg0KMDAwMDA1MzU1OCAwMDAwMCBuDQowMDAwMDUzODQ0
IDAwMDAwIG4NCjAwMDAwNTQxMDQgMDAwMDAgbg0KMDAwMDA1NDM1OSAwMDAwMCBuDQowMDAwMDU0
NDM1IDAwMDAwIG4NCjAwMDAwMDEwNTYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0NC9QcmV2
IDU4NDkzL1Jvb3QgNyAwIFIvSW5mbyA1IDAgUi9JRFs8RUNDMERCRjhCMkU1QzlFNEVBNUM3MjE4
RTg5NTNEMDc+PDEzRTY1MTZCQ0M0ODc5NDRCNUU1REJEMzU4MjJCNTc3Pl0+Pg0Kc3RhcnR4cmVm
DQowDQolJUVPRg0KICAgICAgICAgICAgICAgIA0KNDMgMCBvYmo8PC9MZW5ndGggMTM2L0ZpbHRl
ci9GbGF0ZURlY29kZS9JIDE1Mi9MIDEzNi9TIDQxPj5zdHJlYW0NCnjaYmBgUGZgYMlhAILzSxhQ
ATMQszBwPGBgcktAElaGYgYGJQZ+Rg3mPTwJ2gIMjO9ZGBkq+JrkgdrqBT4rKB5YxZHDF6Gpw3JB
gsn1gbRDqdMkxiamN2yJ2x9IJKg21DE8YtzFsILRA2YsIwPDFQEgzQTEFkDMysDwaC1EnOETQIAB
AHEJGxQNCmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iajw8L01ldGFkYXRhIDQgMCBSL1BhZ2VzIDMg
MCBSL1R5cGUvQ2F0YWxvZy9QYWdlTGFiZWxzIDEgMCBSPj4NZW5kb2JqDTggMCBvYmo8PC9Dcm9w
Qm94WzAgMCA1OTUuMjIgODQyXS9QYXJlbnQgMyAwIFIvQ29udGVudHNbMTMgMCBSIDE0IDAgUiAx
NiAwIFIgMTcgMCBSIDE5IDAgUiAyMCAwIFIgMjMgMCBSIDI0IDAgUl0vUm90YXRlIDAvTWVkaWFC
b3hbMCAwIDU5NS4yMiA4NDJdL1Jlc291cmNlcyA5IDAgUi9UeXBlL1BhZ2U+Pg1lbmRvYmoNOSAw
IG9iajw8L1hPYmplY3Q8PC9JbTM0MCAyNiAwIFIvSW0zNDEgMjcgMCBSL0ltMzQyIDI4IDAgUi9J
bTE5NyAyOSAwIFIvSW0xOTggMzAgMCBSL0ltMTk5IDMxIDAgUj4+L0NvbG9yU3BhY2U8PC9DczYg
MTIgMCBSPj4vRm9udDw8L1RUMiAxMCAwIFIvVFQ0IDExIDAgUi9UVDYgMTUgMCBSL1RUNyAxOCAw
IFIvVFQ5IDIxIDAgUi9UVDExIDIyIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQ10vRXh0
R1N0YXRlPDwvR1MxIDQxIDAgUi9HUzIgNDIgMCBSPj4+Pg1lbmRvYmoNMTAgMCBvYmo8PC9TdWJ0
eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDMyIDAgUi9MYXN0Q2hhciAxMjIvV2lkdGhzWzI3
OCAwIDAgMCAwIDAgNzIyIDAgMCAwIDAgMCAyNzggMCAwIDAgNTU2IDAgNTU2IDAgMCAwIDU1NiAw
IDAgMCAzMzMgMCAwIDAgMCAwIDAgNzIyIDcyMiA3MjIgMCA2NjcgNjExIDc3OCAwIDI3OCAwIDcy
MiA2MTEgODMzIDcyMiA3NzggNjY3IDAgNzIyIDY2NyA2MTEgMCAwIDk0NCAwIDAgMCAwIDAgMCAw
IDAgMCA1NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkg
NjExIDYxMSA2MTEgMCAzODkgNTU2IDMzMyA2MTEgNTU2IDc3OCA1NTYgNTU2IDUwMF0vQmFzZUZv
bnQvQXJpYWwtQm9sZE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlw
ZS9Gb250Pj4NZW5kb2JqDTExIDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRv
ciAzMyAwIFIvTGFzdENoYXIgMjQ1L1dpZHRoc1syNzggMCAwIDAgMCAwIDY2NyAxOTEgMzMzIDMz
MyAwIDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAwIDU1NiA1
NTYgMjc4IDAgMCAwIDAgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDUw
MCAwIDU1NiA4MzMgNzIyIDc3OCA2NjcgNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyAw
IDYxMSAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAyMjIg
NTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1
MDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDU1NiAwIDAgMCA1
MDAgNTU2IDAgMCAwIDAgMjc4IDAgMCAwIDAgMCAwIDAgNTU2XS9CYXNlRm9udC9BcmlhbE1UL0Zp
cnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTEy
IDAgb2JqWy9JQ0NCYXNlZCAyNSAwIFJdDWVuZG9iag0xMyAwIG9iajw8L0xlbmd0aCAxOTQ0L0Zp
bHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiWxXy25bRwzd6yvuUgKi8TzIeXTZtA1SoEWAqKui
C1e1HTeyHdhOjfx9D8m5r8gIkFyezPDNw9HFu49huHna/HjYXBwOcQjD4XoTkuPGNHj8Gb9jcXko
JTuffRoOdxs/3Gy88z7E4XDc7OUz4fNl8+f27eXpNFw/PA4fLr9cPe6yo+3Tbp9c2A67vw6/boJ3
uZRm+vu36c84NOqHQj/rjsV0R+93e3Z5m4f3v+z2BUrffxh+v3reFZe2L7t9aK5tHx4/3+4qgPub
wY6/fbi/vrLPx13A31f3xytzB4GTBd5cIbK4+6e5xcHVaG6pM6GJX2P04tYf97f/IVT4w4iV8fct
XEHgz9+Gh2v4kOHo213ePtjn7d3fejpvL98Mr+As+IeH/v389QZZjNtLO3R6MwT74p3H33s7Ba9+
g6Z+6NugV6JJXg96E7IKFnxxJXsLuX9ayBQdeQv54u1THo5PVq7h6XhvtUmaAwv/0/Pzlx8uLsSP
tn15edmFANvO5H+ubt3Xo/vyfCFlsiMIt6IQFQn4jET57e39DUqb1aefD5vuRHBogRARCFx0DI9o
eLzaXEu/nnseOLlKK9+1S8VRhHv4d7MPUJVLHFCbwKjdT/0/YHIK02UqPuPf6ksVuzEWYg384t3H
KOMShtthQ5iNRta1qcbhTpHSGpDifK2DylnmhhDBQq4kXT8ccSO7vEBOM5K9oxoUiS7BgQXiccYH
6A0yGgP5CLuIvFQXYoKsiSs1uFJYzHhE03hCRAWOoHv1iu9XxEjxrjHPcjd63KSGk7R0bEJm5+EI
tbhCqhRPM5DyILH4VC1D3DQjNc45PJ5l9YRqUyTkMwGrrnKQTAOJVQ9JXtEhRUUJD1pjA4/ESYbW
FFzyeT6RJGNyIqJlEH6SyogFci3YDehshmQwwUmRlEmN5kC4gznXakfHqAYlQt+x2hBcdIDPatGU
FfyPeMGpqSzxzH6ajBuIpF+wA6TumgIJFEkJRU1GJEkugJuaOVUSnIAcvNwAVXNdyM0Rp35DkYJa
wbhqqFaiWoPaINCtkD1F7R7xQpJVMGgla7pliKR3OEYLI9AkW7oxZ/MJJMKPGlrTVHFoaiP1ZEvm
4AKXQaQam7Z3K3WWe/mPZw1x2nzSZFdtNY/GqdIkQMwKChOipb8FtVoRofjta55kSz+VvDiBNmsi
MwatqgxSmGwcz6xqu5JwSNJpa0WJgeAJlQk5zYiOrLYXYYNNQ7xGwFp+fesMyUIJawR1zMg1IXrS
lvEZPUjsJOYuIgKSRl/8P3YJ966WFFBVLpFBsdwD4Gw92jh3P9H0ijDOiMbcuUO7GCYjt2WbC0Vz
XpzoGZPRAfnNMkMz6Y2OzJGnqtZeQ+YMjrfOkKkSqBes5la1yhUpuFMkBLmX5F0zkEQWo1a5wm/i
1qcOepN2PGOvxbIkaSZUry4RauimlX8csYfyCiHjVOmn2AEMr5kKSC6zo1Q0NSQiJif1cpHWB0jQ
2TDkpEgNuV8BccFXCkFJuAlxMUrMFl1qqkPqIoQ6+4Vu4rjyXbS17mlTrkcPhjTqxbxBFr4Qu7GK
jH4uvPQVCMelqxIlNXMVaRC51GgqhemFxoINIBpRVIAkNJjZMdk1dVX0LDzblqWAfqX7GQCpF2OU
SCPiE9uSTWIaPUvWEyFgUNAjSpvWNMezNtLWahF+J6XfiEa+WyBIKJJBzU9rVUcBq5PjalgQR/WL
rYGGD5768uOFLO2lNDYi4onHDJeGsUozHY82ZsKuyGtdnBi9HDUs4zAb30WmFCx6s41xbbqna3E1
xQkRO63YVkXxF7Jo4e6JIqii/BQQDUmeLkVIpS58N1luIO+dCPQEovVdA6NCkzzbmBB0iqxAaIic
Fl6ONTD5eBaZ1bb1pQYCKrpwgMhbQdcHfGY8u4L6joHDbZGr1qHoyj1u8G7AEBnpC0UyHlChzpVh
jyZcrVZBqKxPNNvF6CL2JLQhkrwT5DjSyH2rtKYH+nEPmD1G01fziMYLla2LkZKTaRCGAVC4m6i2
E4XxRA4+9h+HubtYOlXHph6mXp/ki8ZY2yTKeTxw/fIACqpbFhqRbElb07cpXGJLAjjHGyKF1MSz
lTx12euelF2oDT4i88Q3DAml15CZOCY9M1Jda20q+umsDaQ1OMp7Zyacuw3eIUjC0hrjoZt6V+r6
4hD0kSFcJ8+pJTJd8vJc59cQ6dC20nOOFNIAlwjewdDDASlW7sICRqpVFsYEzwZ9BOqNHCdEdEiv
Rr1DeOxrQNEelvJc5ED65BSrPifVUe3ZNqUTKwVTzkskoCOTaQ2Wl++SaQmWZuw/aMBHSHDEj0l5
ZHRkD3ry+MWBfwJg/Go8v/NpvjUX6jtk1BOKjrb++mQ8qdqime5mRJ6s4vMkJ+wi5BdyTfbIljUq
cow2VMnmmuQXiE0V3qoi6g8lmQmse6xHEHGYZLmAEqW8OIH1YFPnwQ/4nYFlXFRhTsKTjOdR1BXO
2IaY/VSmrohSPzyzQzGfU1UTIzJ3G567saTXkLmCk54VEs2XEmpHIucVUjRT4j8LCcDblIwrI9at
xEPB5BLHBFCy3onBUiQbdWJGPDLLassN/wswAN04xksNCmVuZHN0cmVhbQ1lbmRvYmoNMTQgMCBv
Ymo8PC9MZW5ndGggMjAxNC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl0V7uuZLkNzPsr
zhccS6JISvFkBuxkQ8OJ2zAMY8bJBvv7riqqu+/swpigh7p6kMVikcfnvOeYV+a6fYzLp9+5uuwW
C3bcYTDzbpnX8+Ez72k8EHfHL+3lMCfO5cccdzY7+7kQ7Z649zsW5r1nfln518MDXrjp1Q5vfmAl
b/N4r3z/rETH79cFxwsNT0fcuWEigu4wHfcv2BOuL7qCVwZf8XFH29gx7s4N/V4dpu87/GPjgAOE
Hl92BGLvuqDj1/FUa2VvC52we02u2O3LsAM4dJMTYfCRNxEO3NS38MRfVk6tOABHXLh1dMURnnok
Z+iKnSknwiquaUNXAIgMPbrhLt22XXb4Cax9bCLRsLN/dgAJKy97wuuwe4AMdMEOcC27fJyL20+6
8FCP8bFx7dp+TtTKuNtIZWvCqfnTit2zuxLaJ28BNnwVtzRht5Guj11YOfPx3tFxA6kEf9O/2Dyp
lL9WQM81CB4g8vzQHW/Y3m+bnuNEflboZd9dFZDwX5H1If4ju69Yd75Xvv+Bzt8f/5bvtqJ8A1t/
fFmZxV8yQN6DXa18i/zY5dtu67MDvlmMiv9rGljT9jUNCH+AAQd00i1ZHcJ8e7neCvJFphz7KTLK
ifeO43QS8uunqMD75x/iZHn3i/9+ff738advv8b17Zer0UE4ht9NNBso3lGLv3z766Ndf77a9R+s
LVD0t2tef7n+9vd2/RPSsetub2BMEMPXCkRF9Qb56mTIbGKsGwKabxPutURK/L0CRBpo5/29glTe
TgKcK9/2efT5+KygMpGO9w2g5UDlvt84Nl49bpwFiuDx83XkHdm58neRPh//ePw/zIirUQNZwYm/
Yu3HZwUvGITZIIc7S6uG+wXBgLZ97OcD792N9fbasaEG+3PBMc8L2H8WFhZApffxtYTO+4Fj48DL
hdeOl4uvG34XxPMn6hgK0NmpFouAPcLAYU/u38A7LtqNecCvQXSNPSnUi1p5jAXfFcNA/chmMQQE
M7IO0GQh93NAzQsX+qwHlFjooZnsmFWhe9WBwP8KtGy8cUupWKFzyKQM8YIIYY5g9pAHgx7A9n76
59L+0ao+R6sHgAK7GuVpR4VQELrxvX7HEiJ0lJjvO/P0c2KCh3IuYZQ8ALup36Nx1Qtoq8MocOiz
6DO0u0JY6BUme7FNAqU+UyfWW5aKWvhtU+1hQToJihEU2shghc2dXMnJsIEzowq2TUS1yBTaeCuH
Tqwjw8jN6kImWUBgXSyyDQAMshE3HK8wsnADWlvgAK6mngiaZOBop72A6JVs0pNXIHAMD7qyqR+V
DltaKT/sHnmynVJsQMMo4APHAZhr4gL6MsQ2268KS6/sNmeYWSogwqbCXr36BmcsnrA7SZhF/tCn
paZPe0fIp7VSUfa9TsLHnGKEgVmmZlD9irML+sUdknwwxaosh9jMuBargvYW9kkOirqV7xF2gBri
8GAQLB6vJrzaEmwrivJRHARHOTGyWyWLIDX48QLnAcLWD6FsnKiXpVzY7eCkSkZMogsywKpJ0kUn
NgYaq0Ix5gp2aKzdlX3csDkSgXizgJ3iTeK3eeWOGkJ7jSXOYhwqtTmlDff9qE3bYrlyBxh0AKzh
2EbWaBbkytTEA1z9HDj8SfpE27bsfU4M0H3XML29ilvZ75rLSPqgOgAfFhjDALtZnHDb6NSiIrn4
sPtU3EnF4w29sAX/id2in4KSXK1xp+wstqyxz/7JcmfDj31K8+SC8gBfrDg/W0ka/jCs+DKr+v1M
JV3pR5Dil1Fbi7HbayEgdqrDXnNR71W5uw1daLsfxs4o3W5oQbRTQ0qrOqKMyGemaB7KRp/1HTPG
IekSLm2WsquFA7dZzQqADDHGJH+UrEaRo51dcbOGxagCCkXMOV1J6uqHK1LF7ekCrkbRIXIXzWMV
QTCXqbjTa3zto9qLU7JY0vZilPoRWU0pjjOcwTdUGKOcnAepJ1PZJobEFk7t4I6tUpScDMnH2CY7
q5Dow14i1FhTYU4KDDvXiYKjJym66wnGWeoRqrRZH5AaNHcVltekw/J5qm0P8t6ZixKMfgaNzSeQ
Vcw/6rqr9AA6UECtUgzqQlfYJBjlttcnaLOXBvqsZsHpSdlepatBvqTmZcY0zmDgmo+5kpoksmYZ
DvCaZUAGCXOpAk9sSQ+hbixNsp6URHY3SUxRWyX+COTUxeoVxKQwE5hddWKcfvDGZqlKsP3kIlQI
pqmcXolhGNrVNSnpEeq7NU1wHrE64C8CCcc+tyzT9wQK0/fZ37P6l/oRYTgdb62qClMddeF/XqgJ
q1Vp88uNMG2V+pI0siZyvuhEiLmydiqEGNWVm3z6eajjyCdgsnocPlA16CEd5D3IxwwzfyFVczVc
5lffbIvQxWGMe92h0ZItS3MSdJADRpy+Stk7CtGIFW5ug5ziCNqF3cjqorZqxG/5emFTMTCxz3aG
TfZdfGFmP7xnZE69rHLnZwMW2D9MLeqMVQNdgqZyQSXqp6X1KBI3BgkhdquBZbM50PZiIKfmOtHs
jLedbRNMyxLSKZfY2yqGWGcM6+ViFD9ITBC8KM265F9DDY4hUy2Wpjb2RIJUw27cqyYLAsCmPF/b
m5Xm6u9VKnnGJI2eZ0KLmo9e+oa88iGpMuuYdqtxOEfJlW87ZVg6jhWrMpz6xODwcbLwhUvPx/U/
AQYAgeOvqA0KZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9u
dERlc2NyaXB0b3IgMzQgMCBSL0xhc3RDaGFyIDMyL1dpZHRoc1s2MDNdL0Jhc2VGb250L0x1Y2lk
YUNvbnNvbGUvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+
Pg1lbmRvYmoNMTYgMCBvYmo8PC9MZW5ndGggMTgyMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVh
bQ0KSIm8V02P2zYQvftX6FRQRayK3+SxSb9QoGmAOCjQoAfXq911Y1uB7U2a/vq+4ZCU7E3aIoci
QKyhyJk3894MtbeLvjNKW93gNxqp8OuNlKE5bQ4LHWHp2HjXd0qbZr+w0nXR1IXd4unC9hZHdeOt
6rz0tAkrgXZZ04UQGtv7TjsL23XSetgRQWW1N3ArOzctWKm66LIDa2c2QgSTDpQV2SkT0g5tHGwA
cxp23/U9bBM610c60eNJA4TxnTMSIBxAIDdju+jZ1k7BRkztSowg68putqK7mNKnVLWNH10xKd58
BYXyKVBvCIhDMpGrgSp5E5GCydUIUqbk+kjJSSTLtpV2ZqMcVuYTvGI61eu0QxokY22nqICIoXtT
bSqH74Lzsx0ONpdca0ZpHLNqdUJ1xfNucbuwSne9dwl7RPH2sxXXWesaq5CL5gJ5R9QGaCNUm7CD
AOtmOwz8x8lDtTkGncgrVoMyqk/2UOWTY0z6KijKjoKyeLjKY7O4T7iC0vPc6opLv9QMXlmm2sVZ
bmxz3N7LaQfs6Gceql1zKytAJnvZVA+Fp5pbZbKgqDsyyuLhKo8N8abBIelhyq2u5KprCf79xIoK
nU25Vt6U7WzQsx2GW7AyX+wpt7xSq549VFZyjIm3gqLsKCiLh6s8Em/wmtprkmReKDVHo1s146Rk
VlnTfedmPBIKN53PVs2K7VLtcrawUXOqfJX4dQfDq4RfwE9sGQw5H2pvIiWDKC656MmFjoA2tbfV
oYv9RVCNAppZu2v8Sh4h0rnJRtjgYz7RS50mqqdK+06lCWSCSgGM1dXeJERRThsM5rFmf5h7M9t3
GD3pQFmxPLLgwNDIKnJCCGX1XHAaczjOBAdb9p4HaZJssSNKHvKJtEJDLJ2A4KSayQl1uryIUMno
zbSD0jJcWZSFmPA+JlNyYa+42ZECCbpPlbMh9RZmadJEWki1Jp90N7kLU6l08dQVl+nFeTPXI3YG
N1csYEo720GoVEjFDUhwsnH5RVlwq+nWSR68nTDOUyARfvX9S9ncnRZPVwuP8qPpevzLjyhu0iOq
ZwPIXO0XfXO3EE27+mPx1WqlGtmsbhekBcMH86Py1DuSrl4+tqR7G7N9teFH26zeL16Lb/8c2iUo
EZsH+g3ivG2XUndWvGvRcVHgNS5nJZpn9F6LscVxJ/b77fncLhFFDNlD0/62+pFAGQaFCuGaJkz8
xJB6UkbJBGB6wnGdz+NC5MOQcj/LBx8P5AJP+PBI+XwPMNCmOBBuTHxxbCFisc7Wjt9SMuBB3LdL
jQzW2/Q6iON1Dn2zxIVvo29W32S8CIY+5OLdsJt9CxGLhxadLA60pMXN2PyUVsfDeYD7SN5Hdr/6
MnnBTMr+kF/y9+qQdnrUfonGEsOxxTgQJ6DD15cglMjh/KGVWjTjLUWiXMZ8imAE8TtjOrY95f2k
IZK8eNGi/5g8I45nPvpwt94xpI9y5Ty+r8JncuUcfffMuKLHXL6svdWwuT9sN8DwAgoCYtkTwiDu
6L9jizkm1vumJfzP7mmNiMLYf8xTKaktMbznGN8Nx8M6eThQIQIR83Rcv9verNlxpWR5xYm74CQy
J545UZkTQ5xg0CdOFLxnVnRlJSZWHLNiEit2xsoIDDLzof+VDxqSn82Hxs1eGu8i05Bb59k9lxd4
njQvk17eAq6kEUApb7aEjmCvuPGJMOS03rxpbseLJd72fDgn/b5HjRwcjMc32wPeRHHHWebuUtRc
WQ7jjiGMd9sBW7U4EZYllXDI4oUFMqQV2w0DG04cb31gEDfNi2PGwwDGTXF7+niDQ+mpwaku04gs
bbm6T94MqHQ0LU61pyT1WHIdMWIowF1LGIeyn5wD1+FJAx2965qfkxhIPHRwLDp4Ph7fr/nMh3aa
pR9XASaoMp+pAhsxKNS8K1WVgbmUgSkycJDBkubPwM13pYPIpMuZDupS82LIrqYXigqzPmyGuQaM
0ZUAW5N6LcZbNNL+7cOZrhhqvuaLXDIs7x/oESMXM4SIDtSN9G5MXXbgtxdS40G+nOK8TiqlwcAq
DaTSRyq5GC+vxdOHYwr3huf6PauP58vxJgN8ed7udsOxUPyqpZvm0PZi+46PDezkxFYa7paHO3UQ
DZI0n359OJLQOVAvmjzNbh63ULrhbZVvbutv6cpT4ArfI+KH5tf0my/7I7cQeQ5wmlqNNr+naZaG
G42lXPy/AJhQ7Hh1fbgpVXKf+gqRkr5a8RWj8dn8Scn+0/cC/uDBhxYf/a8ax/eeTs37f0y6n8bf
tzseVc26sPL4OsFfYyn0L7mm6ThaajecTpA4a2e/59+HcmERJoibe+i8HQ+fmF/lAyXfW5spekp3
uAHRnNAvUDl1Mnk+nd/er3e7lj7rnqSV5vn4Zovb6VUauVJ8Xcb5J6eRVRqfzMxP87cAAwDsqALs
DQplbmRzdHJlYW0NZW5kb2JqDTE3IDAgb2JqPDwvTGVuZ3RoIDE5NDgvRmlsdGVyL0ZsYXRlRGVj
b2RlPj5zdHJlYW0NCkiJnFdNc9s2EL37V+DUgB2JIfito618uXUcN5InnUlygGVaZkwTHlJ0xvm3
mR7aS4+9dx8WpOQoipOMZyyKIoHF27dv3wZivtgLxPzjnhTe/MPe4/k8FErML/YyP0uDWAT05y7D
zE9FomJ8i8T8em8c+EGgQrsErjKs81b+XnjjiZ/Iu9p449yfyJVHT6ayEL8Ib0yLyRMvp++aH6vd
45WYXuoS17FsWuG9n/+GcGIOZ/4r74HN7L5Bwrs99xJascPCkbzzUj+U4qg47xYjcVqXt1gvkkXT
lis8EtIjKqKYhLkQR+U/y2LkYjrwxnQyWXgBYlmW3TWtlUnBgQRirHyV0Fmf2DiC4dSAAnG8pDgm
8jNOrGRTGvGsoVMmsrBHSmVDO516YxXSzweeCuQhPSpHgCaS4sS4F+07q26pK9448fMosVngK5uE
OJ/4WcxJCH40g3Gu/DB0L+MA6RpTxWeZdysDVBBPRJiVuk9OhpNQ9HTUlpBS8ss8MVBplgxITdbL
x7z8cVExMVrCgzA2tXhG58ZFWyyYAZrygrQgh76YamQjlTe0ZyxLfrvW7YjTLgAoPdx445S+6k9l
dS9vcRwN4cRD4txhT3RXGUeCGdYJpWMh9lTyv6LlzCnac0p4JHJk85XR98bG/WC+EqJl8LP5iul/
vpEvNZzA4fnGNFctMAnlpblxmbJs2iqj7fTk6/Q4JtP7ja70mWl7VK5KXZeEwvF09lo8evJoJJ43
RbEodtRGMhzxrfzNNMtCzD73S5XVLaX2dNqX3YkBhDkgxI1cfhvIMPTTdAPI78WQVEvFG6q1QYOJ
o0F3VpULVolU3hGKjKEuG4tt9h1Uj/pFM7foQTeeeeOEuNTVSyb0UUFCcDw/HYlZWS/1DQrf0ogE
EmIQyh2oqh7Qv4x4RWKD4lTyVleXZiQOGbwTbBbJ6Y8SNCJBUeFPEjTKSd2DTXAHHMAuBH1Yn3et
hTZBkQIQSDXJ8GvWggTdIAAPSv5KUsApQAL4jQfIPOzpGsNBCXmBun5kwdIfbKuwxZ1zU0qkONbY
MJL1OX9Sfwjp4ZH72dHWeOgdFb+qay2Oi5U/Il2q+S19rnekbbu+0LFwwL816c4fnT5vDCNj5ZB6
gpg2HuXDRkpx4gjlgvI328dBUrmuHXxSt7RPP5jjhLb96RyTCHHVXG/UeF81mtm3Kg332NoDJsif
xYZ/Lb1gpyAlk2y3QP/JpLYEIcKXRSNeWmV2d9ryZgzhz21fpe1RFx3TvwSkqaxJck4GzZnxgje6
rHckbTIU8tDdU3YsFu+yKjVX87QD+CHl37CqnXAnMrZRNU7V4kHVYGN2Yr/drLZb85FuV+IpDqDk
uQc2lAR7bWslc3L1IMZqw0alTlY0ChKttNKLK/ZOPkySPeYbgjEC81dFUxkD4tvU1rt5P3Sp3EX+
WpvuQhyYbqXPuFmhEfD62EehxmkjkvhkvRGj7CmFqus3+yaKzilu8+jIUBF5UHfHg1dWH2I2NJlc
auZMXX4iZRZTc31dOmKvrIoWhXiYvtsp+1oL3OFOsnTTk1g3ErNghdaNRHAj9wDf2HmtuuFAWlCW
2su/ICxxlWj69XRt++qhz8BWoYZsp/kO/GFNY1YQd2kVJFQknZtdQq2NodtytipQx8qacMVuDrpB
M8KSrykpVjwpMyvXTgr3zpeZ2SFkYUCufsv9bmKPM0eUcsL/hmyPqZiD7ySXWEaQIrqyeeftysSW
fLwmAlP4YDeM5dzS6YUXy/E+c0872wvFpPPXtv7s1GLnFTQFtA3rEVjyrdO9hryhNPrxxz67EVaa
xOnuktzvltSWDVVzqxe94z608phSkAofj9kGHR7b2SWUT2fOXeRWaXMKZsWPrPtPX4JbQ9JzL6YC
6/j5Ow8VL15d28nJjUnnm79pno54KOpHJU7CnLM/xdQWy9QDKINWRUgQ70WsEQsyxE0/T9jTJXL/
XqRfEUTAnXMbCaXTxhPsltJN6O4HD4w09rqqivW4Ga7HTRxExXbYdC1bo1+4ESYjS5P2TQkT0MSW
GrGh7r21iy8aWBq78F7Y6VTTOIJCiW0uxhGcq7XTFGpip9nN3/Hf2DutQ4MMPSgTS7KjhAxe2ecb
/Pt9kKI1SL2vM7qmyUDMVvq20VcQUHmFSeG0tjlzZu4WNI2kL/ZRB2RVLou6xRDhIeXrSWItIhCL
OJ2IjGoxUfk9mXKTxasze9IPmBiRIzhHhb0U6AQJgaPCsk/ne4qG3jQUmaI2Tm5m4keC3GYMYjbF
3sXewfzb0hGSgcTrRPp8a/wgQgVpHKLeJiqLv2H9yDVy/X4EENT3miu0GpoNmc4pfzhK0EOOK8qZ
T/zDtTgrhGHbx10rQdcC+UgQz8UZ8VUKQtktNIgJb25lIrOsnBprMtFbEnnWG3QkS4+8vA/E8n5i
uR5ZU6MrXxyuBGUem1yUF6tLUdwWNd2qhRZt0ZTUp8D6r7Y5FkiMBdTmaw0DQ9IxNfVF0RTEfXq1
Fg6riLFCpTnlUxQjYBuJ9obGBOO0EOfeOF8OAPh7IQ6fHfJazp71IuLUdHFZW4ONlm+NHnUXavaw
VW5Xd7+rndmNpHVd3nvxvwADAD4TeFwNCmVuZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmo8PC9TdWJ0
eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1szNyAwIFJdL0Jhc2VGb250L0tMTklPTitTeW1ib2xN
VC9Ub1VuaWNvZGUgMzggMCBSL0VuY29kaW5nL0lkZW50aXR5LUgvVHlwZS9Gb250Pj4NZW5kb2Jq
DTE5IDAgb2JqPDwvTGVuZ3RoIDE5OTcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJtFfZ
rttGEn3XV/TTgBxcMVyaWxAM4NxZkAAzMGAB82DPA0W2JFq8pEBScpyvz6mFWnIdwzPAwPAV2ezu
qlN96lT15udVaNZREKWx2fx1FQZhGOZmU6/W/IjBT6v33jt/nXqf/SgJMm+anb/O8fDiZ4H1JkNv
uffB89dZkHobv8DfZx3NPviBPr71oxBfRj8KEs9dWn9dBpE3nCfjLq6fl30++VGEzdXG6MzBdY1p
+2WXavRLTxdP9JN5BrZL7+9+iO9j1dfugy++0LI4DGWr8Mn4/9n8vPruecpMPZkQ/yIz1f0qiYKw
zBK8IwKMuywoBKGAfwtr8Kkgc3EIsxXv87fNysZxUFqTFTaITZQGUWwAMSmxfHSr3erHzQo+Z6Fl
Y/pokyIIMyxKg7QIE7N5gaG9RL64RT4R44wNNn+aqw5ovc/ARu+GQuD1wJx4hDH+Q3RZUJJf19ON
rtC8N/PB9ZO/+chgyijIFUtsg6j4BiwpQBd5Wf43aNbEmn/4KXOBX5zjI3sFiwGtbRKEeZwKScv8
iiO94QB++2SqvjGE5XUIbJDH9hYCjsB77984zhJ2qtmBU3joBnA39obleOMIr4XJ8hQhAUn4dMuv
RyS2ZWBpTfY6Hq/zCvF4rvqqqT74zFVlapgGCr4IcmstYS9DTtD33ubgNBckASsEK/awetjK8o88
7Hi4njVVLj7t4bnJDDvzLzfT1HRJtmE8tr0s3vMyYlRmqlHSyJl5MNtRd+r3eN07P8d24I/mqalg
6iL5KKZNxVNwKKdx2LW1Lkeqmxf18E5G1Hc3soPzFWP/e1d5b/J3LyF6pV7lLcpWolyTZctLLZvL
9O+5h1MF4SAbCRQug4dPZkd8ICJgdFmh/myH+QCsVePuP5JCkDAAM4/2pFjNeZo5golIZ+E9sQcI
n5gzTTupb+dpAqlqCk7VXNgNErKJWDEf2gnhH6qGKb6rpnntLkN3oRjsWtcJhgaBA38jzZvNn29c
Xy8JQ9GYZUGB+BPb2YHEG14ISe6dfRLpnj+1Mq+u5nboJ0kwMOHQ7g8d/s/m6Ja4AV7prSHtqddO
suN0dljTNsDUskcsKja5k6LXCbGTw9ZSY+ZRSdI3E8zLc4NI0QmBzAejlOMDgE04KiFzHBmKiWbS
Yv2RLdGdzv+vgdFc/W6zQREwm51QsihtfK0nBK++YuaKOgtTxnOtT2f6Kak+Uo1xCpfOdR5ObT0t
qhQVyIPYZBAn/ECbMshSYUljF1mCK1Zc+YJApXkQYzkqWRIuAnVVUhZQ4M4t9J8UI8rtQ6weqERS
VA/9zo1KhJ6DVC/JO2w/cuwcaYNTXtzqfHnLnK4zW2dO5xGsAeAD5w0y8Lw/aK4w65RohkMWs9DA
3KFv60rPzkxuIhZARsZ91be/+rQP76k+ynHi6LBGF+m2T7yd+nd0n3lpP8zum5VmrjQZj6D+fJ4H
ERJVmYrTvyOFk0xF3BqzleMX7QF5L+2MUffLyY0zJd10H7CUMWMT2bGT6GGSyAhFDjHjzQ9YF1GV
/QR5nw4qZidePnEun6redSxCkB/1kSPXm8Mwk0zRPif9Ui9EX5Tljg+Zdkqd66VoRIwn0eOgDXLe
+g5KTmEJuYiokMS6iEOOUB4BAN0L9V0kLIajCZDsNyOOvVc7EpfEnhlODlVxNHU36GzK7MS7Ky9N
1epscMDe2CPTA0MMnx0zTIYq3mGxQNPZ5fYBHE4chL4nzV3f8lr0wHxUCgjBmfjQ9lrxpNTRkTpn
dIxkr6pF847T91flySXd4yBGT0om4ygp2eQ1t3+A6eIv1B9d1QFUyDAt/AqjmUQJHZM2DQkAopYK
sY/KDSrGDJ66/1w5iqgNylNh0p6HdYnMAcHfkeAta8ZLqxXR8ZKF10TXt+MwD/WA/Pk9bHhsbcFt
UhxH2bfgTrP4q4WIcccJXNB7izQ12hHtBn3QFgylmqovH5FG4nl4OZ3RWeorAXiWWqJSn7FagipS
Ru6bMuoVKMLeUU6aEwDa9iXcBOT/gvuf7OqwbTsnrTXBoJ6Z+kht5rgKM4oOmXAHsFdUyw3t3XJ5
lPfZ6eVRPy81OsijpLjrdv/gGrGRgrguWRV2lDLcwkNRdXT2C+qzlqBaaR9zaemWSyg3kdzptn3d
nRuHdnx7npcTw90TSmS6lnxFX0OyrLvpNujaqazA1G7g21k3XJvVUqgeUQmRwb2mK65MScolWZ60
oKcxlCX+ckUOqZ3IREqim5TYpasotat4w014xj0MITR/Mj4KfQbZX1NrYcn3PT9X0k/jwBCwwtPX
LaPgnlZ3QAP+ic4uAmgaQC25loH1oxcLh940smdDbQE9QCP5P+JhqYnaE6Hkk6HsIkFNifMyBupI
E0Txs3xqeC0ojrzkBa0RD1QysAeb1lEoPt9NnM2Dp9HVP5meAm0UCpkpMI6X5Vj20/JE36lq8Bv5
WOpf8YyuS7yDzuhrLuIP/YKN7OOVdX3fBr456wVkEH72i17y20tbg8E6g08hJl1YU6yOvpbGhPTx
vtbcEaS4EkQz58dxoO0yr2q2lTz1VK8an+wZtpESuoSO2nVO5kw+VWc2RvcLppQur/0o555vmh7a
gzK70kK7xWcyVImanvQXq4kW1KbMn/2EL1on+dTxKI465iNt/Yhg93v5+nUOmt8EGAC+in2JDQpl
bmRzdHJlYW0NZW5kb2JqDTIwIDAgb2JqPDwvTGVuZ3RoIDE5MDkvRmlsdGVyL0ZsYXRlRGVjb2Rl
Pj5zdHJlYW0NCkiJhFdNk9s2D77nV/CUITuRK0rW17md6ce8SdMkt7YHrc3amtVK+0ryZvLviwcA
JXu3O71YBgmSAAg8ePiH/SH0/aVvXdLsajsZ59Ndbocg8vLV+YzkUaddvivtvSvt7JI9jZs/bSZT
P7lyl9l3LknpY7KdS2ijwhY6bvJrNfPW3IVvzpfb1sPxT+eScldZY9xfX3598+W7N+kuTZvCfDm8
SfhvZb58ffOH/cF5v2toIZ2wt8NJvmF2GfZeOucL2mYcZNwcIG/qi2todnJZDiWX7rztXQHFeCwf
lu5xLv3zaaHH0o4SFHEyDIs5YtPadohGYedlcj4X2e9p+zuZvsR1Hqep8jjIgalJ/M7vPZ33o3hc
bh7Xq8cZBz+33+Blbh8dhxfO1OxFZk8yxCaUtlWN8zeXlyS/M7NDWIIMH1i43CxhwyrdU88xfI+5
fetq3Nsjxw0OFrTuiTdpr3fU065dK3wVXUur1bW0Edd+chVtPzmc3B1dUiMDkH74g/TL6WpGEUXr
nlZwFNnoQZLhpCtvL9FXeomp10v8eXyghVgRcIs1zsIpHmfQuLfTvdhCInZnpZPO3WTm5oz3mez+
y6B2B7Gq7yndm9VWuiH61TlVPQTTDTHKZAtSZW9Xv7Fgup/ZZdLK0jW4a6Lm0cfUb1Y0bMXEG0oZ
4AZpLRf03gZRuTOt/OFsaejDEgqi0Swu6WapUPdWNTmLM9uNw/ws2mn9olRhCqtf2dIgjcY4jgCX
NoprrYrYIyMbi8wl0//W5XF2MufudFYhEaVHFYOCgopHrvMtzPH0rwolFOI4+UpV+v3qnC/Fuffj
Hd0hhamig3v+Rd7GlNrvOKmAmoAXpG1tZwQ8Dh3O3RIOy0UkXjsrAL81j5veiDsrEXkJVU1xSjJg
iEz0kCob7+Nl2W0X469N55rHbVeaogQohMoVfc2DJCIysLJHUQ6AoX6+Beh0g6tU4er9x/99fof1
tA/qO7PvKf6VpeHbKGfZLs1L40lzX5VrqDPOaN3rgrPp2AVXFQ31FAHEu5XJGUY3BP3DSQZeCUS2
mppl2/YV+YntEdHuIcjAERVIad7iIjAwOcSeBxccQpd7UJnj7+1tYPwWdR+jLkVGqIsTCRrQEzJP
4egeXYZ9PAM0yrU9wCeuiEryGd7PjCfyS4bx2IRUoyagW40yqutGHBPXmVdy+youaHsw9QMDRKYE
oJEunTECZyAADENylccwdw4AcRKdYesZDYru0D62h27hds9WsxbFLCexhbV7O+hSkQR4fBR131ez
O9+sL66t99I/xHbPtudse7Xa/tDK3NCewgMa+oz8p0YeOP+bZ3eaNvsVbBXhPsDGmu4n5cZZEnRn
SIZxEgi/B6LVqCeUA9RaqfCZW+hFBG6rVGBRS2BKPrLtrPsQjFtzPYEtmfp4HbgLjtvEUU5Q5Vuo
LovoR5lvIWPsXcDCcnIDZGrUwUnw5n6NG5T26zThQyHoh0/fd9ypanAzUSCzE1SomTv035K5hyjz
jqhk4R6YZCqSCjfk5YPoPmvukaDF8voQtNcJrFfaKFC6uHfmeIv2/0z4YMatPeq0j8SWmDzeXLpv
NtjQo36jZlpYRgbCzO7QOgYlOIPuagaRgypwN2Dorphuwad72gJZkGSvtZxyZS+5VuXP35Ane+KV
AL/JwXAiTRDMB662wMLC5U6nMoRP8JR40yxG/XsZef+CzfwGCCmJ5VW8MXdK2quwfSsCWVMpXWOZ
ITpDBTC3Zl1hawzQzym2X4spnvhRwT2ECaGqbLKMyWOQe8XrRMmapgaPkVvFszdDur0ZYpl+1FsX
dJ2eWkHE7inQ+6AUgKvp87DyIEgXeGS1qzS35vuVXPpILumQTOkq2/Z1NZy+jAEwgrtW5hl19M8p
6J+oERcO+l14vn6Wl35r6/nmZsqpUYAjo0kWsP+dueuYaKM2K8aWBOl3cvwYC6I4yuCgb74HRLrQ
jptZ0TEPqnUUrSASsYJXestLyv87W3AR/tv2nXAOyg6l+X8L9TCfFd+uuP/TDfc/SGb+W2O4fcNx
h5OjgWr6Hmvjew6vGfq0z59pXo5kjGXXw3Iej6JF+YPILePYq+Is79lnpLguow21FvHvF86GIBku
QjeIdJJEWc6iMvJn4gNQbvVavmBOe8LuK+qUbK1cudOnwC6VwqNzqibpBUxyMG6eFOV99BfvuJLr
hBW+p+YiOp1scQyjGZ/CFBvBLx9NbFaJdiN9twk/5UG8XGvgT/k6NbuCH62mTy5nVgxkmUdOF8B0
gSdT2/fMK0cZPbTLmqvAj3GQ8f/o3Z+kd4/iAYq94WdPwf6kqA5+b7XRRemr5rqBa7uXRdKADzxx
1lhz39GlJ+OuXnAva2V7Y6TlFWWsOZD2ruuZeOFu2CggxZGF83gwg4vQ0QjxkfdHw6WzZ+KDtE3y
NTAv+fEVQdZs/Uyh5dYdhM9Q4BHZ7nbUcP5mUZSG10jDA2vExdP98wv0FqpfkrfPh3M4XuQ++24Q
gnYSGTyCOaH5vwxcZDrcSnpD1+xOFJTVgeltDxHzjwADAP0xOtINCmVuZHN0cmVhbQ1lbmRvYmoN
MjEgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDM5IDAgUi9MYXN0Q2hh
ciAzMi9XaWR0aHNbMjUwXS9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZEl0YWxpY01UL0Zp
cnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTIy
IDAgb2JqPDwvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciA0MCAwIFIvTGFzdENoYXIg
MTIxL1dpZHRoc1syNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDUwMCAwIDAgNDQ0IDI3OCAwIDAg
Mjc4IDAgMCAwIDcyMiA1MDAgNTAwIDAgMCAzODkgMzg5IDI3OCAwIDQ0NCAwIDAgNDQ0XS9CYXNl
Rm9udC9UaW1lc05ld1JvbWFuUFMtSXRhbGljTVQvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFu
c2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjMgMCBvYmo8PC9MZW5ndGggMjEyMC9GaWx0
ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl8V02T2zYSvc+vwCkBt4aM+CnymHj3spVyucra5ODs
AaIgiTFFcgloZp1fn9fdICXZmVRSHhFs9Ofr183dv592/3jaJJvNplS79inmn1u1e336pD/aKE2T
re6PUdwklY7HKK6TRs8nM8ib7o+owkE3yIuTGqz88q9RmiepHufPSkX/3a1mmmI101TBTFRrWNok
uR5clJZJrUd5nElJodV7skZCG+0j8uQ1yjLoltef5Y6LyqTUqzEykTaNmNiRZLXoM0dWIv92uJbr
Vi7bIco2ODx1pLPSCIefbbi5HMORk7go9jYqTpO0SBHcP0MO8yXOdJMFJ2ZDedzq47Fr1SU8DIYU
IXfyaOXpEsX4W2o7eBXF7MN3UY1/VTsOIukjaE/1PMqNHjcKErhzqEy35BD7c8v7prr3R7yRYC4j
HRy47JXuexSXEhQj9kYPckp+avWdavGy1mczm9ZbOpsZDLVGPFDlO/bzsR4MMjL9nz1pLfT/SGep
r50fr069t55Cq1HeNINFgMc9gCet16RmuWj6lbPTIG8ZcrJHmbRCWFuuNsGiPdNZ523rr3MUF5RU
lnUIgrOc62m5kFZ69ITgXI/tSBeR1gxPbhF99Gd1Jy1v7qRSRji1pzgy1My05y7a4ufA5ycyUehn
PODtJE9wV9uYAJYBmnHa4EzU+BZ3C33uhnDx5jkiIviK3CTm+q41XsyNfD6EW38Vwq0f12b5lQue
Lz25lxZQk12aMsu5e3Bp+1WnXtBSpTahmVtpTPsXPfKQPVTzMXsAB5HHLMmwISzrHOchgLUPbkqM
kiLDv3vkZ7KzGwfTExjW7IqicKIGebTyKIyF+t/kP7NORwgAkN9orOwGyfIekhxFJlFUEkW+RMHm
L2Qo09eItPeenCl1d7GExUIfRLwzS9XcF74mlxmjqbZBR9D4QH3S8Pf8A79ySiu3HmzNtg+/qH/x
x/FjTn8LhmVKzQiIVdBOfZERJY0i3AbhkTqk4H4SB37Y7TKF2h6ftsm2ghsb/Bd+pjUoJFN5g9iY
Ii+BF9Lg7EpOH0KVJrvUA1lAs7gr5afW+wuKgxw7ee260LUD+/Cv3dNqCgSTqWqbIA2bpC7UbJ+O
Tz/tyM/iLT+zAlxbPPi5YQ/JOSR69/sTzFU5DAAOzaa58Wx949lAUbuzVebqzyN5jrQ7ZWb0RLxl
nqhpmvAE4rSOIKkGRTIne1BesDCyAEJH0BWBxKvjFexM9DqZicenqGbqdepgXVAnyjoS3UOOfwwn
Nd6dn9Zz0z+raSaXXuR2B1buvxASt1pdBzEyXfc9pZ0EziR8eFaL8+yoOEluEb4qitI/cEB5l67t
LV0BprN11szt+VkNo1ftlfEnsWU0Dylu+P5F2nV162DnkFPERqsCpF86kbXC7+jwhvmPxfZyuOgJ
QwM2z0F8pll7tKxuaC2SFm7+HlWhKtS+y+hgducHw2+QTHM4IBoH3lbOG2/j8Rh7cfcMqm+0udUt
0x7QdLJpcQKUGQ4Pacsoa58Q6YsNSRinC/uCvWVLg0KFgAf2QJkg1hPijFPjESHJjenee89BYnkL
zr2OS1QNSJAQrhfFJ/bqYLyBKpG6iMbr0LXivcTv2aVwbxxcon6MeKchVAh/0xtCsGXROQQfsvwq
+0bX92pvkZqXbi1jTlPlcMvPul6kAiHTyorU2slDboqIMQyNhEU3aTXThDyrblD+vHQjGwh156TW
ul0Wsw17O0e0347LqT1whFR7Ej6xlJOXz+HKlV/texHs3Bk+7cUio69cQv44zcCKZcRj3f7Fzr05
iYOhgX545yrVOuaqVLl2eCqypKrLBs/LWL3b9MJE//n9u4/KUZFlLBFjAmqBKUtMnrpWeQlvM1Wg
G2owZcXpXMjyW4osS3RliZ0hL8GwK0me7j4mhC0ToUswap4W5R2S36DLD4SHhSklL8IoV2YX5wkO
cn7HiFRn22PJm0chTWFVrEI9GKwiL/jKjqZxrs+Liov5f7eoZ6PyoALB0axEzf6w1DvEtSxjhT6D
jOJJtDDieO0P5CFSslnQNs6HqF7Fu6HtrwciBW/22Ace9rG7zAHHAPixO13BC4v/H3prZAI6TJXD
GTBVflSefTjLmyW248hIkvxh7/E+MNFwEEEzQz9ozag0i6dwdrJy+y3A5WjutAiA48qVTOKfNH3S
VEKD2O2v8uBkMLeyqfC+mlFaycQkIn5BYoHapCrPsTYBj3VCiEuAsab+GyAWZYG1ErcA3Iy2njsY
3taKQjJKZVy6LCYnUv1LxFsgt9rPsle9l++Edx9vqCGCWpowzsskTdElX2H521kWCFFGxYuw7IQM
3+G6YFxnhGs5BPl4g543+H/v/BwGUys87CkCsx+vXqXlPcDcs8rjUn0OvfMl0OfK5DxESWowYWaE
ywQyg4/AMCo6Q59ubIV2lvk3HWj5t0gZ98jNMmVBpW8M9+aWkJB/w8qwXfqIEo2MtnJAKSp4Xcl4
HBJBTeMQlmHCrbjzvVOYnHEV9gwZNgWmBE+DaQS6e5nluMbTN3n4/Cjy1btiBUe6Lmq8mOGro+Rl
Qdq/klFVyODCeEB3m693XbRZU91ImNZYUb4NC+1PFhX+QBOwYJ9TPdllX0npC1ZJ//1IS0oG83FW
Unjh7WE1GJbWOqnLrLrrwgVz1NDrDgNfYTbwZBF4Mnzu0kBU5puh2/CnXygsKm7UENYE0bHnd8uO
JJ+wQIvz1wO2M+XvVxqDTUWdZjPIMhBsJbKdfJVBSntV1FvZqG9d9U0P765eOnecOxR7WjzJ6HM0
PI1O+MbALq8alHbKwxIJFaBz8tkATewevh3UnwIMAN/Zh1ANCmVuZHN0cmVhbQ1lbmRvYmoNMjQg
MCBvYmo8PC9MZW5ndGggMTgwMC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImkV11v7LYR
fd9fwUcpsBRSor4uigJtnAAJkNsbdJP7cNEHrZZr63pX2kpaJ+mv75kZSqt1YqdFYMAmqRly5syZ
D2+/23y93ZjSxHmikkrHNlFGl3GldFxaNbjNYfP37aaIi1xbpfHjlySbkUoSa6tTtT1ttNo29Ovn
TaDC7efNl9utVUZtD5vI2FinSakiE1emsGp7v9Gx1roklYiXKSl+Ct67KYyK2AY/h8bERdAPT233
oBKt6TgLcvmj6E9BQhVk2xAXJ8ExjCr6RWtVH8detV3Dh5ewDPZOhaRTqxFHuOMUwqw0qEVNdRd5
+BTm+LhzQ1jFZn6ol2cPoYaG6jsX7Ws5+jXMcTCEUQ5d9VgfD5Gs93hzLTNdpn5o5bWRjCzpIvU9
P9fzxZ2Iv9C88zZ8X/M9Rr5krHEnNqsEKlrnsQr/tf0OQcD1xtqUgP4UfBi8+ed+BCzq0A9kjaj2
4mdLZtV8JySmx3pS58GNzps0KRFzLNG4blL1/rnuGoHSeUgBOHSdOrTuuFf9QTWwWHwTWM/y6GVy
g2q8VSf5dOnYhqae2r4bVd3t186AazNpKiLNp2BygBJMhU0lLGNL4A7fliPi4DIALcU3kltuHpwa
+2Pb+POJReWWPa9jXquvn+vjhZXIFW86RzoNemDJ5iU2NiWQ1oI14btwk2LcHo9q59SuHt2e4k3w
uF/Ozt82taNjX+lsaPkYRGgcPUmy/Eg0v8JQVIW85e3v2OZxoggl3nGPxtTL4XjHd3nbHYscHcVv
eWe87D7fIDl5PwTPepr442x3aPCbbpU9rtl9ZkHXTO2z3CDvjKq/TMe2g/v1rn8WbyfxE+8+uE6e
HeqjmoO4Ct7BR2f1rCOzf58bpXADxrAdbozVh34CXYXfRxAUQF0aACNEaLvndoJpU08InNrpjpYM
PHu/hRFg0zV11VePdTsA0HrJaC96HnpOMEK0XtDrx0mlYu32ixsCn+sHh3tuotgcL3uqd7Xatf3D
UJ8f2wY3jk9uah7v1E5gQx0gft67xl1rVh7sfCwGZe5QMRk+ncWio8QGFOVEijJjV+krdgnX71Ut
/ugTFKij2AdPYUSJPJK9JniEvclcF8+8GUOuRedZK7Lwa5EoAwbHqxPW40i+B33Hlq36kMljRNIk
CXoNNyKtzRu9KNWo4yXUsNd/3IuyuDSl9CItqXSNivQie9OL0jmVb3uRlV5kb3pRJr3IBL42HWV3
7UaXVRvymTWL+g6UztF0krvrDmR9Oqw6kPVsuJMPZzenSjRn+3PrVi21DNweHHfNY9f6dKulHtzW
LcnB4WkUmcf+zHzyW6pk3+Cg8CnZXo0xKbTvPOl+247WaSq9b251goupwF05kYbGRn3wZOJUro+3
7X+m6dMIK9GLH+qu/Y/zCS6SF2lfD5LpTd9NdTOnKCc7LT6GUTK7ns7XSbpL5mXiXnFNvWweF2Qz
Dw2cf0i9t3IuepF0hZDu29OZ/anQG+pOVpPaw8CckCqpMrvxRcaYAq/nKispD24mtyvxf2eGsxqa
4NjrA1zhkyaLkxxllqwvKo7jX2Bx+deb1AJhMhij3xjvADnKdQqMvrmgMX6oqS54JAd1f0ErCN7J
kCXBeY+O8QJiGXbmqSjxg6HOFrBno709NA+ipLBVi4f/i/mZsPRq8/t+ag/USWgGWgaDv1F5TKlt
JtI74dF5qplS3XzwjtMF2bjjtAQjyWya83TgT5hblskzu6bzt5wyabU49afD0XZIq5+QNdwp4Rnb
f3/xqIv9+Ww/RrjaL3goTcp11vqh5WrqPLO8ZBgYjCJvrCpSE2OGwr8fVOrxt6iqUki8FsgykDu/
/Z4VSZyvbiipfv+fEvKGgUBRLlZkVUX/4rCAKVBj85VEefPZv7D6TE+sJSQVk1dTEemtjCnjpPS5
uCLgP3xF20sVSgA5xebdTA0fbzSNksBbgF6y2D9rqQh7AaaBMXP1qTwh/nmmEsM9mSg5zvMYHw5u
z6dkBu2l8byjzVzql4CaPwqoCJjMxtntZ4L6iuWJsQWKfn9c71NsV+K0Pdx+f4sPf0ri3xubUZ01
mFVAhjSPq1xFGY8pH79QHQRSlG5TVZUEOkMWJJx5UExBDWREntFZiprdnDZffnuCtLrvNz9AGYU2
YT0MVlbl6UoF41BqF41CNH7wDKsk1KgkJsGQQzfM6zKJS9K35avlHoR4jaCoeZYajNVXgpqloKS5
8OfHDkM3asj0K1VGKWNf9e1pN9QzW9+wEPmS5jeP/LZeABrMJzlli0bO2IRYEYFGwP+KvcWNwKsU
DDNQBDuQ3JgkThPutlBBvixIpjZZsEfUU5IX43gWxYWajlAW0AspaMWiqG9D8Gq/JbJbSxdgy/6J
VxE4lFqbUaXMyyyj/Fz8Vf8VYAArqxXgDQplbmRzdHJlYW0NZW5kb2JqDTI1IDAgb2JqPDwvTGVu
Z3RoIDI1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRlcm5hdGUvRGV2aWNlUkdCPj5zdHJl
YW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZt
dEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TAL
AI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kN
AEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8Wmc
V9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4b
lA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0Wh
wcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4d
vvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbqsVqd
TK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhjrwGv2Aew
LvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKjvm5+z/RZAgKg
AibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5sAsNgOxgDu8F+cBCM
g4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt
0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNe
Bw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gL
lIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+Ihw
hnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0
mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCN
oOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9h
MBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXl
xpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcM
d5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6L
yxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL
23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaE
ncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY9
6/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFe
aq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0RR5Qs
6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hBiEtISch7
ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcIWcSOiMlILLIk
8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofEJcZ1x03Ec+Jz44fj
v05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8k+qZqk89lganJadt
TLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP
5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62X
Vi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj
6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1az
qWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59s
cWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal
77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdE
bdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kb
r5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfg
qFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1
E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48Jf
wtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQ
utE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p
36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7iju
tO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L
/tz/bf//AgwA94Tz+woNCmVuZHN0cmVhbQ1lbmRvYmoNMjYgMCBvYmo8PC9TdWJ0eXBlL0ltYWdl
L0xlbmd0aCAzOC9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3Bh
Y2UgMTIgMCBSL1dpZHRoIDIxL0hlaWdodCAyL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiVr6Zo7n
WWYI8r7MAiQDznMTTy4FaydJC5wEIoAAAwCJ/DFtCg0KZW5kc3RyZWFtDWVuZG9iag0yNyAwIG9i
ajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDIzMy9GaWx0ZXIvQ0NJVFRGYXhEZWNvZGUvSW1hZ2VN
YXNrIHRydWUvQml0c1BlckNvbXBvbmVudCAxL1dpZHRoIDgxL0RlY29kZVBhcm1zPDwvSyAtMS9D
b2x1bW5zIDgxPj4vSGVpZ2h0IDEwNi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KytA38jV4fDf+2eu3
f35SHd8gwIb4W+E34TvptyIPhP+n/TbhHxafDI4ff9EPG/wZHBo+v//of//8uBv/sjhbXweyOE8e
u//Xr/+1/gl679rtSIPh44NcNyQ+3S3+G/khg/4M+RcP9kJ4r4MQrI4YhhfDCsjg8qAsiD4x/+S5
c/BEOT4afVP/+Sv9KuGtrjjz5giCDk3JuRZkOP/6cf+Icij//S/7j4MlmRcyQ//Tcf+uQ7//wyOP
/vJuyOX/9Mjn////r///////+0o//DCyQ4/8VH/qRR/+o/XXERkq//////7QxwAQAQoNCmVuZHN0
cmVhbQ1lbmRvYmoNMjggMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCA0NTIzL0ZpbHRlci9G
bGF0ZURlY29kZS9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAxMiAwIFIvTWFzayAyNyAw
IFIvV2lkdGggODEvSGVpZ2h0IDEwNi9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSInslwtwVdUVhi+0
09apdIqAiY9arU3UII7pqFHRTmunGhSnUiQKJdOKiiiltQyK+GiqgICIoiBPSx8JSEgjUvKCQUaj
lCBQgaCBiBasWHSUFrFIipV+9/43i53zuicBaTvtmX/OnHvuyc3+zr/W2muVlPz/+M89Fu0uHbjx
JDS4MacDF+jfTdC+A97DRz4K1Ks+Wigd/k/9VyAbr/Ti/ucP59fmv/ck6rP+M9I1L3+xXWfTkaIL
PAy29uOb4ZU6/GuGbAgxea9q/OxRQy5JUa/ZV4NmtXz7MKk9LiNYxGUXcYw+soCBh5BrWyZO+0eu
FIiz4u8voIjfcZFjOnv0A9sOeNFvWr6F15KfRcgR1H6X4yeywkD69HHTh6gn7D9WF8jDcs/rRdHU
GV32O3vUXK58dTuqaGxe2pSUbr72yWI0/Z8nBIb30l1z0JDNeVJGZBkXncX+r46gywCOLnul7/0v
nX3ji+J1kVHRLbWvHVyF5h7IDzRayA+9URxB7anYgQ5GxPyRcnli9RYBGnJWv5Vf+O6yThdVJ/KW
SOcVVIH84IJmJORftfST3J9SSNMqjNpaKIUhB6IdhVwGVoL0/FtXI3hRTnH9yUXPHXf1s2nw0ys7
ZZUnPlfaqfMT5X9YAfLk/SdxlvzI03bezQpn7ZoghSGHWRyxZR+Oy3gq2AFj1xeOWTto/AZJHy/9
2Rrhu3ZD/fkeS+t31CiLoX56+7OS+8vazojqwOVFuDysqYD3M+/dqf6v3IzumMsK49se2wwj59Fz
miSu0ZDJmwwcauwWNcgX91m14eM5RLWQTz5/5NB7l0keZDL60oYEBVzyIwd6BzJBEhgDHXaZTJy9
fBMyWKWnK7EDftXoRlHLa8J7yuyttJ0gP7zvNJTV845EYswlfWdJ9l9Ux7S26r11UoTLrngyuoi1
y2WDgjcN+9s351bt8IibAofavCavuxc+j/AXWPYpzj1OnJhITIL66+c8ILlGE9t+o/3I1DpC2oTL
/KGu3ezogMuCJWJRkjcFW1a3s7K+jbjD/Znlb/GwvBY1LvMnLx28W1EN8ujGc1O80rBT80ZJhky5
9i/Sj1yyvRjFRI7vsioVgaqcBQco8dY17EJrXt2DdM1Nl5qQAJm/RbJYLg+c14cC3oo8JtGp6NxL
75D4j1P/dBPSaingUiCybWfYzQMKbKCe2fM06pjLKlYsm/XL62mLtol39eb3UWPzB5KBi5rHLLx5
bMkn/WWxkHtd+9M2yIlhicTlP7j9EempXeORlmcOBiJbeEuGbNt0B1xmz0XpeFYvUbVD/orRRdaZ
rxThSvzlq/auO/iwyzvunTO7dJ3uRe5UlEgUzHuuTrIKZjglQftydPnydN1xXKahQliMWUphZBY3
New3tRw4YOB8JaNBrqjeS1/NlqSQFvJVkwclEksCkc/IHyAZMlKUojCXzb7Dr9jqqYhMIVtZVtq+
veXAC5X71tZ8BK9JyHxLYOPvnz+p1y4MrF18KWemmjG3gqWQL08kcicsLEMuskhNdl8OBiIH9mAZ
XZbF9BIgp3fhlMvixVl4Jbksbdj2V7lc37APGaY2Js6Fjw2RxVJbl0HOPuuCQmS53MdpPtvlsmfO
itNjq2FGIJPLRKnqFcJZ4zVqidjmhXA2f5XC2pvufPN8tdwOrwc5F+ra9etAZl9mqZytaId1X4HI
7e2xy1ZvRuynuEwuK56JZAVzoKxoI/LX/OVsRp9x2yQ6bUV1kMsFKXX++QMPzX7vRmBZaiByRpfD
5qkIZHUd9EuYCwukrrMel/nIMwppRH0Wpttrcb7mqSHJWfL0Sgtsf/lKudz5iV/OJB4iAvtIuexW
YEtYD6xHfEXCWsBzXfN6jcZDg9XFT7Zepk7bBkn/vizkY7uetmzr72x/QYt2l0rtyuWICubnNQG1
8qkPA0l1UbPyHb0ca73YwhZsmwG1QtpS+Piixckp0kFuU64PIWf36//jij3jlMgSbaTkQfZvze2q
2GKUU8aFNtS1eC74qnLh+7SUSnBt05zVfrA3UdXJu18fPAdkGZ03orRT7xc0QkaW64JjunaveKbO
jerBjTkoENltM2zvHrdjaPx92YIzaV/VnrEPbpw8bTeaO3+vLkaPfwWxR7uTI4wilTRGDZ/+R+qP
cvnC++aINyqq04mcfeE3ilZ9tNC12LroEl/D6XoHqQmveT+89jgVW8gVjc0ouTBWyDovqqaOUbrd
PcvAPdIowRBx3ZTayW9fDO8x33kxmcV5S1xex+IxZjHIsljIWue8d6dKfmSPrFcRsjtWeFLeX65r
N+1EyeWlkBP5i1lzVr+VOcX1iH5MwxHg0IldoyIfuamBUe/H5Y20OLkjk8UrPnzStVjddSCyW99M
FMkpb43CX7x2h0ePIpBFnRRpeFE1i0dQwyJw6GC3s2D5igeICj3PGwvnTVmciurju/Ve/8YaAN1Q
LNlenFbq8LscOFz0STUw7kfrwcKQOXpkz0fJ5bV6LWqBH3f1sxbnwhcm4oXwFQ/wmPL3lN61ybfn
rVpeiwnp8W8NUvvhr9V+5MAkDfsqTveV33sBal1ha1jSSBCijuNEuwQmZ91Mw6aCmWpGJcz+alUo
bxI5d+x9pbUtE8Vry5O/Ych+On+cuyU9o8uDR9Yi1pZep0W4srut6fYG7CaP5V68lF2bYnjXuHcR
MeNsxG3aj9tuelxV2m+ZG9VhLrtcnrfhjloZXZ5etR4ZsqjTSpku8KRS1qelkSGrfPjI9bSgpeUf
3H7PX4TMRZeu0w+lcOvGBC8Nud8y66vdVUW77HptyRt/rPifRe7SY4JL7cG3UFc1RkxJQ4evWL5q
r+LZeKXiWxr9vGv21fhjj/0FRSB7cPw5G/hANDLHgGGViBWq5niQPR/PK6iiW6NSwUuf5oEVPve/
d32D8Y5/dD4pHJhrnkLdLpejz2HIDLzYtLSpGbX6MsYtPmBSjnLzFoAAKS03pBXVe/3OmuDF5ZNP
fQDerBOuZUtidgjk1ZyYETkQJ/BjxsCGV8hquX/x4DpildzkQpoyeyszBZh4CiYduPnoJ7WbV/Rf
bLtwj+zLx9RfH7in9J3XC4na70XEWOEZHMJeSGDDKWQD4cKk4QIZjhRoq9/c1kYa5TIx/Whlvvvy
v7/lmF6PJmZWL5ICcy1srAjrwfxPhgW2ALHSoDyKYHS/JTZ65s9ohT3Ey/iQSHTuntNtyNqeWox4
+w35IYqP7GGhwaa1puLRZrObW4+d0WUd8CI6bdWi+JiKAZxNwqabDQ9skldKUm/OG7AjyXt2wXlI
1IFLKvFVbBOMyI8c+HBExdZwAUJl/U4LZoPyn2UrOXviKaNUk9vCenmlUy/7Mrxf+drpNVvWSWHr
CXSZMYRREYmailf5t3Kk6ge+JyQiXDZqeA156L3L0IWXTB18cwPCSs4UbTB7nju22/E3OIx+Ui+s
yeVtL7J4pWFNBe5XfOSFBKZ2xL/QIWTxIqbaVoRcnwrafswAixTPcXj9yOpVxBtdvjLuy2GHeNGE
hWXHdj3NAc9uC5iZVBo4YihqOXDg1nH1k+Y3SDGR+718HBJ1mJsGG7P7CjvgRThy5cDrHK5s55xZ
37yycN7K3yOQpy3aRvuNVD1QHGSKlbRodylT2Kfksh0KQpArXnqeAssmG5NUsNqGhEyfY40r7ZwU
B5nibLLB09Nvh82VMTEJudnLN0mihteQJ5bN5YKs9ONzhwLF+7n78Yf0roRMFwed2713O2FGRWOz
FI0M46FRa3ux301D9lzER1aWGTJKry2FDK+LXLmxXg4ivRYPcml1c0FhuTCJZ11wB8VEtr0Y4XKf
oJa7vcNjIPL9c5Pqe0MV1cbWNrVyrRJQyPD6kVFdwy7EnzNzaTQzWMzVLxt12DJcl+95vUjijpvL
ZmjgOeO+7B5alSGfdUFZfu8F19212pARGzQ7ddEttYhr3cRThhE+Mnx5hlCotfHZj0evQcgCHNyY
I3FHFTtsgPLPLzGRjRpeIcuXpFlZ5WQl1x5k3smJZy6QmwarC+6PGL8C2XafkbfEty+r0UIRjbeH
XYqPbAfIFopLm5rvfOQ5LohPEQlKF/ZRnvKiBo+sVTUQsqhj/l8PMl20xE3AcdzF5H6Hu6+wA2R4
XWTCePq/2C97VrmqMAr7B2yE26iVdqaysrfygig2gmChVlYWYpNYpIxlQJSAcButLKwCNhaihZUE
JSApLIWQws7ehyyyWLz7Y/bMnDtoyGYxnDlzzpnz7Pf79q98ZU9Aw9Z8an+Emcii3usf24aTdC0J
mTZM16glyx77yLqcy8iK3DkyMvIB/9Uinz/spbPTTuRb928cU5dX1k7kI5/fRTY4BQvGiwc3+aRy
lSnjgIz9X1hPkItUvPIzi/W2jo3H4sxKv5s48GgV5AzSUWHaK30pG6PJOzgpFWS0cvuRyKXmlsmi
++sE2S8sdQ0ntBeufJUlGKk7zds3R27pisXLDLXSY9M4Id6fapsDlJe4CqykxpsbOaYHk7ZFLkZs
Dd3y6tdR+pKLuomif5B8gWxHNyVGtcqUJzZB3ePzL97yDiz2z/siL45Oi5MUxRSJhU9cV/IF6qLN
+80vd1Ei60Z9XvviJ2lb5J1m7e7MyMoy4tmzn43MhBFtR+GLWsh2Em/XZSBPrGm09Vg2MoYjMFEi
64wHB66RfLuQZXdUPGQr5MLSdeC9ihTIemEBIv+kVJbJqlzAsquX3dgQeZSuGS6YMmjAvv37a/qx
7j6Mnq/YdLm5/ihLJ7KmQnuCEzvX62JSN/I26qQ2xJtDLJDSGUwQx/nrBLk136d/vq1pwsgcr1tZ
1ikVVl+RkpuED3NGnp99SCKjfIKgrC5yl7qNZemd357LYQoxS3Il7OtWjjp7VbGJyMAuTC5hKb02
ohkrPymDZU5DkHYru6t5aWO6Vv7g7kvIsJ/ce40dOG/abGV4qYtMI6FeIqtMnuzKyKbTLiG5jU6q
z8naXTYT8WvbvLXI0CFRMz11SVcyNivfwcj2W9zPVtb5kuuMrF1CiQwOjQ3+w1/gPLpFbq/2VU9u
+4EWmYCV8OGELaPTSiwnMl4qGVnpy449QbaVS55POxZknMRtjGOqi/zhH68geElWk8K0GMsTK6e9
kN3PyBm2tnLJ8+7ZTC1kxYXDx7d3kW3it+48g4nx8I/uvUos88mxjF6a8Eksd62sn4wsK7cRl8i2
sgC9UW+89x3qZubS4edQI0CxKIpl4jfvnOmnROb8qDM5GFlvNUe2mS5+/B0ZxPWu/Ws9LYugfTut
DBeCS4L3h39+tnSSAxzgmFhukQ+28qT46mnO56+/f1sysqxMZ4WMTB9iOu0GApmtOMDKZRQ6zLFX
2lQvJepSo9PKUBuWDhNluuZYJxHIpLitHHsnstLUvlZeQUY6RpRjGMvAyJnP/7pmbRjLO608iuU5
cvY8Gk5RQb54cFOiCenmKJUwVbEV5PzTy8jYmYfLKukr/z1j2Y5tv83Zyo0oot8+ZSyPrFx6jFwZ
F8Uf0sq0W1a3AzHyopU3r8tG1mNJyFL71xnIOi7IsrKJdKYtwcS4RGI/ZSy3yKUbUUOiGznQGe+n
ZlKkC0r3pdGJMw5nwM3u2aoN9suz8iRjP/Vo8rLfStlga+CaIGf9pR6dxxilMIeX/LZYl7vDY0HW
i82RRz02GdjgGqzce2gnr7z8JRK1n9xOUqpBQoaRuMaTZdzSfe1EDltcLalGjeKkqZBLcGMatFhZ
Q8TTZzeK3dPnRZ1v1SJnzBZkEjWddrd+dZGN6XnWULJpe4Hv1de8ABk587CegzMrTWHQdz/+XreL
urxVFxlhYnIUP4kUdry9m8a3Qi61potc0peumSB3e9ERckZxOT5/ODOuWDmp2xcoyO29BZkzo+5r
hNx9pQnyaE4s7NIIedu1V8M5Wv8v5L3GitEysgBHmGXEaK+8JMayipXnw+NotVbGZAlVPh3FvuyU
yNtaubWgAUuyevys3Bq3fC1ucErk7L42sfLIh33c3Y3TI6cee+TrPeoDHnI88uZc83Uk75N1zPpX
gAEApmqnhAoNCmVuZHN0cmVhbQ1lbmRvYmoNMjkgMCBvYmo8PC9TdWJ0eXBlL0ltYWdlL0xlbmd0
aCAxMy9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAxMiAwIFIvV2lkdGggNC9IZWlnaHQg
MS9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KSPGmLKJZCWQUOblvCg0KZW5kc3RyZWFtDWVuZG9iag0z
MCAwIG9iajw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDg0L0ZpbHRlci9DQ0lUVEZheERlY29kZS9J
bWFnZU1hc2sgdHJ1ZS9CaXRzUGVyQ29tcG9uZW50IDEvV2lkdGggODAvRGVjb2RlUGFybXM8PC9L
IC0xL0NvbHVtbnMgODA+Pi9IZWlnaHQgMTA4L1R5cGUvWE9iamVjdD4+c3RyZWFtDQrIu4IHCDhB
wg6DhB04Tp06DhadB7p13TrT3Truu67r9136/fr/v/1////9//r/3+vfXvr31fVq9rV9Wr2tWrCt
Xhq1asKGrChhQwrwwUGCjgAgAgoNCmVuZHN0cmVhbQ1lbmRvYmoNMzEgMCBvYmo8PC9TdWJ0eXBl
L0ltYWdlL0xlbmd0aCAxNjkwOS9GaWx0ZXIvRmxhdGVEZWNvZGUvQml0c1BlckNvbXBvbmVudCA4
L0NvbG9yU3BhY2UgMTIgMCBSL01hc2sgMzAgMCBSL1dpZHRoIDgwL0hlaWdodCAxMDgvVHlwZS9Y
T2JqZWN0Pj5zdHJlYW0NCkiJ7Jd5UJPpGcA/AVkwHlzKLWcgCQFCSEgIVyDhSEIgdwg5uBKugAEi
NyFCwn1EwRAEOSKRM6CgqKy663aVrrpd3XFaZ6e7O71sO+2423bUP3a6Td+ddDrTmc502lXZP/rM
7598k/ny/PK+7/M8r1b7/3izQf58DACrCSE/0O91Lm8w6F+OA+yy//QFBOjwaY979zq71xnBczy7
LCDUyCCY8vp+PorqxIY3orhrBXZfQMSCaK8z/b6BWJICWTupJmbdnWbiKDmkEan8QOVV7h/ViSMM
pMKbIxTv1SGNdOALgC8W7XXW/0vg77YBWTvCy4r8+bxUA1VypQRi7cONJJddU/opgxL6SEVbFSkG
cvEVua8yhD0vkLxfD3wB8T/W7LXBfxFA1k6GKVd2tTSoMYIxw0NpcaJLUs6ywF3hi9BhDhR7MGZ5
rEV+Qn8id1XsVuXLtoioE7mUSTpnrRj4AkJX5Hut8h8ifEkCH6HYkV5VkoZTRWvFgeoI3rIIo0+I
7SMeUwV0Pe3ftt3kWLiHFEeVd9TItjj1vWbSeEaiIUWyJUdr8fiBFNmWPHOlCPh+x8YP1BrIAuo/
M3Q+1nlVBpTv1OH6Eplz3GA1EmxXt1If84sF8brUXxW2ZrNa/7ah2m2x2jbKtiudhK6Hio+SRjMQ
Gkz5zolAFRyIJ59Or3ikB7J29lruXyJkOBU/lA4QrMiqbjbkzQuCmxAUUy5Sg43VY6efT43+wsCc
5V14uepR5a+6q37XtjP+bMJT4d32cSd/Way4XtXxqMNPFRqoDqfPMDKM9JTxLEJ/UrQmruSTLp/e
ZDt7bfmPALJ2cIPJAJQmpmKnljpBE65I6HOs2VcLrZ92C1eLwaZVvFcrvlJ2rOK45dXiDdt19W7r
waKjM1+bx5+ZHPn75beqjH+YDTgBj9MTss/l5lv4pNPknCkm4xyj8qd9yIsSwF67avF3muwU3u+k
TmTj+0nkczSwsl5VAaEnUQ68A9nT+f71Yc4Fh0VrpRnGTGfRAYgGVb6rHHt2FmI7+58I466LXcXu
EMt5H8fVs9rfWXoYPHeWHHbgwwgjqSmG1OAGBLoTK/mwEXuvA7CHsslbCjvF24q0MXKkJiZ+kIjW
4Va/Xb1ku7RuW/+3bNg2zn9tmfzjnPnFkvmblRWbdekbq/F3M7N/WZr608LYb4xTz2env7o4++eL
DXebsP2kstvKkJMowkAac4aDt5YA4lZkb9mU+MU4ekcFKLjTULKpyJlhRndhfZRBoOCgO3HB9YiQ
JmRICzKoITKoAeFW4eNdHeyjCg5vjo45hSOMpsbpCF5Kv+ONiCB1JFqHD6gPo05QQpsRYS3ogBPh
Ea0xASp4WFNERCsysC4U4rhyFwvAy5lmXumNaiBr523K2olZlAg2ynLNrOP1EdFafM40K0qDTRoh
+1QHK67XcCzC+g+bEG2x2k918OZoUJp4a8K63ZbIltjBzw0nd9vU91uSRskci6hwvRQ/miK/USXd
KkN1YMuu1YjWZGAzM+f5oAB6Kvzx/ang5eAnwhpRuRd4xBUZ8W35wtfL7FAfdtHmhaKNEpQmljCY
BIoqxHIkDpMzztIjW2PDNWiMnpgwTHIr94a3RCPbkeQJasIYGamLYy8ViKwlUZr4rie9FCM9fTJL
YBUxZnMzxrPi9ETSWUrjR63qB03ND1sUNysL1mUeNf4Q5508C5dqooF/L7QZlTPPJ1pLAWk/6X6z
spsVdmg3a5GtaPF6sU91YGxXQvpZ+j6uq0vhofheEn44ybs+KKAOjtLG+NSGwKRH3Mt9wWjhWuoO
vgMxHVsfdqWNZSLaY8CRNPxyHJR0UMEg/v4jcu8UA8WR73So7CimjwhxXfxqwyQbcnAoII7LfuFh
mNQjcSiZPsMCrTx5KJ15rQr4vlHlzN0WgGBDUbmjBIcL0YnJnWUdKD7iLINBfMfMc1kMCzflbKZ7
jW9sNwHeGeNd7Z9rzi+/XeNbE3z610a0Fpc3zwlvixaty4TrYuYcT7hSUHqtevKr85SJ7Ib77f61
Ycj2uGOVx9NNNHQXPnsmL9NEcxTBwPryl6Via1FMD4FuZoY1wjOn6RUf1BKuVdp5E7L0e20A8WYR
yDNOn4jrTSYMp1Xfro3WYhz4ByC+U56Zk3omK3EoI34gKaItljiY4iSGUUwM+XalI/9gbC8xqjOe
MECGGBAYqnmLBS6F7qofNWN0RM2jHuFqUVBjJJTv7KHwG/pymHWhwKc6KG2MQjHSXMRuDvx3sD0E
gVXqKICRJ3JyZlk+6pBkA1W2VoK5UmXn9combZbZSR9PZ85zqt6vAyU0Z4aVMUEHRWl/Acyl8AhM
6im9JEdqo8F1IEobv/pX6+wLM7wZEdtNxPUk654OpU5k08zsOF1izjQbHEbqRE6snihYk7AXBIJl
2bptM8PEKL+lWrVtrn57WfO4L6INlWbMThqhOgkOQhwn7ACJamJAeRDOkEyZzCWOpp351VjamSzK
DBfwen2jliQAkpHW/FE7vi9FslFMP8+F8pxOPemBt0ft4zpD+Q60OVb2DON4Y0S0Dg8WqPyGKkqL
YS8Jwa0hWosFFwEPuV/vZ6OuRd9NFw48Z5jUTf+zIR9loOZJ1/AXBpjUK74n+aDMM9OUlT8vyDjH
II1SEG0YtqVQvFHsqwqqunUCErgeLPLq+ERPHsvxqw1V3lWDtSZYRHZelyzlgR7AviBQ3VOjOuJA
x8mczMEOJEBsR9BWMN0EkiFDuCbG6pPyLwpBlQbJgPWCyTzje5JAKzH+3iS7LJ96fp5tKRCvl1y1
XVn8ZvnMb01btm3VbhN/SbLw0oLpJrZ/rJl7dUFyqZQ0QiUNk0u3K0PUKHCQQ5tQFbeVHmW+oJel
gy7AgOjn2aB0oE/hozQ44UoRuGIkTWXb+f6ySWey7bAXeXlmLhh10D34VGOW+eWKa7E7bZbV83QQ
jHyl28oAVTD4mDL+d9KrNKit84oKECAkFrHvNhgoYFaxCAFiC6uEJARCaAdJLFpYhBCL2ZENAkQA
gylmX81iTM2OjTEeO7Sx03ps13Fm0sZxUs+k8UwnS9M/bqaT10vUafPL4zQz58fTmzd673z33nPO
Td9H9vs/H4rUkZIuZ5EGky1EJ4/tIDe2kW3umlB1XEtbYEFOzlvi6Z8P8Nelm8jOdWSz5VFH+9Pu
gb8Mk4dTz7ZEyg5U9fcborrJ7rU+pYeVBF1cyihFsCnFF7v4NYRiRTZRuvicKxyCjpg5SW98eCHj
QRvgF5Il7pUZkDaSxbkqgBZ6Z5KKk9iDtrQ+6XKWnxJvSWIHkvNXhKBdnmovc54lBGPqNJU8mJQx
xhh9BUXcWn599d0XwxvIdQiTUNzYviQIWnvIDdYSz1nhBRXfQ3Y3kb20cZpoo3gb2d1CdvQvByN7
yawr7PKj6jN1QY1/aKfP5mXN5NqWuCpuV/vUBeSu8EwKzCGfw9pIX8w/pfIWbBWSL1EAv4RvwiMt
oPimnDbLDOuISRulmXGtzLm48x/3Ke+pEobT7MrcTDlWAU0h537fgC7ANTxoyZ7Jq3vQFtIeGTuQ
FNhBwIntoTrUWUZkT7QZxxKVa9r5p17dxz05ywUQpL01/rAs2Mvdc5f5az+sMxfYGeM5Z1tCPTS+
hVtlVfcaMieYwo3i7k968q7xxbulbc90BatFbU/O0+aYME3GLGyYNoa1JIjuSYCGp60LDfj/yEav
CAGld6pTJ6gBjcGRAwn4Mkc0F4spsp38evbXX44VbstyV/jB2qi8Zf4GsknsiR3562jhZmHqWIZk
T1G8K6t8r071vgYcFiYaJ3Xo+UQPVV7551r8SKpfU2D+Gu8AOZTuKjCFuMDmILDaoq1i/rpYtCGl
zbOTRynQ4fH9Kf2fDfCuSUK0xNaPdJdeXU4doYIs+NQGmQqtMIV4NMcSdgroJVJ/UuzQO9THnQb8
XLLMZaEBle/VWkudo7sTUy5TIfmb8a3BN035lhiBhZXU4aw2gj7PZswVuFWcsS918ar351wTluyX
gjFBsdhrgsKDMuYq10nuMfbVJDTq9OulmL6kgFaCiQCD4Vs7Kk6lT9E3kJ3S/cqgVsLwF2OjX85M
/GOx9+Xg6Kupme+Wzz3scK32dtf4OJR7qu/XQd2TRjLxZS4QAKCvYM3ES53zl3kRncTkqazyu6qs
eRZhSwr4uXzBDgD+2pDkS+nANKI3xr8x1LLQAV4BL2p+2lFyu9Kt/IxXjZ+dwtW/Laz7eV+gNhSU
0zjfxIyLQbExEAJPQDUCe91B9hInMt2qfJxUp00EYNZ4DN8Sjs6IZ2Evc5bsy+4gRzG9sagsFLbI
zoSLQ+ViIHnC8+Th9MxxesMHrcU35GFdMaDVBF1s3f0mmH0wAhTTnDGfmzmeDfsIaCNjqaDybl3C
FMOAtydLO240IGcqL1JHjutPBVuRHVTJbpWfvIVhSp9l30AOMqboIe0E2HFclN5ND1slu6UZ4wxn
hQeaDXNqBsNbdqhKHc3OmGIsvF4+pfYB/4X7GBGQtQW+EFHMeDbmQpyryqP+SavyqAr2vi1kb/2H
zaJtOWiRo8wze4YVqg1re9YFakboJICVg02r7mn418QolhGqAJM5QctfE2KFtpQphvB6MbkvgbJR
lvS3ecDb8yUf1QCih1LhAMO7YghdRLsSd+WRyloM82uFkzhMfzPX/9mQm9qHuy7OHM9xV/sOfXEZ
CnQiI5koYnfCLrLX8+IioStOeVs9+fc5L42fucgakiEIuFEexlPj56HyhXMzF9ngiuxBr7LnWeBW
Qa1hloV4+hwT7CmwhRDYEhHYFqy8W5W/KgzpiOj5tN+/KdRV5T351ZRdiauFAGsjcf7VubAwbZQ5
zzpKH09bZHJX+XFTLNK+zIC3Ict90mlAbDcpfZLBulJAmaKjC6xATOof1KPYZiimacYY/QC5CYHQ
ReHZ/uEFO7mT/KBKeVSePJoJQtT95279i4FIPdmnJchO4eSp9nGQuZqwsTDjLkov9XEdSZ9Y+34j
dYaVMkYBAYe46FXjHdNH8moIQPMs4ONtZW4XPuqB6QD/JehJ55/pIFpI95TaZzpc4Ul9y+9Voaio
M5qzqeO0jMkcyb7CodQDeom2kC+8LirbryDfbwW8Dd+oNQGAMpMn3ipJuUSBcGgmsrYscuSuCUh6
sgkbA5bU9+ngwOdD0Ja0BTYcPlZiP/b1dPoolTSYUHJL3v7swukaX9MC0DQ8SOiP04qH/oRyyG5V
T3+7PP3N0tS3V64iW/yNYlQu+uQx/v9gzrPBCu2aH3dE6YneGj/IkwW/KQpsIkj3ZH7ngjyrvSFe
OsrdLr4cg6WpaK8sd5Gtez7gey44oi8OFhbWsjB7jEo8qDLgzWQT7msNOBHYlfwgbWjKcLpTxanm
x+3pY1T4eO2HOtoMC1/s2vt8CKYJLpR3VdH6GGM+1r7UPUxLuo7sQDwI7oyCUzIX2MDOCxL348Ba
YUTWaJElsLaR2AdfiIK/da48Der3U7L/oSzAGXOwHX/sXv1+1UbmID+qlt+qDugIF26JA1rDXcu9
IKNmTTDhDD2qfdF8K7tiB9goTTnW3poAxizLTX0mpj+RssgHvJlv7GC6AQ5Kj1Maf8j/MT3xruWe
mt/VR+qiITyT+lIsBHjhtvgmcos8kHpa7YXm41BMdNVva8qPakAx1v51LfFihkUR3kyAA9uquFNp
kCnYDsw4WLsSx4pjteyOahc5bH7UJt2V46WO0DD/VTADX+hw+1Knue8Wlbc1qGyjmg8aKo9rHZWe
KDq6+rguZYQi2pB4VLlDiksbpZxW+3c87WHMFxhxMMEd4SDXhM5Ijyqf8G4y4M180xbyAUR9IiT/
6L4433rYfSyIPfGRXURTriX8DGoLie0jr36/Un6koi+yIe4qD2tyFjgJl9NzV/nGbCzkJSuxHYYP
BQKvcbGTuSYMpIGDgDcZ5+NgAP1bQ1lXOPJD+dnmcMWhEu7/pLInlC34tmBJ5gJLGGRribOV2AlF
QSkOqyvuqCvu1UoPlL7twcTexH/TXaVBTZhpOAsCAgEVuYUgcoUrnHKFmwQMBCQQAoQjEI4EEkJC
wBAg3CFgOAwJQUBuuYQICgitynitq1Kt9thttbVOx6pr23VHa4+xNvu6aV23tjPPj0xmkvne73uf
C9dPtOe7+kiC0bU+4YrY9GM0JN3UucYroD2cPJ1NWykirBZr8KfDLuRrUHqOyz7Hg4IZ2h1lU+Hk
JvKJH0rsvicXXG1ouNVqx3XBNPla8e0t2Ta1t5pda31gr/zasJ4Ne+EYy+rlE+qTwdJIMFAIfqfU
q5AbQ2UxyROZNhw7K7YtMs+Evylou9Mp+7IPfC1xlIxI1vpt2F/5q00xrLlZf1Z9puISH1Xh0nGv
N3OeDjpsUWKrnbHVtQ4jfzxoU+mE4jlH9OIoc1nEEaJDlbtHvTemaa9jDTphKoUyRytZZUSdrwL8
qVItMwHs07zs4/noWgy6xoM0ScU0+oH9+bZhgYbwcFF9+/YI3WUPlb33ZfrZ270lQUEHI8Fhmz+U
+LUH69G2t3wkHft+NmWGCj0XxXNBkPR289DKx4PmpSijYnPulWrgb/FZTtWmCEIv1Nu3+IvcQjGw
ZNuGy+O4FyotS+3Ce2N77ivCD0XFKHEWJbsIw8mY1oC+ByMorj1Ys+hmG5CFfCzLtz0w8CA2a4Fm
yrBJnE6DgmnBtIsYSNDgD+fFjicDImUx9BWGvyTYju9UdaMOXeddeq7CkmUfoojJWSzybgsCM5V+
3iXcFEENjJDhgHqJ4yn1HzdZltnRV0p5Fw/4irGwVJjWvY0fiSHvAXObP5Y4VLn5tgazznNhgSPk
OKws2r7SiX+1Zjvd8pWSvzHyFirSqNB04JuR0WdTlpzdxeuc4nVWwSlG6RmO5HZnaG907jqDtyk0
yDFJHKOAxccMxO0WONgdQHfelUXKYt2avCL6YumrxZJ78uBVtgZvD/tamcs2uGmLWX4dWCu2PWWB
Nvl8HnYV108oPMVCELVhHFAtX3EgFD2QxKJ1xrL61NzL+aK1osq/VW6jm8PFLoLRLOVBFdIib224
JclbLoofToWdN2eiSJOZ4DWcS5Wr6lUAugYDHHQUeLzF4u3wDfi7jzhIOxNZ814L/d1S/BABDNGz
0S9Gsa/s4oGiM2XwlM4ir7SZrImfZkxKdtkLXI/+MEOaIZsxUXBgF6Gne50PfpYKeHvepEW6Bnhl
HDwEGBkQATqvSr0GoR2O5N7kJ//qsHu9t2uDR6QCf0J9ImE4STfTMP1knkmpdcJYSvU1UXgPvuUT
iRbFANxEH5w3G4lI00Pmm+adZEIiAncO7I2Mn051EXkHdoSCLCj/2Q8E73s0YFpmo51puDULdtv4
lXPBvMm6hWslQT0R1nyH3q/6SZMZ4bK4SAVh/9FUqELyx0N+EiwoP/9KDf0dBmujHGRZdFN85Ml4
0VqZEc0U24XFDe0L6QgjXZcA3p438norANPsb5xv5tkYQJpN418Rtt7tPPpioea9Zogu7IuVyq9H
S85ynKo9IClZsextuc5wM+mqLLd6XzAF47xtzrUeEcoYBFlH/5W//Fd8srch83bgBuPFd6Si91vI
09R9g4m9D/urrh5YUB+feqma+lG1pD6p/PrwtkKLX7mcvR0yth51GyJFx4aD8m4GjhvzL1ejuA56
VCQ0CAjzhvk7a2+09nypdBS4qdQnys+XQ2Do+uJQ6QaXe01IVeWbMawThlPgHjDtWA1+N2/UkWSA
h8gbK8O5N/ozzrKrrtQRp8nSuz2ST6VYWcz0T8eAQSCSDgIPlNAZ4ChwdWvy8ZIEWZejdvH2oOs8
QR4RZN3XwwLgM7z1lgxkwwftBavs5Ely/HjKoftyOOScWjX947HBbyagIEw+n0VxHcGw4Cc66fpG
+SbaOUgIdVpk3bihBNoqE+oA1Aqbcgf8EJE4QmJvVNlXoDGtvmYltloZBkj6TmPazvILfKiW5Pkc
jDgQHMqxzhOvJCRdEGjw5rBBq8UaVFziCTeF2K6Y2MP78f1J7bc719VrrbfbgzrDfMUhjgL0HoEr
7GdAx6tGQDhCMmOaR/TF2ZY7pU5Raq83WpTa6ecaQet5g4w7tDL0LVm2EOyjFPGwJ6yNstQp6tQP
0zPqRZV6tWCNJf28c0G9Mvp8BgoRqDf4bN7J4qDOYARFzyDb2JJlffCzbvyRRB9xsHO1GwQe/+7Q
gW9HIEHpZ5lQF/Knf54b/vcEUCZhJEHx8LAVd0/SbLo1Z09Yb6wpw9Knyc9npRTw5rwx09ka7B9N
C+3BBbRHwINCl4S8xzzPLTnHq7nRPPxsfEW9DDsDfgcJCuaNG95vTDMPU+Ch7ySNUcBtQcaRuaaQ
E16bKawoCBQQ0IxhkzyeMfzdVO47xTlLxdAaVOoVaH/kabLgau3CL8vHfl6EF3cReZkUWMgf9JuD
1WYagtfv4jgoHw35SAIbP2waezoDgc2owGzoyZi7yNcgz6T9ziEjmpkOxUj4fmPhOrPji25/afDI
0zG7KpeQrmjuZUH+Ag17ugLwf/OOkDWwKLFzEboHSSO8W4JoSwwEEZG+RKu+0eTVFEAcJUGESJpK
DZCGBXSGgwjnLtFtuU7RffFOAjeIWB13ur2bg3cwrHQy/mepCNLWwA4sLElMXxxxlAKSEtobKX+g
SJpMnv9laf7lUrSCAP8M9RD8XSfLKPdE0Tn1+ZQpKiJBCxK4To6RJW+34tFAqBzX+IHYttyx5e8S
uwqHoX+Nezb4Y7ui+X8V/CXVALFfGzeUwL9aK/m0O6A9ZOzZuH012pyFIowlF73LipvLA7w5b8hm
PQA/mEBV0fdKw2wrnTKP58YOJ+lRt4r/0VG4xlA+GjDOM4dy1HWvN36MxDzNmXg+ZV3mWH2tsfJa
XdZiIfAdltCG4/hbfkBqHhckdOK7o0zIjQQEgqiF4jnOvpiBuwI3H/h2qOJypUmxdfMn0rkXi8NP
R5fUpyIU+MCuUMOcV4zQzTTWoRm5ifxgXeH+xbe7gQJAT5OiXcNPxlFcpzAZ3rnWUzfHUCfDeEeB
FVVV0PFZl39b4OT3Rx2E7uD4/tIQ0Oq9neEavJ7XrzsKwN7gECaTI+UEE6Y1RZWFHyQa/ofrKg9q
+kzDkVvCEQlE5BIChpsECIGIiKICIpBwhCSGI0ACRAIIhPuSGwEBBSEqyCEQRAFXULGo1a3b3da6
rnW3090/HO2uurXjsbXb0Zm22Sf86Op05vkLviTv+33v+xwZ1h2P++TLBUHtYSShCSnJyL+NGz2c
kHs1X/3dqZAuxNgKVjNHsZKv/LhQeaOEUcs0kliaiH99XJ7h9qN7VrQ35Ffyim9XrGg/Ep5NixsX
0Gs8xt+c2T0UhwOMOr+gw2GY7QtasNaUQ+EWA2iZBBtBwfIi7aKvse9HeRN8RqVPWG+EZ02A7yF/
9Muo8sMZc6mN8SpdIHRYSKm8cZFD0Za0hRxKrq17jc/2vijZcn7Q0UgC7/mqP1qHw+EBnaG8aSEK
VqwUNtxvo8rthp6rs6/nU7JtMW/6AvJmlXv4scjGLw+BQ+AGT7+eUL8cj5sSlN+tEc1muFX7GKyZ
JZ3zRzvCsxlL2uv8qeT+J8euaK+IzkmHXgwrVgoG/63ufzK0sdCZqrB3Lvc4/OhI3b0WbBNek67y
0heYGovNNiBYiY0F59NUd2qT51KTZiUR6hh2a4hoNh02nqgHzUK5LOU0uDg8JVIGiacHS8+fFDNb
g+2K6A5FLts1qQTem6uheKD27iH0EnUi1kSyIbQnQqARk2LWlX5asVHp5F3HxowhCRqJdJdZ80X9
0WfH3ap8nVSQ4FB6uTfsvWg+lZSgv5rp1sLd6p1bTWvnk6ZFmYs5V7XLyFYpM8Kcqwcua69VfFYL
e0zLdSLx1tmV0Is/rdx1PBq+iJRoABXT2fUMmkGKsfCsuOFBCyQGKrC5xJ2qsBOdS6u+14SpNlx1
Jji5qcAJOhg7kTyrXTz/y8LIqzGqfCPkMmlOUvJJceyigsCabV6QE4g+vo9excB9Qjv0ko2RQA1T
zY3TzYwkZh41LFw+vpkIp161Aed+OZ+2KHMu9WQ1c13LPbZ27+h61O/Z6GuRRYM9WLVJFkQxeALk
hahRHllqaZRhAReReVmRpJFofl6ovtvsXRfInxDZFbja5DphTZiNwUiga0Y6xcyl1MMog6z6rCZj
Ue5a5eNdG7gx33l9FiXnmqLgZilGnTBjOAnqgDTAheqQYKIvNoXPcSllhB+NZDWy9s1KAaLfxDu1
BHzr/VyrfQSaNKeDDFwyaf/qZwXGegJjdleYXTGd4CK4AhyY085nLuYhe/o0sR2K3bYPRnU9GmBU
eutJTIw+0CMTCQU3H6nelzy7P3tZuX8xi7Sb5FMfkLOsjBnmn/rPqE8TU09gAisSPcLnHtvp38xd
NZZr/dIKNlNz7KvuNChvlbDauPDPruXelpk0OJ+qew1mUirGWEcUKSZw+7B8eNnfaS/MaeeuaC/L
VvIs5LYRA5GMSk/O4XCA6Df6ZjGBzCV55sW8Hceio0/xT76e6Hui7numHno1trU7AmWAnwlmQBn+
7SGL2qWkKYl7DcuvnWN9wCG4O7zv6Qn3ahbcF0lg8GHe0ROR3au9hDOSuntNKAMyjUHtetiH7QA7
xY0lcrt2DDwbZjYFis+n7xyKQYQkBoOcZmV30IlRzay5X49F8K4PxK9gSTFOAmTeiaSQzjBoPaqC
xLtX+axLMkHjBkLd+yIkmmVSOL3hJX+qTp1JZy8dYP9qOeJulhPIuJCRuiiLm0neORCRuaSIHxck
TgkPXCsOOrwVgmsGNkizxBNjnOr+0ph1KTt+Ip5e6+XXGOha5s5s5SCg0fIc4XIJGvmwZZ0wyakj
r0f6ng5UfF7hWOSSrEnreTZ48sVo/detrX/vzL1akDQtxJrzpoSkuHXrJeYgCrLUyrHMxSzHGjPP
qPS1L3Ro+LJdclHq2cLaMxyPBAeYZVtDo2Gn3WuZIZ3hvY/7W75qa/mqa+hbtWetL7ON49PMCW3f
FvF7FUD0m/bXVgLORc70Mu9kTSpVbm+jdHIo3bKlwtfvEAeUwjkSTk6nogtQECXLOveGsuvhEeQU
0fms1q87i26V2h2k+zZyrLI3YWX0BWarrPU+1WIkNmTbTf44M/zyFA7HjCYaSyzHfzgTN8lv/lsT
soxnrb/tAced/ZEgXrgOY93HKfg5JD49iSmsLBbcucxt14kY1Rd15tk0U6nlplJnh/JVuRdDuTZ4
1vjivydfnkY9i9pLHQ97wcwBHVy4rO2d20JXDgJrSfBWBQHBjCj1oiysdw9vXDj9br7v+Ympt2c1
P81iSveejLeS2aALgxRz3EZI5469pxISNfvdG5gFt8uaHrT61DHple4IVhYyGhafKPj/0E8m2xa5
aH4+N/jdiX0TvO5HPXBEqfPSsTdTEFD/Dq7qz7Ws9iDYKvwFgwTixTwjBWASBJoUbveOqHF+/HhK
yz+6GFXe3N6dG2SbIA32RL8SCgYPDgH3Q+Ib2xZudlHR6WVem5TO7A4uzMzQN+qtV4uAtXm+VU4g
51J2+pIsdiTBsWSLXysHj6InJkuX5ay2EBhmYn9XOcSJ3R02/VYTORxvLqUV3i7FbzmVuQ++GEEx
NnmOhimGHzYLgHI96piguMkfz7Bbgyf+O+nXwoEPHPt+cuDpAKs5eGtPqHdjIDmNmn0pn9kUTBIa
gfTIqVSQoZnUpv+JGgklUh3f91Tt3cCm5dn3Pz9Jr/JCXtAtjphCllJhP8BXM+/OwWL1PB48+9Os
X0sQKnSp8nQ96Ba6UgAQ/e5ZLiIgu5yXekEe2rMbKQZ0pLypSjmfPvGDJrCNG9a70yKThmtEv5Ss
TZK5LBzgjQsQfNSvxkpulzuXeKi/HYPfsM5zgHv/bb/C9R41un5n3s14NwZMvZ1OmBSTokiqz6uy
lhReLQGWCtvdg9EkviEGGEJggF0QU9ZLMKUsqtz62L8GOR1hEcf3+XdzRQtS6xxH8Nu2nm2ULKqR
SMcVlpkUF5Unqym4/n4zDs/+cm7guXrHsajQnl1lf6wu/biEuSADiH5jP6kioFxWZF/Oh83bN5q0
dzQROsLuCLJT2pHi9ZHCbPId16WsRxZAGbtOxs5rF1Lns/0a2XCMzLYQ3rSg95tBz0NM4/0WGEWA
kEK9ZFNif7EFp16MwHJs79uTf70YK+ZS7kXikTA88L1WMvtDD9qvaJehGiS+ke6WMihYZJtCR0OJ
ReFNFfSr+9FRr4aAzIuK2NP8nI8KD/5B5VHtR043R796Sab4Hrdyn55/Doy/+R/bZQLU9JmG8RQE
OayAB3JJQIKgCBIIZ1IgnCEcgWBuQiQBIQQI4RQQwiXhvsJ9yqEhhCsBUYysx9haR3Fot9pVa9fR
Trej2207rrse7fz3zWbrdo/MOxmGSf6T9/ve53l+74zsQRtDmUZTskFEgR1hpowdYfNpUPp+Q6+X
QJEXBJbp1rAjhPbG2IqcdOzKtWx80J6pzYefGtIXjWJvN0m1MuKYORZjWh63wgKLa8WDDRJ6Iuru
NeZcFgk3JKa8D43oJoCCLY+715F1iB4Uw9SQs2Mby7zpUfMKsl61VYeTERYQ9eDzMcAw4eV8fC/R
ox6bd6MQ1qikadavOKqzdCAcwGDuauaJy+Lqz+qArud+mWfNH09RsmUPmlApJnr+MWCaAQ5ZpO8x
PGYMd2ST60SfTYsciAeBJE0lV23WEWfY+vr3ftQbDRXWS0qcpZNGkjMu5aKL3JsetidNM4B48e0R
IT3RBgzdTUHW2OY6Nj1qm/n7DHQaP34sR5sf1B5y8m519qVcwHv4zA7uHubC8QytiDKdsp1raazD
Lau2r7sgfLue9doVYCZ+nIHeMzdy4DQg7q2FjoZ0c0yZR909GUhY34VunnlWhowd2dqCU3drmSo+
HEhAc4i1EM1c4NT9ofFf/XJ0Y+BdGwj2AkCuQdRLyOqpu/V7hXawIqWv8Es+qQieTNHX+3592oKh
Km6Xg6yIA4DQCVpEy794Apa4DwW7ABHJZ1Ig0+E3AG6hy91kD1sVb2fx3aHuFR40BdupzP3Ehrjg
k5P2YgxMo30+Zg5Z5K5l+DbigR5NuLothiiPNUs1hweShpNWkVUlsriAaIo+rmTNpbPV/NGXM+jC
gyY8q10ZtuDJcKp6IaDo2xiLadVb0uOarPhxGmSlf1coeyG99atOt/KjOiRgAtVb6Swu2QjchjSe
vJ1tXvxxMWs+3b81xLcB75iHDvldkb7e9+s/RIbC1gbEjFFoShYcOCre0LnsEFXBGfx+gqpkgE9C
1+CZ4LSQ0ae/bFa8UQU0h+JkQdGDlIAWQu3vZflXJfvFB7xqAmAwSm5Wgjt1P+sDC4Vb0KmeZyXU
SlS/qGCYgcSy1vMXkRUNshY7Es9dSttANio368Ei6HO6vxseNROHogJbCcapO1NXBPnXiihTzNDu
GLAg15OH48+mdD6VQzLCzOuWoxP7DtX5OIidBr8foyvZp+6fhicfbfb3aQ6OHzvGVqYdVmfp632/
2M4ofVnx93k1BMA2VHqrou/FiH8THjjBiGFqJbABy4IE2c4yR0sOpK9mLyHqnA2JdTYaMA8WOui9
99tBbEMQ/Kd6q5F3XsBZStUiV+ImqXB0ekmiKMa0WRZk+tQrReIZWvuTHjVyofx2FfAqrIoVd6rB
36T3Gio3a4G3I/tjwdJhnJwKD8Enk1VMv2ZC4gTVQeKCLnVpf9IBPgAbE0wO8LafLMSYaebTFqT8
eXHg+egacp53nu9S5gbPOaHNizrLSphPS/jVr3T74EyyvujnGEGtIeAbsIES5eQl3RVoOr7ps+Tb
RA0kQCShqIbMOXbmBeh3KedKno3QHlsf7FJ6BNdIAAvyafDbK9zf8V1/59OBiZ9m1Mh5Yi8J0MI4
1cKct3vip4mSmycpU0lqRO17Gt/1tA9UnKUVJU3TEs/QYXKgX4aKB9FvwDClnQVlkS1Fti6lmI4n
/cc1mUR5TPRgzG6hPbAWcKOnFAshkjzLNmKaetX6h/fGCNZyUMe2A36DpgDOowaiAftdCg6wtk5D
SX/zClUL9JV/LT/zsihqMD6oM4y7zIcEtxTYpJxj8zQZ2HrcfrETiKXvu37uMncRWcjaEO3M3Och
9XWr9gaU7fnTAICQo8Sl9Ws56HcO0cifD5pxdQiq25JSjIWXci8i2pyr4sjRBJzso5EfJ8BeYLwB
Ziz4ltOvFHFjVIaSESaPPPtWuYAsZ1+V7My0hoFp+aojY00U2k1KmKAB7TiWuMoeNgGxRPbFzb6d
txDuM+GYgt4BfrLWxYuIZvbdrGc9ltARcVDqFS4nhW81Qv2234h7rfry7wzZl+dIHqMS+2PjplJi
RigN99u8avxEG2KPGl+wfXQhRvlOyVMLJl+eqdyshsiA1IOl1bPev+f5AGWSCktN6vkMxbvZFUQD
gbs700EXMTzdVkhTcCB2F5FV0nDi4Sqc5EZp+kqmYC0Xvu5a5TnwYmjgxaAB3Sx2hKJBVhVvls69
noNMMUw1L759in9BBMZIlEd5VvsZp+3krmQU3So35+6Z+Zui4k4FzMY2mhm+I9QuD41KNCIOxWKb
AmFQYYPzkuJSr5ZA/W+/R2SEohslydMpyQoWoTNi+tX0CrJCGk9CkVEoyjafBv/QnhiY8OrPaopu
lal+Vvk0BTtKXEFozkXueVcl1VsNAM/oQvfSTyvBhfZmO5hwrHTT9c+q3JSCLZ97vbiMrOLbw8N7
45hzPOciVxB1cHfE6F8nV5EL2VfE9gUYsDvQdceTTutsBwcxeIWwcrOGOZcO7YT2RQNdJE0xGr9s
MePubvpjl48sGPwBrrLm89PFN6tiR6m51wvIY4kB7WGupUe8GwkJDzr1Jf3PV9AlCVT4MDnrWn70
MMU+D4NK3IaiGx2R+g395czJO1UOYlf3am+PKu/Wxy1p6jTQdWQ/GbYSQkcYutiNsyQYfD5qn+di
yDT/gGl6sMLLrugA/6KINJTgUYONGCApf1HNI4uggiVEc7D8KKxCFZs1nAWBrQgsHbeOaLMui6wE
tv1/Hp1DltWQoZ/XWvCt7QudY4YpTQ+7qCqOd2NA/Hiifd5+dBFm8Icxt1NelElmUGsYKgEFYdfx
jdyAZr4rw672i2Z4h0CJG6dW3pEGdhH19V/9fiSP1td+sYtXHS56NC5+PAUMp+vpEKbMk6ZiOhdi
IPLArtOWBdRZFvBGwfViu1wXrCzQufhgYAth7Icx0nC8CceCqUkHvoKIlH4hAwEa0s12ZViPvJxS
IcsKZBlk61x6iDxJ7fq295gqNbAtzKvBN7iNCIxtk+s89UYBApx6fc5T6uffFuJa7oXvj5A97kyc
ofk1BcMtY8rcj9Tjup/1g8pAdJ51fgYsM0CsD6imhZ+WA5ECwEBUhXTHgMHiavzp99v+b7+Ef3Be
JkBNn2kYj1td6gpei4AIqKBA5YZwBcKZi4QkJBwJgZAECDm4Isp9n0ICcgVCOCQREq5EiEkAxbNO
t1VHp6O71W09tnXbuqOd6aq1OtVmX5vZTmfabXf3m3eYIcM//N/ve7/n+T0msbXQMrRPSwheRQ1q
j3Sv8uSa87IN/IlnarBX2EDbPHuqikqeSpE/HOq41RXQjIQ0AWIFEanrztH0hSzfliDQWLjUwW0o
/9awrYKdzsXuO4v3Dn4pX7KcXLSYhedKIBqQJmjyfwynaDKQ7ZH2IlfeijioDQUnVXu9Efw3d1UA
bgsavoXv6Fq+v/5Ga9GFsngFiThGgc+di/aIzheVvVdlX+ACkAMuvC3fWfV8Gu4LuhcNty+mH5c+
mwNGuVuyn2YqgGr82bI2i5Qn8U8JAekhIkUfRSsfjdpx7BHk9eCewEW/Z25xKnQB2szScyAf4ZWk
fRU+kbJ4p8K9ojUJQAioU8/9fhh1k8UIF5aoovV/MRTWE9txVwYjOv/dXPRAHEQw2HnAs/gRAnoQ
D7eAvcgDEHUodeMYBeJLZXsOeXEN/G15Dp5V/rH9Cc0320rfrcKNE0VnJZXXG50PuwPECs9Jdghc
hWclQJVAI171/vCSlZdrAbTcSj1BuiFG8QwFSKPQWj/vF1bUMN5aHFMBYyEL3ZuwmeuISP4dSwfp
b4VrFiDSNiJS17GWcuIGk1CyhFApOqg9vONWp9liBokL6Qj3rgkA0yy+WO5Q5GbH2WEvdgEkg71S
P1GD53rW+aFk8ZVX6nzqQ2C7xGfLYuR40YWygrMl2wt2wQC/QWIAqhP52wucnUr22nEcYDOhrwNN
wbhRCkmTXn65BtT7jwKnyL5E25ytzBPZIC8Aop2f9CBob0ObojPi/VXvUNTp4F9YORa9lBcqi4H6
xX4J11ushTwSAc8SJ4igCUCh4ErAvQjSOvp0pke5V+wQHqwB0DesKyZiIJ6zkg+CCR568P1qqpoR
JkNpXs4sWRb1Fj2cctONVto0gzRB3pzvqHpyHPJgnlkU3BpmtKw13GzBK6kbGLbgILurvCCXIejr
fer9wZ5wymQAVOUjABgU3ETCJC24HQVfZbaYdOD7Z4qpmjTvuiD3w95MHZuopjoUuh25LV21nEL3
Yp0P7mOdyEG2h+8o2EU/XQT1i83+2G+UURirSNqWuy1UFo1Vkj2r/Tvu9A58MVZ5rXHq2YxHuU+u
WVx8qaLig0YYgK5PeuBK9j0YKr14SHBKhO7Dc07yAee03+n1FmNYZ3T6Alv7SgcTPvx4tPpqE0Cj
bwNy4TV46yzPxPdvRSIybJyK9xSfL3cp2Wdf4Dr1jRb2asGiX7Isk9X06H4MaSIVXDJvWah+Nb9k
Mbbd6Uydy4bu2m9LScfSCs8djpDGIVJs/sAGnN64s9AVUsx2/i5QdY/6AGv9p35hkbRMa0V2x0f1
J9KnWYmKZNCEqec6GDDpnd54OTZCGlt6sWLm5SxjnpNrFkHM0byYL7pU1n2vnzabhRkhQCgA2ly2
LKdpmaAejuI9mm/nDJalwBbkuoyN3nWBmm/nAataP5IChcIcQqDAKDAUIG36xr7P5AbLyXmLHh7n
GYUgWZVXmnybggK7wgA/Fl4bgaWZ81yyig76FtIeXX61PlwaCxaMm6CkzDLti1wSRohb8512FbqH
DuF+s9/YP1VZi6FhATsFtkSi5VgHsbObxBPmM2k8GYFDkI+nxw8lbRE6etUG5JoKZr8HSzVnG3Kd
i9z5q8UhUgBp5apltfJaA32GCVd75tX89MuFGYve/CaZNkT3xZksy0fvy48/1fo2Bb7FsoHACHcc
MGwDYzPHwIMAO215Mx6y+/07S/YMfznEXy2su94MCK15sTD5dCrLwEvTskRrxcLTkuijGMXDMdpc
Zt3NJvjEo9oX1ZNImqDwjFxkLxbqV5r9sV/0moS9WhDWjQ5pQyaMJBFGqfU3miGG2ORssuPtCGgP
B7eN7o3hnxa33upcs6zlLPE3MDdzlvmQeoCFVi0rE08m/TrCt/DsN3E3J2vouu8XPcrfOfRe1cFL
5dhxCkiBXe629Vm2tgL7DSw7mEZICt41gcMPlRC75t80C3ffVHm1bn+NX/+D0TRddtkHNbGDBMEZ
CdfIh2QEEg0CQlUxEJS3kiZTOm7LvGv9PMo9gT8zdWysItmnOdxav94vrLiLtdaCQFfxfjWMTZKK
5iZxh37hIGzYW4AAwfv6PlOkzbB3l3m5Vx1wlbiXXjzI1Od4NQYCRMEway36hX+/tnCtNKADiVMS
jj+bKblUKb0/MPn18aprTeNfH1v8QdZ+LHhE+5Nf9W9gbFH1Tw12goxg2NC0TNMPegW3uOXPzU5i
l005dq0fdYjPlEAgAhc+UB8QM4IDIMcNE+JVtP+pX8zlhpBu1MDno3QNUHqSY/FuOA44iCwDR3pv
EH6K1opa/iqDlwfYK7tcQ9Uwyq7Wcoz5/BUB96SIZxRlG/mZulyeScxeKmAv8vHHqMmTaUQVnTCe
gh7B4cYpiaPEqAFMaDc6sjsB1Zvo24yM6seAp4PUB7dHhXVFxQ0SIBPFDOAo0wz2Yj6YAl6ZHD+E
jR7AEMdT4cVI6lSuSchZzl/PsPOu8SWr0sDU4Fk7gau1frNZ66J+qrBWeGfMgbpgvJJC12S4Vux7
m2VbfaX5yMd9tddbS9+VME9wWYY8liE3G15mlp06k02fY8TIccAqtNnMdB2bPJVBn2WR1ekpWmai
goQbo0Cggy7820MCpBHQPkGdEtqJRnUnwIiCNCE7IjDDpKRxGmY0Gf4S/i9tOj1lKhPyGmgUZ0VI
n8+CyAPAA7yRt1LI0uXxzCLustBN4hF6JHp/pZ9PW3DcJBl/d/D/6DfMICg5d9hJtBvOF4gIMojm
hXb29eL0N/rxpxr1C43muU79VDv6lWr0qzHl48mBvyt6Px2RPxrvf6zsfaDo/lwuu9vbfW+w529D
7R/3tP5FVvFhQ/WHzUUXDpdcqBCdPyg8XZR7Ssw9LRKeKswx5+aY4QQz02ayQQSIk+RUXSZ9LiNp
lEwaT8GNJWNHiOA7gUdC/ZqQmCECVkHxrUei5bjgjjAH4U7UUYxPcyD5WGpwVxRUlEEA9V82a104
9b94r/KoJu8s+rGHXRQQrSxSDSD7nrAYggkkhEBIQlaSQMJOZA1LhQCBgGyJQsoeJAFkkwDiNqKM
tVXRjp05U0dtz8wonY6ns7RjZ6ba9szMybycnOP/41jfuSd/5Uu++/u9d9+9dMAhNYFjEAe2RUT2
YzOmGM75nvjRNL5BDI3KM0j4Bj57mcdY5sOAm/5ImQDHghtMwfRBNyYxztIzz9Cz9AywJXG9OOhP
dFt4iCISrznmUx0QczLuYCPatybgncpD2FP43CUBXOKxYQphMpM8k5OhZ4AlpupYZC3No3Sva4FH
2li6s9jDry4IDAAom1e5r3f1u6AeKJ6je7HX0cEUWI4l16TEdYkZ/xNZc0VfKAPAywgvFQW0hoDd
JU3TQEjtePY+1X7YU8lWLEf4PDZKsMp17PutGnQppgtD1GaW36w69n6GBdMWodv5VB+e/2F+yWjo
eHiSu5LvINoNCav90ckIZbT2bzNhihjICLvL9lXeru34rGvi77NgU81eDtqevSSs2KoAXQLnJv2g
pmSzxrcmsH77vYGnmpqPauvvtkYpE/3qAolaqnBNlD3HwhjEgNfmC4W/KTNDdl+eCdddH0yepIIx
7t0ZmnihB7WU3WlCMizdK7xTRglTz3X+9cFg2glTFIRhD4fgLwuqul2rfqY5Io+e+lZPGCWHtkUt
/GhIGSaKNyuAY4g8WvG4F2Zw7OuZzs+7C6+VtjxQDv1xYu6lYeyv2kMngjO0dMnliiPyKM03k3QD
DzwYnCFCswpRRA9+eRrTn3REEc4xiEI7YxOHcJi1Ut5WFeD1yL7iSzrDOHo6lXtODNESTBdjnkPV
5Ry/IV03nvcq90uboIR1xiof9ZZfr43tT75uvAYiE9IRM//D6sTXM7Ltlvq7jQNP1Oqdwb7facqu
V/rUoGtvNcDQ1d5qhMyFUaeAQUI3h6HlYag85z2V74BnAOsCqSdcgZFck8I0lW3WvHdfUXhDihtP
h95IUOF2FXntKnQD1lk6NndZwFgRkH+lNOO1yZqLdLvZDPJ0bnBrOOlMVvoEybPigPJhF8gLdCNC
tcS/ny64mD/y1RhICnU6x6PKG9QY04dvuN+u+Wp49vul4b9MNn+iqLvbWHqrOvE0DjwGuCl7vpsl
xwH8JMJEIXwUQrMGce7//eA+6UG3wj15G+Lep+qR57o14wbRlLkain4urfqwvulj+eCXI6ongzD4
sepkSBycZRHkkfSZ3DfIt/BGDYA6DesDSxil4DVEeGGY5XcbgvXfz+dvlMK0RpzEgMlUfjYw/+Na
8yedpi/QbBGKJUQtwUUJQrMIbAmkzTDpc3xgasN3tmDac1eEupezp54NhXdiPEt9Ci6UW7OdHMWu
DhI3EAc7rpMNx8m1bC8MKV6TlqhKRTKRwLYw4XkJKF6Wng2aKd2qzpplErZqExYFgP+TrLmw60UA
yv0O3ro4uC06UXWMbFoQZGhv1dMhML3QzOnarFBFbNYcy3TjPBTYMFSeyRXDmcQOHF0xQmoqtct3
hulzk+xp+7QrqjOh43E3JCOEao1QrTzLfM58OxPZi0UYdvCsDccZnrWg2zfcb9V9t+hV62vDduj+
vA/bnwyeJ+BEMGHUZEW45wSYXhw0nhlvhKy5UrflgEBdLuO8xL/pMPgBrBof2BIK6g1BBnQDwsXy
v5chHbAWedZ8Z7i+3SX7gbK90M100Tl25gY2nQDNDjeUvmZcD2qJsOA42AmcrJi2u0s9nQv2ovhO
Njwn1qLILs/VtwE982Jh6V8G9c6QLd8FYaBM22okM2EAB48zVvjWLEfyeCb5FwoT3jRfqKhL5WZI
1kWQCr2rD8FYUWeYvnWBDnm7YXuO/GkUybFNG6NAOPKtOQwcQ9tjcxa4VkyUNde24eNWMJ+Zc0xL
NspZuKt/R7Vk3MCo8BC4IGCC1J83XgAvB7FCerMSYdqWfVgV359kw3OB36m73aB40GHBtHGRuJOm
qeRpOssg9Cg/0PPFaPQC10z5zZJ9xTf1g3pA0WYpGKFwRXzKCAlsYUBrBIweXF/yaeKpLzSWfEec
htjxmy4k29qa7SBYk3hXo0Hrzv3nItjRXcX7pv+pn32xMPnNxCXjFYouu/qmDNyjfd6uzOnsKCUG
JXQb/fP4uvGS9h/TXhXeVkJHS7aD9KYs6RQhXo1jLuVln+XsL/Ph3Gu2lx6M6E4CvHGy5jKTjZvj
AZSP+kUbxT4ydKomI30i+2BdkOi8hKZnIemIbxO67aHSnu90VIPnGsRgHiCTgtUHJRdcKBx8NpKk
JlKmGWApPSq8U0cyfGr8wIGDtkPTYlS4A5V+8GuUqWzIXDmzHCQHscx1iOzE4gbThReLQtoiMMPk
iFVRmpYOfAE/EVlzmckGnWUAqKsS1jw/pg+bPcsmjhEJIyRnsWfqMNlgXPWXBSIZ0Kj43AWBe/kB
rAYPwpW3Wsg2iBC6rTULVXSl8nBjGIrvXHilIrYnASEhfo1BU9/paXo2GBXLXMf2T5VFV6WFm8cd
BXuiBhJjekyrx71of+pkTpxBkjJKBfzUZM1lJou7WgWAtGJaMWe5SRp8ho7mKfUFzWy8J7fluHiU
eE89n4nrSQ6WR/Q/UYOMgy8KaA8v/lmlvcANybGBbZW7yBWuF4M+uxd7y+40XzNukcZpSK4NKHxc
T5LiQTeSZb3/uD/0QPwQLqY/CbqaZxCmaqmAt8D0VYUu8c2gQZyZzqndbgjriIewkD6VDasEoSA1
2/XyX7bD8pXdeS91OAMUddW4zt0ocCnyDO+Ir9k+QTvLQbItXUQePTsqD6mPe8kBJ7F71+Nuv9oA
Kz5qT/l+dFMw9HCYIj5RnYLtT8m/XEhfFUWO0wBvn6+Zsv96CSB5jMxYZhdeLg08EU6ZYlBmGNz1
Asd8d9UfhsafT4KxJ45mGoyGI/Kw+rvybD2dqmOA7YSRVO0MQWjlnssv36oCYUdYKHRT6MATFWwu
1wL3LD0LN0Tylx1JUhGy59jcxbyjV2UA0kdNgLdM9lUlnMsHYFcEDbfrgk5EELVZ1bea2Ev5EFdD
O2OC5ZEZWlqWjtn66y7JZtnsyyV0S1jdveb8DXHtLRk4ZNeCvTC5FTf+q+KpL+ZyxgtxRgnwxItK
5Ci6zfb1nB1o0+fiMTsA2KwKWRvvvD0XiCBeHijPQoDGLH8gMl8aCkRV52qFU0Q7bnf5Lgp1nO4V
tDTaqNUcmE8rT9d13ZkQtDgM2HZa+GVh7fmG4qMV0vkq/c+mr/+/3rzTru16by2ohuUE5m7nmd7J
27NcpnmqVekEb4x3fzFHeaq7zWqolwfWsxAA8ax8p5n6BLfCs9XKJaq5J8q0Go0SdmW4zPANXxMt
kCIB7BQolmpWnK0JWhZWf6EBWEozhbDLFqou+rFMrVwXGMvAROs4w9NzQWDQ6ii/BUH8yeLVZ2uM
VycAEVuaFBANEs9CANC/SsDsNsnD8miN8VSvgmPlwD6F74Jwm35X/0XhQUuiIlYnCOVIASsp+ylu
hUfLGPyYfZeEyhcoazeZWE10kilSjdmQCuznVpyqkctWirjQqroiCoh0NmdAvDzQ/sMOgJ4FIs2l
McqLIoAo9mS1ZoVu+o5s7UYjYHsM2GAQzZRN3J6l32oB9K9ItqTVJGdg2eUz31e1Ui9mUyqwHeI4
1TXjfKPCqkT5DjuIlwetZyEA6F+IZ1X7HBRaLYCo4kyT+0x3kzbrzN1FqhW60RtSTLtsxLOkXab5
hq2INu2xSdiRKpwjZdZpnX2tW31ptEKXPdC/QAT07ED7hlgA9C/Es4abMtwXhPjM9Q9ZFSNdopxz
oNSi0zZ8ZWzshjS7qS7mXVYJm5MEU6QyduYnnWvRXpUAQUDPDrQPyAFAzwKR0f4K8VojIKo+19h7
f6JOnbHdFPfsAwXKlWrOU91St+WaT3a13p+ttSwGiCD+HWiHkw+A/oV4VmVBKBDxZEkDUez6tOIT
le7rE+Sn+bosCDbeXwT0L8TLQ9qzcADxL8SzaP4FIoh/B9qNNAGY/h1oFw1zABgApuiIwgoNCmVu
ZHN0cmVhbQ1lbmRvYmoNMzIgMCBvYmo8PC9TdGVtViAxMzgvRm9udE5hbWUvQXJpYWwtQm9sZE1U
L0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzMi9EZXNjZW50IC0yMTEv
Rm9udEJCb3hbLTYyOCAtMzc2IDIwMDAgMTAxMF0vQXNjZW50IDkwNS9Gb250RmFtaWx5KEFyaWFs
KS9DYXBIZWlnaHQgNzE4L1hIZWlnaHQgNTE1L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5n
bGUgMD4+DWVuZG9iag0zMyAwIG9iajw8L1N0ZW1WIDg4L0ZvbnROYW1lL0FyaWFsTVQvRm9udFN0
cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMS9Gb250QkJv
eFstNjY1IC0zMjUgMjAwMCAxMDA2XS9Bc2NlbnQgOTA1L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhl
aWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4N
ZW5kb2JqDTM0IDAgb2JqPDwvU3RlbVYgOTYvRm9udE5hbWUvTHVjaWRhQ29uc29sZS9Gb250U3Ry
ZXRjaC9TZW1pQ29uZGVuc2VkL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMC9G
b250QkJveFswIC0yMTEgNjAzIDc4OV0vQXNjZW50IDc4OS9Gb250RmFtaWx5KEx1Y2lkYSBDb25z
b2xlKS9DYXBIZWlnaHQgNjI1L1hIZWlnaHQgNTMxL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGlj
QW5nbGUgMD4+DWVuZG9iag0zNSAwIG9iajw8L0xlbmd0aCA2OTg4L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGgxIDExMDQwPj5zdHJlYW0NCkiJ3FcLVBNnFp48gUReTVDXpfoDRQWSMAFBeVlDCDgu
JJiEiNa6JmEg0byYGUCKComKoNVSRXxSUVtRkfooPrZn6+LR9YFC8VXR9bWybrU+qvUtoPsPVEFb
d8/Zc3bPnp05/5m59//u/b//v/fmThAGgiD9kBKEhYxJ0mApFwubJ0LNcQQRClWa8Ii5968T8P0K
1OmM+RQIPdgxD0H8RiEIh53tyLE+RA/mIsigeCh751gKs7fMq9+PIME0fqcJ12f9uX4yjiCh16Ec
bYIKbzHLiSBDUqH8nslKzShIx0ZD2YEgzE6L3agfGD8Q+hpaiSAMl1U/w8FkcWqh/RGIBza9FR9w
zJKDIMMHQvyXDgJ3zPbeD/0HWhCEBXkgjO6bfiKCLvgUIt2X4CHqEtzjeoSWji197MlwY9a4BFeh
6hKTwZB6of247j0zTA4HQadyeWFcBpvhGslksGvUaDoq6qPxXz+4xB+J775ViAEhETtiQXCEgmM0
faPgdX9snyV186818zqXxp9LqXseLztY4/J+H3UxG+EIYQoF5Q0nFlyvPfhN1OHVi8qahjRpdJ+i
nq+4MtiQkvMz6RD0XS4rg80T9NfhhFljzrEBLZFHUkCJUwV2Yrp0AOpHA/gCr5cAEcBsRolUhIb2
TAT1WpqtONBQeqvDbMsBGpzINxtxoLbbKekINKIHHaZUgVRMloilYtqJQCaXK9K1iiQRGG4MiRkJ
Xl8DHTzAM2YkGiWNQEei8JoExRhpRKT0Z/F/fwPOtX3PnMFBWM5F8NzLmU4nckoC7ppmisQSp/8O
7s5a/h5fzwnnNW157UcjQ3eefuTxwYj7Nyqee/Rr/ctvJ/2h+ftHZTuqG+cH35yV6UNOm3Es16/r
UOajkLrMKVXsLrHBN9Pp35RbeSYwM/zMcSFnbvTXlVsa0sbduBMXWK9bOTtgjaW0cVzK8mkNG6PP
dHqITzXErGayYFK/kRIsyCvWd808zuiTN0o6is5sfrC1sJPTuSwhN2hz2PDLHwvw8uei+YxPJq0y
NPnWljzYs0+454Ru5XR3g+LQ+i/ORxVzAi8RYnYpp3amR/+lQvndx/3TvnNbvNrHkvmcF7W8qXzt
ZbZjTegs/eL91/m5qzYdzjYkJiyrDIxYEVi+4FmW+3sPTz6D+dsMRzTTD/nGd9V5+e2AjuTMueVN
yWUVwXeEU///knirdBga3ON48D+n8XKn/Lfu9N+i+PJ8eL84H1/Um55wE7hjNgonbDiFOqt/kdIL
YRTm0yldp7/dUL+oIqXiQoPvFPMFXrGhgittbnlR9mnyWSy28sZp7vvV9etnTLr1tNOoUO3l29Af
10fXiT0u37MPq/McP5UTpSpu0apa94gS2/iti/ZOebG7pLW9qqE4EEv0sZxasZ2h23DgW8na2AfF
mzI3ng3Er31cN2PNH8+lJJo+EM/q2sVksH4loa1TO1b+/nPzV6eKHGGGoMFJYPy2IL/DFPMp9tOw
QZO3luZGuYc9+uTSlV1V1xfW/q6dPDLWo3r7+YXn/ZY0sa55BOu43ys/T/nixITk06N0DwOaDwyN
EwdHtKy++qcxKT+0WVPyrzWiG7xLWorb4mbXPF0WKg3ze3ZEePvi9hsZMkeyWDQbdXlshMO7hsVk
MJk+hdlVtjnbW3cz3rFVNzbguX0ZM2FC63/l1N8eoUhU2hPw0FcZIbdbrThhNOstQGPPpgr0BA7S
8wwWM2nCCRLIZd0pOQodIY1G0VcpSYsRkVExUTGTUBfjw/84CWkymtRjlFBQUCDJh4YkNJQY7dZw
2IHtpJmyE4Xh8nQNvYadcEiAoRCo8WyJiM5rSao2ic7laOloNL7HT1SSOcdMwQWxJCC36EkSRAIx
SDMbCTsJKfTy0Okt5iw9ZbbbQH6ElI960PZcATNDIxWgvrTgLuBN0JMmWHqU3Sb1Qb16jsJNjWdZ
7bYs6WDUn9awhH697uWQo53odvtynv+WeXjA4M0qcjE8Eah3Z7oYDKSh4uTQTVl/v+l34IW1SKbi
PbWH5rZIBmo2RkRfOW36a1QX9k5bVSf+rUYI9rGPfvTwqMNaeev4V9tC0VURmTN3b54enLOy8WrB
D5xrP7ZXPa7n/2bjl/FzHVef2CerZtm91YoFfmfxC3GA056wzrI81osfLLgdcAwsjvnIMIdzNGhQ
p7p6a3Vq1dl4ZWaCq+iOR5Rul6kxUbE+Trqho21ZR8Zh0aYNB0JULQ+W3mUNKbrnF7v5yZb0ORyr
4e5CQdmoc+3+XuR+7pivhx+42bwk9/C+7J3rtIHf8XNmPplfWL41m7dl/LMuIqCz9MNDD8Z53crU
B6W17ojNuiL4bMqRedbU/tsS3GAhb3BxLqIuzrnu6LwrYDNRBOXTr95sNovJqUGdZbTEYDtL0Nkl
PkVVfzsh7zKtuD/quC3uJ75rnfG/UEguDrMBfhWiATQTNoPxgj0AFaL0l1/vl11/FtOtBIHRhhAe
m4tC8twxqIsd3QfDo01d7CCoHlITUjLMRFEOMjY8/F8UxjoXa6/TxWrQmswkMOIEZc42G/UUDszd
BUMnG07SVUPg2TiB24y4COhtWcBMkSCPhDASkBRhNlKWQh6ZZ5iGGylA2UWAMuGg9xBe+aXrJZ3Q
Gym6IcLWROFW3EaB4ZBJCA/SJGmAVILCRfL1ZoveYKGZvO6tdwNAT8Xy3rbROJq1QmyFbiAOwBXE
BJ6bh5MUOeZ1nJ3gQehL4OsxFYGIqJhIGEY97JCyfBwq0ux5NkoPWenMeIEIhhDEjEBHRPIyNDKI
cxQS5hwTRTdJaUxM9BvuAJBZLEBNI0j4Q0TCnoxnSYBcodbKMCVvgkytlim1mEIDkjCNPFWGpSmS
gEyZ1KcPp2JpGGzDEh6NVmLKlFigHasAGRoFUCXDV0zT7Q5LxuQyrQJAUaNVY3Jt6kSgyUgcp5Br
gVZFm/B0CjUG/1gp++AxlRKkq2VyLSZXQDvoIE2h1ELa9BKYRpMB1/sH81UeFsWRxV9Vdc/goKIg
HmC0FRFQww4eeKBEjuGQU0ZQRF2GUxQY5QoImHFEF1A5PBNEEc8lGIUkKJooQlbUFVdXjGuImogK
Lqt+JPE2TOcNCrjs7vftX/ttv+mZqep6Ve/3e0dVC06B8zz8AtAWWZeRyi4EgqePv7fnW5sVC/wD
FEql0IMKSfB18Q501c/S0ytDu30UAS4e2OxC6RcguHnO89Wru+F/J8HfCW10CfR2ChD8AwP8/ZSK
CZ2LzPf09hZ8/ebJnBWdJHkrOhVc/HyVirmBaLynk/cEVPH1nOcZ9Fany1g/RBUguDr5OLkrlLaC
UqGQ6XHq9wv9HK4KHOWtRKZd1Jj78egydVTvWIyOScSyEBkhxKvj9WEVFRMZoXyTCE5JmBlhyZhA
sshU1O8M7hRVbHKkkLhUhXEQr04SwiKFcDU+iuicRJUoqMLDkxPeZGCUOiGuM2dkKW+2GxyBkaq3
wNPJVrbPXjP5v0nzrv5YdbTaNjomSr7mqL6SCNyaQ3KNXCMxDF3vQda/UBApIdhhLTHAqsLzWEEH
D/+P8yNJ8rDukVQeJDcd3KseyvGwQsxmdXVaJXYyG9OzE3fXFCE2RhVmK8QmYS788+kSOi/54Hcq
nTlnIJdgtcNPr3OP/qS2zXtvWmBT0qINlnUHhfbY6i/S3dJ3l6w6uVLiYWoc2bDY5sVch5yVlU8G
TUttyj9iqLEvWOyx4yxMkylrZk8Vc02s4sB98nMPb9uEn+sbV3e4qkfn/3Vzyd2tj1pFuFD3OGH4
d8Us/lhtePrEVFeH3etyX2etn2pt23pw2lTHk7/+orWw03KjsQaPQOjy5P/B/vFvDoN9JQZvSKE8
D3vWHJYP62apD7N7d2Ph8IzR0zK067XtyEf2KHJ2xtwA/g+JExt8Kqovtj07HH+u3zG5/zvD+9o5
y2fvGaoZDEpIgzgIAzXEggBR+BsPSaVjNKP10fQ2mOK6DjWd0ZSUkByZlLYi8ne9jjSclsDCcybn
lrXuylH9eHLEo4IKWVWxuePDUqchblGR9Xnn1x7XLnbOz31YcGnWj3PWfb5q2NGfig+zV8Gni+Pu
Jl1pbnL5KcK6JvWl37ItQ4779Lt0Lzds0/LPBuwavVT6w6BhaTljgh9ZZYVZDEtNpty0Eq/ZZjV/
UwQ5WvsOlb4XbhW/cNy2vy96lb7ry4QRmWWHnikH7nzaslHbmFNSO2qVUXPb7ZgFoZOKvOhpj08/
3p+9/oHDbZ3fzqutTeeaY8ddOxX6Vf3Sa0VWKuvzmY2qe4VBl01jjT1D75E4z0STT3aFmtw5YNG4
qj5dqDZZdXCoCCk5DS2Fdy4G5zVrZ17IP5Stu3gy/f6kG+OtS7XkCp7qGnp8IbHTklPYdUIfZGuq
/+/fX6kpnBpY1OTyaNRrtwVZOX92yy6wfDwotFegBsuHvhunht0NKcEw7X7C2xnpXz3s5PiuIbeb
Mmnywn8J07bCgn7X9soqV28Rn5tsM/LqHVRrNIr01XEhcVOc01O+u39jxUvTgV6FwdcbMmvFaD/H
xKcZN6OmSJdHKgb1N4ePxFenispsilNaqtLEIzMzv1+07cljTWLJwLI+ZpkbLozKmrhmUO3l+0JW
U9vE7JC0OzdE87KthY7a3BDLzbf2PZUbO5euHu2X1cfj15P2Ox2+/rTRt2VjeaK+qBHuEikAHoAv
4idh0/LNL9sDUdS4L+N5QolUQnkp9Lp81PFqmN0utIv8Rp0bmWRgSOo03U/5xWDHe8NIvIezrWAO
IN55e9/TBYuP+OVgoVsm3rQywsFfvr3fXCqwhCVgA3OgDtrhNBkH/nBGvALhsIB+CO9jfz4chzNw
G1whAiiYkQwQxGLYCGNhLeyB6ZyZWAXe8MDACAbDGJhB1CABU4iG3eQmeIIXzuEA7pADCfg9F/uf
k2n4hIAMFuPqW2EnnIa/wA8wDGe0hevo+ufiV+CCFSUc0uEE3Oad+Q1gAoVwCMqgFu4TW7KftLHH
YpXYIP4DtWzADuwhBKtPGGyGUhx3CC5SC7ZPNBPTxT+K52E4Wl+OqGvhLK71jAgkiITTgyxN90qM
F8uRh75oM1qP4oRofCEJDuDI6/Ca9EHRUoF+QMN1A8UhIIWRWOHGo32BWPFWQzZsQhRFUAJH4QH5
gCwll8hj2o9qaA3vL/WV+vap6fhWdBef4Rp9YRRaOx+WQypqboYtsB01S3GtP6G0QwexJw7EkXiS
AJJP1pMD5AUdT7+nr1l/ZsQmsGAWyjJYM3tpwHf46Xboroj+YipySZBzGXrSBXHOg0WwAhLhQ8gA
DVqXh1KA7JWjVCCfNSjfwC24i9ICD+AhxhyPGGVkHIocxYHMJnNIIPk9iSaJZAc5RqrJaXKWtJEn
dDK1p9OpHw2g0XQFTaIFtIJW0hp6j/6CVs5gCpbIPmLlrI6dZ1dZEwfcHE7FxXDJ3FaugvuWa+ee
cDoeeAsUW17F7+nYq/PShYhjRQcxTNwkFqA8QI5HIJqxYIV4/NGr4bijRCOqFbASJQ25W4eItsNu
5E7P3jGohq8xSuvQv/VwBZoQ3y1ohufwEsnR4zMlo8j7xA75nUXcURain1JIBtGQPFKEPFeSKpQz
5Cai1CHCIBpMl9AUmkE30R10Jz1Bz9Dr6AmRSdATQ5k782LzWQhbwpLYdvYx+4TtZiWsmp1h9Rzl
ZnD+XAK3livg9nJHuXNcI3eTl/MOfC5KBV/Fn+JbJMYSc8lkiVJSLZUYpBm0GujgCzgHlVDVO/dJ
NhlAKuEz0so4pqENdAE1pNeJlrtMrNADMwnwebjb/owWvkeu0qlkPgsnC5E/LYkiIbCLDWd72Rxo
4OOJkvmTCFByO+BX/htQ8bn0c0b5XNZBXtJyWAp5dHlHmRhM+oOS7KcHMWIyYSbYcGZwnU7nThBL
akNrpEdINThKJWw6m2FghK397C6aqTQwIm2gYr+RX23BTVxn+D+7q921fEEWxpYtjFYskmPLsrG5
+KbakiUZgrBjW4ZqgbS6WNRmKPYkQMelpLQMJRXBo0xmINPLNNNh0sTJtEcGOnImpX5rX/LEjNsp
fYBwaR9KyWQInaYY9T8r2dgp0/axM13pO//9/P+ey57dj3H/3MK9Ncy9jc+Ee+SP0gtY3SL/C/Q5
Cd3k0pNyeNegcVGynrtEdi+eXvw9/8PcT0g19zHAYvmij/PjituTm+GuwQO4+OTvwk24xt2APfjU
SOg751Pce9/AJ81eeMyV4n4K43Nk0tvT0/0lT1dnR3vbtq1bWls2Nze5G10N9c/VOR2b1I12xbah
dr21ptpSVbmuYq253LSmrLSk2FgkS6JBwLdWaAyqfVGFOqNUcKo7d7qZrMZQEVuhiFIFVX2rfagS
1d2U1Z5e9Dz4BU9v3tO77ElMigc87kYlqCr0o4CqZMm+oQjy5wOqptD7Ot+v84JTF0pRsNsxQgla
xgIKJVElSPuOj6WC0QD2lyk2+lV/0uhuhIyxGNli5GiVOpkhVd1EZ7iqYGeGA7kUq6I1aiBIq9UA
K4HyjmBslA4ORYIBq92uuRsp8SfUOAW1l65x6S7g19NQ0U8lPY0yzm4HzimZxvnUa1kTxKOuklF1
NHYgQvmYxnKUuzBvgFZ9847lqYidm/2RsyutVj4VtIwrTEylzir0raHISqudtZqGfWAs5+iLpvow
9Ws4iqGwgtm4M1qEkjOYUmF3wu4qf39JNcg00UMKLVJ71bHUoSjOTU2KwvCUfbamxjuXuwk1QSU1
ElHttMeqarHA+kwFpIanLld7lerVFndjxlSeH9hM2ZoCU1K6kkku23ROd2dcaHh5ZAmrSH0eVwRV
EgpWElHxntpZk2yHVKId3fDSCEbRUZyRcVrkj6ZMnUzP4qnBYVKV1GeAK0C9/5fVmlhBIzpMnwFj
2TpZXmtoX+Kpy0UbGtgSkfw4p1hjty5vczcez3I+ddKkIMHhg0Ec25jW2YzDb7ezCT6X9UIcBXpq
KJKXFYhbZ8Hb7NIoF2WW+SXLuj3McmrJshweVXElX8HzC2AdlZ3L/zWmyrXBsU5KKv+NOZm3h8Jq
aGhfRAmmooWxDY2skvL29mVbgaNr/RHeyhU4zsrrVlyUB5admRApoYID/6K+qEezkoyrUtcQpY+a
ojvzrWa02//LoGzuExalk6dhhTJpp2u13LVKXlVeSYrHggUnFxrZl0oZV9qADZpc/KQb271P3nvc
JB/Vh3HldU34CE9Vdn0O+GqHmIE7hisQEwAcwigMiTOwQ+yAnfxp6ETbCMKNttfR5kD/IwX6OteR
y6F+F+ITRCMijFAQcYSG2I34FmKI64D3Eecw1sPiGeXPQ4Txht9AhWEvbERqFu5CjXAb6kQr7BSu
g4o6J+bfYiiBAeQdhpNQIdWymNyfUd4tOtDnr1jDy+AUPoR2jO0ynIFKrH0H2toN9dArHsB8t6ES
+/mZ+CdyCOkuQwB1kHsgAP8H7HsE65hC9PEPIYixzwsu2MHvwvu7Dm7up+BHGkT7OkSL8CO8Jxc8
hzyrvw15Dek4+gxgrAvtO3A8fVjrIP8p7EfajP3u538H18kP4BLSBfTfKjyCteRzPa+H4GxhzHYc
KxBFmBNFshnp3xCP5L1QL92FEPb/4hLlt8BBNnZ4wo8XxnQK4w9iHh//czhUGGOGTSyXDHBPuM51
yJA7j/euiBdwzk+CG8fmK9Jd8l0cqwEdFyCGtJ8B+2tHtCG6Cug0XCFGRDHawyjvEochwSDZoBVj
mzDXCFsbaNuMdeoo1L+7UL9Osc5mHFffUry4CxowxsWbIbwCsIyH+L7xEL9zdEouYcwxjO/mWvA7
6CT3dh7g5825N3gz92Kegor8d3SKseQSrPetAzNXhz8n54QJUom746t6+4Le9uhtM2u55tlmmy3L
Nc2+xUjjbG09kk3e4ls1tpY6s81Tx+Qqb9fhetvNmWrbLcR7da22Vz2tttOIZsRxlJlf3Uy9baJu
4usT35s4K7RBZSXOsrlc9mbJ7V/uqSiqKGpLZ8mvvR1S+ldS+rKU/pqUHpXSX5bSfVJ6u5RuktIu
Ke2Q0pukCtksm+QyuUQ2yrIsyoLMySBXZHM3vS62+StEEyOiwFpB500ca9lGxycBR2QOv+7oWj7E
hcK9tN0Vykq5YdrmClFpcH8kQ8i0hlrKvZolMBLJkhxTnbGyU3sOCMmdOW8tUE0jITqfgFBcoY/C
apYY8UFlUHsJNYcgNNJrgcrjPZYec3d5R1/gGU200LqeXhbXyis0OPUh2Mgx9vFFjl6WbG9ITBtG
bVrXppk2rWsttfRCKByhM7UabWVMrlYjl31XvSfYe0BUDSYRUXru+JiFnoorSsZ7tfCC4IzGE2OM
xpL0qpoMUK8aUDK+E88wn2BmnxrIwIngSCRzwpsMzPq8vqAaC2hzMEDimYbpVem+v5RuDhpI/F97
zJI467KBZRyYfkbGaWYeYBmnWcZplnHAO6BnDI6He0loMJKRoVfDw0enl7liI05V1GrXeitNk936
vHXZLa9YPxCAvAPFeBaX4HtdKYKZ3D63j5lwwTBTGXvlK5gsr3TZrR+QdwomE6rL1V5wHXN94XqZ
XWAJjgcYsJK53Dx3atZsa3Vp7Jzh2BGEX3+4jXHSurwbRCmBOoOQ4MEoGhI8z9UUSUKCQLVc325x
DZgeevoXPQOmR55+06IHejyLHoaWzfZye7kDG1zb8Fjh5x97DfAPPHHm9VPuOncDn33FYJ8Dnlzx
lhVJUFMqVpeUPrCzbl0Dd0z3oKf/fstmUiGqG53btm7f0lrJ3Vi4+ObCwpsXFzhfni7op2Pr/9lP
+x/7scsIryy/v3w7/wQDtorWoJTnBeSnC7yI/I/RCkIRSk/g/QJPYAOZKfAclJHfFnge9QsFXkD+
YYEXYQNnHpmaTB6MJZLKu8rIWFLpnzgycRRVin/ipcmJl2JHxyeOKJOHE01KIHY09h+cmllnSnji
8DGm+SepVM/SMBRFD4VCoEP9A8LbS2LbLShi0cHQJIU0u6Q2JoXXVvJiIZv/xclRZwd/hH/AycnR
1XpyWzvqUB7369yPcx9co7wF+3qu27Wp+o4aaK2iWZaXRkWpSYtVOh36oTcKO+NqPlnqIP47RIwK
t0hxgwTXtAqPlBi5+AGWWFDKbZXCOaOCfq0T4jOpUEQ0+x16F4Ine0462m2mMGZG425XY4h5tBu+
Hly+Luyt1xd0wA5NG7En4w6ldEWcZygFVtRTDOEj5KwRdYc8FeaYCFtA/ro6I6/mfsU/tftkN9f5
Sq6mXGMDB/z/Gb3PZluQOt+4x1NuO1ftky/r0BL44fLluLbP/tv7ev19an1YLYat38v/EWAABzIy
zAoNCmVuZHN0cmVhbQ1lbmRvYmoNMzYgMCBvYmo8PC9TdGVtViAwL0ZvbnROYW1lL0tMTklPTitT
eW1ib2xNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udEZpbGUyIDM1IDAgUi9Gb250V2VpZ2h0IDQw
MC9GbGFncyA0L0Rlc2NlbnQgLTIxOS9Gb250QkJveFswIC0yMjAgMTExMyAxMDA1XS9Bc2NlbnQg
MTAwNS9Gb250RmFtaWx5KFN5bWJvbCkvQ2FwSGVpZ2h0IDAvVHlwZS9Gb250RGVzY3JpcHRvci9J
dGFsaWNBbmdsZSAwPj4NZW5kb2JqDTM3IDAgb2JqPDwvU3VidHlwZS9DSURGb250VHlwZTIvRm9u
dERlc2NyaXB0b3IgMzYgMCBSL0Jhc2VGb250L0tMTklPTitTeW1ib2xNVC9XWzEyMFs0NTldXS9D
SURTeXN0ZW1JbmZvPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShB
ZG9iZSk+Pi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag0zOCAwIG9iajw8L0xlbmd0aCAyMTcv
RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJVFA9T8QwDN3zKzyCGJKLkI6h6nIsHfgQLey5
xC2RqBO56dB/TxK1hxhsy89+es+Wl+65I59AvnOwPSYYPTnGJaxsEa44eYKTBudt2rua7WwiyEzu
tyXh3NEYoGmE/MjDJfEGd8NwflD3IN/YIXuaMvKoP78y0q8x/uCMlEBB24LDUcjLi4mvZkaQlfgH
DltE0LU/7drB4RKNRTY0ITRKnZ/aoyC5//ODdR3tt2FxbGuldSvy9o4XXrnp5sOuzNliPbwaKRY8
4e03McSiVkL8CjAA6lJqlAoNCmVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmo8PC9TdGVtViAxMTYu
ODY3L0ZvbnROYW1lL1RpbWVzTmV3Um9tYW5QUy1Cb2xkSXRhbGljTVQvRm9udFN0cmV0Y2gvTm9y
bWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDk4L0Rlc2NlbnQgLTIxNi9Gb250QkJveFstNTQ3IC0z
MDcgMTIwNiAxMDMyXS9Bc2NlbnQgODkxL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBI
ZWlnaHQgNjU2L1hIZWlnaHQgLTUzMS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0x
NT4+DWVuZG9iag00MCAwIG9iajw8L1N0ZW1WIDcxLjc0Mi9Gb250TmFtZS9UaW1lc05ld1JvbWFu
UFMtSXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDk4L0Rl
c2NlbnQgLTIxNi9Gb250QkJveFstNDk4IC0zMDcgMTEyMCAxMDIzXS9Bc2NlbnQgODkxL0ZvbnRG
YW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTU0Ni9UeXBlL0Zv
bnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNT4+DWVuZG9iag00MSAwIG9iajw8L09QTSAxL09Q
IGZhbHNlL29wIGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlL1NNIDAuMDI+Pg1lbmRvYmoN
NDIgMCBvYmo8PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4dEdTdGF0ZS9TQSB0cnVl
L1NNIDAuMDI+Pg1lbmRvYmoNMSAwIG9iajw8L051bXNbMCAyIDAgUl0+Pg1lbmRvYmoNMiAwIG9i
ajw8L1MvRD4+DWVuZG9iag0zIDAgb2JqPDwvQ291bnQgMS9UeXBlL1BhZ2VzL0tpZHNbOCAwIFJd
Pj4NZW5kb2JqDTQgMCBvYmo8PC9TdWJ0eXBlL1hNTC9MZW5ndGggMzU1OS9UeXBlL01ldGFkYXRh
Pj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3pr
YzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IjMuMS03
MDEiPgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt
cmRmLXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAg
ICAgICAgICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAg
ICA8cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlzdGlsbGVyIDcuMCAoV2luZG93cyk8L3BkZjpQcm9k
dWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRm
OmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAv
MS4wLyI+CiAgICAgICAgIDx4YXA6Q3JlYXRvclRvb2w+UFNjcmlwdDUuZGxsIFZlcnNpb24gNS4y
PC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAgIDx4YXA6TW9kaWZ5RGF0ZT4yMDA1LTA3LTIxVDE1
OjU3OjAyKzAxOjAwPC94YXA6TW9kaWZ5RGF0ZT4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIw
MDUtMDctMjFUMTU6NTc6MDIrMDE6MDA8L3hhcDpDcmVhdGVEYXRlPgogICAgICA8L3JkZjpEZXNj
cmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAg
eG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRj
OmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgog
ICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1k
ZWZhdWx0Ij5NaWNyb3NvZnQgV29yZCAtIE5ldHdvcmtpbmcyMDA2Q0ZQdjEwLmRvYzwvcmRmOmxp
PgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAgICAgICAgIDxk
YzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT5F
ZG11bmRvIE1vbnRlaXJvPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAg
PC9kYzpjcmVhdG9yPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlw
dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9i
ZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFwTU06RG9jdW1lbnRJRD51dWlkOjhlMmUz
YTkzLWM2NWItNDY5Ni05MmJiLWRhMjlhMGY4YjI4ZjwveGFwTU06RG9jdW1lbnRJRD4KICAgICAg
ICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVpZDphOGVlNmEzMi00Yjg5LTRiOGMtOTZmMy02MWI5ODVi
YjRiMDU8L3hhcE1NOkluc3RhbmNlSUQ+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICA8L3Jk
ZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9InciPz4NCmVuZHN0cmVhbQ1lbmRvYmoNNSAw
IG9iajw8L0NyZWF0aW9uRGF0ZShEOjIwMDUwNzIxMTU1NzAyKzAxJzAwJykvQXV0aG9yKEVkbXVu
ZG8gTW9udGVpcm8pL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yKS9Qcm9kdWNlcihB
Y3JvYmF0IERpc3RpbGxlciA3LjAgXChXaW5kb3dzXCkpL01vZERhdGUoRDoyMDA1MDcyMTE1NTcw
MiswMScwMCcpL1RpdGxlKE1pY3Jvc29mdCBXb3JkIC0gTmV0d29ya2luZzIwMDZDRlB2MTAuZG9j
KT4+DWVuZG9iag14cmVmDQowIDYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA1NDUxMCAwMDAw
MCBuDQowMDAwMDU0NTQzIDAwMDAwIG4NCjAwMDAwNTQ1NjYgMDAwMDAgbg0KMDAwMDA1NDYxNiAw
MDAwMCBuDQowMDAwMDU4MjUxIDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNj4+DQpzdGFydHhy
ZWYNCjExNg0KJSVFT0YNCg==

------=_NextPart_000_038D_01C58E44.7CD632E0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_NextPart_000_038D_01C58E44.7CD632E0--





From avt-bounces@ietf.org Fri Jul 22 11:01:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dvz27-0006Cu-Ao; Fri, 22 Jul 2005 11:01:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvz25-0006Cl-Tz
	for avt@megatron.ietf.org; Fri, 22 Jul 2005 11:01:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22563
	for <avt@ietf.org>; Fri, 22 Jul 2005 11:01:47 -0400 (EDT)
Received: from cluster-d.mailcontrol.com ([217.69.20.190]
	helo=rly16d.srv.mailcontrol.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzWB-0000fP-TY
	for avt@ietf.org; Fri, 22 Jul 2005 11:33:06 -0400
Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12])
	by rly16d.srv.mailcontrol.com (MailControl) with SMTP id
	j6MF1T6S013522 for <avt@ietf.org>; Fri, 22 Jul 2005 16:01:29 +0100
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
	smtp id 1870_a8f4d7de_fac1_11d9_8016_0030482aac25;
	Fri, 22 Jul 2005 17:02:45 +0200
Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55])
	by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
	with ESMTP id 2005072217012287-58682 ;
	Fri, 22 Jul 2005 17:01:22 +0200 
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de
	for avt@ietf.org; Fri, 22 Jul 2005 17:03:02 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: Simple estimate for Nr. of retransmissions (WAS:RE: [AVT] IESG
	comments on draft-ietf-avr-rtp-retransmission-11.txt-	Issue 4:
	more parameters needed for RTX?)
Date: Fri, 22 Jul 2005 16:58:49 +0200
Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F31EA09@lan-ex-01.panasonic.de>
Thread-Topic: Simple estimate for Nr. of retransmissions (WAS:RE: [AVT] IESG
	comments on draft-ietf-avr-rtp-retransmission-11.txt-	Issue 4:
	more parameters needed for RTX?)
Thread-Index: AcWOzRFIeSO/tta4QXiiRuvtfGDnXw==
To: "IETF AVT WG" <avt@ietf.org>
From: "Jose Rey" <Jose.Rey@eu.panasonic.com>
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="us-ascii"
X-Scanned-By: MailControl A-05-01-05 (www.mailcontrol.com)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Content-Transfer-Encoding: quoted-printable
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

[warning: long email!]

Hi all,

Following Marks' suggestions (quoted email below) I will try to draft an
algorithm for finding out a simple estimate of the default number of
retransmissions (per packet) that a streaming client and server using
RTX should attempt in order to minimise the packet loss, while
considering the available RTCP bandwidth and the client buffering time
(both values usually known to the client).   The algorithm also requires
knowledge of the RTT, which shall be known at the client at least (?).
The absolute minimum number of retransmission attempts should of course
be one, but the algorithm tries to extract the highest number possible.

This email shall be thought as a first version; there many assumptions I
made and some of them might be wrong.  As a result of these
simplifications, the estimate seems overly conservative but that might
even be good.  I would like to get feedback if people think this is
reasonable, in the first place.  I have not experimented with this since
I don't have the resources to do so.  Also, it would useful to know if
this would help someone creating SDP sessions using RTX to get an idea
of the factors to take into account.

Here it goes:

Scenario
=3D=3D=3D=3D=3D=3D=3D=3D=3D
* streaming scenario; two RTP entities:server and client
* retransmission draft used
* RTCP bandwidth for SRs and RRs =3D 5% (default), 2,5% for server and
client.
* RTP bandwidths of 64, 128, 256 and 512 kbps=20
* RTT =3D 200ms
* RTCP RR compound packet size of  44 bytes containing: 1 RR, 1 SDES
item with CNAME, no encryption header, no profile specific extensions.
This ignores the other RR that could be present because of SSRC
multiplexing since it is not useful for the calculation
* AVPF Generic NACKs used for requesting retransmissions: this add 16
bytes of overhead to the RR for reporting a 16bit mask and 4 bytes more
every multiple of 16: 20 for 32, 24 for 48, etc.
* We assume 1 packet loss every RTCP
* We assume that the additional retransmissions queued on sender don't
add any delay to the first-time transmissions.=20

Observations:

1.- The RTCP_interval at which the client sends retransmission requests
shall be greater than the RTT.  This is logical otherwise the
retransmissions don't have enough time to be received.=20
 + this means for higher RTP bandwidths the default (5% RTP bw for RTCP)
may yield two small RTCP_intervals which have to be adapted using
bandwidth modifiers, so that the resulting RTCP intervals are >=3D RTT
 + For this it is required that the creator of the SDP session has an
estimate of the RTT.
2.- We assume a worst-case scenario at which a new Generic NACK report
block is added every to every new RTCP compound RR.  This may be too
conservative for some scenarios where the packet rate is low but it is
realistic for others like video at 30fps (which may yield in more than
30 packets per second). =20
3.- We assume that each packet exhausts its corresponding number of
available retransmissions, N.  This means that if a packet is requested
for retransmission a maximum of two times, the corresponding generic
NACK report block requesting that particular packet is sent in two
consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the RTCP compound contains that generic
NACK 10 times.  This assumption fixes the RTCP packet size (leaving out
the averaging with SR packets) to the same value after N*RTCP_interval
seconds, namely to 44 bytes + 12 bytes (fixed Generic NACK headers) +
4*N =3D 56 bytes + 4*N


Solution
=3D=3D=3D=3D=3D=3D=3D=3D

In the diagram below, the worst case situation for singleton losses is
represented (first packet SN=3D0 is lost).  There, the client buffering
time required to allocate at least one retransmission  is T=3D T1+T2+
(T3+T4+T1+T2).  The first term accounts for the downlink one-way-delay
and the lost packet detection time (due to reordering buffer).  The
second (in brackets) additionally includes the feedback transmission on
the uplink channel and the processing and queueing delay.  In detail:

T1=3D physical delay DL + transmission delay DL =
(=3Davg-packet-size/downlink
bitrate) + interarrival delay jitter
T2=3D packet-loss-detection-time + time-to-next-client-rtcp-report
T3=3D physical delay UL + transmission delay UL + interarrival delay
jitter
T4=3D feedback processing time + queuing time




      Sender
     +-+---------------------------------^-----\-----------------
      \ \                               /       \
       \ \                             |         |
 SN=3D0   \ \ SN=3D1                  SN=3Dn /         \  RTX(SN=3D0)
         \ \                          /           \
          X \                        /             \
             `.                     /               \
               \                   /                 \
                \                 |                   |
                 \                /                   \    ......
                  \              /                     \
     -------------V-------------/-----------------------V--------
            T1           T2        T3       T4     T1   ........
       Receiver


If there should more than one retransmission required, say N, just
multiply the second term by N.  This means that the client buffering
time required assure N retransmissions is T1+T2 + N*(T3+T4+T1+T2) .

Now we have to find out or simplify each term Ti.  We start with T1+T2.
We know that T1+T3 is ~=3DRTT, so T1 ~=3D T3 ~=3D RTT/2. On the other =
hand,
the worst case T2~=3Dinterarrival delay jitter + RTCP_interval ~=3D
RTCP_interval (?).  So T1+T2 < 2*RTCP_interval. T4 is probably very
small so we ignore it (?). =20
If these approximations are acceptable (T3+T4+T1+T2)~=3D RTT+
RTCP_interval_client <=3D 2*RTCP_interval_client  (as per observation 1
above).  Summarising, the *very conservative* client buffering time
required to guarantee N retransmissions is N* 2* RTCP_interval_client.=20

T =3D 2*RTCP_interval_client + 2*N*RTCP_interval_client =3D 2* (N+1)*
RTCP_interval_client

Numbers:
=3D=3D=3D=3D=3D=3D=3D=3D

Some numerical examples for RTT~=3D200ms

Table 1
				RTCP_interval_client vs. N	Required
Client Buffering Time vs. N [s]			=09
                		  1	2	5	7	10
1	2	5	7	10
RTP bps	RTCP bps=09
64000	      1600	       0.3	0.32	0.38	0.42	0.48
1.2	1.92	4.56	6.72	10.56
128000	3200	       0.15 0.16	0.19	0.21	0.24	0.6
0.96	2.28	3.36	5.28
256000	6400	       0.08	0.08	0.095	0.105	0.12	0.3
0.48	1.14	1.68	2.64
512000	12800	       0.04 0.04	0.048	0.053	0.06	0.15
0.24	0.57	0.84	1.32




Table 2 presents basically the same result as in Table 1 *only* that
those RTCP_intervals < RTT have been replaced with RTT!!

				RTCP_interval_client vs. N	Required
Client Buffering Time vs. N [s]=09
                		  1	2	5	7	10
1	2	5	7	10
RTP bps	RTCP bps=09
64000	      1600	        0.3	0.32	0.38	0.42	0.48
1.2	1.92	4.56	6.72	10.56
128000	3200		  0.2	0.2	0.2	0.21	0.24	0.8
1.2	2.4	3.36	5.28
256000	6400		  0.2	0.2	0.2	0.2	0.24	0.8
1.2	2.4	3.2	5.28
512000	12800		  0.2	0.2	0.2	0.2	0.24	0.8
1.2	2.4	3.2	5.28


Summary
=3D=3D=3D=3D=3D=3D=3D

The conservative estimate for the number of possible retransmissions as
a function of the client buffering time and the RTCP_client_interval,
under the assumptions given would be then:

	N=3D [Client-buffering-time / 2* RTCP_interval_client] -1=20

>From the Tables it can be seen that the estimate does not result in
excessive buffer requirements. =20

Comments?

---------------------------------------------
Jose Rey     mailto:jose.rey@eu.panasonic.com
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: +49(0)6103766-134/166
---------------------------------------------=20


--quote

> >>This still sounds like a big dose of handwaving to me. Can=20
> you not at=20
> >>least include some min/max here so you are sure that=20
> packets don't get=20
> >>lost? A recommended default that would at least *work* and=20
> not cause=20
> >>lost packets? Sure, leave room for optimization based on bandwidth=20
> >>modifiers, specific configuration, etc. but I'm afraid that=20
> without a=20
> >>starting point or specific algorithm you could end up with widely=20
> >>variant choices here from future implementations (unless,=20
> as I said,=20
> >>people just go figure out what vendor x does and copy it, in which=20
> >>case it should have just been in the spec).
> >>
> >=20
> >=20
> > Of course, the minimum is one. For enabling at least one=20
> rtx per packet, the server is only required to save it for=20
> some period of time.  This time has several components:
> >=20
> > 1- the time that the client takes to notice the loss.  For=20
> single tone losses this is when the next packet comes (taking=20
> out reordering buffer now), that is the intearrivel jitter plus
> > 2- the time it has to wait until the next RTCP send time,=20
> which is ~1/2*RTCP interval if we assume uniform=20
> distribution,which is common plus
> > 3- the time it takes for the server to process rtx request=20
> (ignore it?)
> > 4- 1 RTT to account for the initial (failed) tx and the=20
> time it takes for the rtx packet to the client
> >=20
> > For more than 1, just multiply. =20
> >=20
> > This is a rough & quick analysis using common sense but I=20
> haven't experimented with this. For bursty losses this is=20
> more complex, of course (term 2 is complex).  Reordering is a=20
> fixed delay, more or less.
> >=20
> > The maximum can be calculated in the same way by using up=20
> the available buffer. =20
> >=20
> > For the time being, one could make a table with link=20
> bandwidths, typical RTTs and what the buffer amount should be=20
> as f(RTT) for different RTCP bws, at least for the default=20
> 5%.  As well as for the maximum rtxs that the buffer allows.
> >=20
> > Does this make sense?
>=20
> Yes, it is at least something for an implementation to go by.=20
> Since you mention=20
> that you haven't experimented with this, I assume there is not much=20
> implementation of such a method? I was hoping that there were some=20
> implementations to try and document here rather than=20
> designing on the fly based=20
> on my comments. If this is brand new, perhaps you could pass=20
> the table and=20
> algorithm by the WG in a separate thread to see if there is=20
> consensus for it.
>=20
> Thanks,
>=20
> - Mark


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



From avt-bounces@ietf.org Fri Jul 22 11:27:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DvzRH-0001Ua-P1; Fri, 22 Jul 2005 11:27:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DvzRG-0001UU-Go
	for avt@megatron.ietf.org; Fri, 22 Jul 2005 11:27:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25712
	for <avt@ietf.org>; Fri, 22 Jul 2005 11:27:47 -0400 (EDT)
Received: from cluster-d.mailcontrol.com ([217.69.20.190]
	helo=rly13d.srv.mailcontrol.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzvS-0001oY-Cd
	for avt@ietf.org; Fri, 22 Jul 2005 11:59:07 -0400
Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12])
	by rly13d.srv.mailcontrol.com (MailControl) with SMTP id
	j6MFRWYC021218 for <avt@ietf.org>; Fri, 22 Jul 2005 16:27:32 +0100
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
	smtp id 1817_4d00fa30_fac5_11d9_93c6_0030482aac25;
	Fri, 22 Jul 2005 17:28:48 +0200
Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55])
	by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
	with ESMTP id 2005072217272858-59630 ;
	Fri, 22 Jul 2005 17:27:28 +0200 
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de
	for avt@ietf.org; Fri, 22 Jul 2005 17:29:08 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE: [AVT]
	IESG comments on
	draft-ietf-avr-rtp-retransmission-11.txt-	Issue 4: more
	parameters needed for RTX?)
Date: Fri, 22 Jul 2005 17:25:05 +0200
Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F31EA0E@lan-ex-01.panasonic.de>
Thread-Topic: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE:
	[AVT] IESG comments on
	draft-ietf-avr-rtp-retransmission-11.txt-	Issue 4: more
	parameters needed for RTX?)
Thread-Index: AcWOzRFIeSO/tta4QXiiRuvtfGDnXw==
To: "IETF AVT WG" <avt@ietf.org>
From: "Jose Rey" <Jose.Rey@eu.panasonic.com>
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="us-ascii"
X-Scanned-By: MailControl A-05-01-05 (www.mailcontrol.com)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90
Content-Transfer-Encoding: quoted-printable
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


Hi again!


the ML formatting messed up the tables so I send it again
---

[warning: long email!]

Hi all,

Following Marks' suggestions (quoted email below) I will try to draft an
algorithm for finding out a simple estimate of the default number of
retransmissions (per packet) that a streaming client and server using
RTX should attempt in order to minimise the packet loss, while
considering the available RTCP bandwidth and the client buffering time
(both values usually known to the client).   The algorithm also requires
knowledge of the RTT, which shall be known at the client at least (?).
The absolute minimum number of retransmission attempts should of course
be one, but the algorithm tries to extract the highest number possible.

This email shall be thought as a first version; there many assumptions I
made and some of them might be wrong.  As a result of these
simplifications, the estimate seems overly conservative but that might
even be good.  I would like to get feedback if people think this is
reasonable, in the first place.  I have not experimented with this since
I don't have the resources to do so.  Also, it would useful to know if
this would help someone creating SDP sessions using RTX to get an idea
of the factors to take into account.

Here it goes:

Scenario
=3D=3D=3D=3D=3D=3D=3D=3D=3D
* streaming scenario; two RTP entities:server and client
* retransmission draft used
* RTCP bandwidth for SRs and RRs =3D 5% (default), 2,5% for server and
client.
* RTP bandwidths of 64, 128, 256 and 512 kbps=20
* RTT =3D 200ms
* RTCP RR compound packet size of  44 bytes containing: 1 RR, 1 SDES
item with CNAME, no encryption header, no profile specific extensions.
This ignores the other RR that could be present because of SSRC
multiplexing since it is not useful for the calculation
* AVPF Generic NACKs used for requesting retransmissions: this add 16
bytes of overhead to the RR for reporting a 16bit mask and 4 bytes more
every multiple of 16: 20 for 32, 24 for 48, etc.
* We assume 1 packet loss every RTCP
* We assume that the additional retransmissions queued on sender don't
add any delay to the first-time transmissions.=20

Observations:

1.- The RTCP_interval at which the client sends retransmission requests
shall be greater than the RTT.  This is logical otherwise the
retransmissions don't have enough time to be received.=20
 + this means for higher RTP bandwidths the default (5% RTP bw for RTCP)
may yield two small RTCP_intervals which have to be adapted using
bandwidth modifiers, so that the resulting RTCP intervals are >=3D RTT
 + For this it is required that the creator of the SDP session has an
estimate of the RTT.
2.- We assume a worst-case scenario at which a new Generic NACK report
block is added every to every new RTCP compound RR.  This may be too
conservative for some scenarios where the packet rate is low but it is
realistic for others like video at 30fps (which may yield in more than
30 packets per second). =20
3.- We assume that each packet exhausts its corresponding number of
available retransmissions, N.  This means that if a packet is requested
for retransmission a maximum of two times, the corresponding generic
NACK report block requesting that particular packet is sent in two
consecutive RTCP compounds; likewise, if it is requested for
retransmission 10 times, then the RTCP compound contains that generic
NACK 10 times.  This assumption fixes the RTCP packet size (leaving out
the averaging with SR packets) to the same value after N*RTCP_interval
seconds, namely to 44 bytes + 12 bytes (fixed Generic NACK headers) +
4*N =3D 56 bytes + 4*N


Solution
=3D=3D=3D=3D=3D=3D=3D=3D

In the diagram below, the worst case situation for singleton losses is
represented (first packet SN=3D0 is lost).  There, the client buffering
time required to allocate at least one retransmission  is T=3D T1+T2+
(T3+T4+T1+T2).  The first term accounts for the downlink one-way-delay
and the lost packet detection time (due to reordering buffer).  The
second (in brackets) additionally includes the feedback transmission on
the uplink channel and the processing and queueing delay.  In detail:

T1=3D physical delay DL + transmission delay DL =
(=3Davg-packet-size/downlink
bitrate) + interarrival delay jitter
T2=3D packet-loss-detection-time + time-to-next-client-rtcp-report
T3=3D physical delay UL + transmission delay UL + interarrival delay
jitter
T4=3D feedback processing time + queuing time




      Sender
     +-+---------------------------------^-----\-----------------
      \ \                               /       \
       \ \                             |         |
 SN=3D0   \ \ SN=3D1                  SN=3Dn /         \  RTX(SN=3D0)
         \ \                          /           \
          X \                        /             \
             `.                     /               \
               \                   /                 \
                \                 |                   |
                 \                /                   \    ......
                  \              /                     \
     -------------V-------------/-----------------------V--------
            T1           T2        T3       T4     T1   ........
       Receiver


If there should more than one retransmission required, say N, just
multiply the second term by N.  This means that the client buffering
time required assure N retransmissions is T1+T2 + N*(T3+T4+T1+T2) .

Now we have to find out or simplify each term Ti.  We start with T1+T2.
We know that T1+T3 is ~=3DRTT, so T1 ~=3D T3 ~=3D RTT/2. On the other =
hand,
the worst case T2~=3Dinterarrival delay jitter + RTCP_interval ~=3D
RTCP_interval (?).  So T1+T2 < 2*RTCP_interval. T4 is probably very
small so we ignore it (?). =20
If these approximations are acceptable (T3+T4+T1+T2)~=3D RTT+
RTCP_interval_client <=3D 2*RTCP_interval_client  (as per observation 1
above).  Summarising, the *very conservative* client buffering time
required to guarantee N retransmissions is N* 2* RTCP_interval_client.=20

T =3D 2*RTCP_interval_client + 2*N*RTCP_interval_client =3D 2* (N+1)*
RTCP_interval_client

Numbers:
=3D=3D=3D=3D=3D=3D=3D=3D

Some numerical examples for RTT~=3D200ms

Table 1
				RTCP_interval_client vs. N

                		  1	2	5	7	10=09
RTP bps	RTCP bps=09
64000	      1600	       0.3	0.32	0.38	0.42	0.48
128000	3200	       0.15 0.16	0.19	0.21	0.24=09
256000	6400	       0.08	0.08	0.095	0.105	0.12=09
512000	12800	       0.04 0.04	0.048	0.053	0.06=09

			Required Client Buffering Time vs. N [s]

                		 1	2	5	7	10
RTP bps	RTCP bps=09
64000	      1600	       1.2	1.92	4.56	6.72	10.56
128000	3200	       0.6	0.96	2.28	3.36	5.28
256000	6400	       0.3	0.48	1.14	1.68	2.64
512000	12800	       0.15	0.24	0.57	0.84	1.32




Table 2 presents basically the same result as in Table 1 *only* that
those RTCP_intervals < RTT have been replaced with RTT!!

				RTCP_interval_client vs. N=09
                		  1	2	5	7	10=09
RTP bps	RTCP bps=09
64000	      1600	        0.3	0.32	0.38	0.42	0.48=09
128000	3200		  0.2	0.2	0.2	0.21	0.24=09
256000	6400		  0.2	0.2	0.2	0.2	0.24=09
512000	12800		  0.2	0.2	0.2	0.2	0.24=09

				Required Client Buffering Time vs. N [s]

                		  1	2	5	7	10
RTP bps	RTCP bps=09
64000	      1600	        1.2	1.92	4.56	6.72	10.56
128000	3200		  0.8	1.2	2.4	3.36	5.28
256000	6400		  0.8	1.2	2.4	3.2	5.28
512000	12800		  0.8	1.2	2.4	3.2	5.28


Summary
=3D=3D=3D=3D=3D=3D=3D

The conservative estimate for the number of possible retransmissions as
a function of the client buffering time and the RTCP_client_interval,
under the assumptions given would be then:

	N=3D [Client-buffering-time / 2* RTCP_interval_client] -1=20

>From the Tables it can be seen that the estimate does not result in
excessive buffer requirements. =20

Comments?

---------------------------------------------
Jose Rey     mailto:jose.rey@eu.panasonic.com
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: +49(0)6103766-134/166
---------------------------------------------=20


--quote

> >>This still sounds like a big dose of handwaving to me. Can=20
> you not at=20
> >>least include some min/max here so you are sure that=20
> packets don't get=20
> >>lost? A recommended default that would at least *work* and=20
> not cause=20
> >>lost packets? Sure, leave room for optimization based on bandwidth=20
> >>modifiers, specific configuration, etc. but I'm afraid that=20
> without a=20
> >>starting point or specific algorithm you could end up with widely=20
> >>variant choices here from future implementations (unless,=20
> as I said,=20
> >>people just go figure out what vendor x does and copy it, in which=20
> >>case it should have just been in the spec).
> >>
> >=20
> >=20
> > Of course, the minimum is one. For enabling at least one=20
> rtx per packet, the server is only required to save it for=20
> some period of time.  This time has several components:
> >=20
> > 1- the time that the client takes to notice the loss.  For=20
> single tone losses this is when the next packet comes (taking=20
> out reordering buffer now), that is the intearrivel jitter plus
> > 2- the time it has to wait until the next RTCP send time,=20
> which is ~1/2*RTCP interval if we assume uniform=20
> distribution,which is common plus
> > 3- the time it takes for the server to process rtx request=20
> (ignore it?)
> > 4- 1 RTT to account for the initial (failed) tx and the=20
> time it takes for the rtx packet to the client
> >=20
> > For more than 1, just multiply. =20
> >=20
> > This is a rough & quick analysis using common sense but I=20
> haven't experimented with this. For bursty losses this is=20
> more complex, of course (term 2 is complex).  Reordering is a=20
> fixed delay, more or less.
> >=20
> > The maximum can be calculated in the same way by using up=20
> the available buffer. =20
> >=20
> > For the time being, one could make a table with link=20
> bandwidths, typical RTTs and what the buffer amount should be=20
> as f(RTT) for different RTCP bws, at least for the default=20
> 5%.  As well as for the maximum rtxs that the buffer allows.
> >=20
> > Does this make sense?
>=20
> Yes, it is at least something for an implementation to go by.=20
> Since you mention=20
> that you haven't experimented with this, I assume there is not much=20
> implementation of such a method? I was hoping that there were some=20
> implementations to try and document here rather than=20
> designing on the fly based=20
> on my comments. If this is brand new, perhaps you could pass=20
> the table and=20
> algorithm by the WG in a separate thread to see if there is=20
> consensus for it.
>=20
> Thanks,
>=20
> - Mark


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



From avt-bounces@ietf.org Fri Jul 22 12:04:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dw00G-0007iw-2U; Fri, 22 Jul 2005 12:04:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw00D-0007ii-V2
	for avt@megatron.ietf.org; Fri, 22 Jul 2005 12:03:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28289
	for <avt@ietf.org>; Fri, 22 Jul 2005 12:03:54 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw0UU-0003E4-8K
	for avt@ietf.org; Fri, 22 Jul 2005 12:35:14 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 59AE310E5;
	Fri, 22 Jul 2005 18:03:47 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Jul 2005 18:03:45 +0200
Received: from ericsson.com ([147.214.97.151]) by esealmw128.eemea.ericsson.se
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 22 Jul 2005 18:03:45 +0200
Message-ID: <42E118E1.9080007@ericsson.com>
Date: Fri, 22 Jul 2005 18:03:45 +0200
From: =?ISO-8859-1?Q?Mats_N=E4slund?= <mats.naslund@ericsson.com>
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: Guoqiang Lu <guoqian@nortel.com>
Subject: Re: [AVT] SRTCP key derivation
References: <183DD1B052A11A40B76125E42F1CBAAB04C3304A@zcarhxm1.corp.nortel.com>
In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB04C3304A@zcarhxm1.corp.nortel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 22 Jul 2005 16:03:45.0411 (UTC)
	FILETIME=[F0357D30:01C58ED6]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: quoted-printable
Cc: "Karl Norrman \(KI/EAB\)" <karl.norrman@ericsson.com>, mcgrew@cisco.com,
	avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

I think the RFC is quite clear on this issue. (Perhaps there
isn't a "one-liner" that tells you this in one shot, but all
information is there).

First, notice that what really matters is the format/size of
"index DIV key_derivation_rate", because that is what is input to
the KDF. The RFC says:

    Let "a DIV t" denote integer division of a by t, rounded down, and
    with the convention that "a DIV 0 =3D 0" for all a.  We also make the
    convention of treating "a DIV t" as a bit string of the same length
    as a, and thus "a DIV t" will in general have leading zeros.

This means that when it later states:

    *  Let r =3D index DIV key_derivation_rate (with DIV as defined above=
).

    *  Let key_id =3D <label> || r.

r shall have the same bit-size as "index" has. For SRTP,
the index is clearly 48 bits, hence, so should the corresponding r be.

For SRTCP, a bit later it says:

    Replate the SRTP index by the 32-bit quantity: 0 || SRTCP index

here it is explcitly stated that it is a 32-bit quantity, hence
the same size is used for the result of the DIV operation and the
result/input to the KDF is 32 bits, same as before the DIV took
place.

Of course, there may be better ways to do it form implementation point
of view.

Best,

/Mats

Guoqiang Lu wrote:

>>This means that, e.g., the labels will not be in the same octet positio=
n for SRTP and SRTCP.
>=20
>=20
> This seems to contradict the reference implementation by David McGrew f=
ound in srtp.sourceforge.net: The SRTCP key was derived as:
>=20
>  srtp_kdf_generate(&kdf, (uint64_t) label_rtcp_encryption,=20
> 		     tmp_key, cipher_get_key_length(srtp->rtcp_cipher));
> While SRTCP key was derived as:
>=20
>  srtp_kdf_generate(&kdf, (uint64_t) label_rtp_encryption,=20
> 		     tmp_key, cipher_get_key_length(srtp->rtp_cipher));
>=20
> And within the srtp_kdf_generate() function, the label is always assign=
ed to nonce.octet[7].
>=20
> Thanks!
>=20
> Guoqiang Lu
> ESN: 39-36277
> Phone: (613) 763-6277
> guoqian@nortel.com
> --------------------------
> The contents of the this e-mail may be Nortel Confidential!=20
>=20
>=20
> -----Original Message-----
> From: Karl Norrman (KI/EAB) [mailto:karl.norrman@ericsson.com]=20
> Sent: Thursday, July 21, 2005 5:47 AM
> To: Lu, Guoqiang [CAR:9D40:EXCH]
> Cc: mcgrew@cisco.com; Mats N=E4slund (KI/EAB); avt@ietf.org
> Subject: RE: [AVT] SRTCP key derivation
>=20
>=20
> Hello!
>=20
> The SRTCP index should not be padded with zeros to be 48 bits long.  Th=
is means that, e.g., the labels will not be in the same octet position fo=
r SRTP and SRTCP.
>=20
> Regards,
> Karl
>=20
>=20
>>-----Original Message-----
>>From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of=20
>>Guoqiang Lu
>>Sent: den 20 juli 2005 18:40
>>To: avt@ietf.org
>>Cc: mcgrew@cisco.com; Mats N=E4slund (KI/EAB)
>>Subject: [AVT] SRTCP key derivation
>>
>>
>>Hi,
>>In RFC3711, section 4.3.2. SRTCP Key Derivation, it says:
>>
>>"Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index ..."
>>
>>My question is that SRTP index is a 48-bit quantity, should
>>the SRTCP 32-bit quantity "0 || SRTCP index" be patched with=20
>>16 leading zeros?
>>
>>Thanks!
>>
>>Guoqiang Lu
>>ESN: 39-36277
>>Phone: (613) 763-6277
>>guoqian@nortel.com
>>--------------------------
>>The contents of the this e-mail may be Nortel Confidential!
>>
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>avt@ietf.org
>>https://www1.ietf.org/mailman/listinfo/avt
>>
--------------------------------------
Mats N=E4slund, PhD, Senior Specialist
Communications Security Lab
Ericsson Research
SE-16480 Stockholm, Sweden
Visiting adr: Torshamnsgatan 23, Kista
Phone/Fax: (+46 8) 58533739/4047020


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



From avt-bounces@ietf.org Sun Jul 24 01:57:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DwZUe-00031c-5M; Sun, 24 Jul 2005 01:57:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZUX-0002zl-T7
	for avt@megatron.ietf.org; Sun, 24 Jul 2005 01:57:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13609
	for <avt@ietf.org>; Sun, 24 Jul 2005 01:57:33 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwZz5-00043k-A3
	for avt@ietf.org; Sun, 24 Jul 2005 02:29:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Sun, 24 Jul 2005 08:57:42 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D898F@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAAAArXsuAAtQlFIA==
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Mundra, Satish" <smundra@ti.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Satish,

Sorry for response delay.=20

>From my point of view, the "draft-smundra-avt-rtp-red-non-audio-00.txt"
may be considered as a basic concept of redundancy transmission for
T.38-over-RTP. For T.38 applications, the timestamps "lose their
significance and sequence numbers as alone are of interest".

What is the status of this draft?

I have two main comments:

1. According to T.38, the marker bits of RFC 3550 are not used for T.38
over RTP. So, I suggest to declare the 'M' bit field in RFC 2198 as
optional for non-T.38 applications and reserved (=3D=3Dzero) for T.38.

2. The parameter 'level' is not enough for fax transfer. Usually, T.30
control packets (T.30 INDICATORs and T.30 control channel DATA) are
transmitted at one level (for example, 3), while TCF/image DATA packets
are transferred at the same or lower level (for example, 1). So, I
suggest one more parameter 'levelT30' for T.30 control packets. If
'levelT30' is not specified, the parameter 'level' is applied both for
T.30 control and TCF/image packets.

Some minor comments to the text declaring the need of new interpretation
of RFC 2198 for non-audio applications may be added if you are ready to
develop new version of the draft.=20

Regards,
Vladimir Ulybin

-----Original Message-----
From: Mundra, Satish [mailto:smundra@ti.com]=20
Sent: Wednesday, July 20, 2005 5:33 PM
To: Vladimir Ulybin
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Hi Vladimir,

I had submitted a draft(see attached) some time back addressing the need
for modified(simplified) redundancy mechanism=20
for non-audio data based on RTP sequence number alone. =20

There was not much interest/support from workgroup so this draft
expired.

RFC4103 adopted 2198 for use in text conversations by specifying some
additional rules for transmitter and receiver to overcome=20
some of the issues that you identify when one makes use of
audio-redundancy mechanism for non-audio data.=20



Regards,

Satish  =20

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20
> Behalf Of Vladimir Ulybin
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Paul E. Jones; Colin Perkins; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi,
>=20
> You are right. The play out concept of RFC 2198 is=20
> problematic for fax relay. Because, T.38 gateways do not play=20
> the buffers, but transmit according to T.30 standard.=20
> Generally, the fax rates may be different at two sides of=20
> communication, for example, 2400bps at calling fax side and=20
> 14400bps at answer fax side. Also T.30 control signals may=20
> have no synchronization between gateways, but should be=20
> synchronized with near fax machine.
>=20
> The problem of timestamps is not only our (AudioCodes)=20
> problem but is general for different vendors.
>=20
> The packet buffer of a gateway receiving T.38 packets has no=20
> any time mapping. The sequence number is the only ID of T.38=20
> packet. Combining sequence numbers with timestamps in packet=20
> recovery module is highly problematic for interoperability=20
> (and from my point of view is wrong for fax transfer).
>=20
> Unfortunately, typical gateways do not support a complex=20
> protocol RFC 2733. So, we cannot use it as a basic for our=20
> implementation.
>=20
> Thanks,
> Vladimir Ulybin
>=20
>=20
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Wednesday, July 20, 2005 10:49 AM
> To: Vladimir Ulybin
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi,
>=20
> I think a lot of the problems you are having is based on the=20
> fact you are using RFC 2198 for something it wasn't designed=20
> for. It was designed
>=20
> and works as intended for audio payloads that relies on a=20
> single data block (ADU) per timestamp. The formats that=20
> fulfill this can for synchronization and detecting duplicates=20
> rely solely on timestamp. It uses the RTP timestamp primarily=20
> to detect when discontinuous transmissions occur. RFC 2198=20
> doesn't have full sequence number recovery
>=20
> due to the fact that it wasn't needed for all the audio=20
> payloads one was
>=20
> considering to use. Also the solution RFC 2198 employs aren't=20
> suitable at all when the payloads become larger than half of the MTU.
>=20
> If you want sequence number recovery, less hassle with timestamps and
> so: Use RFC 2733 FEC resolves these issue. Or rather the=20
> updated version
>=20
> as RFC 2733 has some issues. Unfortunately we haven't=20
> finished this update yet, but we are getting close.
>=20
> Vladimir Ulybin wrote:
> > Let consider an option to update the
> "draft-jones-avt-audio-t38-05.txt"
> > or write a new draft for T.38 over RTP.
>=20
> This is an ITU defined RTP payload format. I agree that it=20
> has issues and some of them could have been avoided if ITU=20
> had involved AVT in the loop earlier when it was under=20
> proposal. However it is ITU that has change control of it.
>=20
> >=20
> > I think the problems opened in our discussions=20
> > - repetition of T.38 packets and=20
>=20
> If you are using RTP you have certain rules to follow. These=20
> involve the
>=20
> fact that packets can't be repeated using the same RTP=20
> sequence number.=20
> This requires solution like the RTP Retransmission format or=20
> the use of=20
> 2733 FEC.
>=20
> > - excessive complexity of T.38 over RTP caused by timestamps
> > (non-required by T.38)
>=20
> As Colin says RTP timestamps must be set in RTP. However one can make=20
> them simple to only indicate time of transmission. This would=20
> be simpler
>=20
> if people hadn't insisted on making it go over the same RTP=20
> session as=20
> audio. FAX isn't audio and it shouldn't be handled the same=20
> way as audio
>=20
> packets. Thus it should go in its own RTP session where it=20
> can be given=20
> somewhat different treatment. Yes, audio/t38 should in fact=20
> be image/t38
>=20
> or possibly application/t38.
>=20
> Then as I said, stop using RFC 2198 and your timestamp issues mostly=20
> goes away.
>=20
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> 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
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>=20

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



From avt-bounces@ietf.org Sun Jul 24 02:31:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dwa1c-0001uw-Oe; Sun, 24 Jul 2005 02:31:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwa1Z-0001ur-TX
	for avt@megatron.ietf.org; Sun, 24 Jul 2005 02:31:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06709
	for <avt@ietf.org>; Sun, 24 Jul 2005 02:31:43 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwaW9-0004qp-8a
	for avt@ietf.org; Sun, 24 Jul 2005 03:03:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Sun, 24 Jul 2005 09:32:02 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D89A6@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAAAA4BYjAAtGbsEA==
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
Content-Transfer-Encoding: quoted-printable
Cc: Colin Perkins <csp@csperkins.org>, "Mundra, Satish" <smundra@ti.com>,
	avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi, and sorry for delay.

Paul,

The problem is that timestamps cannot help to recover lost T.38 packets,
and do not have a principle meaning for fax transfer, but as I see from
discussion may cause many conflicts of different vendors of gateways in
a field of how transmit and to use the timestamps.=20

What you wrote about timestamps is right while everything is O.K.
(behavior is close to audio, no packet loss) or the same vendor gateways
communicate T.38 over RTP.

The following examples show possible conflicts and disadvantages of
applying timestamps.

Example 1:
A T.38 gateway periodically transmits groups of consecutive packets
having the same timestamp. There may be some reasons of such
transmission; one is the case when a datagram size of receiving gateway
is smaller than working frame size of transmitting gateway; the other is
the case when transmitting gateway does not concatenate small fax
packets into complex packets, so some events are possible at one moment
of time, etc.
Applying timestamps for this case at the stage of receiving from IP will
cause an overwriting of one packet by the next packet with zero time
offset, and as a result the failure of fax transfer even the packet loss
is absent.

Example 2:
A gateway may receive a correct packet sequence (no violations in
sequence number) but incorrect timestamp offsets. As well the gateway
may receive wrong packet sequence but a correct timestamp sequence.=20
What is the guarantee that a receiving gateway will handle normally all
packets in the first case and enter packet recovery in the second case?
If timestamps are mandatory for consideration, then there is no such a
guarantee.

We may avoid all conflicts and improve reliability of fax transfer if
declare that the RTP sequence number is the main ID that is useful for
T.38 over RTP.=20

The concept suggested by Satish satisfies requirements of T.38 fax
transfer over RTP much better than the regular RFC 2198. It is more
reliable, better for interoperability, and does not require a too high
tax for transition from T.38 UDPTL to T.38 over RTP.

Regards,
Vladimir Ulybin


-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Wednesday, July 20, 2005 7:06 PM
To: Vladimir Ulybin; 'Magnus Westerlund'
Cc: 'Colin Perkins'; avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

Forget RFC 2198 for a moment.  You're going to sample the audio, you
will
extract T.30 information from that audio, you will form an RTP packet
using
the time from the clock that is necessarily running.

As Packets arrive, you can do what you want with the timestamps, but
they
can certainly be used for ordering packets if you want or they can be
largely ignored.

Now, if you add RFC 2198 to the picture, you are simply re-transmitting
the
media from a previous packet in the current packet.  The timestamp was
in
the previous packet and the current packet simply has an offset to it.
When
it arrives, you can determine the order of packets.  Isn't that all you
need?

Honestly, I do not see why this is causing such a problem.  I will not
disagree that an alternative (e.g., UDPTL) might be more fitting as it
does
not have timestamps, but as Colin pointing out: it's an RTP tax.  But,
you
get benefits with that tax, including security, RTCP, RTCP-XR, etc.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Wednesday, July 20, 2005 5:51 AM
> To: Magnus Westerlund
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi,
>=20
> You are right. The play out concept of RFC 2198 is problematic for fax
> relay. Because, T.38 gateways do not play the buffers, but transmit
> according to T.30 standard. Generally, the fax rates may be different
at
> two sides of communication, for example, 2400bps at calling fax side
and
> 14400bps at answer fax side. Also T.30 control signals may have no
> synchronization between gateways, but should be synchronized with near
> fax machine.
>=20
> The problem of timestamps is not only our (AudioCodes) problem but is
> general for different vendors.
>=20
> The packet buffer of a gateway receiving T.38 packets has no any time
> mapping. The sequence number is the only ID of T.38 packet. Combining
> sequence numbers with timestamps in packet recovery module is highly
> problematic for interoperability (and from my point of view is wrong
for
> fax transfer).
>=20
> Unfortunately, typical gateways do not support a complex protocol RFC
> 2733. So, we cannot use it as a basic for our implementation.
>=20
> Thanks,
> Vladimir Ulybin
>=20
>=20
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Wednesday, July 20, 2005 10:49 AM
> To: Vladimir Ulybin
> Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi,
>=20
> I think a lot of the problems you are having is based on the fact you
> are using RFC 2198 for something it wasn't designed for. It was
designed
>=20
> and works as intended for audio payloads that relies on a single data
> block (ADU) per timestamp. The formats that fulfill this can for
> synchronization and detecting duplicates rely solely on timestamp. It
> uses the RTP timestamp primarily to detect when discontinuous
> transmissions occur. RFC 2198 doesn't have full sequence number
recovery
>=20
> due to the fact that it wasn't needed for all the audio payloads one
was
>=20
> considering to use. Also the solution RFC 2198 employs aren't suitable
> at all when the payloads become larger than half of the MTU.
>=20
> If you want sequence number recovery, less hassle with timestamps and
> so: Use RFC 2733 FEC resolves these issue. Or rather the updated
version
>=20
> as RFC 2733 has some issues. Unfortunately we haven't finished this
> update yet, but we are getting close.
>=20
> Vladimir Ulybin wrote:
> > Let consider an option to update the
> "draft-jones-avt-audio-t38-05.txt"
> > or write a new draft for T.38 over RTP.
>=20
> This is an ITU defined RTP payload format. I agree that it has issues
> and some of them could have been avoided if ITU had involved AVT in
the
> loop earlier when it was under proposal. However it is ITU that has
> change control of it.
>=20
> >
> > I think the problems opened in our discussions
> > - repetition of T.38 packets and
>=20
> If you are using RTP you have certain rules to follow. These involve
the
>=20
> fact that packets can't be repeated using the same RTP sequence
number.
> This requires solution like the RTP Retransmission format or the use
of
> 2733 FEC.
>=20
> > - excessive complexity of T.38 over RTP caused by timestamps
> > (non-required by T.38)
>=20
> As Colin says RTP timestamps must be set in RTP. However one can make
> them simple to only indicate time of transmission. This would be
simpler
>=20
> if people hadn't insisted on making it go over the same RTP session as
> audio. FAX isn't audio and it shouldn't be handled the same way as
audio
>=20
> packets. Thus it should go in its own RTP session where it can be
given
> somewhat different treatment. Yes, audio/t38 should in fact be
image/t38
>=20
> or possibly application/t38.
>=20
> Then as I said, stop using RFC 2198 and your timestamp issues mostly
> goes away.
>=20
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> 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 avt-bounces@ietf.org Sun Jul 24 11:44:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DwieY-0008Q7-R2; Sun, 24 Jul 2005 11:44:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DwieW-0008Pz-SB
	for avt@megatron.ietf.org; Sun, 24 Jul 2005 11:44:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05121
	for <avt@ietf.org>; Sun, 24 Jul 2005 11:44:30 -0400 (EDT)
Received: from rrcs-24-199-146-6.midsouth.biz.rr.com
	([24.199.146.6] helo=berlin.arid.us ident=system)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwj9C-00066n-Ky
	for avt@ietf.org; Sun, 24 Jul 2005 12:16:15 -0400
Received: from madrid (madrid.arid.us [192.168.1.10])
	by berlin.arid.us (8.12.8/8.12.8) with ESMTP id j6OFi7SA014842;
	Sun, 24 Jul 2005 11:44:07 -0400
Message-Id: <200507241544.j6OFi7SA014842@berlin.arid.us>
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Vladimir Ulybin'" <Vladimir@audiocodes.com>,
	"'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
Date: Sun, 24 Jul 2005 11:42:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
thread-index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAAAA4BYjAAtGbsEAATtaBg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D89A6@aclmsg.corp.audiocodes.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
Content-Transfer-Encoding: 7bit
Cc: 'Colin Perkins' <csp@csperkins.org>, "'Mundra, Satish'" <smundra@ti.com>,
	avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Vladimir,

I must still be missing the point.  If a piece of T.38 information is placed
into any RTP packet, there is a timestamp.  I don't see why two RTP packets
would have the same timestamp.  Bits of fax information is relatively small.
Packets may be received and ordered by those timestamps, as far as I can
see.

Now, if you add RFC 2198 to the picture, it is simply re-sending the
previously transmitted pieces of information.  I don't see how this can be
confusing, though I certainly agree that the timestamps are probably not so
important for T.38.

In any case, I'm not arguing against Satish's draft.  It may be a preferred
mode and, if so, then hopefully it will be progressed further and we could
certainly have that as an option.  The T.38 spec does not suggest a
preference for RFC 2198, RFC 2733, or any other mode.  They're listed as
options, because they're available options.  If another option is made
available, that could certainly be added, too.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Sunday, July 24, 2005 2:32 AM
> To: Paul E. Jones; Magnus Westerlund
> Cc: Colin Perkins; Mundra, Satish; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Hi, and sorry for delay.
> 
> Paul,
> 
> The problem is that timestamps cannot help to recover lost T.38 packets,
> and do not have a principle meaning for fax transfer, but as I see from
> discussion may cause many conflicts of different vendors of gateways in
> a field of how transmit and to use the timestamps.
> 
> What you wrote about timestamps is right while everything is O.K.
> (behavior is close to audio, no packet loss) or the same vendor gateways
> communicate T.38 over RTP.
> 
> The following examples show possible conflicts and disadvantages of
> applying timestamps.
> 
> Example 1:
> A T.38 gateway periodically transmits groups of consecutive packets
> having the same timestamp. There may be some reasons of such
> transmission; one is the case when a datagram size of receiving gateway
> is smaller than working frame size of transmitting gateway; the other is
> the case when transmitting gateway does not concatenate small fax
> packets into complex packets, so some events are possible at one moment
> of time, etc.
> Applying timestamps for this case at the stage of receiving from IP will
> cause an overwriting of one packet by the next packet with zero time
> offset, and as a result the failure of fax transfer even the packet loss
> is absent.
> 
> Example 2:
> A gateway may receive a correct packet sequence (no violations in
> sequence number) but incorrect timestamp offsets. As well the gateway
> may receive wrong packet sequence but a correct timestamp sequence.
> What is the guarantee that a receiving gateway will handle normally all
> packets in the first case and enter packet recovery in the second case?
> If timestamps are mandatory for consideration, then there is no such a
> guarantee.
> 
> We may avoid all conflicts and improve reliability of fax transfer if
> declare that the RTP sequence number is the main ID that is useful for
> T.38 over RTP.
> 
> The concept suggested by Satish satisfies requirements of T.38 fax
> transfer over RTP much better than the regular RFC 2198. It is more
> reliable, better for interoperability, and does not require a too high
> tax for transition from T.38 UDPTL to T.38 over RTP.
> 
> Regards,
> Vladimir Ulybin
> 
> 
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Wednesday, July 20, 2005 7:06 PM
> To: Vladimir Ulybin; 'Magnus Westerlund'
> Cc: 'Colin Perkins'; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> 
> Vladimir,
> 
> Forget RFC 2198 for a moment.  You're going to sample the audio, you
> will
> extract T.30 information from that audio, you will form an RTP packet
> using
> the time from the clock that is necessarily running.
> 
> As Packets arrive, you can do what you want with the timestamps, but
> they
> can certainly be used for ordering packets if you want or they can be
> largely ignored.
> 
> Now, if you add RFC 2198 to the picture, you are simply re-transmitting
> the
> media from a previous packet in the current packet.  The timestamp was
> in
> the previous packet and the current packet simply has an offset to it.
> When
> it arrives, you can determine the order of packets.  Isn't that all you
> need?
> 
> Honestly, I do not see why this is causing such a problem.  I will not
> disagree that an alternative (e.g., UDPTL) might be more fitting as it
> does
> not have timestamps, but as Colin pointing out: it's an RTP tax.  But,
> you
> get benefits with that tax, including security, RTCP, RTCP-XR, etc.
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> > Sent: Wednesday, July 20, 2005 5:51 AM
> > To: Magnus Westerlund
> > Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Hi,
> >
> > You are right. The play out concept of RFC 2198 is problematic for fax
> > relay. Because, T.38 gateways do not play the buffers, but transmit
> > according to T.30 standard. Generally, the fax rates may be different
> at
> > two sides of communication, for example, 2400bps at calling fax side
> and
> > 14400bps at answer fax side. Also T.30 control signals may have no
> > synchronization between gateways, but should be synchronized with near
> > fax machine.
> >
> > The problem of timestamps is not only our (AudioCodes) problem but is
> > general for different vendors.
> >
> > The packet buffer of a gateway receiving T.38 packets has no any time
> > mapping. The sequence number is the only ID of T.38 packet. Combining
> > sequence numbers with timestamps in packet recovery module is highly
> > problematic for interoperability (and from my point of view is wrong
> for
> > fax transfer).
> >
> > Unfortunately, typical gateways do not support a complex protocol RFC
> > 2733. So, we cannot use it as a basic for our implementation.
> >
> > Thanks,
> > Vladimir Ulybin
> >
> >
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> > Sent: Wednesday, July 20, 2005 10:49 AM
> > To: Vladimir Ulybin
> > Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> > Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Hi,
> >
> > I think a lot of the problems you are having is based on the fact you
> > are using RFC 2198 for something it wasn't designed for. It was
> designed
> >
> > and works as intended for audio payloads that relies on a single data
> > block (ADU) per timestamp. The formats that fulfill this can for
> > synchronization and detecting duplicates rely solely on timestamp. It
> > uses the RTP timestamp primarily to detect when discontinuous
> > transmissions occur. RFC 2198 doesn't have full sequence number
> recovery
> >
> > due to the fact that it wasn't needed for all the audio payloads one
> was
> >
> > considering to use. Also the solution RFC 2198 employs aren't suitable
> > at all when the payloads become larger than half of the MTU.
> >
> > If you want sequence number recovery, less hassle with timestamps and
> > so: Use RFC 2733 FEC resolves these issue. Or rather the updated
> version
> >
> > as RFC 2733 has some issues. Unfortunately we haven't finished this
> > update yet, but we are getting close.
> >
> > Vladimir Ulybin wrote:
> > > Let consider an option to update the
> > "draft-jones-avt-audio-t38-05.txt"
> > > or write a new draft for T.38 over RTP.
> >
> > This is an ITU defined RTP payload format. I agree that it has issues
> > and some of them could have been avoided if ITU had involved AVT in
> the
> > loop earlier when it was under proposal. However it is ITU that has
> > change control of it.
> >
> > >
> > > I think the problems opened in our discussions
> > > - repetition of T.38 packets and
> >
> > If you are using RTP you have certain rules to follow. These involve
> the
> >
> > fact that packets can't be repeated using the same RTP sequence
> number.
> > This requires solution like the RTP Retransmission format or the use
> of
> > 2733 FEC.
> >
> > > - excessive complexity of T.38 over RTP caused by timestamps
> > > (non-required by T.38)
> >
> > As Colin says RTP timestamps must be set in RTP. However one can make
> > them simple to only indicate time of transmission. This would be
> simpler
> >
> > if people hadn't insisted on making it go over the same RTP session as
> > audio. FAX isn't audio and it shouldn't be handled the same way as
> audio
> >
> > packets. Thus it should go in its own RTP session where it can be
> given
> > somewhat different treatment. Yes, audio/t38 should in fact be
> image/t38
> >
> > or possibly application/t38.
> >
> > Then as I said, stop using RFC 2198 and your timestamp issues mostly
> > goes away.
> >
> >
> > 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 avt-bounces@ietf.org Mon Jul 25 04:52:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DwyhD-0003dD-Md; Mon, 25 Jul 2005 04:52:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyhC-0003d8-BQ
	for avt@megatron.ietf.org; Mon, 25 Jul 2005 04:52:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28701
	for <avt@ietf.org>; Mon, 25 Jul 2005 04:52:20 -0400 (EDT)
Received: from cluster-d.mailcontrol.com ([217.69.20.190]
	helo=rly11d.srv.mailcontrol.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwzBz-000179-57
	for avt@ietf.org; Mon, 25 Jul 2005 05:24:13 -0400
Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12])
	by rly11d.srv.mailcontrol.com (MailControl) with SMTP id
	j6P8q1vV013259; Mon, 25 Jul 2005 09:52:01 +0100
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
	smtp id 205f_92b84698_fce9_11d9_825d_0030482aac25;
	Mon, 25 Jul 2005 10:53:30 +0200
Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55])
	by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
	with ESMTP id 2005072510515762-98551 ;
	Mon, 25 Jul 2005 10:51:57 +0200 
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de;
	Mon, 25 Jul 2005 10:53:37 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Mon, 25 Jul 2005 10:48:24 +0200
Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F31EA7D@lan-ex-01.panasonic.de>
Thread-Topic: implementation
Thread-Index: AcWQ9Oc3A6b5ReJdQYGkoctZdzzLxwAAFSsg
To: "Mark Mumo" <markmumo@24interactive.net>, <david.leon@nokia.com>
From: "Jose Rey" <Jose.Rey@eu.panasonic.com>
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MailControl A-05-01-05 (www.mailcontrol.com)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: quoted-printable
Cc: avt@ietf.org
Subject: [AVT] RE: implementation
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Mark,

I don't know of any.  There are some Java implementations of RTP (c.f., =
Google) but it seems they don't have retransmission yet.

Cheers,

Jos=E9
=20
=20


________________________________

	From: Mark Mumo [mailto:markmumo@24interactive.net]=20
	Sent: Tuesday, July 25, 2006 10:44 AM
	To: Jose Rey; david.leon@nokia.com
	Cc: avt@ietf.org
	Subject: implementation
=09
=09
	Hi,
	Are there any implementation of RTP retransmission in java?
	=20
	Thanks
	=20
	Mark



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



From avt-bounces@ietf.org Mon Jul 25 05:36:22 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DwzNm-0002Ew-NK; Mon, 25 Jul 2005 05:36:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DwzNl-0002Er-9g
	for avt@megatron.ietf.org; Mon, 25 Jul 2005 05:36:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01222
	for <avt@ietf.org>; Mon, 25 Jul 2005 05:36:18 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwzsZ-0002Oq-J8
	for avt@ietf.org; Mon, 25 Jul 2005 06:08:12 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number
Date: Mon, 25 Jul 2005 12:36:25 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D8D9B@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number
Thread-Index: AcWM/5BSBZvQV+2NTv61EoQySAKxDAADFSAAAA4BYjAAtGbsEAATtaBgAB8R0TA=
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "Paul E. Jones" <paulej@packetizer.com>,
	"Magnus Westerlund" <magnus.westerlund@ericsson.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595
Content-Transfer-Encoding: quoted-printable
Cc: Colin Perkins <csp@csperkins.org>, "Mundra, Satish" <smundra@ti.com>,
	avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Paul,

First of all, the RFC 3550 allows groups of consecutive packets with the
same timestamp: "Several consecutive RTP packets will have equal
timestamps if they are (logically) generated at once". So, T.38 gateway
should be able to receive correctly such sequences.

Second, simple examples of the case when some T.38 packets may have the
same timestamp:
1. The command "hdlc-fcs-OK-sig-end" may be sent as a single packet or
as two consecutive packets "hdlc-fcs-OK" and "hdlc-sig-end" generated at
once.=20
2. The command "hdlc-fcs-OK" followed by "hdlc-data" may be sent as one
complex primary packet or as two consecutive packets generated at once.

And I may give more examples.

I agree with you, that current standards do not make "preference for RFC
2198, RFC 2733, or any other mode".=20

It is our local preference of RFC 2198 for T.38-over-RTP, because it is
similar to T.38 UDPTL with secondary fax packets. The problem is in
strict confinements by timestamps which are not used in fax relay, do
not give any gain in reliability, and require so many changes that cause
us not to use RFC 2198 as is for fax.

The "draft-smundra-avt-rtp-red-non-audio-00.txt", by Satish Mundra,
solves all these problems, because it assigns a highest priority to
sequence numbers similarly to T.38 UDPTL and applies sequence number
offsets in RFC 2198 instead of timestamp offsets. This extension of RFC
2198 is simply convertible into T.38 UDPTL and back.

Our questions:
1. Can we use "draft-smundra-avt-rtp-red-non-audio-00.txt"?=20
2. Is it possible to include this extension in RFC 2198 or generate new
RFC 2198bis taking into account this draft?

Thanks,
Vladimir Ulybin

-----Original Message-----
From: Paul E. Jones [mailto:paulej@packetizer.com]=20
Sent: Sunday, July 24, 2005 6:42 PM
To: Vladimir Ulybin; 'Magnus Westerlund'
Cc: 'Colin Perkins'; 'Mundra, Satish'; avt@ietf.org
Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number

Vladimir,

I must still be missing the point.  If a piece of T.38 information is
placed
into any RTP packet, there is a timestamp.  I don't see why two RTP
packets
would have the same timestamp.  Bits of fax information is relatively
small.
Packets may be received and ordered by those timestamps, as far as I can
see.

Now, if you add RFC 2198 to the picture, it is simply re-sending the
previously transmitted pieces of information.  I don't see how this can
be
confusing, though I certainly agree that the timestamps are probably not
so
important for T.38.

In any case, I'm not arguing against Satish's draft.  It may be a
preferred
mode and, if so, then hopefully it will be progressed further and we
could
certainly have that as an option.  The T.38 spec does not suggest a
preference for RFC 2198, RFC 2733, or any other mode.  They're listed as
options, because they're available options.  If another option is made
available, that could certainly be added, too.

Paul


> -----Original Message-----
> From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> Sent: Sunday, July 24, 2005 2:32 AM
> To: Paul E. Jones; Magnus Westerlund
> Cc: Colin Perkins; Mundra, Satish; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Hi, and sorry for delay.
>=20
> Paul,
>=20
> The problem is that timestamps cannot help to recover lost T.38
packets,
> and do not have a principle meaning for fax transfer, but as I see
from
> discussion may cause many conflicts of different vendors of gateways
in
> a field of how transmit and to use the timestamps.
>=20
> What you wrote about timestamps is right while everything is O.K.
> (behavior is close to audio, no packet loss) or the same vendor
gateways
> communicate T.38 over RTP.
>=20
> The following examples show possible conflicts and disadvantages of
> applying timestamps.
>=20
> Example 1:
> A T.38 gateway periodically transmits groups of consecutive packets
> having the same timestamp. There may be some reasons of such
> transmission; one is the case when a datagram size of receiving
gateway
> is smaller than working frame size of transmitting gateway; the other
is
> the case when transmitting gateway does not concatenate small fax
> packets into complex packets, so some events are possible at one
moment
> of time, etc.
> Applying timestamps for this case at the stage of receiving from IP
will
> cause an overwriting of one packet by the next packet with zero time
> offset, and as a result the failure of fax transfer even the packet
loss
> is absent.
>=20
> Example 2:
> A gateway may receive a correct packet sequence (no violations in
> sequence number) but incorrect timestamp offsets. As well the gateway
> may receive wrong packet sequence but a correct timestamp sequence.
> What is the guarantee that a receiving gateway will handle normally
all
> packets in the first case and enter packet recovery in the second
case?
> If timestamps are mandatory for consideration, then there is no such a
> guarantee.
>=20
> We may avoid all conflicts and improve reliability of fax transfer if
> declare that the RTP sequence number is the main ID that is useful for
> T.38 over RTP.
>=20
> The concept suggested by Satish satisfies requirements of T.38 fax
> transfer over RTP much better than the regular RFC 2198. It is more
> reliable, better for interoperability, and does not require a too high
> tax for transition from T.38 UDPTL to T.38 over RTP.
>=20
> Regards,
> Vladimir Ulybin
>=20
>=20
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej@packetizer.com]
> Sent: Wednesday, July 20, 2005 7:06 PM
> To: Vladimir Ulybin; 'Magnus Westerlund'
> Cc: 'Colin Perkins'; avt@ietf.org
> Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
>=20
> Vladimir,
>=20
> Forget RFC 2198 for a moment.  You're going to sample the audio, you
> will
> extract T.30 information from that audio, you will form an RTP packet
> using
> the time from the clock that is necessarily running.
>=20
> As Packets arrive, you can do what you want with the timestamps, but
> they
> can certainly be used for ordering packets if you want or they can be
> largely ignored.
>=20
> Now, if you add RFC 2198 to the picture, you are simply
re-transmitting
> the
> media from a previous packet in the current packet.  The timestamp was
> in
> the previous packet and the current packet simply has an offset to it.
> When
> it arrives, you can determine the order of packets.  Isn't that all
you
> need?
>=20
> Honestly, I do not see why this is causing such a problem.  I will not
> disagree that an alternative (e.g., UDPTL) might be more fitting as it
> does
> not have timestamps, but as Colin pointing out: it's an RTP tax.  But,
> you
> get benefits with that tax, including security, RTCP, RTCP-XR, etc.
>=20
> Paul
>=20
>=20
> > -----Original Message-----
> > From: Vladimir Ulybin [mailto:Vladimir@audiocodes.com]
> > Sent: Wednesday, July 20, 2005 5:51 AM
> > To: Magnus Westerlund
> > Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> > Subject: RE: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Hi,
> >
> > You are right. The play out concept of RFC 2198 is problematic for
fax
> > relay. Because, T.38 gateways do not play the buffers, but transmit
> > according to T.30 standard. Generally, the fax rates may be
different
> at
> > two sides of communication, for example, 2400bps at calling fax side
> and
> > 14400bps at answer fax side. Also T.30 control signals may have no
> > synchronization between gateways, but should be synchronized with
near
> > fax machine.
> >
> > The problem of timestamps is not only our (AudioCodes) problem but
is
> > general for different vendors.
> >
> > The packet buffer of a gateway receiving T.38 packets has no any
time
> > mapping. The sequence number is the only ID of T.38 packet.
Combining
> > sequence numbers with timestamps in packet recovery module is highly
> > problematic for interoperability (and from my point of view is wrong
> for
> > fax transfer).
> >
> > Unfortunately, typical gateways do not support a complex protocol
RFC
> > 2733. So, we cannot use it as a basic for our implementation.
> >
> > Thanks,
> > Vladimir Ulybin
> >
> >
> > -----Original Message-----
> > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> > Sent: Wednesday, July 20, 2005 10:49 AM
> > To: Vladimir Ulybin
> > Cc: Colin Perkins; Paul E. Jones; avt@ietf.org
> > Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
> >
> > Hi,
> >
> > I think a lot of the problems you are having is based on the fact
you
> > are using RFC 2198 for something it wasn't designed for. It was
> designed
> >
> > and works as intended for audio payloads that relies on a single
data
> > block (ADU) per timestamp. The formats that fulfill this can for
> > synchronization and detecting duplicates rely solely on timestamp.
It
> > uses the RTP timestamp primarily to detect when discontinuous
> > transmissions occur. RFC 2198 doesn't have full sequence number
> recovery
> >
> > due to the fact that it wasn't needed for all the audio payloads one
> was
> >
> > considering to use. Also the solution RFC 2198 employs aren't
suitable
> > at all when the payloads become larger than half of the MTU.
> >
> > If you want sequence number recovery, less hassle with timestamps
and
> > so: Use RFC 2733 FEC resolves these issue. Or rather the updated
> version
> >
> > as RFC 2733 has some issues. Unfortunately we haven't finished this
> > update yet, but we are getting close.
> >
> > Vladimir Ulybin wrote:
> > > Let consider an option to update the
> > "draft-jones-avt-audio-t38-05.txt"
> > > or write a new draft for T.38 over RTP.
> >
> > This is an ITU defined RTP payload format. I agree that it has
issues
> > and some of them could have been avoided if ITU had involved AVT in
> the
> > loop earlier when it was under proposal. However it is ITU that has
> > change control of it.
> >
> > >
> > > I think the problems opened in our discussions
> > > - repetition of T.38 packets and
> >
> > If you are using RTP you have certain rules to follow. These involve
> the
> >
> > fact that packets can't be repeated using the same RTP sequence
> number.
> > This requires solution like the RTP Retransmission format or the use
> of
> > 2733 FEC.
> >
> > > - excessive complexity of T.38 over RTP caused by timestamps
> > > (non-required by T.38)
> >
> > As Colin says RTP timestamps must be set in RTP. However one can
make
> > them simple to only indicate time of transmission. This would be
> simpler
> >
> > if people hadn't insisted on making it go over the same RTP session
as
> > audio. FAX isn't audio and it shouldn't be handled the same way as
> audio
> >
> > packets. Thus it should go in its own RTP session where it can be
> given
> > somewhat different treatment. Yes, audio/t38 should in fact be
> image/t38
> >
> > or possibly application/t38.
> >
> > Then as I said, stop using RFC 2198 and your timestamp issues mostly
> > goes away.
> >
> >
> > 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 avt-bounces@ietf.org Mon Jul 25 07:18:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx0yR-000435-V1; Mon, 25 Jul 2005 07:18:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx0yP-000424-Lj
	for avt@megatron.ietf.org; Mon, 25 Jul 2005 07:18:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07478
	for <avt@ietf.org>; Mon, 25 Jul 2005 07:18:15 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx1TC-0005bB-3u
	for avt@ietf.org; Mon, 25 Jul 2005 07:50:10 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	421654F0001; Mon, 25 Jul 2005 13:18:12 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 25 Jul 2005 13:18:10 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 25 Jul 2005 13:18:10 +0200
Message-ID: <42E4CA71.4040509@ericsson.com>
Date: Mon, 25 Jul 2005 13:18:09 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vladimir Ulybin <Vladimir@audiocodes.com>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
References: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D8D9B@aclmsg.corp.audiocodes.com>
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D8D9B@aclmsg.corp.audiocodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jul 2005 11:18:10.0355 (UTC)
	FILETIME=[8A28B030:01C5910A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: "Paul E. Jones" <paulej@packetizer.com>, Colin Perkins <csp@csperkins.org>,
	"Mundra, Satish" <smundra@ti.com>, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

It is the RTP payload format that specifies the definite rules of the 
RTP timestamp, which must be following the basic RFC 3550 rules. So it 
is very reasonable to specify a limitation that RTP payloads shall not 
use the same timestamp. That is for example done for T.140. If that is 
not done and instead it is actually expected that the RTP timestamp 
becomes the same for packets. Then RFC 2198 is clearly not applicable 
for the RTP payload format.

To me it seems that the T.38 defined RTP payload format specification 
needs some updates to clarify these things. It might also be appropriate 
to recommend one and only one robustness mechanism. And that being a 
mechanism that works for the payload format.

However please remember that you must stay within the ground rules of 
RTP. For example defining the marker bit strangely may not be the 
wisest. At least not as long as it is within an audio RTP session.

cheers

Magnus

PS.
Please remove parts of previous emails that you are not refering to. 
That way the email is simpler to read and waste less storage space.
DS.


-- 

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 avt-bounces@ietf.org Mon Jul 25 11:53:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx5GO-0001WM-N2; Mon, 25 Jul 2005 11:53:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5GM-0001UF-QS
	for avt@megatron.ietf.org; Mon, 25 Jul 2005 11:53:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01902
	for <avt@ietf.org>; Mon, 25 Jul 2005 11:53:04 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx5lC-0007W1-5r
	for avt@ietf.org; Mon, 25 Jul 2005 12:25:01 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73])
	(authenticated bits=0)
	by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id
	j6PFqwjY026265
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
	for <avt@ietf.org>; Mon, 25 Jul 2005 08:52:58 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v733)
Content-Transfer-Encoding: 7bit
Message-Id: <B5F30E8B-E9FA-49CF-B42E-5274A3E1DC47@eecs.berkeley.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: avt@ietf.org
From: lazzaro <lazzaro@eecs.berkeley.edu>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number 
Date: Mon, 25 Jul 2005 08:53:43 -0700
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


Magnus Westerlund <magnus.westerlund at ericsson.com> writes:
> However please remember that you must stay within the ground rules  
> of RTP. For example defining the marker bit strangely may not be  
> the wisest. At least not as long as it is within an audio RTP session.


Indeed -- the unusual use of the marker bit in
mpeg4-generic led to the only bit-level incompatibility
between native RTP MIDI and mpeg4-generic
encapsulated RTP MIDI ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



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



From avt-bounces@ietf.org Mon Jul 25 13:38:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx6tv-0000VN-PW; Mon, 25 Jul 2005 13:38:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx6tt-0000Uo-5M; Mon, 25 Jul 2005 13:38:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09386;
	Mon, 25 Jul 2005 13:37:58 -0400 (EDT)
Received: from mail126.messagelabs.com ([216.82.254.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1Dx7Ok-0002PE-PQ; Mon, 25 Jul 2005 14:09:56 -0400
X-VirusChecked: Checked
X-Env-Sender: gash@att.com
X-Msg-Ref: server-11.tower-126.messagelabs.com!1122312994!4553309!21
X-StarScan-Version: 5.4.15; banners=-,-,-
X-Originating-IP: [192.128.133.132]
Received: (qmail 7021 invoked from network); 25 Jul 2005 17:37:44 -0000
Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132)
	by server-11.tower-126.messagelabs.com with SMTP;
	25 Jul 2005 17:37:44 -0000
Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by
	attrh3i.attrh.att.com (7.2.052)
	id 42E3BC2B0001ED6B; Mon, 25 Jul 2005 13:37:44 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 25 Jul 2005 12:37:44 -0500
Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE694@KCCLUST06EVS1.ugd.att.com>
Thread-Topic: draft-ash-avt-hc-over-mpls-protocol-01.txt
Thread-Index: AcWRMcSV9mx5chWkR/u+Vy5Vq6w29gABbnKw
From: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
To: "Stewart Bryant" <stbryant@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Content-Transfer-Encoding: quoted-printable
Cc: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>, pwe3 <pwe3@ietf.org>,
	avt@ietf.org
Subject: [AVT] RE: draft-ash-avt-hc-over-mpls-protocol-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Stewart,

Thanks a lot for your comments and suggestions.

>     In the example scenario, header compression therefore takes place
>     between R1 and R4, and the MPLS path transports
>     data/compressed-header/MPLS-labels instead of
>     data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.
>=20
> SB> You claim a size reduction but at this stage you have not
> SB> said what the MPLS stack looks like. I assume that you have
> SB> two labels, and as I recall you have just the 000 nibble not
> SB> the control word.

Right, we should clarify that we have (typically) 2 MPLS labels and a PW
Control Octet.
=20
>     The MPLS label stack and link-layer headers are not compressed. =20
>     Therefore HC  over MPLS can significantly reduce the header
>     overhead through compression mechanisms.
>=20
>     MPLS is used to route HC packets over an MPLS LSP without
>     compression/decompression cycles at each intermediate=20
>     router.  MPLS pseudowires (PWs)
>
>     SB> perhaps a reference?

OK, we can reference the PW architecture
http://ietf.org/rfc/rfc3985.txt.

>                                     8 octets              V
>
+------+----------------------------+
>                         MPLS Labels |header|
|
>
+------+----------------------------+
>
\__________________________________/
>                                                       V
>=20
> SB> The above is technically two layers - the PW ident and the CE
> SB> identifier. You may have other MPLS labels for example if you are
> SB> going over a VPN.

OK, we'll clarify in next revision.
=20
>     The PW control octet is used to identify the packet types=20
>     for certain HC schemes, including cTCP [RFC1144], IPHC
>     [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as
>     detailed in Section 4.2.
>=20
> SB> You should call up <draft-ietf-mpls-ecmp-bcp-01.txt> and
> SB> perhaps <draft-ietf-pwe3-cw-05.txt> to explain why your bytes
> SB> start with zero.

OK, we can reference [ECMP-AVOID] and [PW-CNTL-WORD] here as well in in
Section 4.2.
=20
>     Note that ROHC [RFC3095] provides its own packet type within
>     the protocol, and does not require use of the PW control
>     octet.
>=20
> SB> see above
>=20
>
> 4. Protocol Specifications
>=20
>     In Figure 1 we assume an example data flow set up from R1/HC -->
>     R2 --> R3 --> R4/HD, where R1/HC is the ingress router where
>     header compression is performed, and R4/HD is the egress router=20
>     where header decompression is done.  Each router functions as an
>     LSR and supports signaling of LSP/PWs.  A summary of the
>     procedures is as follows:
>=20
>=20
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Sub-TLV Type  |    Length     |    Variable Length Value      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Variable Length Value                 |
>     |                             "                                 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>             Figure 4 - PW Interface Parameters Sub-TLV
>=20
> SB> Do you need to copy this - wouldn't it be better to just reference
> SB> the definitive copy in the PW control RFC - just in case any typos
> SB> creep in?

OK, we can remove Figure 4 and just reference [PW-SIG].

>     Figure 3 shows the HC over MPLS protocol stack.  The PW=20
>     control octet is used to identify the packet types for
>     certain HC schemes, including cTCP [RFC1144], IPHC
>     [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown
>     in Figure 5:
>=20
>=20
>                               0 1 2 3 4 5 6 7 8
>                               +-+-+-+-+-+-+-+-+
>                               |0 0 0 0|Pkt Typ|
>                               +-+-+-+-+-+-+-+-+
>=20
>                         Figure 5 - PW Control Octet
>=20
>     where:
>=20
>     "Packet Type" encoding:
>     0: Reserved
>     1: FULL_HEADER
>     2: COMPRESSED_TCP
>     3: COMPRESSED_TCP_NODELTA
>     4: COMPRESSED_NON_TCP
>     5: COMPRESSED_RTP_8
>     6: COMPRESSED_RTP_16
>     7: COMPRESSED_UDP_8
>     8: COMPRESSED_UDP_16
>     9: CONTEXT_STATE
>     10-15: MUST NOT BE ASSIGNED
>=20
> SB> re 10-15 - Why MNBA? Or do you mean reserved?

The MNBA language suggested by Colin Perkins.  If the these values are
to be assigned in the future, then we need to specify a registry, which
we're not doing at the moment.
=20
>     As discussed in [ECMP-AVOID], since this MPLS payload=20
>     type is not IP, the first nibble is set to 0000 to
>     avoid being mistaken for IP.  This is also consistent
>     with the proposed encoding of the PWE3 control word
>     [PW-CNTL-WORD].
>=20
> SB> OK, you say this here. I think that you should say it=20
> SB> earlier since it is a design choice.

OK, as above.

> 7. IANA Considerations
>=20
>     As discussed in Section 4.1, new PW type values are assigned in
>     [IANA] for HC over MPLS LSP/PWs.  As discussed in Section 4.1,
>     interface parameter sub-TLV type values are specified in=20
>     [IANA] for both the network control protocol for IPv4, IPCP
>     [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472].
>=20
> SB> You say that all IANA actions are described
> SB> in IANA and there are no additional IANA actions. Just to
> SB> make it clear for the IANA reviewer.

We should actually clarify the second sentence to say that:
"As discussed in Section 4.1, interface parameter sub-TLV type values
*need to be* specified in [IANA] for both the network control protocol
for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]."

[IANA]
http://ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt
does not now specify sub-TLV type values for the network control
protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472].

Thanks,
Regards,
Jerry=20

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



From avt-bounces@ietf.org Mon Jul 25 16:26:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx9WT-0001XF-5C; Mon, 25 Jul 2005 16:26:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx5M8-0002ry-Cr; Mon, 25 Jul 2005 11:59:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02484;
	Mon, 25 Jul 2005 11:59:02 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dx5qq-0007jr-8x; Mon, 25 Jul 2005 12:30:59 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 17:58:40 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PFwbDg009042; 
	Mon, 25 Jul 2005 17:58:37 +0200 (MEST)
Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA29614;
	Mon, 25 Jul 2005 16:58:35 +0100 (BST)
Message-ID: <42E50C2B.7000500@cisco.com>
Date: Mon, 25 Jul 2005 16:58:35 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: gash@att.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 25 Jul 2005 16:25:59 -0400
Cc: pwe3 <pwe3@ietf.org>, avt@ietf.org
Subject: [AVT] draft-ash-avt-hc-over-mpls-protocol-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org



    In the example scenario, header compression therefore takes place
    between R1 and R4, and the MPLS path transports
    data/compressed-header/MPLS-labels instead of
    data/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet.

SB> You claim a size reduction but at this stage you have not
SB> said what the MPLS stack looks like. I assume that you have
SB> two labels, and as I recall you have just the 000 nible not
SB> the control word.

    The MPLS
    label stack and link-layer headers are not compressed.  Therefore HC
    over MPLS can significantly reduce the header overhead through
    compression mechanisms.

    MPLS is used to route HC packets over an MPLS LSP without
    compression/decompression cycles at each intermediate router.  MPLS
    pseudowires (PWs)
SB> perhaps a reference?

                                    8 octets              V
                                    +------+----------------------------+
                        MPLS Labels |header|                            |
                                    +------+----------------------------+
                                    \_________________ _________________/
                                                      V

SB> The above is technically two layers - the PW ident and the CE
SB> identifier. You may have other MPLS labels for example if you are
SB> going over a VPN.

    The PW control octet is used to identify the packet types for certain
    HC schemes, including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508],
    and ECRTP [RFC3545], as detailed in Section 4.2.

SB> You should call up <draft-ietf-mpls-ecmp-bcp-01.txt> and
SB> perhaps <draft-ietf-pwe3-cw-05.txt> to explain why your bytes
SB> start with zero.

    Note that ROHC
    [RFC3095] provides its own packet type within the protocol, and does
    not require use of the PW control octet.

SB> see above



4. Protocol Specifications


    In Figure 1 we assume an example data flow set up from R1/HC -->
    R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header
    Compression is performed, and R4/HD is the egress router where header
    Decompression is done.  Each router functions as an LSR and supports
    signaling of LSP/PWs.  A summary of the procedures is as follows:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-TLV Type  |    Length     |    Variable Length Value      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Variable Length Value                 |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 4 - PW Interface Parameters Sub-TLV

SB> Do you need to copy this - wouldn't it be better to just reference
SB> the definitive copy in the PW control RFC - just in case any typos
SB> creep in?



    Figure 3 shows the HC over MPLS protocol stack.  The PW control octet
    is used to identify the packet types for certain HC schemes,
    including cTCP [RFC1144], IPHC [RFC2507], cRTP [RFC2508], and ECRTP
    [RFC3545], as shown in Figure 5:


                              0 1 2 3 4 5 6 7 8
                              +-+-+-+-+-+-+-+-+
                              |0 0 0 0|Pkt Typ|
                              +-+-+-+-+-+-+-+-+

                        Figure 5 - PW Control Octet

    where:

    "Packet Type" encoding:
    0: Reserved
    1: FULL_HEADER
    2: COMPRESSED_TCP
    3: COMPRESSED_TCP_NODELTA
    4: COMPRESSED_NON_TCP
    5: COMPRESSED_RTP_8
    6: COMPRESSED_RTP_16
    7: COMPRESSED_UDP_8
    8: COMPRESSED_UDP_16
    9: CONTEXT_STATE
    10-15: MUST NOT BE ASSIGNED

SB> re 10-15 - Why MNBA? Or do you mean reserved?


    As discussed in [ECMP-AVOID], since this MPLS payload type is not IP,
    the first nibble is set to 0000 to avoid being mistaken for IP.  This
    is also consistent with the proposed encoding of the PWE3 control
    word [PW-CNTL-WORD].

SB> OK, you say this here. I think that you should say it earlier since
SB> it is a design choice.




7. IANA Considerations

    As discussed in Section 4.1, new PW type values are assigned in
    [IANA] for HC over MPLS LSP/PWs.  As discussed in Section 4.1,
    interface parameter sub-TLV type values are specified in [IANA] for
    both the network control protocol for IPv4, IPCP [RFC1332] and the
    IPv6 NCP, IPV6CP [RFC2472].

SB> You say that all IANA actions are described
SB> in IANA and there are no additional IANA actions. Just to
SB> make it clear for the IANA reviewer.



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



From avt-bounces@ietf.org Mon Jul 25 16:26:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx9WT-0001Xe-JH; Mon, 25 Jul 2005 16:26:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dx8JJ-0001QG-RK; Mon, 25 Jul 2005 15:08:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15258;
	Mon, 25 Jul 2005 15:08:20 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dx8oC-0004zN-SR; Mon, 25 Jul 2005 15:40:18 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 25 Jul 2005 21:08:11 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6PJ83Dg021280; 
	Mon, 25 Jul 2005 21:08:04 +0200 (MEST)
Received: from cisco.com (ams-clip-vpn-dhcp4490.cisco.com [10.61.81.137])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA18122;
	Mon, 25 Jul 2005 20:08:02 +0100 (BST)
Message-ID: <42E53892.2060708@cisco.com>
Date: Mon, 25 Jul 2005 20:08:02 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Ash, Gerald R \(Jerry\), ALABS" <gash@att.com>
References: <9473683187ADC049A855ED2DA739ABCA060CE694@KCCLUST06EVS1.ugd.att.com>
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060CE694@KCCLUST06EVS1.ugd.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 25 Jul 2005 16:25:59 -0400
Cc: pwe3 <pwe3@ietf.org>, avt@ietf.org
Subject: [AVT] Re: draft-ash-avt-hc-over-mpls-protocol-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


>>    Figure 3 shows the HC over MPLS protocol stack.  The PW 
>>    control octet is used to identify the packet types for
>>    certain HC schemes, including cTCP [RFC1144], IPHC
>>    [RFC2507], cRTP [RFC2508], and ECRTP [RFC3545], as shown
>>    in Figure 5:
>>
>>
>>                              0 1 2 3 4 5 6 7 8
>>                              +-+-+-+-+-+-+-+-+
>>                              |0 0 0 0|Pkt Typ|
>>                              +-+-+-+-+-+-+-+-+
>>
>>                        Figure 5 - PW Control Octet
>>
>>    where:
>>
>>    "Packet Type" encoding:
>>    0: Reserved
>>    1: FULL_HEADER
>>    2: COMPRESSED_TCP
>>    3: COMPRESSED_TCP_NODELTA
>>    4: COMPRESSED_NON_TCP
>>    5: COMPRESSED_RTP_8
>>    6: COMPRESSED_RTP_16
>>    7: COMPRESSED_UDP_8
>>    8: COMPRESSED_UDP_16
>>    9: CONTEXT_STATE
>>    10-15: MUST NOT BE ASSIGNED
>>
>>SB> re 10-15 - Why MNBA? Or do you mean reserved?
> 
> 
> The MNBA language suggested by Colin Perkins.  If the these values are
> to be assigned in the future, then we need to specify a registry, which
> we're not doing at the moment.
>  
> 

Yes, but you could imagine that some new requirement might come along
say sctp or dccp, and the language here will cause some argument.

Setting up the registry, is not difficult, and no one is going to
argue against Expert Review as the allocation policy in this case :)

> 
> 
>>7. IANA Considerations
>>
>>    As discussed in Section 4.1, new PW type values are assigned in
>>    [IANA] for HC over MPLS LSP/PWs.  As discussed in Section 4.1,
>>    interface parameter sub-TLV type values are specified in 
>>    [IANA] for both the network control protocol for IPv4, IPCP
>>    [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472].
>>
>>SB> You say that all IANA actions are described
>>SB> in IANA and there are no additional IANA actions. Just to
>>SB> make it clear for the IANA reviewer.
> 
> 
> We should actually clarify the second sentence to say that:
> "As discussed in Section 4.1, interface parameter sub-TLV type values
> *need to be* specified in [IANA] for both the network control protocol
> for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472]."
> 
> [IANA]
> http://ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.txt
> does not now specify sub-TLV type values for the network control
> protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472].
> 
> Thanks,
> Regards,
> Jerry 

OK - I saw a bunch of your values in there, and did not notice that
you needed more. It's likely that there will be another spin of
IANA when we resolve the allocation policy, so you should give Luca
the list to put in next time he does an update.

- Stewart


> 
> 

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



From avt-bounces@ietf.org Mon Jul 25 17:19:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxALv-0004C0-Iu; Mon, 25 Jul 2005 17:19:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxALs-00047y-KJ
	for avt@megatron.ietf.org; Mon, 25 Jul 2005 17:19:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24344
	for <avt@ietf.org>; Mon, 25 Jul 2005 17:18:42 -0400 (EDT)
Received: from carrierpigeon.cs.umd.edu ([128.8.129.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAqQ-0000Ww-1Z
	for avt@ietf.org; Mon, 25 Jul 2005 17:50:42 -0400
Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37])
	(authenticated bits=0)
	by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id
	j6PLIVfJ015644
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <avt@ietf.org>; Mon, 25 Jul 2005 17:18:35 -0400 (EDT)
Message-Id: <200507252118.j6PLIVfJ015644@carrierpigeon.cs.umd.edu>
From: "Moustafa Youssef" <moustafa@cs.umd.edu>
To: <avt@ietf.org>
Date: Mon, 25 Jul 2005 17:18:25 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] 1st CFP: Journal of Computer Communications Special Issue on
	"Sensor-Actuator Networks (SANETs)"
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                    Call for Papers
         Journal of Computer Communications
        (http://www.elsevier.com/locate/comcom)
Special Issue on "Sensor-Actuator Networks (SANETs)"

Sensor-Actuator NETworks (SANETs) are comprised of networked sensor
and actuator nodes that communicate among each other using wireless
 links to perform distributed sensing and actuation tasks. The recent
few years have witnessed an increasing interest in the potential use
of SANETs in many applications ranging from healthcare to warfare.
In these applications, sensors are engaged in gathering information
about the physical environment, while actuators are involved in
taking decisions and then performing appropriate actions in the area
of interest. This enables SANETs to provide remote sensing and
actuation services to their users.

SANETs are heterogeneous networks having widely differing sensor
and actuator node characteristics; while sensor nodes are small,
inexpensive, usually static devices with limited computation,
communication and energy resources, actuator nodes are resource-rich
and usually mobile. Also, the number of sensor nodes deployed may be
in the order of hundreds or thousands. In contrast, actuator nodes
are smaller in number due to the different coverage requirements and
physical interaction methods of actuation. Typically, a deployed
SANET is expected to operate autonomously in unattended environments.
Operational requirements of SANETs may vary according to a network=92s
mission defined over a multi-dimensional context, such as field of
deployment (e.g., hostile versus friendly), type of application
(e.g., monitoring, tracking, intrusion detection and mitigation),
mode of operation (e.g., normal, exception, post-event recovery),
and time. In SANETs, depending on the application, there may be a
need to rapidly respond to sensor input. Moreover, so as to provide
right actions, sensor data must still be valid at the time of
acting. Consequently, the issues of real-time communication and
coordination are vital in SANETs. Finally, to realize their
potential, dependable, secure, application-aware design and operation
of SANETs have to be ensured.

Apparently, research is needed to resolve the many complicating
issues that may impede wide-scale SANET adoption. This special issue
of the Journal of Computer Communications will be designated for
reporting on recent research results on SANETs. It is expected that
non-conventional techniques more suited to the characteristics of
SANETs need to be employed. Also, in many cases trade-off would be
necessary in order to ensure practicality by dynamically setting
bounds on aspects such as dependability, security, and QoS. Papers
presenting original and unpublished work are being solicited.
Topics of interest include, although not limited to, the following:

- Sensor-actuator coordination and communication
- Architectural and operational models
- Robust routing and MAC protocols
- Fault and attack resilience middleware
- Models, metrics and measurements
- Self-aware and autonomous networks
- Localization and mobility
- Energy-efficient cross-layer protocols
- Security, dependability, privacy and QoS issues
- Network management
- Formal representation and verification
- Network inference (tomography, etc.)
- Testbeds, simulation and visualization
- Novel applications of sensor and actuator networks

** Submission deadline:   February 15 , 2006
** Decision notification: May 15, 2006
** Final manuscript due:  July 31, 2006
** Publication date:      1st Quarter 2007

** Submission instructions:
Prospective authors should submit their paper and inquiries
electronically to toweissy@vt.edu. The manuscript should not
exceed 30 double-space pages in PDF. The manuscript should be in a
single column font size 11 or larger format. The first page should
include title, authors=92 contact information, an abstract and five
keywords. Authors should include the paper abstract in their message.


** Guest Editors:
Mohamed Eltoweissy:
The Bradley Dept. of Electrical & Computer Eng.,
Virginia Tech, USA,
toweissy@vt.edu

Silvia Giordano:
Dept. of Informatics & Electronics, Univ. of Applied Sci.,
Switzerland,
silvia.giordano@supsi.ch

Stephan Olariu:
Dept. of Computer Science,
Old Dominion University, USA,
olariu@cs.odu.edu

David Simplot-Ryl:
IRCICA/LIFL, University of Lille 1,
INRIA Futurs, France,
David.Simplot@lifl.fr


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



From avt-bounces@ietf.org Mon Jul 25 18:40:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxBcD-0005D3-Op; Mon, 25 Jul 2005 18:40:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxBc7-0005BB-Um; Mon, 25 Jul 2005 18:40:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01413;
	Mon, 25 Jul 2005 18:39:57 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DxC74-00038F-9t; Mon, 25 Jul 2005 19:11:58 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1DxBc3-0000Hl-2P; Mon, 25 Jul 2005 18:39:55 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1DxBc3-0000Hl-2P@newodin.ietf.org>
Date: Mon, 25 Jul 2005 18:39:55 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: avt chair <magnus.westerlund@ericsson.com>, avt chair <csp@csperkins.org>,
	Internet Architecture Board <iab@iab.org>, avt mailing list <avt@ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [AVT] Protocol Action: 'RTP Payload Format for AC-3 Audio' to 
 Proposed Standard 
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

The IESG has approved the following document:

- 'RTP Payload Format for AC-3 Audio '
   <draft-ietf-avt-rtp-ac3-07.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ac3-07.txt

Technical Summary:

This specification defines an RTP payload format for the AC-3 (Dolby 
Digital) multi-channel audio codec. The format supports aggregation
and fragmentation. The design is simple and uses proved concepts 
that are known to work well.

Working Group Summary:

There is strong consensus in the working group that this is an
appropriate solution.  

AC3 is coming out in a new specification (Revision B) in 2005, but this
revision does not affect format carried by the RTP payload;
the allowed media format which the working group reviewed in the
easily available document is identical to the format in the specification
about to appear.  Revision B is referenced in the document to ensure its
best future relevance.

Protocol Quality:

The format's simplicity and usage of proven and well known design
concepts ensures well-working functionality and implementation. The
document has been well reviewed within the WG.

The Responsible AD is Allison Mankin and the WG Chair shepherd 
is Magnus Westerlund.


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



From avt-bounces@ietf.org Tue Jul 26 01:59:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxITP-0005OM-14; Tue, 26 Jul 2005 01:59:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxITN-0005O9-6M
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 01:59:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27136
	for <avt@ietf.org>; Tue, 26 Jul 2005 01:59:23 -0400 (EDT)
Received: from mail1.audiocodes.com ([212.25.125.19]
	helo=aclmsg.corp.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxIyI-0006nq-My
	for avt@ietf.org; Tue, 26 Jul 2005 02:31:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] T.38 over RTP: RTP Sequence Number 
Date: Tue, 26 Jul 2005 08:59:38 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D8FF9@aclmsg.corp.audiocodes.com>
Thread-Topic: [AVT] T.38 over RTP: RTP Sequence Number 
Thread-Index: AcWRpzUmnHVekzjYQ6+y1u3lVxusJA==
From: "Vladimir Ulybin" <Vladimir@audiocodes.com>
To: "lazzaro" <lazzaro@eecs.berkeley.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, avt@ietf.org, "Mundra,
	Satish" <smundra@ti.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


For T.38-over-RTP the marker bit of
"draft-smundra-avt-rtp-red-non-audio-00.txt", by Satish Mundra, is not
required, so it MUST be cleared on transmission and ignored on
receiving.

It will be better to update the draft and specify examples of media
types using the market and reserving it.

Vladimir Ulybin


-----Original Message-----
From: lazzaro [mailto:lazzaro@eecs.berkeley.edu]=20
Sent: Monday, July 25, 2005 6:54 PM
To: avt@ietf.org
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number=20


Magnus Westerlund <magnus.westerlund at ericsson.com> writes:
> However please remember that you must stay within the ground rules =20
> of RTP. For example defining the marker bit strangely may not be =20
> the wisest. At least not as long as it is within an audio RTP session.


Indeed -- the unusual use of the marker bit in
mpeg4-generic led to the only bit-level incompatibility
between native RTP MIDI and mpeg4-generic
encapsulated RTP MIDI ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---





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



From avt-bounces@ietf.org Tue Jul 26 02:54:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxJKL-00082K-42; Tue, 26 Jul 2005 02:54:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJKI-000823-Ko
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 02:54:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21702
	for <avt@ietf.org>; Tue, 26 Jul 2005 02:54:05 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxJpH-00089g-2j
	for avt@ietf.org; Tue, 26 Jul 2005 03:26:09 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4A8A46E9; 
	Tue, 26 Jul 2005 08:53:52 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Jul 2005 08:53:51 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Jul 2005 08:53:51 +0200
Message-ID: <42E5DDFF.9020102@ericsson.com>
Date: Tue, 26 Jul 2005 08:53:51 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vladimir Ulybin <Vladimir@audiocodes.com>
Subject: Re: [AVT] T.38 over RTP: RTP Sequence Number
References: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D8FF9@aclmsg.corp.audiocodes.com>
In-Reply-To: <79B4F738DDD4EF4F85A4641A0FE5EFD6012D8FF9@aclmsg.corp.audiocodes.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Jul 2005 06:53:51.0673 (UTC)
	FILETIME=[C80F9A90:01C591AE]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: lazzaro <lazzaro@eecs.berkeley.edu>, avt@ietf.org, "Mundra,
	Satish" <smundra@ti.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Vladimir,

That draft you refer to is an individual submission which has expired. 
Only the authors can answer if they have any plans to resurrect it and 
address any received comments.

Cheers

Magnus

Vladimir Ulybin wrote:
> For T.38-over-RTP the marker bit of
> "draft-smundra-avt-rtp-red-non-audio-00.txt", by Satish Mundra, is not
> required, so it MUST be cleared on transmission and ignored on
> receiving.
> 
> It will be better to update the draft and specify examples of media
> types using the market and reserving it.
> 
> Vladimir Ulybin


-- 

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 avt-bounces@ietf.org Tue Jul 26 04:03:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxKPv-0005lb-3w; Tue, 26 Jul 2005 04:03:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxKPt-0005lT-DK
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 04:03:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25841
	for <avt@ietf.org>; Tue, 26 Jul 2005 04:03:55 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxKut-0001uW-Fk
	for avt@ietf.org; Tue, 26 Jul 2005 04:36:00 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Jul 2005 10:03:52 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Date: Tue, 26 Jul 2005 10:08:15 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1015941F0@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Thread-Index: AcWReSx7/8sj01jOTimMigEPntWloQAPnQ0g
From: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
To: "Keith Lantz" <klantz@cisco.com>
X-OriginalArrivalTime: 26 Jul 2005 08:03:52.0524 (UTC)
	FILETIME=[8FF698C0:01C591B8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: quoted-printable
Cc: zzx-IETF-AVT <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

It concerns the G.729-based embedded variable bit rate extension to =
G.729 (G729EV). I called it X in the draft because the final =
corresponding annex letter is still not determined.

The other big ITU current work on G.729 is about annex B (VAD and =
silence suppresion) and is not related to the proposed RTP payload =
format.

Aurelien=20

-----Message d'origine-----
De : Keith Lantz [mailto:klantz@cisco.com]=20
Envoy=E9 : mardi 26 juillet 2005 02:29
=C0 : SOLLAUD Aurelien RD-TECH-LAN
Cc : zzx-IETF-AVT
Objet : Re: [AVT] TR: I-D =
ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt=20

I deleted your response to the query below, but ... Having now reviewed =
the list of contributions to the current ITU sessions related to G.729 =
(see the attached list), I've gotta ask: Which of the many enhancements =
still under consideration does this payload format refer to?

Regards, Keith

At 08:51 AM 7/18/2005, Keith Lantz wrote:
>Per the earlier "debate" on this list re VC-1, could you distribute or=20
>otherwise point people at the current draft for the "G.729X" spec?=20
>(Unlike SMPTE, I've never heard anyone object to distribution of an ITU =

>draft.)
>
>Thx, Keith
>
>At 01:43 AM 7/18/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
>>Hi,
>>
>>I posted a -01 update of the RTP payload format for the future=20
>>scalable and wideband extension of G.729 audio codec.
>>
>>The major update is a simplification of the payload format. The=20
>>payload header is no more optional and hence the (tricky)=20
>>acknowledgement procedure has been removed. I added more spec on the =
MBS part.
>>The implementation should be now much easier.
>>
>>Note that the ITU-T standardization of the codec is on schedule, it=20
>>should be delivered at the end of 2005.
>>
>>Comments are welcome.
>>
>>Aurelien
>>
>>-----Message d'origine-----
>>De : i-d-announce-bounces@ietf.org=20
>>[mailto:i-d-announce-bounces@ietf.org]
>>De la part de Internet-Drafts@ietf.org Envoy=E9 : jeudi 14 juillet =
2005=20
>>21:50 =C0 : i-d-announce@ietf.org Objet : I-D=20
>>ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts=20
>>directories.
>>
>>
>>         Title           : RTP payload format for the future scalable =
and
>>                           wideband extension of G.729 audio codec
>>         Author(s)       : A. Sollaud
>>         Filename        : =
draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>>         Pages           : 15
>>         Date            : 2005-7-14
>>
>>This document specifies a real-time transport protocol (RTP) payload
>>    format to be used for the future scalable and wideband extension =
of
>>    the International Telecommunication Union (ITU-T) G.729 audio =
codec.
>>    A media type registration is included for this payload format.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-wb
>>-ext-01.txt
>>

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



From avt-bounces@ietf.org Tue Jul 26 10:01:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxQ0L-0006jo-3e; Tue, 26 Jul 2005 10:01:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQ0J-0006jj-FN
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 10:01:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20044
	for <avt@ietf.org>; Tue, 26 Jul 2005 10:01:53 -0400 (EDT)
Received: from sonussf1.sonusnet.com ([208.45.178.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQVL-0005Ir-IU
	for avt@ietf.org; Tue, 26 Jul 2005 10:34:02 -0400
Received: from sonusmail03.sonusnet.com (sonusmail03.sonusnet.com
	[10.128.32.97])
	by sonussf1.sonusnet.com (8.13.3/8.13.3) with ESMTP id j6QE1ahJ025514; 
	Tue, 26 Jul 2005 10:01:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 26 Jul 2005 10:01:35 -0400
Message-ID: <A3863F3136CBC546A40A61BA9CBA9D930136954E@sonusmail03.sonusnet.com>
Thread-Topic: [AVT] Updated preliminary AVT agenda
Thread-Index: AcWN0bEe0O6ef0QoSaCH6EI/+eyE2gATLRwgAPLxGMA=
From: "Phelan, Tom" <tphelan@sonusnet.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>,
	"IETF AVT WG" <avt@ietf.org>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: 
Subject: [AVT] RE: Strategies for Streaming Media Applications Using
	TCP-Friendly Rate Control
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1314709207=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--===============1314709207==
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

SGkgQWxsLA0KDQpTb21laG93LCB0aGUgc2VjcmV0YXJpYXQgcmVsZW50ZWQgYW5kIGRyYWZ0LWll
dGYtZGNjcC10ZnJjLW1lZGlhLTAwLnR4dCBpcyBub3cgYXZhaWxhYmxlIGluIHRoZSBkcmFmdHMg
cmVwb3NpdG9yeSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0
Zi1kY2NwLXRmcmMtbWVkaWEtMDAudHh0KSwgd2l0aCB0aGUgcHJvcGVyIGJvaWxlcnBsYXRlIDot
KS4NCg0KVGhhbmtzIHRvIHRoZSBzZWNyZXRhcmlhdCBmb3IgYmVpbmcgZmxleGlibGUsIGFuZCBz
ZWUgeW91IGFsbCBpbiBQYXJpcy4NCg0KVG9tIFBoZWxhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+IEZyb206IFBoZWxhbiwgVG9tIA0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAy
MSwgMjAwNSAyOjA4IFBNDQo+IFRvOiAnTWFnbnVzIFdlc3Rlcmx1bmQnOyBJRVRGIEFWVCBXRw0K
PiBTdWJqZWN0OiBTdHJhdGVnaWVzIGZvciBTdHJlYW1pbmcgTWVkaWEgQXBwbGljYXRpb25zIFVz
aW5nIA0KPiBUQ1AtRnJpZW5kbHkNCj4gUmF0ZSBDb250cm9sDQo+IA0KPiANCj4gSGkgQWxsLA0K
PiANCj4gVGhlIGRyYWZ0IEknbSBzY2hlZHVsZWQgdG8gcHJlc2VudCBpbiBQYXJpcyAoIlN0cmF0
ZWdpZXMgZm9yIA0KPiBTdHJlYW1pbmcgTWVkaWEgQXBwbGljYXRpb25zIFVzaW5nIFRDUC1Gcmll
bmRseSBSYXRlIA0KPiBDb250cm9sIiksIHdhcyB1bmZvcnR1bmF0ZWx5IHJlamVjdGVkIGJlY2F1
c2Ugb2Ygb2xkIA0KPiBib2lsZXJwbGF0ZSBhbmQgZGlkbid0IGdldCBmaXhlZCBpbiB0aW1lIGZv
ciB0aGUgY3V0b2ZmIGRhdGUuIA0KPiAgRXZlbiBzbywgTWFnbnVzIGFuZCBDb2xpbiBoYXZlIGdy
YWNpb3VzbHkgYWxsb3dlZCBtZSB0byANCj4gcHJlc2VudCBhbnl3YXkuICBUaGUgZHJhZnQgaXMg
YXZhaWxhYmxlIGF0IA0KPiBodHRwOi8vd3d3LnBoZWxhbi00LmNvbS9kY2NwL2RyYWZ0LWlldGYt
ZGNjcC10ZnJjLW1lZGlhLTAwLnR4dC4NCj4gDQo+IFNvcnJ5IGZvciBiZWluZyBzbG9wcHksIGFu
ZCB0aGFua3MgYWxsIGZvciBwdXR0aW5nIHVwIHdpdGggbWUgOi0pLg0KPiANCj4gVG9tIFBoZWxh
bg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGF2dC1ib3Vu
Y2VzQGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+
ID4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAyMSwgMjAwNSA0
OjQ5IEFNDQo+ID4gVG86IElFVEYgQVZUIFdHDQo+ID4gU3ViamVjdDogW0FWVF0gVXBkYXRlZCBw
cmVsaW1pbmFyeSBBVlQgYWdlbmRhDQo+ID4gDQo+ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4gUGxl
YXNlIHNlZSBiZWxvdyBmb3IgdGhlIEFWVCBhZ2VuZGEuIFRoZSBJRVRGIFdHIHNjaGVkdWxpbmcg
DQo+IGFnZW5kYSBpcyANCj4gPiBub3QgeWV0IGNvbmZpcm1lZCwgdGh1cyB0aGlzIGFnZW5kYSBp
cyBzdGlsbCBwcmVsaW1pbmFyeS4NCj4gPiANCj4gPiBDaGVlcnMNCj4gPiANCj4gPiBNYWdudXMN
Cj4gPiANCj4gPiAtLS0tLS0tDQo+ID4gDQo+ID4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtp
bmcgR3JvdXANCj4gPiANCj4gPiBDSEFJUlM6IENvbGluIFBlcmtpbnMgICAgIDxjc3BAY3NwZXJr
aW5zLm9yZz4NCj4gPiAgICAgICAgICBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1
bmRAZXJpY3Nzb24uY29tPg0KPiA+IA0KPiA+IFR1ZXNkYXksIDIgQXVndXN0IDIwMDUsIDEwOjMw
LTEyOjMwDQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gDQo+
ID4gSW50cm9kdWN0aW9uIGFuZCBTdGF0dXMgVXBkYXRlICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICANCj4gPiAgKENoYWlycykNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ICAgIDEwIG1pbg0KPiA+ICAg
ICBVbmRlciBkZXZlbG9wbWVudDoNCj4gPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtbWltZS1o
MjI0LTAyDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXByb2ZpbGUtc2F2cGYtMDINCj4g
PiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRjcHNzbS0wOQ0KPiA+ICAgICAgICAgICBkcmFm
dC1pZXRmLWF2dC1yZmMyMDMyLWJpcy0wNg0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1y
ZmMyMTkwLXRvLWhpc3RvcmljLTAzDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJmYzI0
MjktYmlzLTA1DQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJmYzI4MzNiaXMtMDkNCj4g
PiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcmZjMjgzM2Jpc2Nhcy0wMA0KPiA+ICAgICAgICAg
ICBkcmFmdC1pZXRmLWF2dC1yZmMyODMzYmlzZGF0YS0wMg0KPiA+ICAgICAgICAgICBkcmFmdC1p
ZXRmLWF2dC1yZmMzNTU1YmlzLTAwDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0Y3At
eHItbWliLTAyDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1hbXItYmlzLTAxDQo+
ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1hdHJhYy1mYW1pbHktMDQNCj4gPiAgICAg
ICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRwLWpwZWcyMDAwLTA4DQo+ID4gICAgICAgICAgIGRyYWZ0
LWlldGYtYXZ0LXJ0cC1qcGVnMjAwMC1iZWFtLTAxDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYt
YXZ0LXJ0cC1taWRpLWZvcm1hdC0xMA0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAt
bWlkaS1ndWlkZWxpbmVzLTEwDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1uby1v
cC0wMA0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAtdm1yLXdiLWV4dGVuc2lvbi0w
MA0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC10ZnJjLXByb2ZpbGUtMDQNCj4gPiAgICAg
ICAgICAgZHJhZnQtaWV0Zi1hdnQtdWxwLTExDQo+ID4gDQo+ID4gICAgICAgICAgIGRyYWZ0LWll
dGYtYXZ0LXJmYzMxMTliaXMtMDMgKEV4cGlyZWQpDQo+ID4gICAgICAgICAgIA0KPiBkcmFmdC1m
aW5sYXlzb24tYXZ0LW1wYS1yb2J1c3QtaW50ZXJvcGVyYWJpbGl0eS0wMSAoRXhwaXJlZCkNCj4g
PiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtdXhwLTA3IChFeHBpcmVkKQ0KPiA+ICAgICAgICAg
ICBkcmFmdC1pZXRmLWF2dC12YXJpYWJsZS1yYXRlLWF1ZGlvLTAwICAgICAoRXhwaXJlZCkNCj4g
PiANCj4gPiAgICAgQUQgb3IgSUVTRyBFdmFsdWF0aW9uDQo+ID4gICAgICAgICAgIGRyYWZ0LWll
dGYtYXZ0LWF1ZGlvLXQxNDBjLTAwDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0cC1y
ZXRyYW5zbWlzc2lvbi0xMQ0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAtZnJhbWlu
Zy1jb250cmFucy0wNQ0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAtdm1yLXdiLTEw
DQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LTNncHAtdGltZWQtdGV4dC0xNQ0KPiA+ICAg
ICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAtYWMzLTA3DQo+ID4gICAgICAgICAgIGRyYWZ0LWll
dGYtYXZ0LXJ0cC1hbXJ3YnBsdXMtMDYNCj4gPiAgICAgICAgICAgZHJhZnQtam9uZXMtYXZ0LWF1
ZGlvLXQzOC0wNQ0KPiA+ICAgICAgICAgICBkcmFmdC1nYXJ1ZGFkcmktYXZ0LTNncHAyLW1pbWUt
MDINCj4gPiAgICAgICAgICAgZHJhZnQtbGltLW1wZWc0LW1pbWUtMDMNCj4gPiANCj4gPiAgICAg
UkZDIEVkaXRvcjoNCj4gPiAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtaGMtbXBscy1yZXFzLTAz
DQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0Y3AtZmVlZGJhY2stMTENCj4gPiAgICAg
ICAgICAgZHJhZnQtYnVybWVpc3Rlci1hdnQtcnRjcC1mZWVkYmFjay1zaW0tMDYNCj4gPiAgICAg
ICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRwLWJ2LTAzDQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYt
YXZ0LXRjcnRwLTA4DQo+ID4gICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXVuY29tcC12aWRlby0w
Ng0KPiA+IA0KPiA+ICAgICBQdWJsaXNoZWQgUkZDcw0KPiA+ICAgICAgICAgICBkcmFmdC1pZXRm
LWF2dC1ydHAtY2xlYXJtb2RlLTA1ICAgICAgLT4gUkZDIDQwNDANCj4gPiAgICAgICAgICAgZHJh
ZnQtaWV0Zi1hdnQtcnRwLWRzci1jb2RlY3MtMDMgICAgIC0+IFJGQyA0MDYwDQo+ID4gICAgICAg
ICAgIGRyYWZ0LWlldGYtYXZ0LXRleHQtcmVkLTA1ICAgICAgICAgICAtPiBSRkMgNDEwMg0KPiA+
ICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1yZmMyNzkzYmlzLTA5ICAgICAgICAgLT4gUkZDIDQx
MDMNCj4gPiANCj4gPiAgICAgSW5kaXZpZHVhbCBkcmFmdHMgd2l0aCBBVlQgcmVsYXRpb24NCj4g
PiAgICAgICAgICAgZHJhZnQtYXNoLWF2dC1oYy1vdmVyLW1wbHMtcHJvdG9jb2wtMDENCj4gPiAg
ICAgICAgICAgZHJhZnQtY2xhcmstYXZ0LXJ0Y3B4ci1iaXMtMDANCj4gPiAgICAgICAgICAgZHJh
ZnQtZXZlbi1hdnQtcmZjMzA0Ny1iaXMtMDENCj4gPiAgICAgICAgICAgZHJhZnQtZmVpdGVuLWF2
dC1ic2FjbW9kZS1mb3ItcmZjMzY0MC0wMA0KPiA+ICAgICAgICAgICBkcmFmdC1rZXJyLWF2dC12
b3JiaXMtcnRwLTA0DQo+ID4gICAgICAgICAgIGRyYWZ0LWtsZW1ldHMtYXZ0LXJ0cC12YzEtMDAN
Cj4gPiAgICAgICAgICAgZHJhZnQta29yZW4tYXZ0LWVjcnRwLXJlb3JkZXItMDANCj4gPiAgICAg
ICAgICAgZHJhZnQtbGVubm94LWF2dC1hcHAtc2hhcmluZy0wMA0KPiA+ICAgICAgICAgICBkcmFm
dC1sa2Nob2ktYXZ0LWlwdHZkYnMtcmVxLTAwDQo+ID4gICAgICAgICAgIGRyYWZ0LXBlcmtpbnMt
YXZ0LXVuY29tcC12aWRlby1leHQtMDANCj4gPiAgICAgICAgICAgZHJhZnQtc2luZ2VyLXJ0cC1o
ZHJleHQtMDANCj4gPiAgICAgICAgICAgZHJhZnQtc2luZ2VyLXNtcHRlLXJ0cC0wMQ0KPiA+ICAg
ICAgICAgICBkcmFmdC1zb2xsYXVkLWF2dC1ydHAtZzcyOS1zY2FsLXdiLWV4dC0wMQ0KPiA+ICAg
ICAgICAgICBkcmFmdC1zdGlyYnUtYXZ0LWxyZHAtMDANCj4gPiAgICAgICAgICAgZHJhZnQtdml0
YWxpLWlldGYtYXZ0LW1kYy1sYy0wMA0KPiA+ICAgICAgICAgICBkcmFmdC13ZW5nZXItYXZ0LWF2
cGYtY2NtLTAwDQo+ID4gICAgICAgICAgIGRyYWZ0LXhpZS1hdnQtY29tcGFjdC1idW5kbGUtZXZy
Yy0wMA0KPiA+ICAgICAgICAgICBkcmFmdC14aWUtYXZ0LXJ0cC1hbnRpLXNoYWRvdy0wMQ0KPiA+
IA0KPiA+IFVzaW5nIHRoZSBSVFAgSGVhZGVyIEV4dGVuc2lvbiBmb3IgU01UUEUgVGltZXN0YW1w
cwkJKFNpbmdlcikNCj4gPiAgICAgZHJhZnQtc2luZ2VyLXJ0cC1oZHJleHQtMDAJCQkJDQo+ID4g
CSAgIDUgbWluDQo+ID4gICAgIGRyYWZ0LXNpbmdlci1zbXB0ZS1ydHAtMDENCj4gPiANCj4gPiBD
b21wYWN0IEJ1bmRsZWQgUlRQIEZvcm1hdCBmb3IgRVZSQyBTcGVlY2ggICAgICAgICAgICAgICAg
ICAgIA0KPiA+ICAgICAgKFhpZSkNCj4gPiAgICAgZHJhZnQteGllLWF2dC1jb21wYWN0LWJ1bmRs
ZS1ldnJjLTAwICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ICAgICAgMTAgbWluDQo+ID4gDQo+
ID4gUlRQIFBheWxvYWQgRm9ybWF0IGZvciBWaWRlbyBDb2RlYyAxIChWQy0xKSAgICAgICAgICAg
ICAgICAgICANCj4gPiAgKEtsZW1ldHMpDQo+ID4gICAgIGRyYWZ0LWtsZW1ldHMtYXZ0LXJ0cC12
YzEtMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gPiAgICAgIDE1IG1pbg0KPiA+
IA0KPiA+IFVwZGF0ZSBvZiBJVFUgRy43MjIuMSBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAgICAg
ICAgICAgICAgICAgDQo+ID4gICAgIChFdmVuKQ0KPiA+ICAgICBkcmFmdC1ldmVuLWF2dC1yZmMz
MDQ3LWJpcy0wMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ID4gICAgICAxMCBtaW4N
Cj4gPiANCj4gPiBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIEVDTiBQcm9iaW5nICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KPiA+IChBbGV4YW5kZXIpDQo+ID4gICAgIGRyYWZ0LWFsZXhhbmRl
ci1ydHAtcGF5bG9hZC1mb3ItZWNuLXByb2JpbmctMDEgICAgICAgICAgICANCj4gPiAgICAgIDEw
IG1pbg0KPiA+ICAgICBkcmFmdC1iYWJpYXJ6LXRzdndnLXJ0ZWNuLTA0DQo+ID4gICAgIGRyYWZ0
LWFsZXhhbmRlci1ydGVjbi11c2UtY2FzZXMtMDANCj4gPiAgICAgZHJhZnQtYWxleGFuZGVyLWNv
bmdlc3Rpb24tc3RhdHVzLXByZWNvbmRpdGlvbnMtMDANCj4gPiANCj4gPiBQcm90b2NvbCBFeHRl
bnNpb25zIGZvciBIZWFkZXIgQ29tcHJlc3Npb24gb3ZlciBNUExTICAgICAgICAgIA0KPiA+ICAg
ICAgKEFzaCkNCj4gPiAgICAgZHJhZnQtYXNoLWF2dC1oYy1vdmVyLW1wbHMtcHJvdG9jb2wtMDEg
ICAgICAgICAgICAgICAgICAgIA0KPiA+ICAgICAgMTUgbWluDQo+ID4gDQo+ID4gUlRQIFByb2Zp
bGUgZm9yIFRDUCBGcmllbmRseSBSYXRlIENvbnRyb2wgICAgICAgICAgICAgICAgICAgICANCj4g
PiAgIChHaGFyYWkpDQo+ID4gICAgIGRyYWZ0LWlldGYtYXZ0LXRmcmMtcHJvZmlsZS0wNCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANCj4gPiAgICAgIDE1IG1pbg0KPiA+IA0KPiA+IFN0cmF0
ZWdpZXMgZm9yIFN0cmVhbWluZyBNZWRpYSBBcHBsaWNhdGlvbnMgVXNpbmcgVEZSQyAgICAgICAg
DQo+ID4gICAoUGhlbGFuKQ0KPiA+ICAgICBkcmFmdC1pZXRmLWRjY3AtdGZyYy1tZWRpYS0wMCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ID4gICAgICAxNSBtaW4NCj4gPiANCj4gPiBG
RUMgc3RyZWFtaW5nIGZyYW1ld29yayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIA0KPiA+ICAgKFdhdHNvbikNCj4gPiAgICAgZHJhZnQtd2F0c29uLXRzdndnLWZlYy1zZi0w
MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ICAgICAgMTUgbWluDQo+ID4gDQo+
ID4gDQo+ID4gDQo+ID4gV2VkbmVzZGF5LCAzIEF1Z3VzdCAyMDA1LCA5OjAwLTEwOjAwDQo+ID4g
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gDQo+ID4gUlRDUCBYUiBW
b0lQIE1ldHJpY3MgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlICAgICAgICAgICAgICANCj4g
PiAgICAoQ2xhcmspDQo+ID4gICAgIGRyYWZ0LWF2dC1ydGNwLXhyLW1pYi0wMiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICANCj4gPiAgICAgIDEwIG1pbg0KPiA+IA0KPiA+IFJUQ1Ag
WFIgLSBOZXcgUGFyYW1ldGVyIEV4dGVuc2lvbnMgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQo+ID4gICAgKENsYXJrKQ0KPiA+ICAgICBkcmFmdC1jbGFyay1hdnQtcnRjcHhyLWJpcy0wMCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ID4gICAgICAxMCBtaW4NCj4gPiANCj4gPiBP
cGVuIGlzc3VlcyB3aXRoIENvZGVjIENvbnRyb2wgTWVzc2FnZXMgaW4gQVZQRiAgICAgICAgICAg
ICAgIA0KPiA+ICAgKFdlbmdlcikNCj4gPiAgICAgZHJhZnQtd2VuZ2VyLWF2dC1hdnBmLWNjbS0w
MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiA+ICAgICAgMTUgbWluDQo+ID4gDQo+
ID4gTWVkaWEgVHlwZSBEaXNjdXNzaW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICANCj4gPiAgIChjaGFpcnMpDQo+ID4gICAgIGRyYWZ0LWlldGYtYXZ0LXJmYzM1NTVi
aXMtMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gPiAgICAgIDE1IG1pbg0KPiA+
ICAgICBkcmFmdC1mcmVlZC1tZWRpYS10eXBlLXJlZy0wNA0KPiA+ICAgICBNYWlsaW5nIGxpc3Qg
ZGlzY3Vzc2lvbg0KPiA+IA0KPiA+IFJUQ1AgRXh0ZW5zaW9ucyBmb3IgU1NNIHNlc3Npb25zIHdp
dGggdW5pY2FzdCBmZWVkYmFjayAgICAgICAgDQo+ID4gICAgICAoT3R0KQ0KPiA+ICAgICBkcmFm
dC1pZXRmLWF2dC1ydGNwc3NtLTA5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+
ID4gICAgICAxMCBtaW4NCj4gPiANCj4gPiANCj4gPiAtLSANCj4gPiANCj4gPiBNYWdudXMgV2Vz
dGVybHVuZA0KPiA+IA0KPiA+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNl
YXJjaCBFQUIvVFZBL0ENCj4gPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IEVyaWNzc29uIEFCICAg
ICAgICAgICAgICAgIHwgUGhvbmUgKzQ2IDggNDA0ODI4Nw0KPiA+IFRvcnNoYW1zZ2F0YW4gMjMg
ICAgICAgICAgIHwgRmF4ICAgKzQ2IDggNzU3NTU1MA0KPiA+IFMtMTY0IDgwIFN0b2NraG9sbSwg
U3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gPiANCj4g
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEF1
ZGlvL1ZpZGVvIFRyYW5zcG9ydCBXb3JraW5nIEdyb3VwDQo+ID4gYXZ0QGlldGYub3JnDQo+ID4g
aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+ID4gDQo+IA0K


--===============1314709207==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1314709207==--



From avt-bounces@ietf.org Tue Jul 26 10:02:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxQ1E-0006na-Tf; Tue, 26 Jul 2005 10:02:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDKi-0004kG-Ie
	for avt@megatron.ietf.org; Mon, 25 Jul 2005 20:30:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10192
	for <avt@ietf.org>; Mon, 25 Jul 2005 20:30:06 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxDpb-00078E-6h
	for avt@ietf.org; Mon, 25 Jul 2005 21:02:07 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 25 Jul 2005 17:29:15 -0700
X-IronPort-AV: i="3.95,141,1120460400"; 
	d="doc'32?scan'32,208,32"; a="200506179:sNHT104279358"
Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com
	[171.70.93.77])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6Q0TC6p001313;
	Mon, 25 Jul 2005 17:29:12 -0700 (PDT)
Received: from klantz-w2k02.cisco.com ([128.107.171.1]) by
	vtg-um-e2k6.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 25 Jul 2005 17:29:11 -0700
Message-Id: <6.2.1.2.2.20050725172137.030fba48@vtg-um-e2k6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 25 Jul 2005 17:29:07 -0700
To: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
From: Keith Lantz <klantz@cisco.com>
Subject: Re: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
In-Reply-To: <6.2.1.2.2.20050718085026.03160368@vtg-um-e2k6.cisco.com>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1014FD822@ftrdmel1.rd.francetelecom.fr>
	<6.2.1.2.2.20050718085026.03160368@vtg-um-e2k6.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_60751095==_"
X-OriginalArrivalTime: 26 Jul 2005 00:29:11.0539 (UTC)
	FILETIME=[0B3AA430:01C59179]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 47eb13257e5eeecbfccfdcf9d9b7a97e
X-Mailman-Approved-At: Tue, 26 Jul 2005 10:02:50 -0400
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

--=====================_60751095==_
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA10192

I deleted your response to the query below, but ... Having now reviewed t=
he=20
list of contributions to the current ITU sessions related to G.729 (see t=
he=20
attached list), I've gotta ask: Which of the many enhancements still unde=
r=20
consideration does this payload format refer to?

Regards, Keith

At 08:51 AM 7/18/2005, Keith Lantz wrote:
>Per the earlier "debate" on this list re VC-1, could you distribute or=20
>otherwise point people at the current draft for the "G.729X" spec? (Unli=
ke=20
>SMPTE, I've never heard anyone object to distribution of an ITU draft.)
>
>Thx, Keith
>
>At 01:43 AM 7/18/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
>>Hi,
>>
>>I posted a -01 update of the RTP payload format for the future scalable=
=20
>>and wideband extension of G.729 audio codec.
>>
>>The major update is a simplification of the payload format. The payload=
=20
>>header is no more optional and hence the (tricky) acknowledgement=20
>>procedure has been removed. I added more spec on the MBS part.
>>The implementation should be now much easier.
>>
>>Note that the ITU-T standardization of the codec is on schedule, it=20
>>should be delivered at the end of 2005.
>>
>>Comments are welcome.
>>
>>Aurelien
>>
>>-----Message d'origine-----
>>De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or=
g]=20
>>De la part de Internet-Drafts@ietf.org
>>Envoy=E9 : jeudi 14 juillet 2005 21:50
>>=C0 : i-d-announce@ietf.org
>>Objet : I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts=20
>>directories.
>>
>>
>>         Title           : RTP payload format for the future scalable a=
nd
>>                           wideband extension of G.729 audio codec
>>         Author(s)       : A. Sollaud
>>         Filename        : draft-sollaud-avt-rtp-g729-scal-wb-ext-01.tx=
t
>>         Pages           : 15
>>         Date            : 2005-7-14
>>
>>This document specifies a real-time transport protocol (RTP) payload
>>    format to be used for the future scalable and wideband extension of
>>    the International Telecommunication Union (ITU-T) G.729 audio codec.
>>    A media type registration is included for this payload format.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-wb-=
ext-01.txt
>>

--=====================_60751095==_
Content-Type: application/msword; name="G729stuff.doc";
	x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Disposition: attachment; filename="G729stuff.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAAngEAAAAAAAAA
EAAAoAEAAAEAAAD+////AAAAAJoBAACbAQAAnAEAAJ0BAAD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEABUAJBAAA+BK/AAAAAAAAEAAAAAAABgAAMUAAAA4AYmpiau5G7kYAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAQ5QBAIwsAACMLAAA+jUAAAAAAAA2AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAFgJAAAAAAAAWAkAAFgJ
AAAAAAAAWAkAAAAAAABYCQAAAAAAAFgJAAAAAAAAWAkAABQAAAAAAAAAAAAAAGwJAAAAAAAAEGoA
AAAAAAAQagAAAAAAABBqAAA4AAAASGoAAIwAAADUagAAvAQAAGwJAAAAAAAAvKsAADQBAACcbwAA
2gUAAHZ1AAAoAAAAnnUAAAAAAACedQAAAAAAAEaGAAAAAAAAIYcAAD4AAABfhwAAFAAAAHOHAAAM
AAAAO6sAAAIAAAA9qwAAAAAAAD2rAAAAAAAAPasAAAAAAAA9qwAAAAAAAD2rAAAAAAAAPasAACQA
AADwrAAAUgIAAEKvAAB0AAAAYasAABUAAAAAAAAAAAAAAAAAAAAAAAAAWAkAAAAAAAC4iAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAhhwAAAAAAACGHAAAAAAAAuIgAAAAAAAC4iAAAAAAAAGGrAAAAAAAA
AAAAAAAAAABYCQAAAAAAAFgJAAAAAAAAnnUAAAAAAAAAAAAAAAAAAEaGAADbAAAAdqsAABYAAAA+
jgAAAAAAAD6OAAAAAAAAPo4AAAAAAAC4iAAAiAAAAFgJAAAAAAAAnnUAAAAAAABYCQAAAAAAAEaG
AAAAAAAAO6sAAAAAAAAAAAAAAAAAAD6OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAuIgAAAAAAAA7qwAAAAAAAAAAAAAAAAAAPo4AAAAAAAA+jgAA
HgAAAFmRAAAYAAAAWAkAAAAAAABYCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgZEAAAAAAACedQAAqBAAAJBvAAAMAAAAELTRZWqR
xQEAAAAAAAAAABBqAAAAAAAAQIkAAGQAAABxkQAACAAAAAAAAAAAAAAAl5MAAKQXAACMqwAAMAAA
ALyrAAAAAAAAeZEAAAgAAAC2rwAAAAAAAKSJAABCBAAAtq8AABAAAACBkQAAAAAAAAAAAAAAAAAA
bAkAAAAAAABsCQAAAAAAAFgJAAAAAAAAWAkAAAAAAABYCQAAAAAAAFgJAAAAAAAAAAAAAAAAAACB
kQAAbgAAALavAAAAAAAAAAAAAAAAAABYCQAAAAAAAO+RAACoAQAAf4cAAD4AAAC9hwAALAAAAD6O
AAAAAAAA6YcAACQAAAANiAAAqwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf4cA
AAAAAAB/hwAAAAAAAH+HAAAAAAAAYasAAAAAAABhqwAAAAAAAGwJAAAAAAAAbAkAAKRgAAAQagAA
AAAAAAAAAAAAAAAA5o0AAFgAAABsCQAAAAAAAGwJAAAAAAAAEGoAAAAAAAACAAEBAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERlbGF5
ZWQgQ29udHJpYnV0aW9ucw1OdW1iZXIHU291cmNlB1RpdGxlB1F1ZXN0aW9ucwcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcT
IEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0
ZW1zJmxhbmc9ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQtMDEwNCIgFEQgMTA0FQcTIEhZUEVS
TElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1m
b2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZzb3VyY2U9TWluZHNwZWVkJTIwVGVjaG5v
bG9naWVzLCUyMEluYy4iIBRNaW5kc3BlZWQgVGVjaG5vbG9naWVzLCBJbmMuFQdEaXNjdXNzaW9u
IG9mIHRoZSBwcm9wb3NlZCBBcHBlbmRpeCBJSUkgb2YgRy43MjkHEyBIWVBFUkxJTksgImh0dHA6
Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJl
bnQ9VDA1LVNHMTYtMDUwNzI2LUQmcXVlc3Rpb249UTEwLzE2IiAUUTEwLzE2FQcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9t
ZWV0aW5nZG9jLmFzcD90eXBlPW1pdGVtcyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1E
LTAxMTEiIBREIDExMRUHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5n
ZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmc291
cmNlPU1hdHN1c2hpdGElMjBFbGVjdHJpYyUyMChQYW5hc29uaWMpIiAUTWF0c3VzaGl0YSBFbGVj
dHJpYyAoUGFuYXNvbmljKRUHUGF0ZW50IGludGVudCBkZWNsYXJhdGlvbiBmb3IgdGhlIEcuNzI5
RVYgc3RhbmRhcmQHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9j
LmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmcXVlc3Rp
b249UTEwLzE2IiAUUTEwLzE2FQcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRp
bmdkb2MuYXNwP3R5cGU9bWl0ZW1zJmxhbmc9ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQtMDEz
NCIgFEQgMTM0FQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2Mu
YXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZzb3VyY2U9
RnJhbmNlJTIwVGVsZWNvbSIgFEZyYW5jZSBUZWxlY29tFQdGcmFuY2UgVGVsZWNvbSBHNzI5RVYg
SVBSIFN0YXRlbWVudAcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdk
b2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZxdWVz
dGlvbj1RMTAvMTYiIBRRMTAvMTYVBwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21k
L21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0ZW1zJmxhbmc9ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2
LUQtMDEzNSIgFEQgMTM1FQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRp
bmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZz
b3VyY2U9RnJhbmNlJTIwVGVsZWNvbSIgFEZyYW5jZSBUZWxlY29tFQdGcmFuY2UgVGVsZWNvbSBH
NzI5RVYgQ2FuZGlkYXRlOiBIaWdoIGxldmVsIGRlc2NyaXB0aW9uIGFuZCBjb21wbGV4aXR5IGV2
YWx1YXRpb24HEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFz
cD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmcXVlc3Rpb249
UTEwLzE2IiAUUTEwLzE2FQcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHEyBIWVBFUkxJTksgImh0dHA6Ly93
d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD90eXBlPW1pdGVtcyZsYW5nPWUmcGFyZW50PVQw
NS1TRzE2LTA1MDcyNi1ELTAxNTEiIBREIDE1MRUHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1
LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNH
MTYtMDUwNzI2LUQmc291cmNlPUVUUkkiIBRFVFJJFQdIaWdoLWxldmVsIGRlc2NyaXB0aW9uIG9m
IEVUUkkgY2FuZGlkYXRlIGNvZGVjIGZvciBHLjcyOUVWBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3
Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmcGFyZW50PVQw
NS1TRzE2LTA1MDcyNi1EJnF1ZXN0aW9uPVExMC8xNiIgFFExMC8xNhUHBxMgSFlQRVJMSU5LICJo
dHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/dHlwZT1taXRlbXMmbGFuZz1lJnBh
cmVudD1UMDUtU0cxNi0wNTA3MjYtRC0wMTUyIiAURCAxNTIVBxMgSFlQRVJMSU5LICJodHRwOi8v
d3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmcGFyZW50
PVQwNS1TRzE2LTA1MDcyNi1EJnNvdXJjZT1FVFJJIiAURVRSSRUHQ29tcGxleGl0eSBldmFsdWF0
aW9uIG9mIEVUUkkgY2FuZGlkYXRlIGNvZGVjIGZvciBHLjcyOUVWBxMgSFlQRVJMSU5LICJodHRw
Oi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmcGFy
ZW50PVQwNS1TRzE2LTA1MDcyNi1EJnF1ZXN0aW9uPVExMC8xNiIgFFExMC8xNhUHBxMgSFlQRVJM
SU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/dHlwZT1taXRlbXMmbGFu
Zz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRC0wMTUzIiAURCAxNTMVBxMgSFlQRVJMSU5LICJo
dHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMm
cGFyZW50PVQwNS1TRzE2LTA1MDcyNi1EJnNvdXJjZT1FVFJJIiAURVRSSRUHRGVjbGFyYXRpb24g
b2YgSVBSIHBvbGljeSByZWdhcmRpbmcgRy43MjlFViBjYW5kaWRhdGUHEyBIWVBFUkxJTksgImh0
dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZw
YXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmcXVlc3Rpb249UTEwLzE2IiAUUTEwLzE2FQcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcTIEhZUEVSTElO
SyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0ZW1zJmxhbmc9
ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQtMDE3NiIgFEQgMTc2FQcTIEhZUEVSTElOSyAiaHR0
cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBh
cmVudD1UMDUtU0cxNi0wNTA3MjYtRCZzb3VyY2U9U2Ftc3VuZyUyMEVsZWN0cm9uaWNzJTIwQ28u
LCUyMEx0ZC4iIBRTYW1zdW5nIEVsZWN0cm9uaWNzIENvLiwgTHRkLhUHSGlnaC1sZXZlbCBkZXNj
cmlwdGlvbiBvZiBTYW1zdW5nIGNhbmRpZGF0ZSBhbGdvcml0aG0gZm9yIEcuNzI5IEVWIGNvZGVj
BxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1l
JnR5cGU9bWZvbGRlcnMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1EJnF1ZXN0aW9uPVExMC8xNiIg
FFExMC8xNhUHBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5h
c3A/dHlwZT1taXRlbXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRC0wMTc3IiAURCAx
NzcVBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFu
Zz1lJnR5cGU9bWZvbGRlcnMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1EJnNvdXJjZT1TYW1zdW5n
JTIwRWxlY3Ryb25pY3MlMjBDby4sJTIwTHRkLiIgFFNhbXN1bmcgRWxlY3Ryb25pY3MgQ28uLCBM
dGQuFQdEZWNsYXJhdGlvbiBvZiBJUFIgcG9saWN5IGZvciBHLjcyOSBFViBjb2RlYwcTIEhZUEVS
TElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1m
b2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZxdWVzdGlvbj1RMTAvMTYiIBRRMTAvMTYV
BwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9
bWl0ZW1zJmxhbmc9ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQtMDE3OCIgFEQgMTc4FQcTIEhZ
UEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBl
PW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZzb3VyY2U9U2Ftc3VuZyUyMEVsZWN0
cm9uaWNzJTIwQ28uLCUyMEx0ZC4iIBRTYW1zdW5nIEVsZWN0cm9uaWNzIENvLiwgTHRkLhUHUHJv
cG9zYWwgZm9yIGFuIGFwcGxpY2F0aW9uIG9mIEcuVkJSIEVWB1EyMS8xNiwgUTkvMTYHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5n
ZG9jLmFzcD90eXBlPW1pdGVtcyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1ELTAxODMi
IBREIDE4MxUHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFz
cD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmc291cmNlPVRl
eGFzJTIwSW5zdHJ1bWVudHMsJTIwSW5jLiIgFFRleGFzIEluc3RydW1lbnRzLCBJbmMuFQdBcHBl
bmRpeCBJSSBJbXByb3ZlbWVudHMgb3ZlciBHLjcyOSBBbm5leCBCIFZBRDogRXZhbHVhdGlvbiBv
biBUSUEtSVMtNzI3IFRlc3QgQ2FzZXMHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9t
ZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUw
NzI2LUQmcXVlc3Rpb249UTEwLzE2IiAUUTEwLzE2FQcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcH
BxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/dHlwZT1t
aXRlbXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRC0wMTg5IiAURCAxODkVBxMgSFlQ
RVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9
bWZvbGRlcnMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1EJnNvdXJjZT1DYW5hZGEiIBRDYW5hZGEV
B0hpZ2gtbGV2ZWwgZGVzY3JpcHRpb24gb2YgVm9pY2VBZ2UgY2FuZGlkYXRlIGZvciBHLjcyOUVW
BxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1l
JnR5cGU9bWZvbGRlcnMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1EJnF1ZXN0aW9uPVExMC8xNiIg
FFExMC8xNhUHBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5h
c3A/dHlwZT1taXRlbXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRC0wMTkwIiAURCAx
OTAVBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFu
Zz1lJnR5cGU9bWZvbGRlcnMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1EJnNvdXJjZT1DYW5hZGEi
IBRDYW5hZGEVB1ZvaWNlQWdlIElQUiBpbnRlbnQgZGVjbGFyYXRpb24gZm9yIHRoZSBJVFUtVCBH
LjcyOUVWIHNwZWVjaCBjb2RlYwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21l
ZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYt
RCZxdWVzdGlvbj1RMTAvMTYiIBRRMTAvMTYVBwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUu
aW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0ZW1zJmxhbmc9ZSZwYXJlbnQ9VDA1LVNHMTYt
MDUwNzI2LUQtMDE5MSIgFEQgMTkxFQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21k
L21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3
MjYtRCZzb3VyY2U9Tm9ydGVsIiAUTm9ydGVsFQdNZXRob2QgZm9yIEluZm9ybWF0aW9uIEV4Y2hh
bmdlIGluIER5bmFtaWMgQ29vcmRpbmF0aW9uIG9mIFZFLVNQRi9TUEQHEyBIWVBFUkxJTksgImh0
dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZw
YXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmcXVlc3Rpb249UTE4LzE2IiAUUTE4LzE2FQcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcH
BwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcTIEhZUEVSTElO
SyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0ZW1zJmxhbmc9
ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQtMDIxNCIgFEQgMjE0FQcTIEhZUEVSTElOSyAiaHR0
cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnBh
cmVudD1UMDUtU0cxNi0wNTA3MjYtRCZzb3VyY2U9U2llbWVucyIgFFNpZW1lbnMVB0hpZ2ggbGV2
ZWwgZGVzY3JpcHRpb24gb2YgdGhlIHNjYWxhYmxlIDgtMzIga2JpdC9zIGFsZ29yaXRobSBzdWJt
aXR0ZWQgdG8gdGhlIFF1YWxpZmljYXRpb24gVGVzdCBieSBNYXRzdXNoaXRhLCBNaW5kc3BlZWQg
YW5kIFNpZW1lbnMHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9j
LmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmcXVlc3Rp
b249UTEwLzE2IiAUUTEwLzE2FQcHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9t
ZWV0aW5nZG9jLmFzcD90eXBlPW1pdGVtcyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1E
LTAyMTUiIBREIDIxNRUHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5n
ZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LUQmc291
cmNlPVNpZW1lbnMiIBRTaWVtZW5zFQdJUFIgcG9saWN5IHJlZ2FyZGluZyBHLjcyOUVWIGNhbmRp
ZGF0ZQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xh
bmc9ZSZ0eXBlPW1mb2xkZXJzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtRCZxdWVzdGlvbj1RMTAv
MTYiIBRRMTAvMTYVBwcHBwcHBw1UZW1wb3JhcnkgRG9jdW1lbnRzIJYgV1AzDU51bWJlcgdTb3Vy
Y2UHVGl0bGUHUXVlc3Rpb25zBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBxMg
SFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/dHlwZT1taXRl
bXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQtV1AzLTAwNjQiIBQ2NC1XUDMVIAcT
IEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0
eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVREJnNvdXJj
ZT1FZGl0b3IlMjBHLjcyOSUyMEFwcGVuZGl4JTIwSUkiIBRFZGl0b3IgRy43MjkgQXBwZW5kaXgg
SUkVB0RyYWZ0IHRleHQgZm9yIG5ldyBHLjcyOSBBcHBlbmRpeCBJSSAoRy43MjkgQW5uZXggQiBl
bmhhbmNlbWVudHMgaW4gdm9pY2Utb3Zlci1JUCBhcHBsaWNhdGlvbnMpBxMgSFlQRVJMSU5LICJo
dHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMm
c3ViZ3JvdXA9V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmcXVlc3Rpb249UTEwLzE2IiAU
UTEwLzE2FQcHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFz
cD90eXBlPW1pdGVtcyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URC1XUDMtMDA2NSIg
FDY1LVdQMxUgBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5h
c3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmc3ViZ3JvdXA9V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3
MjYtVEQmc291cmNlPVJhcHBvcnRldXIlMjBRMTAvMTYiIBRSYXBwb3J0ZXVyIFExMC8xNhUHUXVh
bGl0eSBBc3Nlc3NtZW50IFF1YWxpZmljYXRpb24gVGVzdCBQbGFuIGZvciB0aGUgSVRVLVQgRy43
MjkgYmFzZWQgZW1iZWRkZWQgdmFyaWFibGUgYml0LXJhdGUgKEcuNzI5RVYpIGV4dGVuc2lvbiB0
byB0aGUgSVRVLVQgRy43MjkgU3BlZWNoIENvZGVjBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0
dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmc3ViZ3JvdXA9V1Az
JnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmcXVlc3Rpb249UTEwLzE2IiAUUTEwLzE2FQcHEyBI
WVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD90eXBlPW1pdGVt
cyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URC1XUDMtMDA2NiIgFDY2LVdQMxUgBxMg
SFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5
cGU9bWZvbGRlcnMmc3ViZ3JvdXA9V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmc291cmNl
PVJhcHBvcnRldXIlMjBRMTAvMTYiIBRSYXBwb3J0ZXVyIFExMC8xNhUHUXVhbGlmaWNhdGlvbiBQ
cm9jZXNzaW5nIFRlc3QgUGxhbiBmb3IgdGhlIElUVS1UIEcuNzI5IGJhc2VkIGVtYmVkZGVkIHZh
cmlhYmxlIGJpdC1yYXRlIChHLjcyOUVWKSBleHRlbnNpb24gdG8gdGhlIElUVS1UIEcuNzI5IFNw
ZWVjaCBDb2RlYwcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2Mu
YXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUw
NzI2LVREJnF1ZXN0aW9uPVExMC8xNiIgFFExMC8xNhUHBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3
Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/dHlwZT1taXRlbXMmbGFuZz1lJnBhcmVudD1UMDUt
U0cxNi0wNTA3MjYtVEQtV1AzLTAwNjciIBQ2Ny1XUDMVIAcTIEhZUEVSTElOSyAiaHR0cDovL3d3
dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3Vw
PVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVREJnNvdXJjZT1SYXBwb3J0ZXVyJTIwUTEwLzE2
IiAUUmFwcG9ydGV1ciBRMTAvMTYVB0ludGVyb3BlcmFiaWxpdHkgU3ViamVjdGl2ZSBUZXN0IFBs
YW4gZm9yIHRoZSBGbG9hdGluZyBQb2ludCBWZXJzaW9uIG9mIEcuNzIyLjEgQW5uZXggQwcTIEhZ
UEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBl
PW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVREJnF1ZXN0aW9u
PVExMC8xNiIgFFExMC8xNhUHBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVl
dGluZ2RvYy5hc3A/dHlwZT1taXRlbXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQt
V1AzLTAwNjgiIBQ2OC1XUDMVIAcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21l
ZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1
LVNHMTYtMDUwNzI2LVREJnNvdXJjZT1SYXBwb3J0ZXVyJTIwUTEwLzE2IiAUUmFwcG9ydGV1ciBR
MTAvMTYVB0cuNzI5RVYgcXVhbGlmaWNhdGlvbiBwaGFzZSB0ZXN0IHJlc3VsdHM6IHN1YmplY3Rp
dmUgYW5kIG9iamVjdGl2ZSAoV0ItUEVTUSkgc2NvcmVzIGZvciBFeHBlcmltZW50IDFiIHdpZGVi
YW5kIGNvbmRpdGlvbnMHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5n
ZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZzdWJncm91cD1XUDMmcGFyZW50PVQwNS1TRzE2
LTA1MDcyNi1URCZxdWVzdGlvbj1RMTAvMTYiIBRRMTAvMTYVBwcTIEhZUEVSTElOSyAiaHR0cDov
L3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0ZW1zJmxhbmc9ZSZwYXJlbnQ9
VDA1LVNHMTYtMDUwNzI2LVRELVdQMy0wMDY5IiAUNjktV1AzFSAHEyBIWVBFUkxJTksgImh0dHA6
Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZzdWJn
cm91cD1XUDMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URCZzb3VyY2U9UmFwcG9ydGV1ciUyMFEx
MC8xNiIgFFJhcHBvcnRldXIgUTEwLzE2FQdHLjcyOUVWIHF1YWxpZmljYXRpb24gcGhhc2UgdGVz
dCByZXN1bHRzOiBFeHBlcmltZW50IDUgKENsZWFuIFNwZWVjaDsgd2lkZSBiYW5kIGNhc2UsIEJp
dCByYXRlIGdyYW51bGFyaXR5KQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21l
ZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1
LVNHMTYtMDUwNzI2LVREJnF1ZXN0aW9uPVExMC8xNiIgFFExMC8xNhUHBwcHBwcHEyBIWVBFUkxJ
TksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD90eXBlPW1pdGVtcyZsYW5n
PWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URC1XUDMtMDA3MSIgFDcxLVdQMxUgBxMgSFlQRVJM
SU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZv
bGRlcnMmc3ViZ3JvdXA9V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmc291cmNlPVJhcHBv
cnRldXIlMjBRMTAvMTYiIBRSYXBwb3J0ZXVyIFExMC8xNhUHUXVhbGlmaWNhdGlvbiBwaGFzZSBv
ZiBHNzI5RVY6IHRlc3QgcmVzdWx0cyAoRXhwIDEtNCkHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cu
aXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZzdWJncm91cD1X
UDMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URCZxdWVzdGlvbj1RMTAvMTYiIBRRMTAvMTYVBwcH
BwcHBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/dHlw
ZT1taXRlbXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQtV1AzLTAwNzMiIBQ3My1X
UDMVIAcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xh
bmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVRE
JnNvdXJjZT1SYXBwb3J0ZXVyJTIwUTEwLzE2IiAUUmFwcG9ydGV1ciBRMTAvMTYVB0cuNzI5RVYg
cXVhbGlmaWNhdGlvbiBwaGFzZSB0ZXN0IHJlc3VsdHM6IEV4cGVyaW1lbnQgNiAoQ2xlYW4gU3Bl
ZWNoOyBiaXQgcmF0ZSBzd2l0Y2hpbmcgY2FzZSkHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1
LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlwZT1tZm9sZGVycyZzdWJncm91cD1XUDMm
cGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URCZxdWVzdGlvbj1RMTAvMTYiIBRRMTAvMTYVBwcTIEhZ
UEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP3R5cGU9bWl0ZW1z
Jmxhbmc9ZSZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVRELVdQMy0wMDc0IiAUNzQtV1AzFSAHEyBI
WVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD9sYW5nPWUmdHlw
ZT1tZm9sZGVycyZzdWJncm91cD1XUDMmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URCZzb3VyY2U9
SVNPL0lFQyUyMEpUQyUyMDEvU0MlMjAyOSIgFElTTy9JRUMgSlRDIDEvU0MgMjkVB1RleHQgZm9y
IEFtZW5kbWVudCAxIHRvIFJlY29tbWVuZGF0aW9uIElUVS1UIFJlYy4gVC44MDAgfCBJU08vSUVD
IDE1NDQ0LTEgIkluZm9ybWF0aW9uIHRlY2hub2xvZ3kgLS0gSlBFRyAyMDAwIGltYWdlIGNvZGlu
ZyBzeXN0ZW06IENvcmUgY29kaW5nIHN5c3RlbSwgQU1FTkRNRU5UIDE6IFByb2ZpbGUgZm9yIGRp
Z2l0YWwgY2luZW1hIGFwcGxpY2F0aW9ucyIgKGZvciBDb25zZW50KQcTIEhZUEVSTElOSyAiaHR0
cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1
Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVREJnF1ZXN0aW9uPVEyMy8xNiIgFFEy
My8xNhUHBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/
dHlwZT1taXRlbXMmbGFuZz1lJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQtV1AzLTAwNzUiIBQ3
NS1XUDMVIAcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pdHUuaW50L21kL21lZXRpbmdkb2MuYXNw
P2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQMyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2
LVREJnNvdXJjZT1FZGl0b3IlMjBHLjcyOSUyMEFwcGVuZGl4JTIwSUlJIiAURWRpdG9yIEcuNzI5
IEFwcGVuZGl4IElJSRUHRHJhZnQgdGV4dCBmb3IgbmV3IEcuNzI5IEFwcGVuZGl4IElJSSAiRy43
MjkgQW5uZXggQiBlbmhhbmNlbWVudHMgaW4gdm9pY2Utb3Zlci1JUCBhcHBsaWNhdGlvbnMiBxMg
SFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5
cGU9bWZvbGRlcnMmc3ViZ3JvdXA9V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmcXVlc3Rp
b249UTEwLzE2IiAUUTEwLzE2FQcHEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9t
ZWV0aW5nZG9jLmFzcD90eXBlPW1pdGVtcyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1U
RC1XUDMtMDA3NiIgFDc2LVdQMxUgBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQv
bWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmc3ViZ3JvdXA9V1AzJnBhcmVudD1U
MDUtU0cxNi0wNTA3MjYtVEQmc291cmNlPVJhcHBvcnRldXIlMjBRMTAvMTYiIBRSYXBwb3J0ZXVy
IFExMC8xNhUHUmFwcG9ydGV1ciBRMTAvMTYgRy43MjlFViBxdWFsaWZpY2F0aW9uIHBoYXNlIHRl
c3QgcmVzdWx0czogQ29tcGxleGl0eSBldmFsdWF0aW9uBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3
Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1lJnR5cGU9bWZvbGRlcnMmc3ViZ3JvdXA9
V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmcXVlc3Rpb249UTEwLzE2IiAUUTEwLzE2FQcH
EyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaXR1LmludC9tZC9tZWV0aW5nZG9jLmFzcD90eXBlPW1p
dGVtcyZsYW5nPWUmcGFyZW50PVQwNS1TRzE2LTA1MDcyNi1URC1XUDMtMDA3NyIgFDc3LVdQMxUg
BxMgSFlQRVJMSU5LICJodHRwOi8vd3d3Lml0dS5pbnQvbWQvbWVldGluZ2RvYy5hc3A/bGFuZz1l
JnR5cGU9bWZvbGRlcnMmc3ViZ3JvdXA9V1AzJnBhcmVudD1UMDUtU0cxNi0wNTA3MjYtVEQmc291
cmNlPVJhcHBvcnRldXIlMjBRMTAvMTYiIBRSYXBwb3J0ZXVyIFExMC8xNhUHUTEwLzE2IEludGVy
aW0gQWN0aXZpdGllcyAoQXByaWwtSnVseSAyMDA1KQcTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5p
dHUuaW50L21kL21lZXRpbmdkb2MuYXNwP2xhbmc9ZSZ0eXBlPW1mb2xkZXJzJnN1Ymdyb3VwPVdQ
MyZwYXJlbnQ9VDA1LVNHMTYtMDUwNzI2LVREJnF1ZXN0aW9uPVExMC8xNiIgFFExMC8xNhUHBw0N
X19fX19fX19fX19fX19fX19fDQMNDQQNDQMNDQQNDS0gEyBQQUdFICBcKiBNRVJHRUZPUk1BVCAU
MhUgLQ1URCA3OSAoUExFTi8xNikNDUNvbnRhY3Q6B1RTQgdUZWw6CSs0MSAyMiA3MzAgNjgwNQ1G
YXg6CSs0MSAyMiA3MzAgNTg1Mw1FbWFpbAkTIEhZUEVSTElOSyAibWFpbHRvOnRzYnNnMTZAaXR1
LmludCIgARR0c2JzZzE2QGl0dS5pbnQVIAcHQXR0ZW50aW9uOiBUaGlzIGlzIG5vdCBhIHB1Ymxp
Y2F0aW9uIG1hZGUgYXZhaWxhYmxlIHRvIHRoZSBwdWJsaWMsIGJ1dCBhbiBpbnRlcm5hbCBJVFUt
VCBEb2N1bWVudCBpbnRlbmRlZCBvbmx5IGZvciB1c2UgYnkgdGhlIE1lbWJlciBTdGF0ZXMgb2Yg
SVRVLCBieSBJVFUtVCBTZWN0b3IgTWVtYmVycyBhbmQgQXNzb2NpYXRlcywgYW5kIHRoZWlyIHJl
c3BlY3RpdmUgc3RhZmYgYW5kIGNvbGxhYm9yYXRvcnMgaW4gdGhlaXIgSVRVIHJlbGF0ZWQgd29y
ay4gSXQgc2hhbGwgbm90IGJlIG1hZGUgYXZhaWxhYmxlIHRvLCBhbmQgdXNlZCBieSwgYW55IG90
aGVyIHBlcnNvbnMgb3IgZW50aXRpZXMgd2l0aG91dCB0aGUgcHJpb3Igd3JpdHRlbiBjb25zZW50
IG9mIElUVS1ULgcHDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFQgAABYIAAAcCAAAHQgAACMIAAAkCAAAMwgAADQI
AAA1CAAANwgAADgIAAA5CAAAOggAADwIAAA9CAAAPggAAD8IAABBCAAAQggAAEMIAABECAAARggA
AEcIAABICAAASQgAAEsIAABMCAAATQgAAE4IAABQCAAAUQgAAFIIAABTCAAAVQgAAFYIAABXCAAA
WAgAAFoIAABbCAAAXAgAAF0IAABfCAAAYAgAAGEIAABiCAAAZAgAAGUIAABmCAAAZwgAAGkIAADv
3tG+0b7Rvq+cj5yAnI+cgJyPnICcj5yAnI+cgJyPnICcj5yAnI+cgJyPnICcj5yAnAAAHBVobGwi
ABZoFGPCAENKFABPSgAAUUoAAGFKFAAAGBVobGwiABZoFGPCAENKFABtSAkEc0gJBAAkFWhsbCIA
FmgUY8IAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkEABwVaGxsIgAWaFVlkABDShQAT0oAAFFKAABh
ShQAACQVaGxsIgAWaFVlkAA+KgFCKgJDShQAbUgJBHBoAAD/AHNICQQAGBVobGwiABZoVWWQAENK
FABtSAkEc0gJBAAgFWiLEQ8AFmhVZZAAQ0oYAE9KAABRSgAAXkoAAGFKGAAAIBVoixEPABZoQh2D
AENKGABPSgAAUUoAAF5KAABhShgAMgAGAAAWCAAAHQgAACQIAAAqCAAANAgAADUIAAD6AAAAAAAA
AAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA
ADgAAAAAAAAAAAAAAAAAAAAAAAAAuAAAa2QAAAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAENAEF1hgM
AQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEDAEAAAAAAAAMAQAAAAAA
AAAG0AsMAQAAAAAAAAwBAAAAAAAAAAbtEAwBAAAAAAAADAEAAAAAAAAABiEFDAEAAAAAAAAMAQAA
AAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2
A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQ
AAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNf
AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEACRUAFiQBSWYB
AAAAZ2RCHYMAAAQBAGdkQh2DAAAGAAYAAPo9AAAwQAAA/v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAIBAQI1CAAANggAADcIAAA4CAAAOQgAADoIAAA7CAAAPAgAAPYAAAAA
AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAC3AABrZAMBAAAWJAEXJAFJZgEAAAAAVAEA
ApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQMAQAAAAAA
AAAAAAAAAAAAAAbQCwwBAAAAAAAAAAAAAAAAAAAABu0QDAEAAAAAAAAAAAAAAAAAAAAGIQUMAQAA
AAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA
/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB
CgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAJ
FAAWJAFJZgEAAABnZEIdgwAABzwIAAA9CAAAPggAAD8IAABACAAAQQgAAEIIAABDCAAA9gAAAAAA
AAAAAAAAAPYAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA
AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAAAAALcAAGtkAwIAABYkARckAUlmAQAAAABUAQAC
lmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAA
AAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAA
AAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA
/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/
AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEK
A2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAkU
ABYkAUlmAQAAAGdkQh2DAAAHQwgAAEQIAABFCAAARggAAEcIAABICAAASAAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2T1AgAA
FiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSu
EJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAA
AAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAA
AP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAA
AP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AACKVAEAAAVICAAASQgAAEoIAABLCAAATAgAAE0IAABIAAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZOcDAAAW
JAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4Q
myG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAA
AAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAIpUAQAABU0IAABOCAAATwgAAFAIAABRCAAAUggAAEgAAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk2QQAABYk
ARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCb
IbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAA
AAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/
G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/
NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAilQBAAAFUggAAFMIAABUCAAAVQgAAFYIAABXCAAASAAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TLBQAAFiQB
FyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJsh
vCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAA
AAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b
1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP80
1gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AACKVAEAAAVXCAAAWAgAAFkIAABaCAAAWwgAAFwIAABIAAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZL0GAAAWJAEX
JAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8
JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAA
AAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvW
EAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTW
BgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAIpUAQAABVwIAABdCAAAXggAAF8IAABgCAAAYQgAAEgAAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkrwcAABYkARck
AUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwm
ACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAA
AAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQ
AAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYG
AAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAilQBAAAFYQgAAGIIAABjCAAAZAgAAGUIAABmCAAASAAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2ShCAAAFiQBFyQB
SWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYA
JusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAA
AAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAA
AAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYA
AQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AACKVAEAAAVmCAAAZwgAAGgIAABpCAAAaggAAGsIAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZJMJAAAWJAEXJAFJ
ZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm
6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAA
AAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAA
AP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgAB
BQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAIpUAQAABWkIAABqCAAAawgAAGwIAABuCAAAbwgAAHAIAABxCAAAcwgAAHQIAAB1CAAAdggA
AHcIAADaCAAA2wgAAN0IAADgCAAA4QgAAOIIAADjCAAAawkAAGwJAACICQAAiQkAAIoJAAC7CQAA
vAkAACwKAAAtCgAAMwoAADQKAAA1CgAANgoAADgKAAA5CgAAOgoAADsKAAA9CgAAPgoAAD8KAABA
CgAAQgoAAEMKAABECgAARQoAAEcKAABICgAASQoAAEoKAABMCgAATQoAAE4KAABPCgAAUQoAAFIK
AABTCgAAVAoAAFUKAAC4CgAAuQoAALsKAAC+CgAAvwoAAMAKAADBCgAATAsAAE0LAADz4NHg8+DR
4PPg0brguqfguuC64LrguuDzuuC64Lrg0eDz4NHg8+DR4PPg0eDz4NHg8+DR4PPg0brguqfguuC6
4LokFWhsbCIAFmhEb5oAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkEAC0DagAAAAAVaGxsIgAWaBRj
wgA+KgFCKgJDShQAVQgBbUgJBHBoAAD/AHNICQQcFWhsbCIAFmgUY8IAQ0oUAE9KAABRSgAAYUoU
AAAkFWhsbCIAFmgUY8IAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkEABgVaGxsIgAWaBRjwgBDShQA
bUgJBHNICQRCawgAAGwIAABtCAAAbggAAG8IAABwCAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2SFCgAAFiQBFyQBSWYB
AAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusE
AAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAA
BiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/
AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUD
AAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AACKVAEAAAVwCAAAcQgAAHIIAABzCAAAdAgAAHUIAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZHcLAAAWJAEXJAFJZgEA
AAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQA
AAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAG
IQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8A
AAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMA
ADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AIpUAQAABXUIAAB2CAAA4ggAAIoJAAC7CQAANQoAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkaQwAABYkARckAUlmAQAA
AABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAA
AAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYh
BQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8E
AQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAA
AP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAA
NNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
ilQBAAAFNQoAADYKAAA3CgAAOAoAADkKAAA6CgAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2RbDQAAFiQBFyQBSWYBAAAA
AFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAA
AAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEF
AAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQB
AAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA
/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA0
1gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACK
VAEAAAU6CgAAOwoAADwKAAA9CgAAPgoAAD8KAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZE0OAAAWJAEXJAFJZgEAAAAA
VAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAA
AAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUA
AAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEA
AAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/
AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTW
BgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpU
AQAABT8KAABACgAAQQoAAEIKAABDCgAARAoAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkPw8AABYkARckAUlmAQAAAABU
AQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAA
AAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAA
AAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAA
AAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8A
AAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYG
AAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQB
AAAFRAoAAEUKAABGCgAARwoAAEgKAABJCgAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2QxEAAAFiQBFyQBSWYBAAAAAFQB
AAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAA
AAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAA
AAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAA
AAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAA
AP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYA
AQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA
AAVJCgAASgoAAEsKAABMCgAATQoAAE4KAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZCMRAAAWJAEXJAFJZgEAAAAAVAEA
ApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAA
AAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAA
AAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA
/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB
CgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAA
BU4KAABPCgAAUAoAAFEKAABSCgAAUwoAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkFRIAABYkARckAUlmAQAAAABUAQAC
lmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAA
AAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAA
AAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA
/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/
AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEK
A2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAF
UwoAAFQKAADACgAAbgsAAKELAAAbDAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2QHEwAAFiQBFyQBSWYBAAAAAFQBAAKW
bAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAA
AAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAA
AAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/
BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8A
AAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoD
bABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVN
CwAAbAsAAG0LAABuCwAAoQsAAKILAAASDAAAEwwAABkMAAAaDAAAGwwAABwMAAAeDAAAHwwAACAM
AAAhDAAAIwwAACQMAAAlDAAAJgwAACgMAAApDAAAKgwAACsMAAAtDAAALgwAAC8MAAAwDAAAMgwA
ADMMAAA0DAAANQwAADcMAAA4DAAAOQwAADoMAAA8DAAAPQwAAD4MAAA/DAAAQQwAAEIMAABDDAAA
RAwAAEYMAABHDAAASAwAAEkMAABLDAAATAwAAE0MAABODAAAUAwAAFEMAABSDAAAUwwAAFUMAABW
DAAAVwwAAFgMAABZDAAAWgwAAFsMAABcDAAAXQwAAF8MAABgDAAA7dbtydbt1u3W7brtye267cnt
uu3J7brtye267cntuu3J7brtye267cntuu3J7brtye267cntuu3J7brtp8ntuu3JJBVoGGfQABZo
FGPCAD4qAUIqAkNKFABtSAwEcGgAAP8Ac0gMBAAcFWhsbCIAFmgUY8IAQ0oUAE9KAABRSgAAYUoU
AAAYFWhsbCIAFmgUY8IAQ0oUAG1ICQRzSAkEAC0DagAAAAAVaGxsIgAWaBRjwgA+KgFCKgJDShQA
VQgBbUgJBHBoAAD/AHNICQQkFWhsbCIAFmgUY8IAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkEQhsM
AAAcDAAAHQwAAB4MAAAfDAAAIAwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk+RMAABYkARckAUlmAQAAAABUAQAClmwA
BdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAA
AAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAA
AAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQB
AAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA
/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wA
YfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFIAwA
ACEMAAAiDAAAIwwAACQMAAAlDAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TrFAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF
1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAA
AAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAA
AAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEA
ABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/
HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh
9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAUlDAAA
JgwAACcMAAAoDAAAKQwAACoMAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZN0VAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXW
GAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAA
AAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAA
AAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAA
FPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c
1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2
A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABSoMAAAr
DAAALAwAAC0MAAAuDAAALwwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkzxYAABYkARckAUlmAQAAAABUAQAClmwABdYY
DAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAA
AAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAA
AAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU
9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzW
EAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYD
XwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFLwwAADAM
AAAxDAAAMgwAADMMAAA0DAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TBFwAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgM
AQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAA
AAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAA
AAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2
A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQ
AAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNf
AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAU0DAAANQwA
ADYMAAA3DAAAOAwAADkMAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZLMYAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwB
AAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAA
AAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAA
AAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYD
ySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAA
AAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18A
cNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABTkMAAA6DAAA
OwwAADwMAAA9DAAAPgwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkpRkAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEA
AAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAA
BtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAA
AAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJ
JhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAA
AP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw
1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFPgwAAD8MAABA
DAAAQQwAAEIMAABDDAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2SXGgAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAA
DAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG
0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAA
ABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8km
FTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA
/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDW
KAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVDDAAARAwAAEUM
AABGDAAARwwAAEgMAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZIkbAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAM
AQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQ
CwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAA
E9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYV
NgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/
AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYo
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABUgMAABJDAAASgwA
AEsMAABMDAAATQwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAkUABYkAUlmAQAAAGdkQh2DALcAAGtkexwAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwB
AAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtAL
AAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT
1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2
ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8A
AAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFTQwAAE4MAABPDAAA
UAwAAFEMAABSDAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2RtHQAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEA
AAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsA
AAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPW
MAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYB
F/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAA
AP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVSDAAAUwwAAFQMAABV
DAAAVgwAAFcMAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ
FAAWJAFJZgEAAABnZEIdgwC3AABrZF8eAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAA
DAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAA
AAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9Yw
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX
9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA
/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABVcMAABYDAAAWQwAAFoM
AABbDAAAXAwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkU
ABYkAUlmAQAAAGdkQh2DALcAAGtkUR8AABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAM
AQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAA
AAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2
AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/
AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFXAwAAF0MAABeDAAAXwwA
AGAMAABhDAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQA
FiQBSWYBAAAAZ2RCHYMAtwAAa2RDIAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwB
AAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAA
AAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YD
AAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8A
AAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVgDAAAYQwAAGIMAABkDAAA
ZQwAAGYMAABnDAAAaQwAAGoMAABrDAAAbAwAAG4MAABvDAAAcAwAAHEMAABzDAAAdAwAAHUMAAB2
DAAAeAwAAHkMAAB6DAAAewwAAH0MAAB+DAAAfwwAAIAMAACCDAAAgwwAAIQMAACFDAAAhwwAAIgM
AACJDAAAigwAAIsMAADuDAAA7wwAAPEMAAD0DAAA9QwAAPYMAAD3DAAAbw0AAHANAAB+DQAAfw0A
AIANAACkDQAApQ0AABUOAAAWDgAAHA4AAB0OAAAeDgAAHw4AACAOAACDDgAAhA4AAIYOAACJDgAA
ig4AAIsOAACMDgAABA8AAAUPAAATDwAA7d7t0e3e7dHt3u3R7d7t0e3e7dHt3u3R7d7t0e3e7dHt
3rrtuqftuu267brtuu3Ruu267brt3rrtuqftuu267brtJBVobGwiABZoRG+aAD4qAUIqAkNKFABt
SAkEcGgAAP8Ac0gJBAAtA2oAAAAAFWhsbCIAFmgUY8IAPioBQioCQ0oUAFUIAW1ICQRwaAAA/wBz
SAkEGBVobGwiABZoFGPCAENKFABtSAkEc0gJBAAcFWhsbCIAFmgUY8IAQ0oUAE9KAABRSgAAYUoU
AAAkFWhsbCIAFmgUY8IAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkEQmEMAABiDAAAYwwAAGQMAABl
DAAAZgwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYk
AUlmAQAAAGdkQh2DALcAAGtkNSEAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAA
DAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAA
AAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAA
GPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA
/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFZgwAAGcMAABoDAAAaQwAAGoM
AABrDAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQB
SWYBAAAAZ2RCHYMAtwAAa2QnIgAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAM
AQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAA
AAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY
9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/
AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVrDAAAbAwAAG0MAABuDAAAbwwA
AHAMAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJ
ZgEAAABnZEIdgwC3AABrZBkjAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwB
AAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAA
AAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwB
AAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2
AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8A
AAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABXAMAABxDAAAcgwAAHMMAAB0DAAA
dQwAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlm
AQAAAGdkQh2DALcAAGtkCyQAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEA
AAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAA
AAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYD
AAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAA
AP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFdQwAAHYMAAB3DAAAeAwAAHkMAAB6
DAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYB
AAAAZ2RCHYMAtwAAa2T9JAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAA
BAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAA
AAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMA
ABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA
/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAV6DAAAewwAAHwMAAB9DAAAfgwAAH8M
AABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEA
AABnZEIdgwC3AABrZO8lAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAE
AQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAA
AAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAA
GtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/
HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABX8MAACADAAAgQwAAIIMAACDDAAAhAwA
AEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAA
AGdkQh2DALcAAGtk4SYAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQB
AAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAA
AAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa
1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d
1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFhAwAAIUMAACGDAAAhwwAAIgMAACJDAAA
SAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAA
Z2RCHYMAtwAAa2TTJwAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEA
AAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAA
AAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrW
EAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3W
EAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAWJDAAAigwAAPYMAACADQAApA0AAB4OAABI
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABn
ZEIdgwC3AABrZMUoAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAA
BAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAA
AAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQ
AAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQ
AAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABR4OAAAfDgAAiw4AABUPAABnDwAA4Q8AAEgA
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdk
Qh2DALcAAGtktykAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAE
AQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAA
AAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAA
AAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAA
AAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFEw8AABQPAAAVDwAAZw8AAGgPAADYDwAA2Q8A
AN8PAADgDwAA4Q8AAOIPAADkDwAA5Q8AAOYPAADnDwAA6Q8AAOoPAADrDwAA7A8AAO4PAADvDwAA
8A8AAPEPAADzDwAA9A8AAPUPAAD2DwAA+A8AAPkPAAD6DwAA+w8AAP0PAAD+DwAA/w8AAAAQAAAC
EAAAAxAAAAQQAAAFEAAABxAAAAgQAAAJEAAAChAAAAwQAAANEAAADhAAAA8QAAAREAAAEhAAABMQ
AAAUEAAAFhAAABcQAAAYEAAAGRAAABsQAAAcEAAAHRAAAB4QAAAgEAAAIRAAACIQAAAjEAAAJRAA
ACYQAAAnEAAAKBAAACoQAAArEAAA6NXI6NXo1ejVudXI1bnVyNW51cjVudXI1bnVyNW51cjVudXI
1bnVrNW51cjVudXI1bnVyNW51cjVudXI1bnVyNW51cgYFWgYZ9AAFmgUY8IAQ0oUAG1IDARzSAwE
ABwVaGxsIgAWaBRjwgBDShQAT0oAAFFKAABhShQAABgVaGxsIgAWaBRjwgBDShQAbUgJBHNICQQA
JBVobGwiABZoFGPCAD4qAUIqAkNKFABtSAkEcGgAAP8Ac0gJBAAtA2oAAAAAFWhsbCIAFmgUY8IA
PioBQioCQ0oUAFUIAW1ICQRwaAAA/wBzSAkEAEThDwAA4g8AAOMPAADkDwAA5Q8AAOYPAABIAAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEId
gwC3AABrZKkqAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEA
AAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAA
Bu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA
/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA
/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABeYPAADnDwAA6A8AAOkPAADqDwAA6w8AAEgAAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2D
ALcAAGtkmysAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAA
CNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG
7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/
AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/
AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAF6w8AAOwPAADtDwAA7g8AAO8PAADwDwAASAAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMA
twAAa2SNLAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI
1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbt
EAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8A
AAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8A
AAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAXwDwAA8Q8AAPIPAADzDwAA9A8AAPUPAABIAAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3
AABrZH8tAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjW
XAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0Q
AAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAA
AP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAA
AP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABfUPAAD2DwAA9w8AAPgPAAD5DwAA+g8AAEgAAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcA
AGtkcS4AABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZc
AATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAA
AAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA
/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA
/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAilQBAAAF+g8AAPsPAAD8DwAA/Q8AAP4PAAD/DwAASAAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAA
a2RjLwAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwA
BPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAA
AAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AACKVAEAAAX/DwAAABAAAAEQAAACEAAAAxAAAAQQAABIAAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABr
ZFUwAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE
8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAA
AAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8A
AAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8A
AAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAIpUAQAABQQQAAAFEAAABhAAAAcQAAAIEAAACRAAAEgAAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk
RzEAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz
/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAA
AAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAA
AP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAA
AP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAilQBAAAFCRAAAAoQAAALEAAADBAAAA0QAAAOEAAASAAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2Q5
MgAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/
3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAA
AAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA
/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA
/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AACKVAEAAAUOEAAADxAAABAQAAAREAAAEhAAABMQAABIAAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZCsz
AAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//e
BK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAA
AAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/
AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/
AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAIpUAQAABRMQAAAUEAAAFRAAABYQAAAXEAAAGBAAAEgAAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkHTQA
ABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94E
rhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAA
AAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAilQBAAAFGBAAABkQAAAaEAAAGxAAABwQAAAdEAAASAAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2QPNQAA
FiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSu
EJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAA
AAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAA
AP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAA
AP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AACKVAEAAAUdEAAAHhAAAB8QAAAgEAAAIRAAACIQAABIAAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZAE2AAAW
JAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4Q
myG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAA
AAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAIpUAQAABSIQAAAjEAAAJBAAACUQAAAmEAAAJxAAAEgAAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk8zYAABYk
ARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCb
IbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAA
AAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/
G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/
NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAilQBAAAFJxAAACgQAAApEAAAKhAAACsQAAAsEAAASAAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TlNwAAFiQB
FyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJsh
vCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAA
AAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b
1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP80
1gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AACKVAEAAAUrEAAALBAAAC0QAAAuEAAAkRAAAJIQAACUEAAAlxAAAJgQAACZEAAAmhAA
AAYRAAAHEQAACxEAAAwRAAANEQAASBEAAEkRAAC5EQAAuhEAAMARAADBEQAAwhEAAMMRAADEEQAA
JxIAACgSAAAqEgAALRIAAC4SAAAvEgAAMBIAAJwSAACdEgAAoRIAAKISAACjEgAA3RIAAN4SAABO
EwAATxMAAFUTAABWEwAAVxMAAFgTAABZEwAAvBMAAL0TAAC/EwAAwhMAAMMTAADEEwAAxRMAADEU
AAAyFAAANhQAADcUAAA4FAAAbhQAAG8UAADfFAAA4BQAAOYUAADnFAAA6BQAAOkUAADrFAAA7d7H
7ce07cftx+3H7cftp8ftx+3H7d7H7ce07cftx+3H7cftp8ftx+3H7d7H7ce07cftx+3H7cftp8ft
x+3H7d7tGBVobGwiABZoFGPCAENKFABtSAkEc0gJBAAkFWhsbCIAFmhEb5oAPioBQioCQ0oUAG1I
CQRwaAAA/wBzSAkEAC0DagAAAAAVaGxsIgAWaBRjwgA+KgFCKgJDShQAVQgBbUgJBHBoAAD/AHNI
CQQcFWhsbCIAFmgUY8IAQ0oUAE9KAABRSgAAYUoUAAAkFWhsbCIAFmgUY8IAPioBQioCQ0oUAG1I
CQRwaAAA/wBzSAkEQiwQAAAtEAAAmRAAAA0RAABIEQAAwhEAAEgAAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk1zgAABYkARck
AUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwm
ACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAA
AAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQ
AAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYG
AAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAilQBAAAFwhEAAMMRAAAvEgAAoxIAAN0SAABXEwAASAAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TJOQAAFiQBFyQB
SWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYA
JusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAA
AAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAA
AAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYA
AQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AACKVAEAAAVXEwAAWBMAAMQTAAA4FAAAbhQAAOgUAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZLs6AAAWJAEXJAFJ
ZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm
6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAA
AAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAA
AP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgAB
BQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAIpUAQAABegUAADpFAAA6hQAAOsUAADsFAAA7RQAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkrTsAABYkARckAUlm
AQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbr
BAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAA
AAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA
/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEF
AwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAilQBAAAF6xQAAOwUAADtFAAA7hQAAPAUAADxFAAA8hQAAPMUAAD1FAAA9hQAAPcUAAD4FAAA
+hQAAPsUAAD8FAAA/RQAAP8UAAAAFQAAARUAAAIVAAAEFQAABRUAAAYVAAAHFQAACRUAAAoVAAAL
FQAADBUAAA4VAAAPFQAAEBUAABEVAAATFQAAFBUAABUVAAAWFQAAGBUAABkVAAAaFQAAGxUAAB0V
AAAeFQAAHxUAACAVAAAiFQAAIxUAACQVAAAlFQAAJxUAACgVAAApFQAAKhUAACwVAAAtFQAALhUA
AC8VAAAxFQAAMhUAADMVAAA0FQAANhUAADcVAAA4FQAAORUAADsVAAA8FQAAPRUAAD4VAABAFQAA
QRUAAEIVAABDFQAARRUAAEYVAABHFQAASBUAAEoVAABLFQAATBUAAE0VAABPFQAAUBUAAFEVAADz
4NHg8+DR4PPg0eDz4NHg8+DR4PPg0eDz4NHg8+DR4PPg0eDz4NHg8+DR4PPg0eDz4NHg8+DR4PPg
0eDz4NHg8+DR4PPg0eDz4NHg8+DR4PPgAAAAABwVaGxsIgAWaBRjwgBDShQAT0oAAFFKAABhShQA
ACQVaGxsIgAWaBRjwgA+KgFCKgJDShQAbUgJBHBoAAD/AHNICQQAGBVobGwiABZoFGPCAENKFABt
SAkEc0gJBFLtFAAA7hQAAO8UAADwFAAA8RQAAPIUAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZJ88AAAWJAEXJAFJZgEA
AAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQA
AAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAG
IQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8A
AAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMA
ADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AIpUAQAABfIUAADzFAAA9BQAAPUUAAD2FAAA9xQAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkkT0AABYkARckAUlmAQAA
AABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAA
AAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYh
BQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8E
AQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAA
AP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAA
NNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
ilQBAAAF9xQAAPgUAAD5FAAA+hQAAPsUAAD8FAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2SDPgAAFiQBFyQBSWYBAAAA
AFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAA
AAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEF
AAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQB
AAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA
/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA0
1gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACK
VAEAAAX8FAAA/RQAAP4UAAD/FAAAABUAAAEVAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZHU/AAAWJAEXJAFJZgEAAAAA
VAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAA
AAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUA
AAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEA
AAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/
AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTW
BgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpU
AQAABQEVAAACFQAAAxUAAAQVAAAFFQAABhUAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkZ0AAABYkARckAUlmAQAAAABU
AQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAA
AAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAA
AAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAA
AAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8A
AAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYG
AAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQB
AAAFBhUAAAcVAAAIFQAACRUAAAoVAAALFQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2RZQQAAFiQBFyQBSWYBAAAAAFQB
AAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAA
AAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAA
AAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAA
AAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAA
AP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYA
AQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA
AAULFQAADBUAAA0VAAAOFQAADxUAABAVAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZEtCAAAWJAEXJAFJZgEAAAAAVAEA
ApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAA
AAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAA
AAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA
/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB
CgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAA
BRAVAAARFQAAEhUAABMVAAAUFQAAFRUAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkPUMAABYkARckAUlmAQAAAABUAQAC
lmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAA
AAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAA
AAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA
/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/
AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEK
A2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAF
FRUAABYVAAAXFQAAGBUAABkVAAAaFQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2QvRAAAFiQBFyQBSWYBAAAAAFQBAAKW
bAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAA
AAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAA
AAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/
BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8A
AAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoD
bABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAUa
FQAAGxUAABwVAAAdFQAAHhUAAB8VAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZCFFAAAWJAEXJAFJZgEAAAAAVAEAApZs
AAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAA
AAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAA
AAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8E
AQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAA
AP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNs
AGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABR8V
AAAgFQAAIRUAACIVAAAjFQAAJBUAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkE0YAABYkARckAUlmAQAAAABUAQAClmwA
BdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAA
AAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAA
AAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQB
AAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA
/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wA
YfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFJBUA
ACUVAAAmFQAAJxUAACgVAAApFQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2QFRwAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF
1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAA
AAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAA
AAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEA
ABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/
HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh
9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAUpFQAA
KhUAACsVAAAsFQAALRUAAC4VAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZPdHAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXW
GAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAA
AAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAA
AAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAA
FPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c
1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2
A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABS4VAAAv
FQAAMBUAADEVAAAyFQAAMxUAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk6UgAABYkARckAUlmAQAAAABUAQAClmwABdYY
DAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAA
AAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAA
AAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU
9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzW
EAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYD
XwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFMxUAADQV
AAA1FQAANhUAADcVAAA4FQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TbSQAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgM
AQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAA
AAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAA
AAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2
A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQ
AAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNf
AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAU4FQAAORUA
ADoVAAA7FQAAPBUAAD0VAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZM1KAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwB
AAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAA
AAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAA
AAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYD
ySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAA
AAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18A
cNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABT0VAAA+FQAA
PxUAAEAVAABBFQAAQhUAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkv0sAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEA
AAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAA
BtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAA
AAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJ
JhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAA
AP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw
1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFQhUAAEMVAABE
FQAARRUAAEYVAABHFQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2SxTAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAA
DAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG
0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAA
ABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8km
FTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA
/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDW
KAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVHFQAASBUAAEkV
AABKFQAASxUAAEwVAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZKNNAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAM
AQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQ
CwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAA
E9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYV
NgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/
AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYo
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABUwVAABNFQAAThUA
AE8VAABQFQAAURUAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAkUABYkAUlmAQAAAGdkQh2DALcAAGtklU4AABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwB
AAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtAL
AAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT
1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2
ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8A
AAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFURUAAFIVAABTFQAA
VBUAAFUVAABWFQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2SHTwAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEA
AAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsA
AAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPW
MAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYB
F/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAA
AP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVRFQAAUhUAAFQVAABV
FQAAVhUAAFcVAABYFQAAuxUAALwVAAC+FQAAwRUAAMIVAADDFQAAxBUAAE8WAABQFgAAbRYAAG4W
AABvFgAAuBYAALkWAAApFwAAKhcAADAXAAAxFwAAMhcAADMXAAA0FwAAlxcAAJgXAACaFwAAnRcA
AJ4XAACfFwAAoBcAACsYAAAsGAAASRgAAEoYAABLGAAAeBgAAHkYAADpGAAA6hgAAPAYAADxGAAA
8hgAAPMYAAD0GAAAVxkAAFgZAABaGQAAXRkAAF4ZAABfGQAAYBkAAOsZAADsGQAACRoAAAoaAAAL
GgAAMxoAAEEaAABCGgAARBoAAEUaAABGGgAA8d7R3vG63rqn3rreut663rre0breut663vG63rqn
3rreut663rre0breut663vG63rqn3rreut663rre0d7x3tHeJBVobGwiABZoRG+aAD4qAUIqAkNK
FABtSAkEcGgAAP8Ac0gJBAAtA2oAAAAAFWhsbCIAFmgUY8IAPioBQioCQ0oUAFUIAW1ICQRwaAAA
/wBzSAkEGBVobGwiABZoFGPCAENKFABtSAkEc0gJBAAkFWhsbCIAFmgUY8IAPioBQioCQ0oUAG1I
CQRwaAAA/wBzSAkEABwVaGxsIgAWaBRjwgBDShQAT0oAAFFKAABhShQAQlYVAABXFQAAwxUAAG8W
AAC4FgAAMhcAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkU
ABYkAUlmAQAAAGdkQh2DALcAAGtkeVAAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAM
AQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAA
AAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2
AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/
AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFMhcAADMXAACfFwAASxgA
AHgYAADyGAAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQA
FiQBSWYBAAAAZ2RCHYMAtwAAa2RrUQAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwB
AAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAA
AAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YD
AAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8A
AAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAXyGAAA8xgAAF8ZAAALGgAA
MxoAAEEaAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAW
JAFJZgEAAABnZEIdgwC3AABrZF1SAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEA
AAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAA
AAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMA
ABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAA
AP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABUEaAABCGgAAQxoAAEQaAABF
GgAARhoAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYk
AUlmAQAAAGdkQh2DALcAAGtkT1MAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAA
DAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAA
AAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAA
GPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA
/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFRhoAAEcaAABIGgAASRoAAEoa
AABLGgAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQB
SWYBAAAAZ2RCHYMAtwAAa2RBVAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAM
AQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAA
AAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY
9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/
AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVGGgAARxoAAEkaAABKGgAASxoA
AEwaAABOGgAATxoAAFAaAABRGgAAUxoAAFQaAABVGgAAVhoAAFcaAAC6GgAAuxoAAL0aAADAGgAA
wRoAAMIaAADDGgAARhsAAEcbAABeGwAAXxsAAGAbAAC1GwAAthsAACYcAAAnHAAALRwAAC4cAAAv
HAAAMBwAADIcAAAzHAAANBwAADUcAAA3HAAAOBwAADkcAAA6HAAAPBwAAD0cAAA+HAAAPxwAAEEc
AABCHAAAQxwAAEQcAABGHAAARxwAAEgcAABJHAAAShwAAK0cAACuHAAAsBwAAPHe0d7x3tG+8d7R
3vGn3qeU3qfep96n3qfe0afep96n3vHe0d7x3tHe8d7R3vHe0d7x3tHe8afep5QAACQVaGxsIgAW
aERvmgA+KgFCKgJDShQAbUgJBHBoAAD/AHNICQQALQNqAAAAABVobGwiABZoFGPCAD4qAUIqAkNK
FABVCAFtSAkEcGgAAP8Ac0gJBCQVaGxsIgAWaEtOewA+KgFCKgJDShQAbUgJBHBoAAD/AHNICQQA
GBVobGwiABZoFGPCAENKFABtSAkEc0gJBAAkFWhsbCIAFmgUY8IAPioBQioCQ0oUAG1ICQRwaAAA
/wBzSAkEABwVaGxsIgAWaBRjwgBDShQAT0oAAFFKAABhShQAOksaAABMGgAATRoAAE4aAABPGgAA
UBoAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlm
AQAAAGdkQh2DALcAAGtkM1UAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEA
AAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAA
AAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYD
AAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAA
AP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFUBoAAFEaAABSGgAAUxoAAFQaAABV
GgAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYB
AAAAZ2RCHYMAtwAAa2QlVgAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAA
BAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAA
AAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMA
ABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA
/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVVGgAAVhoAAMIaAABgGwAAtRsAAC8c
AABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEA
AABnZEIdgwC3AABrZBdXAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAE
AQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAA
AAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAA
GtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/
HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABS8cAAAwHAAAMRwAADIcAAAzHAAANBwA
AEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAA
AGdkQh2DALcAAGtkCVgAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQB
AAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAA
AAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa
1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d
1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFNBwAADUcAAA2HAAANxwAADgcAAA5HAAA
SAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAA
Z2RCHYMAtwAAa2T7WAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEA
AAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAA
AAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrW
EAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3W
EAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAU5HAAAOhwAADscAAA8HAAAPRwAAD4cAABI
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABn
ZEIdgwC3AABrZO1ZAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAA
BAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAA
AAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQ
AAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQ
AAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABT4cAAA/HAAAQBwAAEEcAABCHAAAQxwAAEgA
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdk
Qh2DALcAAGtk31oAABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAE
AQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAA
AAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAA
AAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAA
AAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFQxwAAEQcAABFHAAARhwAAEccAABIHAAASAAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RC
HYMAtwAAa2TRWwAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQB
AAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAA
AAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwB
AAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAA
AP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAA
AP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAVIHAAASRwAALUcAAAtHQAAZh0AAOAdAABIAAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEId
gwC3AABrZMNcAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEA
AAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAA
Bu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA
/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA
/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABbAcAACzHAAAtBwAALUcAAC2HAAAJB0AACUdAAAr
HQAALB0AAC0dAABmHQAAZx0AANcdAADYHQAA3h0AAN8dAADgHQAA4R0AAOIdAABFHgAARh4AAEge
AABLHgAATB4AAE0eAABOHgAAvB4AAL0eAADDHgAAxB4AAMUeAAAIHwAACR8AAHkfAAB6HwAAgB8A
AIEfAACCHwAAgx8AAIQfAADnHwAA6B8AAOofAADtHwAA7h8AAO8fAADwHwAAXiAAAF8gAABlIAAA
ZiAAAGcgAACtIAAAriAAAB4hAAAfIQAAJSEAACYhAAAnIQAAKCEAACohAAArIQAALCEAAC0hAAAv
IQAAMCEAADEhAADt1u3W7dbt1u3J1u3W7dbtutbt1qft1u3W7dbt1u3J1u3W7dbtutbt1qft1u3W
7dbt1u3J1u3W7dbtuu3J7brtye0kFWhsbCIAFmhEb5oAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkE
ABwVaGxsIgAWaBRjwgBDShQAT0oAAFFKAABhShQAABgVaGxsIgAWaBRjwgBDShQAbUgJBHNICQQA
LQNqAAAAABVobGwiABZoFGPCAD4qAUIqAkNKFABVCAFtSAkEcGgAAP8Ac0gJBCQVaGxsIgAWaBRj
wgA+KgFCKgJDShQAbUgJBHBoAAD/AHNICQRC4B0AAOEdAABNHgAAxR4AAAgfAACCHwAASAAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMA
twAAa2S1XQAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI
1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbt
EAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8A
AAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8A
AAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAWCHwAAgx8AAO8fAABnIAAArSAAACchAABIAAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3
AABrZKdeAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjW
XAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0Q
AAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAA
AP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAA
AP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABSchAAAoIQAAKSEAACohAAArIQAALCEAAEgAAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcA
AGtkmV8AABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZc
AATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAA
AAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA
/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA
/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFLCEAAC0hAAAuIQAALyEAADAhAAAxIQAASAAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAA
a2SLYAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwA
BPP/3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAA
AAAAAAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/
AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/
AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AACKVAEAAAUxIQAAMiEAADMhAAA0IQAANSEAADYhAABIAAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABr
ZH1hAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE
8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAA
AAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8A
AAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8A
AAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAIpUAQAABTEhAAAyIQAANCEAADUhAAA2IQAANyEAADkhAAA6IQAAOyEA
ADwhAAA+IQAAPyEAAEAhAABBIQAAQyEAAEQhAABFIQAARiEAAEghAABJIQAASiEAAEshAABNIQAA
TiEAAE8hAABQIQAAUiEAAFMhAABUIQAAVSEAAFchAABYIQAAWSEAAFohAABcIQAAXSEAAF4hAABf
IQAAYSEAAGIhAABjIQAAZCEAAGYhAABnIQAAaCEAAGkhAABrIQAAbCEAAG0hAABuIQAAcCEAAHEh
AAByIQAAcyEAAHUhAAB2IQAAdyEAAHghAAB6IQAAeyEAAHwhAAB9IQAAfyEAAIAhAACBIQAAgiEA
AIQhAACFIQAAhiEAAIchAACJIQAAiiEAAIshAACMIQAAjiEAAI8hAACQIQAAkSEAAJMhAACUIQAA
lSEAAJYhAADx3tHe8d7R3vHe0d7x3tHe8d7R3vHe0d7x3tHe8d7R3vHe0d7x3tHe8d7R3vHe0d7x
3tHe8d7R3vHe0d7x3tHe8d7R3vHe0d7x3tHe8d7R3vEAAAAAAAAAAAAYFWhsbCIAFmgUY8IAQ0oU
AG1ICQRzSAkEACQVaGxsIgAWaBRjwgA+KgFCKgJDShQAbUgJBHBoAAD/AHNICQQAHBVobGwiABZo
FGPCAENKFABPSgAAUUoAAGFKFABRNiEAADchAAA4IQAAOSEAADohAAA7IQAASAAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2Rv
YgAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/
3gSuEJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAA
AAAAAAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA
/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA
/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AACKVAEAAAU7IQAAPCEAAD0hAAA+IQAAPyEAAEAhAABIAAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZGFj
AAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//e
BK4QmyG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAA
AAAAAAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/
AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/
AAAA/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAIpUAQAABUAhAABBIQAAQiEAAEMhAABEIQAARSEAAEgAAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkU2QA
ABYkARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94E
rhCbIbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAA
AAAAAAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAilQBAAAFRSEAAEYhAABHIQAASCEAAEkhAABKIQAASAAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2RFZQAA
FiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSu
EJshvCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAA
AAAAAAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAA
AP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAA
AP801gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AACKVAEAAAVKIQAASyEAAEwhAABNIQAATiEAAE8hAABIAAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZDdmAAAW
JAEXJAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4Q
myG8JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAA
AAAAAAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAIpUAQAABU8hAABQIQAAUSEAAFIhAABTIQAAVCEAAEgAAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkKWcAABYk
ARckAUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCb
IbwmACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAA
AAAAAAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/
G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/
NNYGAAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAilQBAAAFVCEAAFUhAABWIQAAVyEAAFghAABZIQAASAAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2QbaAAAFiQB
FyQBSWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJsh
vCYAJusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAA
AAAAAAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b
1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP80
1gYAAQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AACKVAEAAAVZIQAAWiEAAFshAABcIQAAXSEAAF4hAABIAAAAAAAAAAAAAAAAPwAAAAAA
AAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZA1pAAAWJAEX
JAFJZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8
JgAm6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAA
AAAAAAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvW
EAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTW
BgABBQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAIpUAQAABV4hAABfIQAAYCEAAGEhAABiIQAAYyEAAEgAAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk/2kAABYkARck
AUlmAQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwm
ACbrBAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAA
AAAAAAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQ
AAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYG
AAEFAwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAilQBAAAFYyEAAGQhAABlIQAAZiEAAGchAABoIQAASAAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2TxagAAFiQBFyQB
SWYBAAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYA
JusEAAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAA
AAAABiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAA
AAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYA
AQUDAAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AACKVAEAAAVoIQAAaSEAAGohAABrIQAAbCEAAG0hAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAA
AAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZONrAAAWJAEXJAFJ
ZgEAAAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm
6wQAAAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAA
AAAGIQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAA
AP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgAB
BQMAADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAIpUAQAABW0hAABuIQAAbyEAAHAhAABxIQAAciEAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAA
AAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtk1WwAABYkARckAUlm
AQAAAABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbr
BAAAAAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAA
AAYhBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8EAQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA
/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEF
AwAANNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAilQBAAAFciEAAHMhAAB0IQAAdSEAAHYhAAB3IQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAA
AAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2THbQAAFiQBFyQBSWYB
AAAAAFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusE
AAAAAAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAA
BiEFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wQBAAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/
AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUD
AAA01gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AACKVAEAAAV3IQAAeCEAAHkhAAB6IQAAeyEAAHwhAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAA
AD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZLluAAAWJAEXJAFJZgEA
AAAAVAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQA
AAAAAAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAG
IQUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
BAEAAAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8A
AAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMA
ADTWBgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AIpUAQAABXwhAAB9IQAAfiEAAH8hAACAIQAAgSEAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkq28AABYkARckAUlmAQAA
AABUAQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAA
AAAAAAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYh
BQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8E
AQAAAAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAA
AP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAA
NNYGAAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
ilQBAAAFgSEAAIIhAACDIQAAhCEAAIUhAACGIQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/
AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2SdcAAAFiQBFyQBSWYBAAAA
AFQBAAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAA
AAAAAAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEF
AAAAAAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQB
AAAAAAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA
/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA0
1gYAAQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACK
VAEAAAWGIQAAhyEAAIghAACJIQAAiiEAAIshAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8A
AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZI9xAAAWJAEXJAFJZgEAAAAA
VAEAApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAA
AAAAAAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUA
AAAAAAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEA
AAAAAP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/
AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTW
BgABCgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpU
AQAABYshAACMIQAAjSEAAI4hAACPIQAAkCEAAEgAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAA
AAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkUABYkAUlmAQAAAGdkQh2DALcAAGtkgXIAABYkARckAUlmAQAAAABU
AQAClmwABdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAA
AAAAAAAAAAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAA
AAAAAAAAAAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAA
AAAA/wQBAAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8A
AAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYG
AAEKA2wAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQB
AAAFkCEAAJEhAACSIQAAkyEAAJQhAACVIQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAA
AAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2RzcwAAFiQBFyQBSWYBAAAAAFQB
AAKWbAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAA
AAAAAAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAA
AAAAAAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAA
AAD/BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAA
AP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYA
AQoDbABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA
AAWVIQAAliEAAAIiAAB8IgAAAiMAAHwjAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAA
AAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZGV0AAAWJAEXJAFJZgEAAAAAVAEA
ApZsAAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAA
AAAAAAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAA
AAAAAAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA
/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgAB
CgNsAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAA
BZYhAACXIQAA+iEAAPshAAD9IQAAACIAAAEiAAACIgAAAyIAAHIiAABzIgAAeiIAAHsiAAB8IgAA
AiMAAAMjAABzIwAAdCMAAHojAAB7IwAAfCMAAH0jAAB+IwAA4SMAAOIjAADkIwAA5yMAAOgjAADp
IwAA6iMAAFkkAABaJAAAYSQAAGIkAABjJAAAiiQAAIskAAD7JAAA/CQAAAIlAAADJQAABCUAAAUl
AAAHJQAACCUAAAklAAAKJQAACyUAACUlAAArJQAA6NXowtXo1ejV6NXo1bXo1ejV6NWm6NXowtXo
1ejV6NXo1bXo1ejV6NWm1bXVpp+OhwAAAAAAAAAAAAAAAAAAAAAAAAAAAAwVaEIdgwAWaFxkZwAA
IBVoixEPABZoQh2DAENKGABPSgAAUUoAAF5KAABhShgAAAwVaEIdgwAWaBRjwgAAHBVobGwiABZo
FGPCAENKFABPSgAAUUoAAGFKFAAAGBVobGwiABZoFGPCAENKFABtSAkEc0gJBAAkFWhsbCIAFmhE
b5oAPioBQioCQ0oUAG1ICQRwaAAA/wBzSAkEACQVaGxsIgAWaBRjwgA+KgFCKgJDShQAbUgJBHBo
AAD/AHNICQQALQNqAAAAABVobGwiABZoFGPCAD4qAUIqAkNKFABVCAFtSAkEcGgAAP8Ac0gJBAAx
fCMAAH0jAADpIwAAYyQAAIokAAAEJQAASAAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAA
AAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAACRQAFiQBSWYBAAAAZ2RCHYMAtwAAa2RXdQAAFiQBFyQBSWYBAAAAAFQBAAKW
bAAF1hgMAQAADAEAAAwBAAAMAQAABAEAAAQBAAAI1lwABPP/3gSuEJshvCYAJusEAAAAAAAAAAAA
AAAAAAAAAAAG0AsAAAAAAAAAAAAAAAAAAAAAAAbtEAAAAAAAAAAAAAAAAAAAAAAABiEFAAAAAAAA
AAAAAAAAAAAAABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/
BAEAABT2A8kmFTYBF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8A
AAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoD
bABh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEAAAUE
JQAABSUAAAYlAAAHJQAACCUAAAklAABIAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAA
AAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAJFAAWJAFJZgEAAABnZEIdgwC3AABrZEl2AAAWJAEXJAFJZgEAAAAAVAEAApZs
AAXWGAwBAAAMAQAADAEAAAwBAAAEAQAABAEAAAjWXAAE8//eBK4QmyG8JgAm6wQAAAAAAAAAAAAA
AAAAAAAAAAbQCwAAAAAAAAAAAAAAAAAAAAAABu0QAAAAAAAAAAAAAAAAAAAAAAAGIQUAAAAAAAAA
AAAAAAAAAAAAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8E
AQAAFPYDySYVNgEX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAA
AP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNs
AGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQAABQkl
AAAKJQAACyUAACUlAAAsJQAAMyUAAEgAAAAAAAAAAAAAAABGAAAAAAAAAAAAAAAAQQAAAAAAAAAA
AAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAAAAAABIVABYkAUlmAQAAAGdkXGRnAGzGEBMA
AAD/AAAAABAAAAEAAAAABAEAZ2RCHYMAAAEAALcAAGtkO3cAABYkARckAUlmAQAAAABUAQAClmwA
BdYYDAEAAAwBAAAMAQAADAEAAAQBAAAEAQAACNZcAATz/94ErhCbIbwmACbrBAAAAAAAAAAAAAAA
AAAAAAAABtALAAAAAAAAAAAAAAAAAAAAAAAG7RAAAAAAAAAAAAAAAAAAAAAAAAYhBQAAAAAAAAAA
AAAAAAAAAAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQB
AAAU9gPJJhU2ARf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA
/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wA
YfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAAAFKyUA
ACwlAAAyJQAAMyUAAEIlAABDJQAAZyUAAGglAADQJQAA0SUAANclAADYJQAA2iUAANslAABvJgAA
cCYAAIgmAACJJgAA6iYAAOsmAABpJwAAaicAAHAnAABxJwAAcycAAHQnAADcJwAA3ScAAOMnAADk
JwAA5icAAOcnAABwKAAAcSgAAIIoAACDKAAAGCkAABkpAACXKQAAmCkAAJ4pAACfKQAAoSkAAKIp
AAAKKgAACyoAABEqAAASKgAAFCoAABUqAACeKgAAnyoAALAqAACxKgAAPisAAD8rAAC9KwAAvisA
AMQrAADFKwAAxysAAMgrAAAwLAAAMSwAADcsAAA4LAAAOiwAADssAADELAAAxSwAANYsAADXLAAA
8+zz7PPj1uPWxNbj1uPWtdbj1uPWtdbj1uPWxNbj1uPWtdbj1uPWtdbj1uPWxNbj1uPWtdbj1uPW
tdbj1uPWxNbj1uPWtdYAAAAcFWgTXGMAFmhcZGcAPioBQioJQ0oUAHBoAABmAAAiFWgTXGMAFmhc
ZGcANQiBPioBQioJQ0oUAFwIgXBoAABmAAAZA2oAAAAAFWgTXGMAFmhcZGcAQ0oUAFUIARAVaBNc
YwAWaFxkZwBDShQAAAwVaEIdgwAWaFxkZwAAGBVoQh2DABZoXGRnAD4qAUIqAnBoAAD/AEczJQAA
OSUAAEMlAABEJQAARSUAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAACcA
AAAAAAAAAAAAAAAAAAAAAAAAEhQAFiQBSWYBAAAAZ2RcZGcAbMYQEwAAAP8A/wAAEAAAAQAAALIA
AGtkLXgAABYkARckAUlmAQAAAAKWHgAENAEF1hgMAQEADAEBAAwBAQAMAQEABgEBAAYBAQAI1lwA
BJT/mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAAAAAAAAAG1QQAAAAAAAAAAAAAAAAAAAAAAAZ9EwAA
AAAAAAAAAAAAAAAAAAAABjUGAAAAAAAAAAAAAAAAAAAAABPWMAAAAAAMAQAAAAAAAAwBAAAAAAAA
DAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAABgEAABT2Ao0SFTYBF/YDAAAa1hAAAAD/AAAA/wAAAP8A
AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A
AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAABIVABYkAUlmAQAAAGdkXGRnAGzGEBMAAAD/AAAAABAAAAEAAAAABEUlAABG
JQAARyUAAEglAABJJQAASiUAAEslAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAA
AAAAAAA7AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
sAAAa2S2eAAAFiQBFyQBSWYBAAAAApYeAAXWGAwBAQAMAQEADAEBAAwBAQAGAQEABgEBAAjWXAAE
lP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAAAAAAAAAAAAbVBAAAAAAAAAAAAAAAAAAAAAAABn0TAAAA
AAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAAAAAAAAAAAAAAE9YwAAAAAAwBAAAAAAAADAEAAAAAAAAM
AQAAAAAAAAwBAAAAAAAABgEAAAAAAAAGAQAAFPYCjRIVNgEX9gMAABrWEAAAAP8AAAD/AAAA/wAA
AP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAA
AP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AAAAEhQAFiQBSWYBAAAAZ2RcZGcAbMYQEwAAAP8A/wAAEAAAAQAAAAAGSyUAAEwl
AABNJQAATiUAAE8lAABQJQAAUSUAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAAOwAAAAAAAAAA
AAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACw
AABrZDx5AAAWJAEXJAFJZgEAAAAClh4ABdYYDAEBAAwBAQAMAQEADAEBAAYBAQAGAQEACNZcAASU
/5gFbQrqHR8kACYEBgAAAAAAAAAAAAAAAAAAAAAABtUEAAAAAAAAAAAAAAAAAAAAAAAGfRMAAAAA
AAAAAAAAAAAAAAAAAAY1BgAAAAAAAAAAAAAAAAAAAAAT1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwB
AAAAAAAADAEAAAAAAAAGAQAAAAAAAAYBAAAU9gKNEhU2ARf2AwAAGtYQAAAA/wAAAP8AAAD/AAAA
/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA
/zTWBgABBQMAADTWBgABCgNsAGH2AwAAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAAASFAAWJAFJZgEAAABnZFxkZwBsxhATAAAA/wD/AAAQAAABAAAAAAZRJQAAUiUA
AFMlAABUJQAAVSUAAFYlAABXJQAA7AAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAADsAAAAAAAAAAAA
AAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAA
AGtkwnkAABYkARckAUlmAQAAAAKWHgAF1hgMAQEADAEBAAwBAQAMAQEABgEBAAYBAQAI1lwABJT/
mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAAAAAAAAAG1QQAAAAAAAAAAAAAAAAAAAAAAAZ9EwAAAAAA
AAAAAAAAAAAAAAAABjUGAAAAAAAAAAAAAAAAAAAAABPWMAAAAAAMAQAAAAAAAAwBAAAAAAAADAEA
AAAAAAAMAQAAAAAAAAYBAAAAAAAABgEAABT2Ao0SFTYBF/YDAAAa1hAAAAD/AAAA/wAAAP8AAAD/
G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/
NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAABIUABYkAUlmAQAAAGdkXGRnAGzGEBMAAAD/AP8AABAAAAEAAAAABlclAABYJQAA
WSUAAFolAABbJQAAXCUAAE4AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsA
AAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQA
FiQBSWYBAAAAZ2RcZGcAbMYQEwAAAP8A/wAAEAAAAQAAAACwAABrZEh6AAAWJAEXJAFJZgEAAAAC
lh4ABdYYDAEBAAwBAQAMAQEADAEBAAYBAQAGAQEACNZcAASU/5gFbQrqHR8kACYEBgAAAAAAAAAA
AAAAAAAAAAAABtUEAAAAAAAAAAAAAAAAAAAAAAAGfRMAAAAAAAAAAAAAAAAAAAAAAAY1BgAAAAAA
AAAAAAAAAAAAAAAT1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAGAQAAAAAA
AAYBAAAU9gKNEhU2ARf2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c
1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2
AwAAcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAFXCUAAF0lAABe
JQAAXyUAAGAlAABhJQAATgAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAA
AAAAAAAAAAAAADsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFAAW
JAFJZgEAAABnZFxkZwBsxhATAAAA/wD/AAAQAAABAAAAALAAAGtkznoAABYkARckAUlmAQAAAAKW
HgAF1hgMAQEADAEBAAwBAQAMAQEABgEBAAYBAQAI1lwABJT/mAVtCuodHyQAJgQGAAAAAAAAAAAA
AAAAAAAAAAAG1QQAAAAAAAAAAAAAAAAAAAAAAAZ9EwAAAAAAAAAAAAAAAAAAAAAABjUGAAAAAAAA
AAAAAAAAAAAAABPWMAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAA
BgEAABT2Ao0SFTYBF/YDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzW
EAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYD
AABw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAVhJQAAYiUAAGMl
AABkJQAAZSUAAGYlAABOAAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAA
AAAAAAAAAAAAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIUABYk
AUlmAQAAAGdkXGRnAGzGEBMAAAD/AP8AABAAAAEAAAAAsAAAa2RUewAAFiQBFyQBSWYBAAAAApYe
AAXWGAwBAQAMAQEADAEBAAwBAQAGAQEABgEBAAjWXAAElP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAA
AAAAAAAAAAbVBAAAAAAAAAAAAAAAAAAAAAAABn0TAAAAAAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAA
AAAAAAAAAAAAE9YwAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAABgEAAAAAAAAG
AQAAFPYCjRIVNgEX9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQ
AAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMA
AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAABWYlAABnJQAA2iUA
AIomAADqJgAAcicAAE4AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAA
AAAAAAAAAAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQAFiQB
SWYBAAAAZ2RcZGcAbMYQEwAAAP8A/wAAEAAAAQAAAACwAABrZNp7AAAWJAEXJAFJZgEAAAAClh4A
BdYYDAEBAAwBAQAMAQEADAEBAAYBAQAGAQEACNZcAASU/5gFbQrqHR8kACYEBgAAAAAAAAAAAAAA
AAAAAAAABtUEAAAAAAAAAAAAAAAAAAAAAAAGfRMAAAAAAAAAAAAAAAAAAAAAAAY1BgAAAAAAAAAA
AAAAAAAAAAAT1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAGAQAAAAAAAAYB
AAAU9gKNEhU2ARf2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAA
AAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAA
cNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAFcicAAHMnAADmJwAA
hCgAABgpAACgKQAATgAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAA
AAAAAAAAADsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFAAWJAFJ
ZgEAAABnZFxkZwBsxhATAAAA/wD/AAAQAAABAAAAALAAAGtkYHwAABYkARckAUlmAQAAAAKWHgAF
1hgMAQEADAEBAAwBAQAMAQEABgEBAAYBAQAI1lwABJT/mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAA
AAAAAAAG1QQAAAAAAAAAAAAAAAAAAAAAAAZ9EwAAAAAAAAAAAAAAAAAAAAAABjUGAAAAAAAAAAAA
AAAAAAAAABPWMAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAABgEA
ABT2Ao0SFTYBF/YDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAA
AP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw
1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAWgKQAAoSkAABQqAACy
KgAAPisAAMYrAABOAAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAA
AAAAAAAAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIUABYkAUlm
AQAAAGdkXGRnAGzGEBMAAAD/AP8AABAAAAEAAAAAsAAAa2TmfAAAFiQBFyQBSWYBAAAAApYeAAXW
GAwBAQAMAQEADAEBAAwBAQAGAQEABgEBAAjWXAAElP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAAAAAA
AAAAAAbVBAAAAAAAAAAAAAAAAAAAAAAABn0TAAAAAAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAAAAAA
AAAAAAAAE9YwAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAABgEAAAAAAAAGAQAA
FPYCjRIVNgEX9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA
/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDW
KAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAABcYrAADHKwAAOiwAANgs
AAAwLQAAuC0AAE4AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAA
AAAAAAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQAFiQBSWYB
AAAAZ2RcZGcAbMYQEwAAAP8A/wAAEAAAAQAAAACwAABrZGx9AAAWJAEXJAFJZgEAAAAClh4ABdYY
DAEBAAwBAQAMAQEADAEBAAYBAQAGAQEACNZcAASU/5gFbQrqHR8kACYEBgAAAAAAAAAAAAAAAAAA
AAAABtUEAAAAAAAAAAAAAAAAAAAAAAAGfRMAAAAAAAAAAAAAAAAAAAAAAAY1BgAAAAAAAAAAAAAA
AAAAAAAT1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAGAQAAAAAAAAYBAAAU
9gKNEhU2ARf2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/
AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAcNYo
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAF1ywAADAtAAAxLQAAry0A
ALAtAAC2LQAAty0AALktAAC6LQAAIi4AACMuAAApLgAAKi4AACwuAAAtLgAAti4AALcuAADILgAA
yS4AAEQvAABFLwAAwy8AAMQvAADKLwAAyy8AAM0vAADOLwAANjAAADcwAAA9MAAAPjAAAEAwAABB
MAAAyjAAAMswAADcMAAA3TAAAEoxAABLMQAAyTEAAMoxAADQMQAA0TEAANgxAADZMQAAQTIAAEIy
AABIMgAASTIAAEsyAABMMgAA1TIAANYyAADnMgAA6DIAAB8zAAAgMwAAnjMAAJ8zAAClMwAApjMA
AK0zAACuMwAAFjQAABc0AAAdNAAAHjQAACA0AAAhNAAAqjQAAKs0AAC8NAAAvTQAAB01AAAeNQAA
nDUAAJ01AACjNQAApDUAAKY1AAD36vfq2+r36vfqyer36vfq2+r36vfq2+r36vfqyer36vfq2+r3
6vfq2+r36vfqyer36vfq2+r36vfq2+r36vfqyer36vfq2+r36vfq2+r3AAAAIhVoE1xjABZoXGRn
ADUIgT4qAUIqCUNKFABcCIFwaAAAZgAAHBVoE1xjABZoXGRnAD4qAUIqCUNKFABwaAAAZgAAGQNq
AAAAABVoE1xjABZoXGRnAENKFABVCAEQFWgTXGMAFmhcZGcAQ0oUAE+4LQAAuS0AACwuAADKLgAA
RC8AAMwvAABOAAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAA
AAAAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIUABYkAUlmAQAA
AGdkXGRnAGzGEBMAAAD/AP8AABAAAAEAAAAAsAAAa2TyfQAAFiQBFyQBSWYBAAAAApYeAAXWGAwB
AQAMAQEADAEBAAwBAQAGAQEABgEBAAjWXAAElP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAAAAAAAAAA
AAbVBAAAAAAAAAAAAAAAAAAAAAAABn0TAAAAAAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAAAAAAAAAA
AAAAE9YwAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAABgEAAAAAAAAGAQAAFPYC
jRIVNgEX9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAA
AP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWKAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAABcwvAADNLwAAQDAAAN4wAABK
MQAA0jEAAE4AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAA
AAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQAFiQBSWYBAAAA
Z2RcZGcAbMYQEwAAAP8A/wAAEAAAAQAAAACwAABrZHh+AAAWJAEXJAFJZgEAAAAClh4ABdYYDAEB
AAwBAQAMAQEADAEBAAYBAQAGAQEACNZcAASU/5gFbQrqHR8kACYEBgAAAAAAAAAAAAAAAAAAAAAA
BtUEAAAAAAAAAAAAAAAAAAAAAAAGfRMAAAAAAAAAAAAAAAAAAAAAAAY1BgAAAAAAAAAAAAAAAAAA
AAAT1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAGAQAAAAAAAAYBAAAU9gKN
EhU2ARf2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA
/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAcNYoAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAF0jEAANMxAADUMQAA1TEAANYx
AADXMQAATgAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAA
ADsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFAAWJAFJZgEAAABn
ZFxkZwBsxhATAAAA/wD/AAAQAAABAAAAALAAAGtk/n4AABYkARckAUlmAQAAAAKWHgAF1hgMAQEA
DAEBAAwBAQAMAQEABgEBAAYBAQAI1lwABJT/mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAAAAAAAAAG
1QQAAAAAAAAAAAAAAAAAAAAAAAZ9EwAAAAAAAAAAAAAAAAAAAAAABjUGAAAAAAAAAAAAAAAAAAAA
ABPWMAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAABgEAABT2Ao0S
FTYBF/YDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/
AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAXXMQAA2DEAAEsyAADpMgAAHzMA
AKczAABOAAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAA
OwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIUABYkAUlmAQAAAGdk
XGRnAGzGEBMAAAD/AP8AABAAAAEAAAAAsAAAa2SEfwAAFiQBFyQBSWYBAAAAApYeAAXWGAwBAQAM
AQEADAEBAAwBAQAGAQEABgEBAAjWXAAElP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAAAAAAAAAAAAbV
BAAAAAAAAAAAAAAAAAAAAAAABn0TAAAAAAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAAAAAAAAAAAAAA
E9YwAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAABgEAAAAAAAAGAQAAFPYCjRIV
NgEX9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8A
AAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWKAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAABaczAACoMwAAqTMAAKozAACrMwAA
rDMAAE4AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQAFiQBSWYBAAAAZ2Rc
ZGcAbMYQEwAAAP8A/wAAEAAAAQAAAACwAABrZAqAAAAWJAEXJAFJZgEAAAAClh4ABdYYDAEBAAwB
AQAMAQEADAEBAAYBAQAGAQEACNZcAASU/5gFbQrqHR8kACYEBgAAAAAAAAAAAAAAAAAAAAAABtUE
AAAAAAAAAAAAAAAAAAAAAAAGfRMAAAAAAAAAAAAAAAAAAAAAAAY1BgAAAAAAAAAAAAAAAAAAAAAT
1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAGAQAAAAAAAAYBAAAU9gKNEhU2
ARf2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAA
AP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAcNYoAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAFrDMAAK0zAAAgNAAAvjQAAB01AACl
NQAATgAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFAAWJAFJZgEAAABnZFxk
ZwBsxhATAAAA/wD/AAAQAAABAAAAALAAAGtkkIAAABYkARckAUlmAQAAAAKWHgAF1hgMAQEADAEB
AAwBAQAMAQEABgEBAAYBAQAI1lwABJT/mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAAAAAAAAAG1QQA
AAAAAAAAAAAAAAAAAAAAAAZ9EwAAAAAAAAAAAAAAAAAAAAAABjUGAAAAAAAAAAAAAAAAAAAAABPW
MAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAABgEAABT2Ao0SFTYB
F/YDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA
/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAWlNQAApjUAABk2AAC/NgAAmzcAACM4
AABOAAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIUABYkAUlmAQAAAGdkXGRn
AGzGEBMAAAD/AP8AABAAAAEAAAAAsAAAa2QWgQAAFiQBFyQBSWYBAAAAApYeAAXWGAwBAQAMAQEA
DAEBAAwBAQAGAQEABgEBAAjWXAAElP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAAAAAAAAAAAAbVBAAA
AAAAAAAAAAAAAAAAAAAABn0TAAAAAAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAAAAAAAAAAAAAAE9Yw
AAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAABgEAAAAAAAAGAQAAFPYCjRIVNgEX
9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/
AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWKAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAABaY1AACnNQAADzYAABA2AAAWNgAAFzYA
ABk2AAAaNgAAqTYAAKo2AAC9NgAAvjYAAJs3AACcNwAAGjgAABs4AAAhOAAAIjgAACQ4AAAlOAAA
jTgAAI44AACUOAAAlTgAAJc4AACYOAAALTkAAC45AABHOQAASDkAAKo5AACrOQAAKToAACo6AAAw
OgAAMToAADM6AAA0OgAAnDoAAJ06AACjOgAApDoAAKY6AACnOgAAMDsAADE7AABCOwAAQzsAAJY7
AACXOwAAFTwAABY8AAAcPAAAHTwAAB88AAAgPAAAiDwAAIk8AACPPAAAkDwAAJI8AACTPAAAHD0A
AB09AAAuPQAALz0AAFw9AABdPQAA2z0AANw9AADiPQAA4z0AAOU9AADmPQAA5z0AAPLp8tfy6fLp
8sjy6fLp8sjy6fLp8tfy6fLp8sjy6fLp8sjy6fLp8tfy6fLp8sjy6fLp8sjy6fLp8tfy6fLp8sjy
6fLp8sjy6cS9AAAAAAwVaEIdgwAWaJFe1wAABhZokV7XAAAcFWgTXGMAFmhcZGcAPioBQioJQ0oU
AHBoAABmAAAiFWgTXGMAFmhcZGcANQiBPioBQioJQ0oUAFwIgXBoAABmAAAQFWgTXGMAFmhcZGcA
Q0oUAAAZA2oAAAAAFWgTXGMAFmhcZGcAQ0oUAFUIAQBKIzgAACQ4AACXOAAASTkAAKo5AAAyOgAA
TgAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFAAWJAFJZgEAAABnZFxkZwBs
xhATAAAA/wD/AAAQAAABAAAAALAAAGtknIEAABYkARckAUlmAQAAAAKWHgAF1hgMAQEADAEBAAwB
AQAMAQEABgEBAAYBAQAI1lwABJT/mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAAAAAAAAAG1QQAAAAA
AAAAAAAAAAAAAAAAAAZ9EwAAAAAAAAAAAAAAAAAAAAAABjUGAAAAAAAAAAAAAAAAAAAAABPWMAAA
AAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAABgEAABT2Ao0SFTYBF/YD
AAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAA
AP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAUyOgAAMzoAAKY6AABEOwAAljsAAB48AABO
AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIUABYkAUlmAQAAAGdkXGRnAGzG
EBMAAAD/AP8AABAAAAEAAAAAsAAAa2QiggAAFiQBFyQBSWYBAAAAApYeAAXWGAwBAQAMAQEADAEB
AAwBAQAGAQEABgEBAAjWXAAElP+YBW0K6h0fJAAmBAYAAAAAAAAAAAAAAAAAAAAAAAbVBAAAAAAA
AAAAAAAAAAAAAAAABn0TAAAAAAAAAAAAAAAAAAAAAAAGNQYAAAAAAAAAAAAAAAAAAAAAE9YwAAAA
AAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAABgEAAAAAAAAGAQAAFPYCjRIVNgEX9gMA
ABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA
/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh9gMAAHDWKAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAABR48AAAfPAAAkjwAADA9AABcPQAA5D0AAE4A
AAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQAFiQBSWYBAAAAZ2RcZGcAbMYQ
EwAAAP8AAAAAEAAAAQAAAACwAABrZKiCAAAWJAEXJAFJZgEAAAAClh4ABdYYDAEBAAwBAQAMAQEA
DAEBAAYBAQAGAQEACNZcAASU/5gFbQrqHR8kACYEBgAAAAAAAAAAAAAAAAAAAAAABtUEAAAAAAAA
AAAAAAAAAAAAAAAGfRMAAAAAAAAAAAAAAAAAAAAAAAY1BgAAAAAAAAAAAAAAAAAAAAAT1jAAAAAA
DAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAAAAAGAQAAAAAAAAYBAAAU9gKNEhU2ARf2AwAA
GtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/
HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAcNYoAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAF5D0AAOU9AADmPQAA5z0AAPo9AAD8PQAA/T0A
AP89AABOAAAAAAAAAAAAAAAASQAAAAAAAAAAAAAAAEkAAAAAAAAAAAAAAABBAAAAAAAAAAAAAAAA
PwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAEAAAAHAAADJAFhJAFn
ZKtE6AAABAAAZ2RCHYMAALAAAGtkLoMAABYkARckAUlmAQAAAAKWHgAF1hgMAQEADAEBAAwBAQAM
AQEABgEBAAYBAQAI1lwABJT/mAVtCuodHyQAJgQGAAAAAAAAAAAAAAAAAAAAAAAG1QQAAAAAAAAA
AAAAAAAAAAAAAAZ9EwAAAAAAAAAAAAAAAAAAAAAABjUGAAAAAAAAAAAAAAAAAAAAABPWMAAAAAAM
AQAAAAAAAAwBAAAAAAAADAEAAAAAAAAMAQAAAAAAAAYBAAAAAAAABgEAABT2Ao0SFTYBF/YDAAAa
1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d
1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAABw1igAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAfnPQAA+T0AAPo9AAD7PQAA/T0AAP49AAAAPgAA
AT4AAAM+AAAEPgAABj4AAAg+AAAJPgAAHz4AACA+AAAhPgAAIj4AACg+AAAqPgAANT4AADY+AAA9
PgAAcz4AAHQ+AACYPgAAmT4AAJo+AACpPgAAqj4AAK0+AAC3PgAA9D4AAA4/AAAtQAAALkAAAPz1
7ent6e3p7ency9zLvMvcstyuoJWGlXSGZ4aVV9xX3LIeFWhyfWoAFmjaFyoANQiBQ0oSAE9KAABR
SgAAXAiBABgVaK1GEgAWaNoXKgAwShEAT0oAAFFKAAAAIwIIgQNqtIMAAAYIARVorUYSABZo2hcq
AE9KAABRSgAAVQgBHQNqAAAAABVorUYSABZo2hcqAE9KAABRSgAAVQgBFBVorUYSABZo2hcqAE9K
AABRSgAAABoVaK1GEgAWaNoXKgA1CIFPSgAAUUoAAFwIgQAGFmjaFyoAABIWaNoXKgBDShIAT0oA
AFFKAAAAHRZoJDEmAENKEgBPSgAAUUoAAG1IAARuSAAEdQgBIQNqAAAAABVocn1qABZo2hcqAENK
EgBPSgAAUUoAAFUIARgVaHJ9agAWaNoXKgBDShIAT0oAAFFKAAAABhZouwf4AAAPA2oAAAAAFmi7
B/gAVQgBDBVoQh2DABZoSX46AAAGFmhCHYMAIv89AAAAPgAAAj4AAAM+AAAFPgAABj4AACU+AAA1
PgAANj4AAD8+AABDPgAAWD4AAG0+AACsPgAArT4AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOsAAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAA
AAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAa2R3
hAAAFiQBFyQBSWYBAAAAAFQBAAKWbAADNAEI1kYAA5T/7AUtF4omAAZYBgwBAAAAAAAAAAAAAAAA
AAAABkERDAEAAAAAAAAAAAAAAAAAAAAGXQ8MAQAAAAAAAAAAAAAAAAAAFPYD9iYX9gMAABj2AwAA
GtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8A
AAD/NNYGAAEKA2wAYfYDAABmNAGKVAEACQAAFiQBSWYBAAAAZ2R2GxgAAAkPAAMkARSk8ABhJAFn
ZHJ9agAABw8AAyQBYSQBZ2RyfWoAAAEAAAAOrT4AACxAAAAtQAAALkAAAC9AAAAwQAAAMUAAAPYA
AAAAAAAAAAAAAACzAAAAAAAAAAAAAAAArgAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACnAAAAAAAA
AAAAAAAAnwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAcAAAMkAWEkAWdkq0ToAAABAAAABAAAZ2SLEQ8AAAQAAGdkcn1qAEMAAGtkBIUAABYkARck
AUlmAQAAAABUAQAClmwAAzQBCNYaAAHH/4omAAbDJgQBAAAEAQAABAEAAAQBAAAU9gP2Jhf2AzMA
GPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/MtYGAAEKAzkANNYGAAEKA2wAYfYDAABm
NAGKVAEACQAAFiQBSWYBAAAAZ2R2GxgAAAYuQAAAL0AAADBAAAAxQAAA/PjxAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwVaEId
gwAWaEl+OgAABhZouwf4AAAGFmjaFyoAA0EACjABB1APAAhQDwAmUAkAMZBoAS9SIAA6cF1/+wAf
sH0uILDIQSGwbgQisG4EI5CJBSSQiQUlsAAAF7A3AhiwNwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsAAQ0
ARPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8km
FTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAS/WCwAEBQAAAP8M
AQAAYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAP4A
FiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YA
AesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQID
A+0QNdYFAwQDIQU51gMAAQEv1gsABAEAAAD/DAEAAGH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPr
BDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwA
E9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYV
NgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZf
ACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0Q
I3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAA
AAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMA
AQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAW
JAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB
6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD
7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD
7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sE
NdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sE
NdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT
1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2
ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8A
IXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAj
dgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAA
AAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwAB
AWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYk
ARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHr
BCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPt
EDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPt
EDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPW
MAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYB
GPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAh
dgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2
AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEB
YfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQB
FyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesE
I3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0Q
NdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0Q
NdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwB
AAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXW
BQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXW
BQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9Yw
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY
9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2
AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YD
BCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA
/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh
9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEX
JAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQj
dgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA1
1gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA1
1gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYF
AQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYF
AQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2
AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYA
BGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgME
IQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/
BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2
A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARck
AUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2
AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXW
BQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXW
BQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUB
AgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUB
AgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYD
AAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAE
aAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQh
BTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8E
AQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYD
XwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQB
SWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YB
AtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYF
AwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYF
AwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQEC
A9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQEC
A9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMA
ADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARo
ATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEF
OlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQB
AAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNf
AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJ
ZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC
0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUD
BAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUD
BAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID
0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID
0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAA
NdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgB
NdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6
VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEA
ABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18A
cNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlm
AQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQ
CyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQME
AyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
ilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQME
AyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQ
CzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQ
CzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA1
1gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE1
1gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpW
CwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAA
FPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw
1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYB
AAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtAL
I3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQD
IQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACK
VAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQD
IQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9AL
NdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9AL
NdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwB
AAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXW
BQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXW
BQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYL
AAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU
9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDW
KAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEA
AAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0Asj
dgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMh
BTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpU
AQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMh
BSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As1
1gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As1
1gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYF
AAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYF
AAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsA
ApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2
A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYo
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAA
AAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2
AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEF
OdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQB
APAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEF
I3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXW
BQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXW
BQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUA
AQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUA
AQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAC
lmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYD
ySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAA
AZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YC
A+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8E
AQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU5
1gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA
8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUj
dgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYF
AgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYF
AgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQAB
A+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQAB
A+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKW
bAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJ
JhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAAB
ll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID
7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQB
AAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnW
AwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDw
ABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2
AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUC
AwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUC
AwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED
6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED
6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZs
ABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8km
FTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGW
XwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPt
ECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEA
AAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYD
AAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAA
FiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YA
AesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQID
A+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQID
A+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPr
BDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPr
BDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwA
E9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYV
NgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZf
ACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0Q
I3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAA
AAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMA
AQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAW
JAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB
6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD
7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD
7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sE
NdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sE
NdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT
1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2
ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8A
IXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAj
dgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAA
AAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwAB
AWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYk
ARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHr
BCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPt
EDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPt
EDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPW
MAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYB
GPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAh
dgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2
AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEB
YfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQB
FyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesE
I3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0Q
NdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0Q
NdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwB
AAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXW
BQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXW
BQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9Yw
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY
9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2
AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YD
BCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA
/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh
9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEX
JAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQj
dgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA1
1gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA1
1gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYF
AQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYF
AQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2
AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYA
BGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgME
IQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/
BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2
A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARck
AUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2
AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXW
BQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXW
BQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUB
AgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUB
AgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYD
AAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAE
aAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQh
BTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8E
AQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYD
XwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQB
SWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YB
AtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYF
AwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYF
AwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQEC
A9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQEC
A9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMA
ADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARo
ATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEF
OlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQB
AAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNf
AHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJ
ZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC
0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUD
BAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUD
BAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID
0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID
0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAA
NdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgB
NdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6
VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEA
ABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18A
cNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlm
AQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQ
CyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQME
AyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
ilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQME
AyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQ
CzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQ
CzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA1
1gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE1
1gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpW
CwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAA
FPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw
1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYB
AAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtAL
I3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQD
IQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACK
VAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQD
IQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9AL
NdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9AL
NdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwB
AAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXW
BQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXW
BQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYL
AAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU
9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDW
KAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEA
AAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0Asj
dgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMh
BTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpU
AQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMh
BSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As1
1gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As1
1gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEA
AAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYF
AAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYF
AAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsA
ApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2
A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYo
AAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAA
AAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2
AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEF
OdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQB
APAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEF
I3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwB
AAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXW
BQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXW
BQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAA
AAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUA
AQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUA
AQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAC
lmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYD
ySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igA
AAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAA
AZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YC
A+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8E
AQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU5
1gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA
8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUj
dgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEA
AAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYF
AgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYF
AgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAA
AAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQAB
A+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQAB
A+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKW
bAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJ
JhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAA
AP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAAB
ll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID
7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQB
AAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnW
AwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDw
ABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2
AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAA
AAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUC
AwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAA
AAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUC
AwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAA
AP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED
6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA
/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED
6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZs
ABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8km
FTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA
/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGW
XwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPt
ECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEA
AAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYD
AAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAA
FiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YA
AesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAA
AAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQID
A+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAA
AP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQID
A+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA
/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPr
BDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/
AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPr
BDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwA
E9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYV
NgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/
AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZf
ACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0Q
I3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAA
AAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMA
AQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAW
JAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB
6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAA
AP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD
7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA
/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD
7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/
DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sE
NdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8A
AAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sE
NdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT
1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2
ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8A
AAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8A
IXYABGgBNdYFAAED6wQ11gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAj
dgMEIQU6VgsAApZsABPWMAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAA
AAD/BAEAABT2A8kmFTYBGPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwAB
AWH2A18AcNYoAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYk
ARckAUlmAQAAAAGWXwAhdgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHr
BCN2AQLQCyN2AgPtECN2AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA
/wwBAAAAAAD/BAEAAAAAAP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPt
EDXWBQMEAyEFOdYDAAEBYfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/
AAAA/wAAilQBAPAAFiQBFyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPt
EDXWBQMEAyEFI3YAAesEI3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8M
AQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAA
AAAA/wAAAP8AAAAAAP8AAAD/AACKVAEA8AAWJAEXJAFJZgEAAAABll8AIXYABGgBNdYFAAED6wQ1
1gUBAgPQCzXWBQIDA+0QNdYFAwQDIQUjdgAB6wQjdgEC0AsjdgID7RAjdgMEIQU6VgsAApZsABPW
MAAAAP8MAQAAAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wQBAAAAAAD/BAEAABT2A8kmFTYB
GPYDAAA11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBTnWAwABAWH2A18AcNYoAAAA/wAA
AP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAIpUAQDwABYkARckAUlmAQAAAAGWXwAh
dgAEaAE11gUAAQPrBDXWBQECA9ALNdYFAgMD7RA11gUDBAMhBSN2AAHrBCN2AQLQCyN2AgPtECN2
AwQhBTpWCwAClmwAE9YwAAAA/wwBAAAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/BAEAAAAA
AP8EAQAAFPYDySYVNgEY9gMAADXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFOdYDAAEB
YfYDXwBw1igAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8AAAD/AAAAAAD/AAAA/wAAilQBAPAAFiQB
FyQBSWYBAAAAAZZfACF2AARoATXWBQABA+sENdYFAQID0As11gUCAwPtEDXWBQMEAyEFI3YAAesE
I3YBAtALI3YCA+0QI3YDBCEFOlYLAAKWbAAT1jAAAAD/DAEAAAAAAP8MAQAAAAAA/wwBAAAAAAD/
DAEAAAAAAP8EAQAAAAAA/wQBAAAU9gPJJhU2ARj2AwAANdYFAAED6wQ11gUBAgPQCzXWBQIDA+0Q
NdYFAwQDIQU51gMAAQFh9gNfAHDWKAAAAP8AAAD/AAAAAAD/AAAA/wAAAAAA/wAAAP8AAAAAAP8A
AAD/AACKVAEAhwAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYFAAEDBAY11gUBAgPVBDXWBQIDA30T
NdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMAApYeAAQ0ART2Ao0SFTYBNdYFAAED
BAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARckAUlmAQAAAAGWsv8hdgAEaAE1
1gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2AQLVBCN2AgN9EyN2AwQ1BjpW
EwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BjnWAwABAYQAFiQB
FyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUCAwN9EzXWBQMEAzUGI3YAAQQG
I3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQABAwQGNdYFAQID1QQ11gUCAwN9
EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYFAAEDBAY11gUBAgPVBDXW
BQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMAApYeABT2Ao0SFTYBNdYF
AAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARckAUlmAQAAAAGWsv8hdgAE
aAE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2AQLVBCN2AgN9EyN2AwQ1
BjpWEwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BjnWAwABAYQA
FiQBFyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUCAwN9EzXWBQMEAzUGI3YA
AQQGI3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQABAwQGNdYFAQID1QQ11gUC
AwN9EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYFAAEDBAY11gUBAgPV
BDXWBQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMAApYeABT2Ao0SFTYB
NdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARckAUlmAQAAAAGWsv8h
dgAEaAE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2AQLVBCN2AgN9EyN2
AwQ1BjpWEwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BjnWAwAB
AYQAFiQBFyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUCAwN9EzXWBQMEAzUG
I3YAAQQGI3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQABAwQGNdYFAQID1QQ1
1gUCAwN9EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYFAAEDBAY11gUB
AgPVBDXWBQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMAApYeABT2Ao0S
FTYBNdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARckAUlmAQAAAAGW
sv8hdgAEaAE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2AQLVBCN2AgN9
EyN2AwQ1BjpWEwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BjnW
AwABAYQAFiQBFyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUCAwN9EzXWBQME
AzUGI3YAAQQGI3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQABAwQGNdYFAQID
1QQ11gUCAwN9EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYFAAEDBAY1
1gUBAgPVBDXWBQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMAApYeABT2
Ao0SFTYBNdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARckAUlmAQAA
AAGWsv8hdgAEaAE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2AQLVBCN2
AgN9EyN2AwQ1BjpWEwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1
BjnWAwABAYQAFiQBFyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUCAwN9EzXW
BQMEAzUGI3YAAQQGI3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQABAwQGNdYF
AQID1QQ11gUCAwN9EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYFAAED
BAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMAApYe
ABT2Ao0SFTYBNdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARckAUlm
AQAAAAGWsv8hdgAEaAE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2AQLV
BCN2AgN9EyN2AwQ1BjpWEwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUD
BAM1BjnWAwABAYQAFiQBFyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUCAwN9
EzXWBQMEAzUGI3YAAQQGI3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQABAwQG
NdYFAQID1QQ11gUCAwN9EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgBNdYF
AAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6VhMA
ApYeABT2Ao0SFTYBNdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQGEABYkARck
AUlmAQAAAAGWsv8hdgAEaAE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM11gUDBAM1BiN2AAEEBiN2
AQLVBCN2AgN9EyN2AwQ1BjpWEwAClh4AFPYCjRIVNgE11gUAAQMEBjXWBQECA9UENdYFAgMDfRM1
1gUDBAM1BjnWAwABAYQAFiQBFyQBSWYBAAAAAZay/yF2AARoATXWBQABAwQGNdYFAQID1QQ11gUC
AwN9EzXWBQMEAzUGI3YAAQQGI3YBAtUEI3YCA30TI3YDBDUGOlYTAAKWHgAU9gKNEhU2ATXWBQAB
AwQGNdYFAQID1QQ11gUCAwN9EzXWBQMEAzUGOdYDAAEBhAAWJAEXJAFJZgEAAAABlrL/IXYABGgB
NdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQYjdgABBAYjdgEC1QQjdgIDfRMjdgMENQY6
VhMAApYeABT2Ao0SFTYBNdYFAAEDBAY11gUBAgPVBDXWBQIDA30TNdYFAwQDNQY51gMAAQHDAAAA
RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAQAAAAdABzAGIAcwBnADEANgBAAGkAdAB1
AC4AaQBuAHQAAADgyep5+brOEYyCAKoAS6kLLgAAAG0AYQBpAGwAdABvADoAdABzAGIAcwBnADEA
NgBAAGkAdAB1AC4AaQBuAHQAAACLABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQNYBjXWBQEC
A0ERNdYFAgMDXQ8jdgABWAYjdgECQREjdgIDXQ86VgsAApZsAAM0ART2A/YmGPYDAAA11gUAAQNY
BjXWBQECA0ERNdYFAgMDXQ8v1gsAAwEAAAD/DAEAADTWBgABBQAAAGY0AYpUAQBtABYkARckAUlm
AQAAAAGWMwAhdgABaAE11gUAAQPDJiN2AAHDJjpWCwAClmwAAzQBFPYD9iYX9gMzABj2AwAANdYF
AAEDwyYv1gsAAQ8AAAD/BAEAADLWBgABCgM5ADTWBgABBQAAAGY0AYpUAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAUAB8AEgABAJwADwADAAAAAwAAAAAATAAAQPH/AgBMAAwAAAAAAAAAAAAG
AE4AbwByAG0AYQBsAAAAAgAAACQAQ0oWAE9KAgBRSgIAX0gBBGFKGABtSAkEbkgECHNICQR0SAQI
bAABQAEAAgBsAAwEAABCHYMAAAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAKgABAAYkAQckAQomAAtG
AQAPhK8BEYRR/hOk8AAUpDwAQCYAXoSvAWCEUf4WADUIgUNKHABLSCAAXAiBXkoCAGFKIABcAAJA
AQACAFwADAQAAEIdgwAAAAkASABlAGEAZABpAG4AZwAgADIAAAAXAAIABiQBCiYBC0YBABOk8AAU
pDwAQCYBABgANQiBNgiBQ0ocAFwIgV0IgV5KAgBhShwAVgADQAEAAgBWAAwEAABCHYMAAAAJAEgA
ZQBhAGQAaQBuAGcAIAAzAAAAFwADAAYkAQomAgtGAQATpPAAFKQ8AEAmAgASADUIgUNKGgBcCIFe
SgIAYUoaAFoABEABAAIAWgAMBAAAQh2DAAAACQBIAGUAYQBkAGkAbgBnACAANAAAABcABAAGJAEK
JgMLRgEAE6TwABSkPABAJgMAFgA1CIFDShwAT0oAAFFKAABcCIFhShwAVAAFQAEAAgBUAAwEAABC
HYMAAAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAAFAAFAAomBAtGAQATpPAAFKQ8AEAmBBQANQiBNgiB
Q0oaAFwIgV0IgWFKGgBSAAZAAQACAFIADAQAAEIdgwAAAAkASABlAGEAZABpAG4AZwAgADYAAAAU
AAYACiYFC0YBABOk8AAUpDwAQCYFEgA1CIFPSgAAUUoAAFwIgWFKFgBMAAdAAQACAEwADAQAAEId
gwAAAAkASABlAGEAZABpAG4AZwAgADcAAAAUAAcACiYGC0YBABOk8AAUpDwAQCYGDABDShgAT0oA
AFFKAABSAAhAAQACAFIADAQAAEIdgwAAAAkASABlAGEAZABpAG4AZwAgADgAAAAUAAgACiYHC0YB
ABOk8AAUpDwAQCYHEgA2CIFDShgAT0oAAFFKAABdCIFIAAlAAQACAEgADAQAAEIdgwAAAAkASABl
AGEAZABpAG4AZwAgADkAAAAUAAkACiYIC0YBABOk8AAUpDwAQCYICABeSgIAYUoWAEQAQUDy/6EA
RAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0
AAAAAABWAGlA8/+zAFYADAUAAAAAAAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpW
CwAX9gMAADTWBgABBQMAADTWBgABCgNsAGH2AwAAAgALAAAAKABrQPT/wQAoAAAFAAAAAAAAAAAH
AE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAADQAH0ABAPIANAAMAAAAAAAAAAAABgBIAGUAYQBkAGUA
cgAAAA0ADwANxggAAl8SviQBAgAAADQAIEABAAIBNAAMAAAAAAAAAAAABgBGAG8AbwB0AGUAcgAA
AA0AEAANxggAAl8SviQBAgAAAEgAVUCiABEBSAAMAAAAmznkAAAACQBIAHkAcABlAHIAbABpAG4A
awAAAB0ANwiAPioBT0oEAFFKBABTKoBZKABvKABwaAAAZgAAKgBXQKIAIQEqAAwAAACbOeQAAAAG
AFMAdAByAG8AbgBnAAAABgA1CIFcCIEIAYJAswAzAQgBDAAAAEIdgwAAAAwAVABhAGIAbABlACAA
RwByAGkAZAAgADUAAAC7ADpWEwAT1jAAAAAADAEAAAAAAAAMAQAAAAAAAAwBAAAAAAAADAEAAAAA
AAAGAQAAAAAAAAYBAABq1hgIAIXWCAAAAP8AAAAAhtYIAAAA/wAAAABq1hgCAIXWCAAAAP8AAAAA
htYIAAAA/wAAAABq1iMBAIDWCAAAAAAMAQAAhdYIAAAA/wAAAACG1ggAAAD/AAAAAGrWGAAChdYI
AAAAAAYBAACG1ggAAAD/AAAAAIfWCgAAAP8AAAD/AAAAAgATABYAhcoICAA1CAFcCAGFyggCADUI
AVwIAZQA/k8BAEIBlAAMAAAAQh2DAAAACgBUAGEAYgBsAGUAXwB0AGUAeAB0AAAASQAUAA3GLAAO
HAE3AlMDbgSKBaUGwQfcCPgJEwsvDEoNZg6BD0BAQEBAQEBAQEBAQEBAE6QoABSkKAA1JAA3JAA4
JAA5RAIASCQAABwAT0oAAFBKAABRSgAAYUoUAG1ICQhzSAkIdEgJBEYA/k9BAUIBRgAMAAAAQh2D
AAAACgBUAGEAYgBsAGUAXwBoAGUAYQBkAAAAEwAVAAMkAQYkAROkUAAUpFAAYSQBAAMANQiBAEQA
E0ABAAIARAANBQAAQh2DAAAABQBUAE8AQwAgADEAAAAKABYAE6R4ABSkeAAVADUIgTsIgUNKFABP
SgAAUUoAAFwIgQA+ABRAAQACAD4ADQUAAEIdgwAAAAUAVABPAEMAIAAyAAAACgAXAA+E3ABehNwA
DwA6CIFDShQAT0oAAFFKAAAAQAAVQAEAAgBAAA0FAABCHYMAAAAFAFQATwBDACAAMwAAAAoAGAAP
hLgBXoS4ARIANgiBQ0oUAE9KAABRSgAAXQiBPgAWQAEAAgA+AA0FAABCHYMAAAAFAFQATwBDACAA
NAAAAAoAGQAPhJQCXoSUAhAAQ0oSAE9KAABRSgAAYUoVAD4AF0ABAAIAPgANBQAAQh2DAAAABQBU
AE8AQwAgADUAAAAKABoAD4RwA16EcAMQAENKEgBPSgAAUUoAAGFKFQA+ABhAAQACAD4ADQUAAEId
gwAAAAUAVABPAEMAIAA2AAAACgAbAA+ETARehEwEEABDShIAT0oAAFFKAABhShUAPgAZQAEAAgA+
AA0FAABCHYMAAAAFAFQATwBDACAANwAAAAoAHAAPhCgFXoQoBRAAQ0oSAE9KAABRSgAAYUoVAD4A
GkABAAIAPgANBQAAQh2DAAAABQBUAE8AQwAgADgAAAAKAB0AD4QEBl6EBAYQAENKEgBPSgAAUUoA
AGFKFQA+ABtAAQACAD4ADQUAAEIdgwAAAAUAVABPAEMAIAA5AAAACgAeAA+E4AZehOAGEABDShIA
T0oAAFFKAABhShUAAAAAADE4AAAFAACUAQAAAP////8AAAAAFgAAAB0AAAAkAAAAKgAAADQAAAA1
AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMA
AABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAA
AFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAA
YAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABu
AAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAADiAAAAigEAALsBAAA1AgAANgIAADcC
AAA4AgAAOQIAADoCAAA7AgAAPAIAAD0CAAA+AgAAPwIAAEACAABBAgAAQgIAAEMCAABEAgAARQIA
AEYCAABHAgAASAIAAEkCAABKAgAASwIAAEwCAABNAgAATgIAAE8CAABQAgAAUQIAAFICAABTAgAA
VAIAAMACAABuAwAAoQMAABsEAAAcBAAAHQQAAB4EAAAfBAAAIAQAACEEAAAiBAAAIwQAACQEAAAl
BAAAJgQAACcEAAAoBAAAKQQAACoEAAArBAAALAQAAC0EAAAuBAAALwQAADAEAAAxBAAAMgQAADME
AAA0BAAANQQAADYEAAA3BAAAOAQAADkEAAA6BAAAOwQAADwEAAA9BAAAPgQAAD8EAABABAAAQQQA
AEIEAABDBAAARAQAAEUEAABGBAAARwQAAEgEAABJBAAASgQAAEsEAABMBAAATQQAAE4EAABPBAAA
UAQAAFEEAABSBAAAUwQAAFQEAABVBAAAVgQAAFcEAABYBAAAWQQAAFoEAABbBAAAXAQAAF0EAABe
BAAAXwQAAGAEAABhBAAAYgQAAGMEAABkBAAAZQQAAGYEAABnBAAAaAQAAGkEAABqBAAAawQAAGwE
AABtBAAAbgQAAG8EAABwBAAAcQQAAHIEAABzBAAAdAQAAHUEAAB2BAAAdwQAAHgEAAB5BAAAegQA
AHsEAAB8BAAAfQQAAH4EAAB/BAAAgAQAAIEEAACCBAAAgwQAAIQEAACFBAAAhgQAAIcEAACIBAAA
iQQAAIoEAAD2BAAAgAUAAKQFAAAeBgAAHwYAAIsGAAAVBwAAZwcAAOEHAADiBwAA4wcAAOQHAADl
BwAA5gcAAOcHAADoBwAA6QcAAOoHAADrBwAA7AcAAO0HAADuBwAA7wcAAPAHAADxBwAA8gcAAPMH
AAD0BwAA9QcAAPYHAAD3BwAA+AcAAPkHAAD6BwAA+wcAAPwHAAD9BwAA/gcAAP8HAAAACAAAAQgA
AAIIAAADCAAABAgAAAUIAAAGCAAABwgAAAgIAAAJCAAACggAAAsIAAAMCAAADQgAAA4IAAAPCAAA
EAgAABEIAAASCAAAEwgAABQIAAAVCAAAFggAABcIAAAYCAAAGQgAABoIAAAbCAAAHAgAAB0IAAAe
CAAAHwgAACAIAAAhCAAAIggAACMIAAAkCAAAJQgAACYIAAAnCAAAKAgAACkIAAAqCAAAKwgAACwI
AAAtCAAAmQgAAA0JAABICQAAwgkAAMMJAAAvCgAAowoAAN0KAABXCwAAWAsAAMQLAAA4DAAAbgwA
AOgMAADpDAAA6gwAAOsMAADsDAAA7QwAAO4MAADvDAAA8AwAAPEMAADyDAAA8wwAAPQMAAD1DAAA
9gwAAPcMAAD4DAAA+QwAAPoMAAD7DAAA/AwAAP0MAAD+DAAA/wwAAAANAAABDQAAAg0AAAMNAAAE
DQAABQ0AAAYNAAAHDQAACA0AAAkNAAAKDQAACw0AAAwNAAANDQAADg0AAA8NAAAQDQAAEQ0AABIN
AAATDQAAFA0AABUNAAAWDQAAFw0AABgNAAAZDQAAGg0AABsNAAAcDQAAHQ0AAB4NAAAfDQAAIA0A
ACENAAAiDQAAIw0AACQNAAAlDQAAJg0AACcNAAAoDQAAKQ0AACoNAAArDQAALA0AAC0NAAAuDQAA
Lw0AADANAAAxDQAAMg0AADMNAAA0DQAANQ0AADYNAAA3DQAAOA0AADkNAAA6DQAAOw0AADwNAAA9
DQAAPg0AAD8NAABADQAAQQ0AAEINAABDDQAARA0AAEUNAABGDQAARw0AAEgNAABJDQAASg0AAEsN
AABMDQAATQ0AAE4NAABPDQAAUA0AAFENAABSDQAAUw0AAFQNAABVDQAAVg0AAFcNAADDDQAAbw4A
ALgOAAAyDwAAMw8AAJ8PAABLEAAAeBAAAPIQAADzEAAAXxEAAAsSAAAzEgAAQRIAAEISAABDEgAA
RBIAAEUSAABGEgAARxIAAEgSAABJEgAAShIAAEsSAABMEgAATRIAAE4SAABPEgAAUBIAAFESAABS
EgAAUxIAAFQSAABVEgAAVhIAAMISAABgEwAAtRMAAC8UAAAwFAAAMRQAADIUAAAzFAAANBQAADUU
AAA2FAAANxQAADgUAAA5FAAAOhQAADsUAAA8FAAAPRQAAD4UAAA/FAAAQBQAAEEUAABCFAAAQxQA
AEQUAABFFAAARhQAAEcUAABIFAAASRQAALUUAAAtFQAAZhUAAOAVAADhFQAATRYAAMUWAAAIFwAA
ghcAAIMXAADvFwAAZxgAAK0YAAAnGQAAKBkAACkZAAAqGQAAKxkAACwZAAAtGQAALhkAAC8ZAAAw
GQAAMRkAADIZAAAzGQAANBkAADUZAAA2GQAANxkAADgZAAA5GQAAOhkAADsZAAA8GQAAPRkAAD4Z
AAA/GQAAQBkAAEEZAABCGQAAQxkAAEQZAABFGQAARhkAAEcZAABIGQAASRkAAEoZAABLGQAATBkA
AE0ZAABOGQAATxkAAFAZAABRGQAAUhkAAFMZAABUGQAAVRkAAFYZAABXGQAAWBkAAFkZAABaGQAA
WxkAAFwZAABdGQAAXhkAAF8ZAABgGQAAYRkAAGIZAABjGQAAZBkAAGUZAABmGQAAZxkAAGgZAABp
GQAAahkAAGsZAABsGQAAbRkAAG4ZAABvGQAAcBkAAHEZAAByGQAAcxkAAHQZAAB1GQAAdhkAAHcZ
AAB4GQAAeRkAAHoZAAB7GQAAfBkAAH0ZAAB+GQAAfxkAAIAZAACBGQAAghkAAIMZAACEGQAAhRkA
AIYZAACHGQAAiBkAAIkZAACKGQAAixkAAIwZAACNGQAAjhkAAI8ZAACQGQAAkRkAAJIZAACTGQAA
lBkAAJUZAACWGQAAAhoAAHwaAAACGwAAfBsAAH0bAADpGwAAYxwAAIocAAAEHQAABR0AAAYdAAAH
HQAACB0AAAkdAAAKHQAACx0AACUdAAAsHQAAMx0AADkdAABDHQAARB0AAEUdAABGHQAARx0AAEgd
AABJHQAASh0AAEsdAABMHQAATR0AAE4dAABPHQAAUB0AAFEdAABSHQAAUx0AAFQdAABVHQAAVh0A
AFcdAABYHQAAWR0AAFodAABbHQAAXB0AAF0dAABeHQAAXx0AAGAdAABhHQAAYh0AAGMdAABkHQAA
ZR0AAGYdAABnHQAA2h0AAIoeAADqHgAAch8AAHMfAADmHwAAhCAAABghAACgIQAAoSEAABQiAACy
IgAAPiMAAMYjAADHIwAAOiQAANgkAAAwJQAAuCUAALklAAAsJgAAyiYAAEQnAADMJwAAzScAAEAo
AADeKAAASikAANIpAADTKQAA1CkAANUpAADWKQAA1ykAANgpAABLKgAA6SoAAB8rAACnKwAAqCsA
AKkrAACqKwAAqysAAKwrAACtKwAAICwAAL4sAAAdLQAApS0AAKYtAAAZLgAAvy4AAJsvAAAjMAAA
JDAAAJcwAABJMQAAqjEAADIyAAAzMgAApjIAAEQzAACWMwAAHjQAAB80AACSNAAAMDUAAFw1AADk
NQAA5TUAAOY1AADnNQAA+jUAAPw1AAD9NQAA/zUAAAA2AAACNgAAAzYAAAU2AAAGNgAAJTYAADU2
AAA2NgAAPzYAAEM2AABYNgAAbTYAAKw2AACtNgAALDgAAC04AAAuOAAALzgAADI4AAAIAAEgATAA
AAAAAAAAgAAAAIAAAAACAAAAAAAAqQAAABUwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAVMAAA
AAAAAACAAAAAAAEAANAAAAAAIACpAAAAFTAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABUwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAA
AIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAA
AAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADU
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZ
AAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAw
AAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAA
AACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACRAAAAADAAAAAAAAAAgAAA
AAABAAAEAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA
1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
mQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAJEAAAAA
MAAAAAAAAACAAAAAAAEAAAQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAA
AAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAA
AAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEA
ANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAA
ADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAA
AAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACA
AAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAAB
AADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAA
AAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAAAAAAAAAIACRAAAAADAAAAAAAAAAgAAAAAABAAAEAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAJEAAAAAMAAA
AAAAAACAAAAAAAEAAAQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAA
gAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAA
AQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkA
AAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAA
AAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAA
AIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAA
AAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADU
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZ
AAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAw
AAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAA
AACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAA
AAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA
1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
mQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAA
MAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAA
AAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAA
AAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEA
ANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAA
ADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAA
AAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACA
AAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAAB
AADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAA
AAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAA
AAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAA
gAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAA
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAA
AQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
ANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAA
ACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAJkA
AAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQw
AAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACZAAAAADAA
AAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAAAAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAA
AACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAmQAAAAAwAAAAAAAA
AIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAA
gAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACA
AAAAAAEAAAAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAA
AAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAJkAAAAAMAAAAAAAAACAAAAA
AAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAA
AQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAAB
AAAAAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEA
AAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA
AAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADU
AAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAA
AAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAA
ACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAmQAAAAAwAAAAAAAAAIAAAAAAAQAA1AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAA
qQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACZ
AAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAAAAAAAAACAAqQAA
ABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAAAEAANQAAAAAIACpAAAA
FDAAAAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAAABAADQAAAAACAAmQAAAAAw
AAAAAAAAAIAAAAAAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgAAAAAABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACAAAAAAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAAABAADUAAAAACAAqQAAABQwAAAA
AAAAAIAAAAAAAQAAAAAAAAAgAKkAAAAUMAAAAAAAAACAAAAAAAEAAAAAAAAAIACpAAAAFDAAAAAA
AAAAgAAAAAABAAAAAAAAACAAqQAAABQwAAAAAAAAAIAAAAAAAQAAAAAAAAAgAJkAAAAAMAAAAAAA
AACAAAAAAAEAANQAAAAAIACYAAAAADAAAAAAAAAAgAAAAAAAAAAAAAAAAAAACAABIAEwAQAAAAAA
AIAAAACAAAAAAgAAAAAAAKEAAAAVMAAAAAAAAACADyQCAAEAANAAAAAAIAChAAAAFTAAAAAAAAAA
gA8kAgABAADQAAAAACAAoQAAABUwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKEAAAAVMAAAAAAAAACA
DyQCAAEAANAAAAAAIACRAAAAADAAAAAAAAAAgA8kAgABAADUAAAAACAAqQAAABQwAAAAAAAAAIAA
AACAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAA
AIABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAA
gAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAACA
AQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIAB
AADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA
0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADU
AAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAA
AAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAA
AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAA
IACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAg
AKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAA
qQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACZ
AAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAA
ABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAAIACpAAAA
FDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAU
MAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAmQAAAAAw
AAAAAAAAAIAPJAIAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAA
AAAAAACADyQCAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgA8kAgABAADUAAAAACAAqQAAABQwAAAA
AAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAAAAAA
AAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAJkAAAAAMAAAAAAA
AACADyQCAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAA
AIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAAAAAAAAAA
gA8kAgABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAPJAIAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACA
DyQCAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAP
JAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgA8k
AgABAADUAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQC
AAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIA
AQAA0AAAAAAgAJkAAAAAMAAAAAAAAACADyQCAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIAB
AADQAAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACAAAAAgAEA
ANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA
1AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQ
AAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAA
AAAAIACZAAAAADAAAAAAAAAAgA8kAgABAADUAAAAACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAA
AAAgAKkAAAAUMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgAAAAIABAADQAAAA
ACAAqQAAABQwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAANQAAAAA
IACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAg
AKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAA
mQAAAAAwAAAAAAAAAIAPJAIAAQAA1AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACp
AAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkA
AAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACZAAAAADAAAAAAAAAAgA8kAgABAADUAAAAACAAqQAA
ABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAA
FDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAAAAAAAIAPJAIAAQAA0AAAAAAgAJkAAAAA
MAAAAAAAAACADyQCAAEAANQAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQw
AAAAAAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAA
AAAAAAAAgA8kAgABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAPJAIAAQAA1AAAAAAgAKkAAAAUMAAA
AAAAAACADyQCAAEAANAAAAAAIACpAAAAFDAAAAAAAAAAgA8kAgABAADQAAAAACAAqQAAABQwAAAA
AAAAAIAPJAIAAQAA0AAAAAAgAKkAAAAUMAAAAAAAAACADyQCAAEAANAAAAAAIACZAAAAADAAAAAA
AAAAgA8kAgABAADUAAAAACAAmAAAAAAwAAAAAAAAAIAPJAIAAAAA+AAAAACAAJAAAAAAMAAAAAAA
AACADyQCAAAAAHgAAAAAAACYAAAAADAAAAAAAAAAgA8kAgAAAAB4AAAAAAAAmEAAAAAwAAAAAAAA
AIAAAACAAAAAYAAAAAAAB1w+ATAAMAAAAAAAAAEAAAABAAAAAMAAAAAAnAeYQAAAADAAAAAAAAAA
gAAAAIAAAABgAAAAAAAHXD4BMAAwAAAAAAAAAQAAAAEAAAAAAAAAAACcB5hAAAAAMAAAAAAAAACA
AAAAgAAAAGAAAAAAAAdcPgEwADAAAAAAAAABAAAAAQAAAAAAAAAAAJwHmEAAAAAwAAAAAAAAAIAA
AACAAAAAYAAAAAAAB1w+ATAAMAAAAAAAAAEAAAABAAAAAAAAAAAAnAeYQAAADzAAAAAAAAAAgAAA
AIAAAAD4AAAAAIAHmEAAAA8wAAAAAAAAAIAAAACAAAAAeAAAAAAAAJhAAAAAMAAAAAAAAACAAAAA
gAAAALgAAAAAAACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAACAAqUAAAAAwAAAAAAAAAIAAAACA
AQAAAAAAAAAgAKlAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAAACpQAAAADAAAAAAAAAAgAAAAIAB
AAAAAAAAAAAAqUAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAAAgAJlAAAAAMAAAAAAAAACAAAAAgAEA
AAQAAAAAIACpQAAAADAAAAAAAAAAgAAAAIABAAAAAAAAACAAmUAAAAAwAAAAAAAAAIAAAACAAQAA
BAAAAAAgAJhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAADAAAAAAAAAAgAAAAIAAAAC4
AAAAAAAAXD4BMAAwAAAAAAAAAQAAAAEAAAAAAAAAMBKcBwAAAAADAAAABgAAAAYAAAAJAAAADAAA
AAwAAAAMAAAAPAAAADwAAAA8AAAAPAAAADUCAAA4AgAAAAYAAGkIAABNCwAAYAwAABMPAAArEAAA
6xQAAFEVAABGGgAAsBwAADEhAACWIQAAKyUAANcsAACmNQAA5z0AAC5AAAAxQAAAIQAAAC4AAAA5
AAAASAAAAFMAAABjAAAAaAAAAH4AAACEAAAAjgAAAJQAAACpAAAArQAAALkAAADBAAAAxgAAAMkA
AAAABgAANQgAADwIAABDCAAASAgAAE0IAABSCAAAVwgAAFwIAABhCAAAZggAAGsIAABwCAAAdQgA
ADUKAAA6CgAAPwoAAEQKAABJCgAATgoAAFMKAAAbDAAAIAwAACUMAAAqDAAALwwAADQMAAA5DAAA
PgwAAEMMAABIDAAATQwAAFIMAABXDAAAXAwAAGEMAABmDAAAawwAAHAMAAB1DAAAegwAAH8MAACE
DAAAiQwAAB4OAADhDwAA5g8AAOsPAADwDwAA9Q8AAPoPAAD/DwAABBAAAAkQAAAOEAAAExAAABgQ
AAAdEAAAIhAAACcQAAAsEAAAwhEAAFcTAADoFAAA7RQAAPIUAAD3FAAA/BQAAAEVAAAGFQAACxUA
ABAVAAAVFQAAGhUAAB8VAAAkFQAAKRUAAC4VAAAzFQAAOBUAAD0VAABCFQAARxUAAEwVAABRFQAA
VhUAADIXAADyGAAAQRoAAEYaAABLGgAAUBoAAFUaAAAvHAAANBwAADkcAAA+HAAAQxwAAEgcAADg
HQAAgh8AACchAAAsIQAAMSEAADYhAAA7IQAAQCEAAEUhAABKIQAATyEAAFQhAABZIQAAXiEAAGMh
AABoIQAAbSEAAHIhAAB3IQAAfCEAAIEhAACGIQAAiyEAAJAhAACVIQAAfCMAAAQlAAAJJQAAMyUA
AEUlAABLJQAAUSUAAFclAABcJQAAYSUAAGYlAAByJwAAoCkAAMYrAAC4LQAAzC8AANIxAADXMQAA
pzMAAKwzAAClNQAAIzgAADI6AAAePAAA5D0AAP89AACtPgAAMUAAACIAAAAkAAAAJQAAACYAAAAn
AAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA
AAA3AAAAOAAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAA
AEYAAABHAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFQAAABVAAAA
VgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGQAAABl
AAAAZgAAAGcAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQA
AAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB/AAAAgAAAAIEAAACCAAAAgwAA
AIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI8AAACQAAAAkQAAAJIAAACTAAAA
lQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACj
AAAApAAAAKUAAACmAAAApwAAAKgAAACqAAAAqwAAAKwAAACuAAAArwAAALAAAACxAAAAsgAAALMA
AAC0AAAAtQAAALYAAAC3AAAAuAAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADCAAAAwwAA
AMQAAADFAAAAxwAAAMgAAAAABgAAMEAAACMAAAB2AAAA2gAAAOAAAADiAAAAawEAAIgBAAC7AQAA
LAIAADMCAABUAgAAuAIAAL4CAADAAgAATAMAAGwDAAChAwAAEgQAABkEAACKBAAA7gQAAPQEAAD2
BAAAbwUAAH4FAACkBQAAFQYAABwGAAAfBgAAgwYAAIkGAACLBgAABAcAABMHAABnBwAA2AcAAN8H
AAAtCAAAkQgAAJcIAACZCAAABgkAAAsJAABICQAAuQkAAMAJAADDCQAAJwoAAC0KAAAvCgAAnAoA
AKEKAADdCgAATgsAAFULAABYCwAAvAsAAMILAADECwAAMQwAADYMAABuDAAA3wwAAOYMAABXDQAA
uw0AAMENAADDDQAATw4AAG0OAAC4DgAAKQ8AADAPAAAzDwAAlw8AAJ0PAACfDwAAKxAAAEkQAAB4
EAAA6RAAAPAQAADzEAAAVxEAAF0RAABfEQAA6xEAAAkSAABWEgAAuhIAAMASAADCEgAARhMAAF4T
AAC1EwAAJhQAAC0UAABJFAAArRQAALMUAAC1FAAAJBUAACsVAABmFQAA1xUAAN4VAADhFQAARRYA
AEsWAABNFgAAvBYAAMMWAAAIFwAAeRcAAIAXAACDFwAA5xcAAO0XAADvFwAAXhgAAGUYAACtGAAA
HhkAACUZAACWGQAA+hkAAAAaAAACGgAAchoAAHoaAAACGwAAcxsAAHobAAB9GwAA4RsAAOcbAADp
GwAAWRwAAGEcAACKHAAA+xwAAAIdAABnHQAA0B0AANcdAADaHQAAbx4AAIgeAADqHgAAaR8AAHAf
AABzHwAA3B8AAOMfAADmHwAAcCAAAIIgAAAYIQAAlyEAAJ4hAAChIQAACiIAABEiAAAUIgAAniIA
ALAiAAA+IwAAvSMAAMQjAADHIwAAMCQAADckAAA6JAAAxCQAANYkAAAwJQAAryUAALYlAAC5JQAA
IiYAACkmAAAsJgAAtiYAAMgmAABEJwAAwycAAMonAADNJwAANigAAD0oAABAKAAAyigAANwoAABK
KQAAySkAANApAADYKQAAQSoAAEgqAABLKgAA1SoAAOcqAAAfKwAAnisAAKUrAACtKwAAFiwAAB0s
AAAgLAAAqiwAALwsAAAdLQAAnC0AAKMtAACmLQAADy4AABYuAAAZLgAAqS4AAL0uAACbLwAAGjAA
ACEwAAAkMAAAjTAAAJQwAACXMAAALTEAAEcxAACqMQAAKTIAADAyAAAzMgAAnDIAAKMyAACmMgAA
MDMAAEIzAACWMwAAFTQAABw0AAAfNAAAiDQAAI80AACSNAAAHDUAAC41AABcNQAA2zUAAOI1AAAx
OAAAE1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWM
E1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU
/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWM
E1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU
/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWM
E1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU
/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWM
E1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU
/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWMDgAAACUAAAAnAAAA
eQAAAJ8AAACvAAAAOAIAABMhFP+VgBNYFP8VhNUAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAAB
AAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAA
AAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAA
AAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////
AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAAB
AAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAA
AAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAA
AAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////
AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAAB
AAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAA
AAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAA
AAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////
AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAAPAADwOAAAAAAABvAYAAAAAggAAAIAAAABAAAAAQAAAAEAAAACAAAA
QAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAA
DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAAS
AArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHw
BAAAAAEAAAD//wIAAAANAF8AVABvAGMAMQAwADkAOAAyADkAMAA2ADcADQBfAFQAbwBjADEAMAA5
ADgAMgA5ADAANwAyAAAAAAALHQAAMjgAAAAAAAABAAAAFQAAACQdAAAyOAAA//8EAAAABgCmWUMR
AAABABSF4gIGAKdZQxEBAAEAvHjiAgYAqFlDEQAAAQDUhOICBgCpWUMRAQABAFSF4gKABQAAgAUA
ABUHAAAVBwAAMjgAAAAAAAACAAEAAAACAAIAAAACAAMAAAACAIYFAACGBQAAGwcAABsHAAAyOAAA
AAAAAAEAAAACAAAAAwAAAAIAAABCAAAAAwAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv
ZmZpY2U6c21hcnR0YWdzDoBjb3VudHJ5LXJlZ2lvbgCAOQAAAAQAAAAqgHVybjpzY2hlbWFzLW1p
Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWAcGxhY2UAgAwAAAEBAAAAAAAAAAQAAAAAAAMA
AAAAAAQAAAAAAAMAAAAAAAAAAABsAQAAdQEAAEcVAABPFQAAxRYAAM0WAADsGgAA9RoAAPo1AAD6
NQAA/DUAAPw1AAD9NQAA/TUAAP81AAAANgAAAjYAAAM2AAAFNgAABjYAAC84AAAyOAAABwAcAAcA
HAAHABwABwAcAAcABAAHAAQAAgAEAAcABAAHAAQABwAEAAcAAgAAAAAA0ykAANQpAAD6NQAA+jUA
APw1AAD8NQAA/TUAAP01AAD/NQAAADYAAAI2AAADNgAABTYAAAY2AAAvOAAAMjgAAAcABAAHAAQA
BwAEAAIABAAHAAQABwAEAAcABAAHAAIAAAAAAGQZAABkGQAAZRkAAGUZAABmGQAAZhkAAGcZAABn
GQAAaRkAAGkZAABqGQAAahkAAGsZAABrGQAAbBkAAGwZAABuGQAAbhkAAG8ZAABvGQAAcBkAAHAZ
AABxGQAAcRkAAHMZAABzGQAAdBkAAHQZAAB1GQAAdRkAAHYZAAB2GQAAeBkAAHgZAAB5GQAAeRkA
AHoZAAB6GQAAexkAAHsZAAB9GQAAfRkAAH4ZAAB+GQAAfxkAAH8ZAACAGQAAgBkAAIIZAACCGQAA
gxkAAIMZAACEGQAAhBkAAIUZAACFGQAAhxkAAIcZAACIGQAAiBkAAIkZAACJGQAAihkAAIoZAACM
GQAAjBkAAI0ZAACNGQAAjhkAAI4ZAACPGQAAjxkAAJEZAACRGQAAkhkAAJIZAACTGQAAkxkAAJQZ
AACUGQAABR0AAAUdAAAGHQAABh0AAAcdAAAHHQAACB0AAAgdAAALHQAACx0AAEQdAABEHQAARR0A
AEUdAABGHQAARh0AAEcdAABHHQAASR0AAEkdAABKHQAASh0AAEsdAABLHQAATB0AAEwdAABOHQAA
Th0AAE8dAABPHQAAUB0AAFAdAABRHQAAUR0AAFMdAABTHQAAVB0AAFQdAABVHQAAVR0AAFYdAABW
HQAAWB0AAFgdAABZHQAAWR0AAFodAABaHQAAWx0AAFsdAABdHQAAXR0AAF4dAABeHQAAXx0AAF8d
AABgHQAAYB0AAGIdAABiHQAAYx0AAGMdAABkHQAAZB0AAGUdAABlHQAA0ykAANMpAADUKQAA1CkA
ANUpAADVKQAA1ikAANYpAACoKwAAqCsAAKkrAACpKwAAqisAAKorAACrKwAAqysAAPo1AAD6NQAA
/DUAAPw1AAD9NQAA/TUAAP81AAAANgAAAjYAAAM2AAAFNgAABjYAAAg2AAAiNgAANDYAADY2AABD
NgAALzgAADI4AAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD
AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQABwAE
AAIABAAHAAQABwAEAAcABAAFAAcABQAHAAUABwACAAAAAAD6NQAA+jUAAPw1AAD8NQAA/TUAAP01
AAD/NQAAADYAAAI2AAADNgAABTYAAAY2AAAvOAAAMjgAAAcABAAHAAQAAgAEAAcABAAHAAQABwAE
AAcAAgABAPpgQlpuaJTFAQACAAMABAAFAAYABwAIAAkAAAABAAAAABABAAAAAAAAAAAAAAAAAAAA
AAANGAAAD4TWAxGEUP4VxgUAAdYDBl6E1gNghFD+bygAh2gAAAAAiEgAAAEAAAABAAAAABABAwAA
AAAAAAAAAAAAAAAAAAANGAEAD4RAAhGEwP0VxgUAAUACBl6EQAJghMD9bygAh2gAAAAAiEgAAAMA
AAAuAAEAAQAAAAAQAQMFAAAAAAAAAAAAAAAAAAAADRgCAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw
/W8oAIdoAAAAAIhIAAAFAAAALgABAC4AAgABAAAAABABAwUHAAAAAAAAAAAAAAAAAAANGAMAD4Rg
AxGEoPwVxgUAAWADBl6EYANghKD8bygAh2gAAAAAiEgAAAcAAAAuAAEALgACAC4AAwABAAAAABAB
AwUHCQAAAAAAAAAAAAAAAAANGAQAD4TwAxGEEPwVxgUAAfADBl6E8ANghBD8bygAh2gAAAAAiEgA
AAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAQAQMFBwkLAAAAAAAAAAAAAAAADRgFAA+EgAQRhID7
FcYFAAGABAZehIAEYISA+28oAIdoAAAAAIhIAAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAA
ABABAwUHCQsNAAAAAAAAAAAAAAANGAYAD4QQBRGE8PoVxgUAARAFBl6EEAVghPD6bygAh2gAAAAA
iEgAAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAABABAwUHCQsNDwAAAAAAAAAAAAAN
GAcAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6bygAh2gAAAAAiEgAAA8AAAAuAAEALgACAC4AAwAu
AAQALgAFAC4ABgAuAAcAAQAAAAAQAQMFBwkLDQ8RAAAAAAAAAAAADRgIAA+EMAYRhND5FcYFAAEw
BgZehDAGYITQ+W8oAIdoAAAAAIhIAAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4A
CAABAAAA+mBCWgAAAAAAAAAAAAAAAP///////wEAAAAAAP//AQAAAAAABgDoW64dAAAAAAAAAAAA
AQIAAgBkTW4vAAAAAAAAAAAAAQIAAgAbS0JTAAAAAAAAAAAAAQIAAgCbBBNZAAAAAAAAAAAAAQIA
AgA4au9kAAAAAAAAAAAAAQIAAgDHLQJtAAAAAAAAAAAAAQIAAgBkAAAABAAAAAgAAADlAAAAAAAA
AGMAAADlaQQAy14GAOgACQBxUAoAixEPAAZaEQCkPxIAmGcTANIIFAB2GxgA1RcaALQ2HgD0YB8A
I3EgAHxYIgBsbCIAJDEmANoXKgA4KCwAKEkuAPkLMwByADUAyjk2AEl+OgC8WzsAJGA8AIFUQAAN
UEIAaHBEAEhjTwCJNlMANkBTAP0QVADyPlcAPWVXABJNWADpZ1gA5gFeAPF9YABncGEAy1ZjABNc
YwCOQGUAXGRnAKIDaAAML2oAcn1qAIYsbQBDbG4AbDd3ABJadwBLTnsAmkp8APppfQDOM34AMnqC
AEIdgwBdBIkAIwSKAC5UigBwe44AVWWQAEs8kwDqTZUA0EGYAERvmgC/LZ0ArT+dADRangB0ZJ8A
HA+jAEVxowC2DKcAbEawAGlZtAACPbgAFGPCAG5WxgCUTckABVvJANpoyQDdc8oAVErOABhn0ABw
d9UAVHXWAK5/1gCRXtcASWbbAI9A3gDTeN8A+CPgAFx+4wCbOeQAq0ToAAxI8wCBTvMAuwf4AHMQ
+QBdf/sAAAAAABYAAAAdAAAAJAAAACoAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAA
ADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAA
SgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABY
AAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYA
AABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAA
AHUAAAB2AAAA4gAAAIoBAAC7AQAANQIAADYCAAA3AgAAOAIAADkCAAA6AgAAOwIAADwCAAA9AgAA
PgIAAD8CAABAAgAAQQIAAEICAABDAgAARAIAAEUCAABGAgAARwIAAEgCAABJAgAASgIAAEsCAABM
AgAATQIAAE4CAABPAgAAUAIAAFECAABSAgAAUwIAAFQCAADAAgAAbgMAAKEDAAAbBAAAHAQAAB0E
AAAeBAAAHwQAACAEAAAhBAAAIgQAACMEAAAkBAAAJQQAACYEAAAnBAAAKAQAACkEAAAqBAAAKwQA
ACwEAAAtBAAALgQAAC8EAAAwBAAAMQQAADIEAAAzBAAANAQAADUEAAA2BAAANwQAADgEAAA5BAAA
OgQAADsEAAA8BAAAPQQAAD4EAAA/BAAAQAQAAEEEAABCBAAAQwQAAEQEAABFBAAARgQAAEcEAABI
BAAASQQAAEoEAABLBAAATAQAAE0EAABOBAAATwQAAFAEAABRBAAAUgQAAFMEAABUBAAAVQQAAFYE
AABXBAAAWAQAAFkEAABaBAAAWwQAAFwEAABdBAAAXgQAAF8EAABgBAAAYQQAAGIEAABjBAAAZAQA
AGUEAABmBAAAZwQAAGgEAABpBAAAagQAAGsEAABsBAAAbQQAAG4EAABvBAAAcAQAAHEEAAByBAAA
cwQAAHQEAAB1BAAAdgQAAHcEAAB4BAAAeQQAAHoEAAB7BAAAfAQAAH0EAAB+BAAAfwQAAIAEAACB
BAAAggQAAIMEAACEBAAAhQQAAIYEAACHBAAAiAQAAIkEAACKBAAA9gQAAIAFAACkBQAAHgYAAB8G
AACLBgAAFQcAAGcHAADhBwAA4gcAAOMHAADkBwAA5QcAAOYHAADnBwAA6AcAAOkHAADqBwAA6wcA
AOwHAADtBwAA7gcAAO8HAADwBwAA8QcAAPIHAADzBwAA9AcAAPUHAAD2BwAA9wcAAPgHAAD5BwAA
+gcAAPsHAAD8BwAA/QcAAP4HAAD/BwAAAAgAAAEIAAACCAAAAwgAAAQIAAAFCAAABggAAAcIAAAI
CAAACQgAAAoIAAALCAAADAgAAA0IAAAOCAAADwgAABAIAAARCAAAEggAABMIAAAUCAAAFQgAABYI
AAAXCAAAGAgAABkIAAAaCAAAGwgAABwIAAAdCAAAHggAAB8IAAAgCAAAIQgAACIIAAAjCAAAJAgA
ACUIAAAmCAAAJwgAACgIAAApCAAAKggAACsIAAAsCAAALQgAAJkIAAANCQAASAkAAMIJAADDCQAA
LwoAAKMKAADdCgAAVwsAAFgLAADECwAAOAwAAG4MAADoDAAA6QwAAOoMAADrDAAA7AwAAO0MAADu
DAAA7wwAAPAMAADxDAAA8gwAAPMMAAD0DAAA9QwAAPYMAAD3DAAA+AwAAPkMAAD6DAAA+wwAAPwM
AAD9DAAA/gwAAP8MAAAADQAAAQ0AAAINAAADDQAABA0AAAUNAAAGDQAABw0AAAgNAAAJDQAACg0A
AAsNAAAMDQAADQ0AAA4NAAAPDQAAEA0AABENAAASDQAAEw0AABQNAAAVDQAAFg0AABcNAAAYDQAA
GQ0AABoNAAAbDQAAHA0AAB0NAAAeDQAAHw0AACANAAAhDQAAIg0AACMNAAAkDQAAJQ0AACYNAAAn
DQAAKA0AACkNAAAqDQAAKw0AACwNAAAtDQAALg0AAC8NAAAwDQAAMQ0AADINAAAzDQAANA0AADUN
AAA2DQAANw0AADgNAAA5DQAAOg0AADsNAAA8DQAAPQ0AAD4NAAA/DQAAQA0AAEENAABCDQAAQw0A
AEQNAABFDQAARg0AAEcNAABIDQAASQ0AAEoNAABLDQAATA0AAE0NAABODQAATw0AAFANAABRDQAA
Ug0AAFMNAABUDQAAVQ0AAFYNAABXDQAAww0AAG8OAAC4DgAAMg8AADMPAACfDwAASxAAAHgQAADy
EAAA8xAAAF8RAAALEgAAMxIAAEESAABCEgAAQxIAAEQSAABFEgAARhIAAEcSAABIEgAASRIAAEoS
AABLEgAATBIAAE0SAABOEgAATxIAAFASAABREgAAUhIAAFMSAABUEgAAVRIAAFYSAADCEgAAYBMA
ALUTAAAvFAAAMBQAADEUAAAyFAAAMxQAADQUAAA1FAAANhQAADcUAAA4FAAAORQAADoUAAA7FAAA
PBQAAD0UAAA+FAAAPxQAAEAUAABBFAAAQhQAAEMUAABEFAAARRQAAEYUAABHFAAASBQAAEkUAAC1
FAAALRUAAGYVAADgFQAA4RUAAE0WAADFFgAACBcAAIIXAACDFwAA7xcAAGcYAACtGAAAJxkAACgZ
AAApGQAAKhkAACsZAAAsGQAALRkAAC4ZAAAvGQAAMBkAADEZAAAyGQAAMxkAADQZAAA1GQAANhkA
ADcZAAA4GQAAORkAADoZAAA7GQAAPBkAAD0ZAAA+GQAAPxkAAEAZAABBGQAAQhkAAEMZAABEGQAA
RRkAAEYZAABHGQAASBkAAEkZAABKGQAASxkAAEwZAABNGQAAThkAAE8ZAABQGQAAURkAAFIZAABT
GQAAVBkAAFUZAABWGQAAVxkAAFgZAABZGQAAWhkAAFsZAABcGQAAXRkAAF4ZAABfGQAAYBkAAGEZ
AABiGQAAYxkAAGQZAABlGQAAZhkAAGcZAABoGQAAaRkAAGoZAABrGQAAbBkAAG0ZAABuGQAAbxkA
AHAZAABxGQAAchkAAHMZAAB0GQAAdRkAAHYZAAB3GQAAeBkAAHkZAAB6GQAAexkAAHwZAAB9GQAA
fhkAAH8ZAACAGQAAgRkAAIIZAACDGQAAhBkAAIUZAACGGQAAhxkAAIgZAACJGQAAihkAAIsZAACM
GQAAjRkAAI4ZAACPGQAAkBkAAJEZAACSGQAAkxkAAJQZAACVGQAAlhkAAAIaAAB8GgAAAhsAAHwb
AAB9GwAA6RsAAGMcAACKHAAABB0AAAUdAAAGHQAABx0AAAgdAAAJHQAACh0AACUdAAAsHQAAMx0A
ADkdAABDHQAARB0AAEUdAABGHQAARx0AAEgdAABJHQAASh0AAEsdAABMHQAATR0AAE4dAABPHQAA
UB0AAFEdAABSHQAAUx0AAFQdAABVHQAAVh0AAFcdAABYHQAAWR0AAFodAABbHQAAXB0AAF0dAABe
HQAAXx0AAGAdAABhHQAAYh0AAGMdAABkHQAAZR0AAGYdAABnHQAA2h0AAIoeAADqHgAAch8AAHMf
AADmHwAAhCAAABghAACgIQAAoSEAABQiAACyIgAAPiMAAMYjAADHIwAAOiQAANgkAAAwJQAAuCUA
ALklAAAsJgAAyiYAAEQnAADMJwAAzScAAEAoAADeKAAASikAANIpAADTKQAA1CkAANUpAADWKQAA
1ykAANgpAABLKgAA6SoAAB8rAACnKwAAqCsAAKkrAACqKwAAqysAAKwrAACtKwAAICwAAL4sAAAd
LQAApS0AAKYtAAAZLgAAvy4AAJsvAAAjMAAAJDAAAJcwAABJMQAAqjEAADIyAAAzMgAApjIAAEQz
AACWMwAAHjQAAB80AACSNAAAMDUAAFw1AADkNQAA5TUAAPo1AAA2NgAAPzYAAEM2AACsNgAArTYA
ACw4AAAtOAAAMjgAAAAAAAAIAAAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAA
ngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAAC
AQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIB
AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEA
AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAA
AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAAC
AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4B
AAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA
AJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAA
AgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC
AQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIB
AAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEA
AAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAA
AgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACe
AQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB
AACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA
AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA
AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC
AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIB
AAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEA
AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAA
ngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAAC
AQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIB
AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEA
AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAA
AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAAC
AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4B
AAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA
AJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAA
AgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC
AQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIB
AAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEA
AAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAA
AgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACe
AQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB
AACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA
AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA
AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC
AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIB
AAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEA
AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAA
ngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAAC
AQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIB
AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEA
AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJYBAAAIAAAA
AgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAACe
AQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB
AACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA
AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA
AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC
AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEAAAIB
AAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAngEA
AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAJYBAAAAAAAACAAAAAIBAAACAQAA
AgEAAJ4BAAQCAQAAlgEABP9ADYABANMpAADTKQAACNcPBAEAAQDTKQAAAAA/ANMpAABAhMB7AhAA
AAAAAAAAMTgAAFAAABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD/
/wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAUAAABHFpABAAACAgYDBQQFAgMEh3oAIAAA
AIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAF
BQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYE
AgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOwKQAYYHAgEGAAMBAQEB
AQEAAAAAAA4IEAAAAAAAAAAAAAQAAAAAAFMAaQBtAFMAdQBuAAAAi1tTTwAAQSaQAQAAAgsGAwIC
AgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAcgBlAGIAdQBjAGgAZQB0ACAATQBTAAAAIgAE
ADEIiBgA8NAC5ARoAQAAAACpzJcmrMyXJnvMlyYDAAMAAAAOCAAA7C0AAAEAGwAAAAQAAxBhAAAA
DggAAOwtAAABABsAAABhAAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4E
iQVuALQAgYISNAAAEAAZAGQAAAAZAAAA3zUAAN81AAAAAAAA6W4G6QAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAQQIAAAAACDKDcQDwEAAI3AMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAJ8P8PAQABPwAA5AQAAP///3////9/////
f////3////9/////f////3+aSnwA//8SAAAAAAAAABIAVABFAE0AUABPAFIAQQBSAFkAIABEAE8A
QwBVAE0ARQBOAFQAAAAAAAAABQBmAHIAbwBzAHQADgBEAGEAdgBlACAATABpAG4AZABiAGUAcgBn
AGgAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAABgAAAAEAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAA
AAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAAQCAAASAAAAAQAAAJgAAAACAAAAoAAAAAMA
AAC8AAAABAAAAMgAAAAFAAAA2AAAAAYAAADkAAAABwAAAGABAAAIAAAAdAEAAAkAAACMAQAAEgAA
AJgBAAAKAAAAtAEAAAsAAADAAQAADAAAAMwBAAANAAAA2AEAAA4AAADkAQAADwAAAOwBAAAQAAAA
9AEAABMAAAD8AQAAAgAAAOQEAAAeAAAAEwAAAFRFTVBPUkFSWSBET0NVTUVOVAAAHgAAAAEAAAAA
RU1QHgAAAAYAAABmcm9zdABBUh4AAAABAAAAAHJvcx4AAABzAAAAVEQgeHh4IChQTEVOLzE2KSAg
Rm9yOiBHZW5ldmEsIDI2IEp1bHkgLSA1IEF1Z3VzdCAyMDA1DURvY3VtZW50IGRhdGU6IA1TYXZl
ZCBieSBJRi00MzUxMyBhdCAxMTozMToxNCBvbiAyMC4wNy4yMDA1AAAeAAAACwAAAE5vcm1hbC5k
b3QATh4AAAAPAAAARGF2ZSBMaW5kYmVyZ2gAKR4AAAACAAAAMwB2ZR4AAAAUAAAATWljcm9zb2Z0
IFdvcmQgMTAuMABAAAAAANJJawAAAABAAAAAAOruD2SRxQFAAAAAAGb47WmRxQFAAAAAADhCWWqR
xQEDAAAAAQAAAAMAAAAOCAAAAwAAAOwtAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAAC
AAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmupAEAAGABAAAPAAAAAQAAAIAA
AAACAAAAiAAAAA4AAACUAAAADwAAAKQAAAAEAAAA2AAAAAUAAADgAAAABgAAAOgAAAARAAAA8AAA
ABcAAAD4AAAACwAAAAABAAAQAAAACAEAABMAAAAQAQAAFgAAABgBAAANAAAAIAEAAAwAAAA/AQAA
AgAAAOQEAAAeAAAAAQAAAAAAdAAeAAAABgAAAElUVS1UAG8AHgAAACwAAABJbnRlcm5hdGlvbmFs
IFRlbGVjb21tdW5pY2F0aW9uIFVuaW9uIChJVFUpAAMAAAA3LAAAAwAAAGEAAAADAAAAGwAAAAMA
AADfNQAAAwAAAE8aCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEwAA
AFRFTVBPUkFSWSBET0NVTUVOVAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAADwVQAA
CQAAAAAAAABQAAAAAQAAAM8AAAACAAAA1wAAAAMAAABfVQAABAAAAHtVAAAFAAAAh1UAAAYAAACv
VQAABwAAALtVAAAIAAAA41UAAAcAAAACAAAADAAAAF9QSURfSExJTktTAAMAAAAHAAAARG9jbnVt
AAQAAAAIAAAARG9jZGF0ZQAFAAAACgAAAERvY29ybGFuZwAGAAAADAAAAERvY2JsdWVwaW5rAAcA
AAAIAAAARG9jZGVzdAAIAAAACgAAAERvY2F1dGhvcgACAAAA5AQAAEEAAACAVAAA+AEAAAMAAABW
AAMAAwAAAPYAAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4A
aQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBu
AGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcA
UAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAFQARAAm
AHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAOAB3AAMA
AADzAAAAAwAAAAAAAAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1
AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0A
ZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAm
AHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8A
dQByAGMAZQA9AFIAYQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAxADAALwAxADYAAAAfAAAAAQAA
AAAAAAADAAAALAA3AAMAAADwAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8A
LwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBz
AHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0A
VAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAtADAAMAA3ADcAAAAA
AB8AAAABAAAAAAAAAAMAAABWAAMAAwAAAO0AAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQA
dABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABv
AGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMA
dQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAw
ADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAA
AQAAAAAAAAADAAAAOAB3AAMAAADqAAAAAwAAAAAAAAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6
AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4A
YQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBn
AHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAA
NwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9AFIAYQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAx
ADAALwAxADYAAAAfAAAAAQAAAAAAAAADAAAALAA2AAMAAADnAAAAAwAAAAAAAAADAAAABQAAAB8A
AABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0
AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0A
ZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBX
AFAAMwAtADAAMAA3ADYAAAAAAB8AAAABAAAAAAAAAAMAAABWAAMAAwAAAOQAAAADAAAAAAAAAAMA
AAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAv
AG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0A
ZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBU
ADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEA
MQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAcgAgAAMAAADhAAAAAwAAAAAAAAADAAAABQAA
AB8AAACIAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUA
ZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBs
AGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUA
LQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9AEUAZABpAHQAbwBy
ACUAMgAwAEcALgA3ADIAOQAlADIAMABBAHAAcABlAG4AZABpAHgAJQAyADAASQBJAEkAAAAfAAAA
AQAAAAAAAAADAAAALAA1AAMAAADeAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6
AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4A
YQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0
AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAtADAAMAA3ADUA
AAAAAB8AAAABAAAAAAAAAAMAAABVAAAAAwAAANsAAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABo
AHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcA
ZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAm
AHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYA
LQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMgAzAC8AMQA2AAAAAAAf
AAAAAQAAAAAAAAADAAAADQBAAAMAAADYAAAAAwAAAAAAAAADAAAABQAAAB8AAACCAAAAaAB0AHQA
cAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBj
AC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUA
YgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1
ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9AEkAUwBPAC8ASQBFAEMAJQAyADAASgBUAEMA
JQAyADAAMQAvAFMAQwAlADIAMAAyADkAAAAfAAAAAQAAAAAAAAADAAAALAA0AAMAAADVAAAAAwAA
AAAAAAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQA
LwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBt
AHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAA
NwAyADYALQBUAEQALQBXAFAAMwAtADAAMAA3ADQAAAAAAB8AAAABAAAAAAAAAAMAAABWAAMAAwAA
ANIAAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUA
LgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBl
ACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYA
cABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBl
AHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAOAB3AAMAAADPAAAA
AwAAAAAAAAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBu
AHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQA
eQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQBy
AGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMA
ZQA9AFIAYQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAxADAALwAxADYAAAAfAAAAAQAAAAAAAAAD
AAAALAAzAAMAAADMAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0
AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUA
LQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAtADAAMAA3ADMAAAAAAB8AAAAB
AAAAAAAAAAMAAABWAAMAAwAAAMkAAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoA
LwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBh
AHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcA
cgBvAHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3
ADIANgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAA
AAADAAAAOAB3AAMAAADGAAAAAwAAAAAAAAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6AC8ALwB3
AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAA
PwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1
AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYA
LQBUAEQAJgBzAG8AdQByAGMAZQA9AFIAYQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAxADAALwAx
ADYAAAAfAAAAAQAAAAAAAAADAAAALAAxAAMAAADDAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAA
aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBn
AGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAA
YQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAt
ADAAMAA3ADEAAAAAAB8AAAABAAAAAAAAAAMAAABWAAMAAwAAAMAAAAADAAAAAAAAAAMAAAAFAAAA
HwAAAHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBl
AHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwA
ZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAt
AFMARwAxADYALQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8A
MQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAOAB3AAMAAAC9AAAAAwAAAAAAAAADAAAABQAAAB8AAAB8
AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkA
bgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQBy
AHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcA
MQA2AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9AFIAYQBwAHAAbwByAHQAZQB1
AHIAJQAyADAAUQAxADAALwAxADYAAAAfAAAAAQAAAAAAAAADAAAALQA5AAMAAAC6AAAAAwAAAAAA
AAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBt
AGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMA
JgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAy
ADYALQBUAEQALQBXAFAAMwAtADAAMAA2ADkAAAAAAB8AAAABAAAAAAAAAAMAAABWAAMAAwAAALcA
AAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBp
AG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYA
dAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABh
AHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMA
dABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAOAB3AAMAAAC0AAAAAwAA
AAAAAAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQA
LwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBw
AGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUA
bgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9
AFIAYQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAxADAALwAxADYAAAAfAAAAAQAAAAAAAAADAAAA
LQA4AAMAAACxAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu
AGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkA
cABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBT
AEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAtADAAMAA2ADgAAAAAAB8AAAABAAAA
AAAAAAMAAABWAAMAAwAAAK4AAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAv
AHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMA
cAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBv
AHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIA
NgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAAD
AAAAOAB3AAMAAACrAAAAAwAAAAAAAAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBs
AGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAA
PQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBU
AEQAJgBzAG8AdQByAGMAZQA9AFIAYQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAxADAALwAxADYA
AAAfAAAAAQAAAAAAAAADAAAALQA3AAMAAACoAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAAaAB0
AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQA
bwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQBy
AGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAtADAA
MAA2ADcAAAAAAB8AAAABAAAAAAAAAAMAAABWAAMAAwAAAKUAAAADAAAAAAAAAAMAAAAFAAAAHwAA
AHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQA
aQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABl
AHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMA
RwAxADYALQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2
AAAAAAAfAAAAAQAAAAAAAAADAAAAOAB3AAMAAACiAAAAAwAAAAAAAAADAAAABQAAAB8AAAB8AAAA
aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBn
AGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMA
JgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2
AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9AFIAYQBwAHAAbwByAHQAZQB1AHIA
JQAyADAAUQAxADAALwAxADYAAAAfAAAAAQAAAAAAAAADAAAALQA2AAMAAACfAAAAAwAAAAAAAAAD
AAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQA
LwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMAJgBs
AGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYA
LQBUAEQALQBXAFAAMwAtADAAMAA2ADYAAAAAAB8AAAABAAAAAAAAAAMAAABWAAMAAwAAAJwAAAAD
AAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4A
dAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5
AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUAcAA9AFcAUAAzACYAcABhAHIA
ZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAFQARAAmAHEAdQBlAHMAdABp
AG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAOAB3AAMAAACZAAAAAwAAAAAA
AAADAAAABQAAAB8AAAB8AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBt
AGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUA
PQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBXAFAAMwAmAHAAYQByAGUAbgB0
AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQAJgBzAG8AdQByAGMAZQA9AFIA
YQBwAHAAbwByAHQAZQB1AHIAJQAyADAAUQAxADAALwAxADYAAAAfAAAAAQAAAAAAAAADAAAALQA1
AAMAAACWAAAAAwAAAAAAAAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkA
dAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABl
AD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcA
MQA2AC0AMAA1ADAANwAyADYALQBUAEQALQBXAFAAMwAtADAAMAA2ADUAAAAAAB8AAAABAAAAAAAA
AAMAAABWAAMAAwAAAJMAAAADAAAAAAAAAAMAAAAFAAAAHwAAAHEAAABoAHQAdABwADoALwAvAHcA
dwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/
AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHMAdQBiAGcAcgBvAHUA
cAA9AFcAUAAzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAt
AFQARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAA
cgAgAAMAAACQAAAAAwAAAAAAAAADAAAABQAAAB8AAACHAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu
AGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEA
bgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBzAHUAYgBnAHIAbwB1AHAAPQBX
AFAAMwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBUAEQA
JgBzAG8AdQByAGMAZQA9AEUAZABpAHQAbwByACUAMgAwAEcALgA3ADIAOQAlADIAMABBAHAAcABl
AG4AZABpAHgAJQAyADAASQBJAAAAAAAfAAAAAQAAAAAAAAADAAAALQA0AAMAAACNAAAAAwAAAAAA
AAADAAAABQAAAB8AAABbAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBt
AGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBtAHMA
JgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAy
ADYALQBUAEQALQBXAFAAMwAtADAAMAA2ADQAAAAAAB8AAAABAAAAAAAAAAMAAAA3ACIAAwAAAIoA
AAADAAAAAAAAAAMAAAAFAAAAHwAAAGMAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBp
AG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYA
dAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2
AC0AMAA1ADAANwAyADYALQBEACYAcQB1AGUAcwB0AGkAbwBuAD0AUQAxADAALwAxADYAAAAAAB8A
AAABAAAAAAAAAAMAAABNAAoAAwAAAIcAAAADAAAAAAAAAAMAAAAFAAAAHwAAAGIAAABoAHQAdABw
ADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMA
LgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHAAYQBy
AGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBEACYAcwBvAHUAcgBjAGUA
PQBTAGkAZQBtAGUAbgBzAAAAHwAAAAEAAAAAAAAAAwAAABQAUQADAAAAhAAAAAMAAAAAAAAAAwAA
AAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8A
bQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABh
AG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0A
RAAtADAAMgAxADUAAAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAACBAAAAAwAAAAAAAAADAAAABQAA
AB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUA
ZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBs
AGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0A
RAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAATQAK
AAMAAAB+AAAAAwAAAAAAAAADAAAABQAAAB8AAABiAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkA
dAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBn
AD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0A
UwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0AUwBpAGUAbQBlAG4AcwAA
AB8AAAABAAAAAAAAAAMAAAAUAFEAAwAAAHsAAAADAAAAAAAAAAMAAAAFAAAAHwAAAFYAAABoAHQA
dABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABv
AGMALgBhAHMAcAA/AHQAeQBwAGUAPQBtAGkAdABlAG0AcwAmAGwAYQBuAGcAPQBlACYAcABhAHIA
ZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAEQALQAwADIAMQA0AAAAHwAA
AAEAAAAAAAAAAwAAAD8AIgADAAAAeAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAYwAAAGgAdAB0AHAA
OgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAu
AGEAcwBwAD8AbABhAG4AZwA9AGUAJgB0AHkAcABlAD0AbQBmAG8AbABkAGUAcgBzACYAcABhAHIA
ZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAEQAJgBxAHUAZQBzAHQAaQBv
AG4APQBRADEAOAAvADEANgAAAAAAHwAAAAEAAAAAAAAAAwAAAEcAFwADAAAAdQAAAAMAAAAAAAAA
AwAAAAUAAAAfAAAAYQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBk
AC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AbABhAG4AZwA9AGUAJgB0AHkAcABlAD0A
bQBmAG8AbABkAGUAcgBzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3
ADIANgAtAEQAJgBzAG8AdQByAGMAZQA9AE4AbwByAHQAZQBsAAAAAAAfAAAAAQAAAAAAAAADAAAA
FwBZAAMAAAByAAAAAwAAAAAAAAADAAAABQAAAB8AAABWAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu
AGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkA
cABlAD0AbQBpAHQAZQBtAHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBT
AEcAMQA2AC0AMAA1ADAANwAyADYALQBEAC0AMAAxADkAMQAAAB8AAAABAAAAAAAAAAMAAAA3ACIA
AwAAAG8AAAADAAAAAAAAAAMAAAAFAAAAHwAAAGMAAABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0
AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcAZABvAGMALgBhAHMAcAA/AGwAYQBuAGcA
PQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBT
AEcAMQA2AC0AMAA1ADAANwAyADYALQBEACYAcQB1AGUAcwB0AGkAbwBuAD0AUQAxADAALwAxADYA
AAAAAB8AAAABAAAAAAAAAAMAAABXAAEAAwAAAGwAAAADAAAAAAAAAAMAAAAFAAAAHwAAAGEAAABo
AHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBuAGcA
ZABvAGMALgBhAHMAcAA/AGwAYQBuAGcAPQBlACYAdAB5AHAAZQA9AG0AZgBvAGwAZABlAHIAcwAm
AHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAANwAyADYALQBEACYAcwBvAHUA
cgBjAGUAPQBDAGEAbgBhAGQAYQAAAAAAHwAAAAEAAAAAAAAAAwAAABcAWQADAAAAaQAAAAMAAAAA
AAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8A
bQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBz
ACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcA
MgA2AC0ARAAtADAAMQA5ADAAAAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAABmAAAAAwAAAAAAAAAD
AAAABQAAAB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQA
LwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBt
AGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcA
MgA2AC0ARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAAD
AAAAVwABAAMAAABjAAAAAwAAAAAAAAADAAAABQAAAB8AAABhAAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBs
AGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQA
MAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0AQwBhAG4AYQBk
AGEAAAAAAB8AAAABAAAAAAAAAAMAAAAXAFgAAwAAAGAAAAADAAAAAAAAAAMAAAAFAAAAHwAAAFYA
AABoAHQAdABwADoALwAvAHcAdwB3AC4AaQB0AHUALgBpAG4AdAAvAG0AZAAvAG0AZQBlAHQAaQBu
AGcAZABvAGMALgBhAHMAcAA/AHQAeQBwAGUAPQBtAGkAdABlAG0AcwAmAGwAYQBuAGcAPQBlACYA
cABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAEQALQAwADEAOAA5
AAAAHwAAAAEAAAAAAAAAAwAAADcAIgADAAAAXQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAYwAAAGgA
dAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBk
AG8AYwAuAGEAcwBwAD8AbABhAG4AZwA9AGUAJgB0AHkAcABlAD0AbQBmAG8AbABkAGUAcgBzACYA
cABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAwADUAMAA3ADIANgAtAEQAJgBxAHUAZQBz
AHQAaQBvAG4APQBRADEAMAAvADEANgAAAAAAHwAAAAEAAAAAAAAAAwAAABAAGwADAAAAWgAAAAMA
AAAAAAAAAwAAAAUAAAAfAAAAdgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0
AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AbABhAG4AZwA9AGUAJgB0AHkA
cABlAD0AbQBmAG8AbABkAGUAcgBzACYAcABhAHIAZQBuAHQAPQBUADAANQAtAFMARwAxADYALQAw
ADUAMAA3ADIANgAtAEQAJgBzAG8AdQByAGMAZQA9AFQAZQB4AGEAcwAlADIAMABJAG4AcwB0AHIA
dQBtAGUAbgB0AHMALAAlADIAMABJAG4AYwAuAAAAHwAAAAEAAAAAAAAAAwAAABcAWAADAAAAVwAA
AAMAAAAAAAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkA
bgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0
AGUAbQBzACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAA
NQAwADcAMgA2AC0ARAAtADAAMQA4ADMAAAAfAAAAAQAAAAAAAAADAAAAHwAVAAMAAABUAAAAAwAA
AAAAAAADAAAABQAAAB8AAAB+AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQA
LwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBw
AGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAA
NQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0AUwBhAG0AcwB1AG4AZwAlADIAMABFAGwAZQBj
AHQAcgBvAG4AaQBjAHMAJQAyADAAQwBvAC4ALAAlADIAMABMAHQAZAAuAAAAHwAAAAEAAAAAAAAA
AwAAABcAVwADAAAAUQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3
AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8A
dAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1
AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQA3ADgAAAAfAAAAAQAAAAAAAAADAAAA
NwAiAAMAAABOAAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu
AGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEA
bgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1
AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8A
MQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAHwAVAAMAAABLAAAAAwAAAAAAAAADAAAABQAAAB8AAAB+
AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkA
bgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQBy
AHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHMA
bwB1AHIAYwBlAD0AUwBhAG0AcwB1AG4AZwAlADIAMABFAGwAZQBjAHQAcgBvAG4AaQBjAHMAJQAy
ADAAQwBvAC4ALAAlADIAMABMAHQAZAAuAAAAHwAAAAEAAAAAAAAAAwAAABcAVwADAAAASAAAAAMA
AAAAAAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0
AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUA
bQBzACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAw
ADcAMgA2AC0ARAAtADAAMQA3ADcAAAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAABFAAAAAwAAAAAA
AAADAAAABQAAAB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBt
AGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUA
PQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAw
ADcAMgA2AC0ARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAA
AAADAAAAHwAVAAMAAABCAAAAAwAAAAAAAAADAAAABQAAAB8AAAB+AAAAaAB0AHQAcAA6AC8ALwB3
AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAA
PwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9
AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0AUwBhAG0A
cwB1AG4AZwAlADIAMABFAGwAZQBjAHQAcgBvAG4AaQBjAHMAJQAyADAAQwBvAC4ALAAlADIAMABM
AHQAZAAuAAAAHwAAAAEAAAAAAAAAAwAAABcAVwADAAAAPwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA
VgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABp
AG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUA
JgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQA3
ADYAAAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAAA8AAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAA
aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBn
AGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMA
JgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBl
AHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAKQB9AAMAAAA5AAAA
AwAAAAAAAAADAAAABQAAAB8AAABfAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBu
AHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQA
eQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAt
ADAANQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0ARQBUAFIASQAAAAAAHwAAAAEAAAAAAAAA
AwAAABcAVQADAAAANgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3
AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8A
dAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1
AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQA1ADMAAAAfAAAAAQAAAAAAAAADAAAA
NwAiAAMAAAAzAAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAu
AGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEA
bgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1
AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8A
MQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAKQB9AAMAAAAwAAAAAwAAAAAAAAADAAAABQAAAB8AAABf
AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkA
bgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQBy
AHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHMA
bwB1AHIAYwBlAD0ARQBUAFIASQAAAAAAHwAAAAEAAAAAAAAAAwAAABcAVQADAAAALQAAAAMAAAAA
AAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8A
bQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBz
ACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcA
MgA2AC0ARAAtADAAMQA1ADIAAAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAAAqAAAAAwAAAAAAAAAD
AAAABQAAAB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQA
LwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBt
AGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcA
MgA2AC0ARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAAD
AAAAKQB9AAMAAAAnAAAAAwAAAAAAAAADAAAABQAAAB8AAABfAAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBs
AGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQA
MAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0ARQBUAFIASQAA
AAAAHwAAAAEAAAAAAAAAAwAAABcAVQADAAAAJAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAVgAAAGgA
dAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBk
AG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUAJgBwAGEA
cgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQA1ADEAAAAf
AAAAAQAAAAAAAAADAAAANwAiAAMAAAAhAAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAAaAB0AHQA
cAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBj
AC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEA
cgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBlAHMAdABp
AG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAIAA9AAMAAAAeAAAAAwAAAAAA
AAADAAAABQAAAB8AAABrAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBt
AGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUA
PQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAw
ADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0ARgByAGEAbgBjAGUAJQAyADAAVABlAGwAZQBjAG8A
bQAAAAAAHwAAAAEAAAAAAAAAAwAAABcAUwADAAAAGwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAVgAA
AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4A
ZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUAJgBw
AGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQAzADUA
AAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAAAYAAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAAaAB0
AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQA
bwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBw
AGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBlAHMA
dABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAIAA9AAMAAAAVAAAAAwAA
AAAAAAADAAAABQAAAB8AAABrAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQA
LwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBw
AGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAA
NQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0ARgByAGEAbgBjAGUAJQAyADAAVABlAGwAZQBj
AG8AbQAAAAAAHwAAAAEAAAAAAAAAAwAAABcAUwADAAAAEgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA
VgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABp
AG4AZwBkAG8AYwAuAGEAcwBwAD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUA
JgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQAz
ADQAAAAfAAAAAQAAAAAAAAADAAAANwAiAAMAAAAPAAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAA
aAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBn
AGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMA
JgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBl
AHMAdABpAG8AbgA9AFEAMQAwAC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAWQBTAAMAAAAMAAAA
AwAAAAAAAAADAAAABQAAAB8AAAB+AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBu
AHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQA
eQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAt
ADAANQAwADcAMgA2AC0ARAAmAHMAbwB1AHIAYwBlAD0ATQBhAHQAcwB1AHMAaABpAHQAYQAlADIA
MABFAGwAZQBjAHQAcgBpAGMAJQAyADAAKABQAGEAbgBhAHMAbwBuAGkAYwApAAAAHwAAAAEAAAAA
AAAAAwAAABcAUQADAAAACQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAVgAAAGgAdAB0AHAAOgAvAC8A
dwB3AHcALgBpAHQAdQAuAGkAbgB0AC8AbQBkAC8AbQBlAGUAdABpAG4AZwBkAG8AYwAuAGEAcwBw
AD8AdAB5AHAAZQA9AG0AaQB0AGUAbQBzACYAbABhAG4AZwA9AGUAJgBwAGEAcgBlAG4AdAA9AFQA
MAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAtADAAMQAxADEAAAAfAAAAAQAAAAAAAAAD
AAAANwAiAAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAABjAAAAaAB0AHQAcAA6AC8ALwB3AHcA
dwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBs
AGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQAZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQA
MAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAmAHEAdQBlAHMAdABpAG8AbgA9AFEAMQAw
AC8AMQA2AAAAAAAfAAAAAQAAAAAAAAADAAAAfgAvAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8A
AAB7AAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQALwBtAGQALwBtAGUAZQB0
AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwBsAGEAbgBnAD0AZQAmAHQAeQBwAGUAPQBtAGYAbwBsAGQA
ZQByAHMAJgBwAGEAcgBlAG4AdAA9AFQAMAA1AC0AUwBHADEANgAtADAANQAwADcAMgA2AC0ARAAm
AHMAbwB1AHIAYwBlAD0ATQBpAG4AZABzAHAAZQBlAGQAJQAyADAAVABlAGMAaABuAG8AbABvAGcA
aQBlAHMALAAlADIAMABJAG4AYwAuAAAAAAAfAAAAAQAAAAAAAAADAAAAFwBQAAMAAAAAAAAAAwAA
AAAAAAADAAAABQAAAB8AAABWAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdAB1AC4AaQBuAHQA
LwBtAGQALwBtAGUAZQB0AGkAbgBnAGQAbwBjAC4AYQBzAHAAPwB0AHkAcABlAD0AbQBpAHQAZQBt
AHMAJgBsAGEAbgBnAD0AZQAmAHAAYQByAGUAbgB0AD0AVAAwADUALQBTAEcAMQA2AC0AMAA1ADAA
NwAyADYALQBEAC0AMAAxADAANAAAAB8AAAABAAAAAAAAAAMAAAAPACQAAwAAAAMAAAADAAAAAAAA
AAMAAAAFAAAAHwAAABcAAABtAGEAaQBsAHQAbwA6AHQAcwBiAHMAZwAxADYAQABpAHQAdQAuAGkA
bgB0AAAAAAAfAAAAAQAAAAAAAAAeAAAAEQAAAFREIHh4eCAoUExFTi8xNikAZWNvHgAAAAEAAAAA
RCB4HgAAAB8AAABFbmdsaXNoIG9ubHkgT3JpZ2luYWw6IEVuZ2xpc2gAIB4AAAABAAAAAG5nbB4A
AAAgAAAAR2VuZXZhLCAyNiBKdWx5IC0gNSBBdWd1c3QgMjAwNQAeAAAAAQAAAABlbmUAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA
BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAAS
AAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAA
AAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAA
AC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAA
PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABL
AAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkA
AABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAA
AGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAA
dgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACE
AAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIA
AACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAA
AKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAA
rwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9
AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAP7/
///MAAAAzQAAAM4AAADPAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAA
ANoAAADbAAAA3AAAAN0AAADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA
6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2
AAAA9wAAAPgAAAD5AAAA+gAAAPsAAAD8AAAA/QAAAP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQB
AAAFAQAABgEAAAcBAAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAD+////DwEAABABAAARAQAAEgEA
ABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAA
IQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAv
AQAAMAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7AQAAPAEAAD0B
AAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAARQEAAEYBAABHAQAASAEAAEkBAABKAQAASwEA
AEwBAABNAQAATgEAAE8BAABQAQAAUQEAAFIBAABTAQAAVAEAAFUBAABWAQAAVwEAAFgBAABZAQAA
WgEAAFsBAABcAQAAXQEAAF4BAABfAQAAYAEAAGEBAABiAQAAYwEAAGQBAABlAQAA/v///2cBAABo
AQAAaQEAAGoBAABrAQAAbAEAAG0BAAD+////bwEAAHABAABxAQAAcgEAAHMBAAB0AQAAdQEAAHYB
AAB3AQAAeAEAAHkBAAB6AQAAewEAAHwBAAB9AQAAfgEAAH8BAACAAQAAgQEAAIIBAACDAQAAhAEA
AIUBAACGAQAAhwEAAIgBAACJAQAAigEAAIsBAACMAQAAjQEAAI4BAACPAQAAkAEAAJEBAACSAQAA
kwEAAJQBAACVAQAAlgEAAJcBAACYAQAAmQEAAP7////9/////f////3////9////nwEAAP7////+
/////v//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA
cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////
////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAw9P1lapHFAaEBAACAAAAAAAAAAEQA
YQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ywAAAHOFAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAOAQAAxq8AAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDlAEAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ
AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZgEAAAAQAAAAAAAABQBE
AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA
AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABu
AQAAlFcAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAA
AMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdv
cmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
--=====================_60751095==_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=====================_60751095==_--




From avt-bounces@ietf.org Tue Jul 26 10:56:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxQrb-0003Py-Hx; Tue, 26 Jul 2005 10:56:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQra-0003Pr-9E
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 10:56:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25655
	for <avt@ietf.org>; Tue, 26 Jul 2005 10:56:55 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRMd-0007C6-GS
	for avt@ietf.org; Tue, 26 Jul 2005 11:29:04 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 59D9365C
	for <avt@ietf.org>; Tue, 26 Jul 2005 16:56:44 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Jul 2005 16:56:43 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Jul 2005 16:56:43 +0200
Message-ID: <42E64F2B.3050202@ericsson.com>
Date: Tue, 26 Jul 2005 16:56:43 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Jul 2005 14:56:43.0259 (UTC)
	FILETIME=[3C78CCB0:01C591F2]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Subject: [AVT] To consider at the AVT session in Paris
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi AVT participants,

We have a very packed schedule for the two AVT sessions in Paris. Due to 
this we must all help ensure that this will go smoothly and be a 
productive meeting. Thus please remember the following, especially 
people doing presentations:

- The approved time is for discussing issues, not for information.
- Keep slide material to a minimum and concentrate it to explain the 
issues and possible solution alternatives that you like to discuss.
- Assume that people has read the drafts.
- Read the drafts you are interested in!
- Leave time for actual discussion of raised issues
- Leave time for other to raise issues

Also presenters, the slides SHALL be sent to us chairs TWO days prior to 
the session you will present in! This allows us chairs to review the 
slides and provide feedback on them.

Presenters are also recommended to prime the discussion by sending 
emails to the list about the issues they like to discuss a few days in 
advance.

Cheers

Magnus Westerlund
AVT chair

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 avt-bounces@ietf.org Tue Jul 26 12:18:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxS8N-0001Qx-Cq; Tue, 26 Jul 2005 12:18:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxS8L-0001Qp-Jv
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 12:18:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02852
	for <avt@ietf.org>; Tue, 26 Jul 2005 12:18:19 -0400 (EDT)
Received: from cluster-d.mailcontrol.com ([217.69.20.190]
	helo=rly18d.srv.mailcontrol.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxSdQ-0001ok-Jk
	for avt@ietf.org; Tue, 26 Jul 2005 12:50:29 -0400
Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12])
	by rly18d.srv.mailcontrol.com (MailControl) with SMTP id
	j6QGI2cb030553; Tue, 26 Jul 2005 17:18:02 +0100
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
	smtp id 344f_0f801694_fdf1_11d9_9f00_0030482aac25;
	Tue, 26 Jul 2005 18:19:36 +0200
Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55])
	by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
	with ESMTP id 2005072618175909-159708 ;
	Tue, 26 Jul 2005 18:17:59 +0200 
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de;
	Tue, 26 Jul 2005 18:19:38 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE:
	[AVT]IESG comments
	ondraft-ietf-avr-rtp-retransmission-11.txt-	Issue 4:
	moreparameters needed for RTX?)
Date: Tue, 26 Jul 2005 18:15:27 +0200
Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F31EBF1@lan-ex-01.panasonic.de>
Thread-Topic: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE:
	[AVT]IESG comments
	ondraft-ietf-avr-rtp-retransmission-11.txt-	Issue 4:
	moreparameters needed for RTX?)
Thread-Index: AcWOzRFIeSO/tta4QXiiRuvtfGDnXwDL50sQ
To: "IETF AVT WG" <avt@ietf.org>
From: "Jose Rey" <Jose.Rey@eu.panasonic.com>
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MailControl A-05-01-05 (www.mailcontrol.com)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e
Content-Transfer-Encoding: quoted-printable
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>,
	Colin Perkins <csp@csperkins.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


Hi,

I would like to hear from people what they think of this proposal: is it =
too wrong or is it acceptable? =20

The retransmission draft is in is final phase and I would NOT like to =
delay this much more or to hold a lengthy discussion on this.  If the =
feeling is that the below proposal is too bold, we should think of =
satisfying the IESG request on this matter in other form and not in the =
draft.

Please comment,

Jos=E9

=20

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20
> Behalf Of Jose Rey
> Sent: Friday, July 22, 2005 5:25 PM
> To: IETF AVT WG
> Subject: Re-send: Simple estimate for Nr. of retransmissions=20
> (WAS:RE: [AVT]IESG comments=20
> ondraft-ietf-avr-rtp-retransmission-11.txt- Issue 4:=20
> moreparameters needed for RTX?)
>=20
>=20
> Hi again!
>=20
>=20
> the ML formatting messed up the tables so I send it again
> ---
>=20
> [warning: long email!]
>=20
> Hi all,
>=20
> Following Marks' suggestions (quoted email below) I will try=20
> to draft an algorithm for finding out a simple estimate of=20
> the default number of retransmissions (per packet) that a=20
> streaming client and server using RTX should attempt in order=20
> to minimise the packet loss, while considering the available=20
> RTCP bandwidth and the client buffering time
> (both values usually known to the client).   The algorithm=20
> also requires
> knowledge of the RTT, which shall be known at the client at least (?).
> The absolute minimum number of retransmission attempts should=20
> of course be one, but the algorithm tries to extract the=20
> highest number possible.
>=20
> This email shall be thought as a first version; there many=20
> assumptions I made and some of them might be wrong.  As a=20
> result of these simplifications, the estimate seems overly=20
> conservative but that might even be good.  I would like to=20
> get feedback if people think this is reasonable, in the first=20
> place.  I have not experimented with this since I don't have=20
> the resources to do so.  Also, it would useful to know if=20
> this would help someone creating SDP sessions using RTX to=20
> get an idea of the factors to take into account.
>=20
> Here it goes:
>=20
> Scenario
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
> * streaming scenario; two RTP entities:server and client
> * retransmission draft used
> * RTCP bandwidth for SRs and RRs =3D 5% (default), 2,5% for=20
> server and client.
> * RTP bandwidths of 64, 128, 256 and 512 kbps
> * RTT =3D 200ms
> * RTCP RR compound packet size of  44 bytes containing: 1 RR,=20
> 1 SDES item with CNAME, no encryption header, no profile=20
> specific extensions.
> This ignores the other RR that could be present because of=20
> SSRC multiplexing since it is not useful for the calculation
> * AVPF Generic NACKs used for requesting retransmissions:=20
> this add 16 bytes of overhead to the RR for reporting a 16bit=20
> mask and 4 bytes more every multiple of 16: 20 for 32, 24 for 48, etc.
> * We assume 1 packet loss every RTCP
> * We assume that the additional retransmissions queued on=20
> sender don't add any delay to the first-time transmissions.=20
>=20
> Observations:
>=20
> 1.- The RTCP_interval at which the client sends=20
> retransmission requests shall be greater than the RTT.  This=20
> is logical otherwise the retransmissions don't have enough=20
> time to be received.=20
>  + this means for higher RTP bandwidths the default (5% RTP=20
> bw for RTCP) may yield two small RTCP_intervals which have to=20
> be adapted using bandwidth modifiers, so that the resulting=20
> RTCP intervals are >=3D RTT  + For this it is required that the=20
> creator of the SDP session has an estimate of the RTT.
> 2.- We assume a worst-case scenario at which a new Generic=20
> NACK report block is added every to every new RTCP compound=20
> RR.  This may be too conservative for some scenarios where=20
> the packet rate is low but it is realistic for others like=20
> video at 30fps (which may yield in more than 30 packets per second). =20
> 3.- We assume that each packet exhausts its corresponding=20
> number of available retransmissions, N.  This means that if a=20
> packet is requested for retransmission a maximum of two=20
> times, the corresponding generic NACK report block requesting=20
> that particular packet is sent in two consecutive RTCP=20
> compounds; likewise, if it is requested for retransmission 10=20
> times, then the RTCP compound contains that generic NACK 10=20
> times.  This assumption fixes the RTCP packet size (leaving=20
> out the averaging with SR packets) to the same value after=20
> N*RTCP_interval seconds, namely to 44 bytes + 12 bytes (fixed=20
> Generic NACK headers) + 4*N =3D 56 bytes + 4*N
>=20
>=20
> Solution
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> In the diagram below, the worst case situation for singleton=20
> losses is represented (first packet SN=3D0 is lost).  There,=20
> the client buffering time required to allocate at least one=20
> retransmission  is T=3D T1+T2+ (T3+T4+T1+T2).  The first term=20
> accounts for the downlink one-way-delay and the lost packet=20
> detection time (due to reordering buffer).  The second (in=20
> brackets) additionally includes the feedback transmission on=20
> the uplink channel and the processing and queueing delay.  In detail:
>=20
> T1=3D physical delay DL + transmission delay DL=20
> (=3Davg-packet-size/downlink
> bitrate) + interarrival delay jitter
> T2=3D packet-loss-detection-time +=20
> time-to-next-client-rtcp-report T3=3D physical delay UL +=20
> transmission delay UL + interarrival delay jitter T4=3D=20
> feedback processing time + queuing time
>=20
>=20
>=20
>=20
>       Sender
>      +-+---------------------------------^-----\-----------------
>       \ \                               /       \
>        \ \                             |         |
>  SN=3D0   \ \ SN=3D1                  SN=3Dn /         \  RTX(SN=3D0)
>          \ \                          /           \
>           X \                        /             \
>              `.                     /               \
>                \                   /                 \
>                 \                 |                   |
>                  \                /                   \    ......
>                   \              /                     \
>      -------------V-------------/-----------------------V--------
>             T1           T2        T3       T4     T1   ........
>        Receiver
>=20
>=20
> If there should more than one retransmission required, say N,=20
> just multiply the second term by N.  This means that the=20
> client buffering time required assure N retransmissions is=20
> T1+T2 + N*(T3+T4+T1+T2) .
>=20
> Now we have to find out or simplify each term Ti.  We start=20
> with T1+T2.
> We know that T1+T3 is ~=3DRTT, so T1 ~=3D T3 ~=3D RTT/2. On the=20
> other hand, the worst case T2~=3Dinterarrival delay jitter +=20
> RTCP_interval ~=3D RTCP_interval (?).  So T1+T2 <=20
> 2*RTCP_interval. T4 is probably very small so we ignore it (?). =20
> If these approximations are acceptable (T3+T4+T1+T2)~=3D RTT+=20
> RTCP_interval_client <=3D 2*RTCP_interval_client  (as per=20
> observation 1 above).  Summarising, the *very conservative*=20
> client buffering time required to guarantee N retransmissions=20
> is N* 2* RTCP_interval_client.=20
>=20
> T =3D 2*RTCP_interval_client + 2*N*RTCP_interval_client =3D 2*=20
> (N+1)* RTCP_interval_client
>=20
> Numbers:
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Some numerical examples for RTT~=3D200ms
>=20
> Table 1
> 				RTCP_interval_client vs. N
>=20
>                 		  1	2	5	7	10=09
> RTP bps	RTCP bps=09
> 64000	      1600	       0.3	0.32	0.38	0.42	0.48
> 128000	3200	       0.15 0.16	0.19	0.21	0.24=09
> 256000	6400	       0.08	0.08	0.095	0.105	0.12=09
> 512000	12800	       0.04 0.04	0.048	0.053	0.06=09
>=20
> 			Required Client Buffering Time vs. N [s]
>=20
>                 		 1	2	5	7	10
> RTP bps	RTCP bps=09
> 64000	      1600	       1.2	1.92	4.56	6.72	10.56
> 128000	3200	       0.6	0.96	2.28	3.36	5.28
> 256000	6400	       0.3	0.48	1.14	1.68	2.64
> 512000	12800	       0.15	0.24	0.57	0.84	1.32
>=20
>=20
>=20
>=20
> Table 2 presents basically the same result as in Table 1=20
> *only* that those RTCP_intervals < RTT have been replaced with RTT!!
>=20
> 				RTCP_interval_client vs. N=09
>                 		  1	2	5	7	10=09
> RTP bps	RTCP bps=09
> 64000	      1600	        0.3	0.32	0.38	0.42	0.48=09
> 128000	3200		  0.2	0.2	0.2	0.21	0.24=09
> 256000	6400		  0.2	0.2	0.2	0.2	0.24=09
> 512000	12800		  0.2	0.2	0.2	0.2	0.24=09
>=20
> 				Required Client Buffering Time vs. N [s]
>=20
>                 		  1	2	5	7	10
> RTP bps	RTCP bps=09
> 64000	      1600	        1.2	1.92	4.56	6.72	10.56
> 128000	3200		  0.8	1.2	2.4	3.36	5.28
> 256000	6400		  0.8	1.2	2.4	3.2	5.28
> 512000	12800		  0.8	1.2	2.4	3.2	5.28
>=20
>=20
> Summary
> =3D=3D=3D=3D=3D=3D=3D
>=20
> The conservative estimate for the number of possible=20
> retransmissions as a function of the client buffering time=20
> and the RTCP_client_interval, under the assumptions given=20
> would be then:
>=20
> 	N=3D [Client-buffering-time / 2* RTCP_interval_client] -1=20
>=20
> >From the Tables it can be seen that the estimate does not result in
> excessive buffer requirements. =20
>=20
> Comments?
>=20
> ---------------------------------------------
> Jose Rey     mailto:jose.rey@eu.panasonic.com
> P R D C G - Panasonic R&D Center Germany GmbH
> Phone/Fax: +49(0)6103766-134/166
> ---------------------------------------------=20
>=20
>=20
> --quote
>=20
> > >>This still sounds like a big dose of handwaving to me. Can
> > you not at
> > >>least include some min/max here so you are sure that
> > packets don't get
> > >>lost? A recommended default that would at least *work* and
> > not cause
> > >>lost packets? Sure, leave room for optimization based on=20
> bandwidth=20
> > >>modifiers, specific configuration, etc. but I'm afraid that
> > without a
> > >>starting point or specific algorithm you could end up with widely=20
> > >>variant choices here from future implementations (unless,
> > as I said,
> > >>people just go figure out what vendor x does and copy it,=20
> in which=20
> > >>case it should have just been in the spec).
> > >>
> > >=20
> > >=20
> > > Of course, the minimum is one. For enabling at least one
> > rtx per packet, the server is only required to save it for=20
> some period=20
> > of time.  This time has several components:
> > >=20
> > > 1- the time that the client takes to notice the loss.  For
> > single tone losses this is when the next packet comes (taking out=20
> > reordering buffer now), that is the intearrivel jitter plus
> > > 2- the time it has to wait until the next RTCP send time,
> > which is ~1/2*RTCP interval if we assume uniform=20
> distribution,which is=20
> > common plus
> > > 3- the time it takes for the server to process rtx request
> > (ignore it?)
> > > 4- 1 RTT to account for the initial (failed) tx and the
> > time it takes for the rtx packet to the client
> > >=20
> > > For more than 1, just multiply. =20
> > >=20
> > > This is a rough & quick analysis using common sense but I
> > haven't experimented with this. For bursty losses this is more=20
> > complex, of course (term 2 is complex).  Reordering is a=20
> fixed delay,=20
> > more or less.
> > >=20
> > > The maximum can be calculated in the same way by using up
> > the available buffer. =20
> > >=20
> > > For the time being, one could make a table with link
> > bandwidths, typical RTTs and what the buffer amount should be as=20
> > f(RTT) for different RTCP bws, at least for the default 5%.=20
>  As well=20
> > as for the maximum rtxs that the buffer allows.
> > >=20
> > > Does this make sense?
> >=20
> > Yes, it is at least something for an implementation to go by.=20
> > Since you mention
> > that you haven't experimented with this, I assume there is not much=20
> > implementation of such a method? I was hoping that there were some=20
> > implementations to try and document here rather than=20
> designing on the=20
> > fly based on my comments. If this is brand new, perhaps you=20
> could pass=20
> > the table and algorithm by the WG in a separate thread to=20
> see if there=20
> > is consensus for it.
> >=20
> > Thanks,
> >=20
> > - Mark
>=20
>=20
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>=20
>=20


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



From avt-bounces@ietf.org Tue Jul 26 12:57:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxSk3-0004uA-GF; Tue, 26 Jul 2005 12:57:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSjz-0004ta-W9
	for avt@megatron.ietf.org; Tue, 26 Jul 2005 12:57:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05495
	for <avt@ietf.org>; Tue, 26 Jul 2005 12:57:13 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DxTF5-0002zc-Oh for avt@ietf.org; Tue, 26 Jul 2005 13:29:24 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-2.cisco.com with ESMTP; 26 Jul 2005 09:57:06 -0700
Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com
	[171.70.93.77])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6QGv3Is023927;
	Tue, 26 Jul 2005 09:57:03 -0700 (PDT)
Received: from klantz-w2k02.cisco.com ([171.69.114.110]) by
	vtg-um-e2k6.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 26 Jul 2005 09:57:05 -0700
Message-Id: <6.2.1.2.2.20050726093519.02fff828@vtg-um-e2k6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 26 Jul 2005 09:37:09 -0700
To: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
From: Keith Lantz <klantz@cisco.com>
Subject: RE: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1015941F0@ftrdmel1.rd.franc
	etelecom.fr>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1015941F0@ftrdmel1.rd.francetelecom.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-OriginalArrivalTime: 26 Jul 2005 16:57:05.0639 (UTC)
	FILETIME=[0D588770:01C59203]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA05495
Cc: zzx-IETF-AVT <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Figured it was EV. My point was that there are multiple alternatives for =
EV=20
that are still in play, as noted in the document list I distributed=20
earlier. So my question was "which of those alternatives (for EV)" does=20
your draft relate to? (I'm guessing its France Telecom's proposal, but on=
e=20
can never be sure. ;-) )

Keith

At 01:08 AM 7/26/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
>It concerns the G.729-based embedded variable bit rate extension to G.72=
9=20
>(G729EV). I called it X in the draft because the final corresponding ann=
ex=20
>letter is still not determined.
>
>The other big ITU current work on G.729 is about annex B (VAD and silenc=
e=20
>suppresion) and is not related to the proposed RTP payload format.
>
>Aurelien
>
>-----Message d'origine-----
>De : Keith Lantz [mailto:klantz@cisco.com]
>Envoy=E9 : mardi 26 juillet 2005 02:29
>=C0 : SOLLAUD Aurelien RD-TECH-LAN
>Cc : zzx-IETF-AVT
>Objet : Re: [AVT] TR: I-D=20
>ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>
>I deleted your response to the query below, but ... Having now reviewed=20
>the list of contributions to the current ITU sessions related to G.729=20
>(see the attached list), I've gotta ask: Which of the many enhancements=20
>still under consideration does this payload format refer to?
>
>Regards, Keith
>
>At 08:51 AM 7/18/2005, Keith Lantz wrote:
> >Per the earlier "debate" on this list re VC-1, could you distribute or
> >otherwise point people at the current draft for the "G.729X" spec?
> >(Unlike SMPTE, I've never heard anyone object to distribution of an IT=
U
> >draft.)
> >
> >Thx, Keith
> >
> >At 01:43 AM 7/18/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
> >>Hi,
> >>
> >>I posted a -01 update of the RTP payload format for the future
> >>scalable and wideband extension of G.729 audio codec.
> >>
> >>The major update is a simplification of the payload format. The
> >>payload header is no more optional and hence the (tricky)
> >>acknowledgement procedure has been removed. I added more spec on the=20
> MBS part.
> >>The implementation should be now much easier.
> >>
> >>Note that the ITU-T standardization of the codec is on schedule, it
> >>should be delivered at the end of 2005.
> >>
> >>Comments are welcome.
> >>
> >>Aurelien
> >>
> >>-----Message d'origine-----
> >>De : i-d-announce-bounces@ietf.org
> >>[mailto:i-d-announce-bounces@ietf.org]
> >>De la part de Internet-Drafts@ietf.org Envoy=E9 : jeudi 14 juillet 20=
05
> >>21:50 =C0 : i-d-announce@ietf.org Objet : I-D
> >>ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
> >>
> >>A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories.
> >>
> >>
> >>         Title           : RTP payload format for the future scalable=
 and
> >>                           wideband extension of G.729 audio codec
> >>         Author(s)       : A. Sollaud
> >>         Filename        : draft-sollaud-avt-rtp-g729-scal-wb-ext-01.=
txt
> >>         Pages           : 15
> >>         Date            : 2005-7-14
> >>
> >>This document specifies a real-time transport protocol (RTP) payload
> >>    format to be used for the future scalable and wideband extension =
of
> >>    the International Telecommunication Union (ITU-T) G.729 audio cod=
ec.
> >>    A media type registration is included for this payload format.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-w=
b
> >>-ext-01.txt
> >>

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



From avt-bounces@ietf.org Wed Jul 27 03:54:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxgkX-0000sE-HS; Wed, 27 Jul 2005 03:54:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgkV-0000s9-LS
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 03:54:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05397
	for <avt@ietf.org>; Wed, 27 Jul 2005 03:54:41 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxhFh-0002PC-1G
	for avt@ietf.org; Wed, 27 Jul 2005 04:26:59 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 09:54:32 +0200
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.5.7226.0
Subject: RE: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Date: Wed, 27 Jul 2005 09:54:29 +0200
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1015944F6@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: [AVT] TR: I-D
	ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt 
Thread-Index: AcWSAw8ceuKLYHrBRHmW7iiX5ckbxAAezgzw
From: "SOLLAUD Aurelien RD-TECH-LAN" <aurelien.sollaud@francetelecom.com>
To: "Keith Lantz" <klantz@cisco.com>
X-OriginalArrivalTime: 27 Jul 2005 07:54:32.0923 (UTC)
	FILETIME=[6CD402B0:01C59280]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Content-Transfer-Encoding: quoted-printable
Cc: zzx-IETF-AVT <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Keith,
The answer is: all alternatives. There is nothing specific to any =
particular implementation.

The proposed payload format is based on the Terms of Reference and will =
apply whatever candidate becomes the actual standard. (Since the winner =
MUST be compliant with the Terms of Reference)

Please re-read the second part of my previous answer
http://www1.ietf.org/mail-archive/web/avt/current/msg05676.html

Regards,
Aurelien

-----Message d'origine-----
De : Keith Lantz [mailto:klantz@cisco.com]=20
Envoy=E9 : mardi 26 juillet 2005 18:37
=C0 : SOLLAUD Aurelien RD-TECH-LAN
Cc : zzx-IETF-AVT
Objet : RE: [AVT] TR: I-D =
ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt=20

Figured it was EV. My point was that there are multiple alternatives for =
EV that are still in play, as noted in the document list I distributed =
earlier. So my question was "which of those alternatives (for EV)" does =
your draft relate to? (I'm guessing its France Telecom's proposal, but =
one can never be sure. ;-) )

Keith

At 01:08 AM 7/26/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
>It concerns the G.729-based embedded variable bit rate extension to=20
>G.729 (G729EV). I called it X in the draft because the final=20
>corresponding annex letter is still not determined.
>
>The other big ITU current work on G.729 is about annex B (VAD and=20
>silence
>suppresion) and is not related to the proposed RTP payload format.
>
>Aurelien
>
>-----Message d'origine-----
>De : Keith Lantz [mailto:klantz@cisco.com] Envoy=E9 : mardi 26 juillet=20
>2005 02:29 =C0 : SOLLAUD Aurelien RD-TECH-LAN Cc : zzx-IETF-AVT Objet : =

>Re: [AVT] TR: I-D ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
>
>I deleted your response to the query below, but ... Having now reviewed =

>the list of contributions to the current ITU sessions related to G.729=20
>(see the attached list), I've gotta ask: Which of the many enhancements =

>still under consideration does this payload format refer to?
>
>Regards, Keith
>
>At 08:51 AM 7/18/2005, Keith Lantz wrote:
> >Per the earlier "debate" on this list re VC-1, could you distribute=20
> >or otherwise point people at the current draft for the "G.729X" spec?
> >(Unlike SMPTE, I've never heard anyone object to distribution of an=20
> >ITU
> >draft.)
> >
> >Thx, Keith
> >
> >At 01:43 AM 7/18/2005, SOLLAUD Aurelien RD-TECH-LAN wrote:
> >>Hi,
> >>
> >>I posted a -01 update of the RTP payload format for the future=20
> >>scalable and wideband extension of G.729 audio codec.
> >>
> >>The major update is a simplification of the payload format. The=20
> >>payload header is no more optional and hence the (tricky)=20
> >>acknowledgement procedure has been removed. I added more spec on the
> MBS part.
> >>The implementation should be now much easier.
> >>
> >>Note that the ITU-T standardization of the codec is on schedule, it=20
> >>should be delivered at the end of 2005.
> >>
> >>Comments are welcome.
> >>
> >>Aurelien
> >>
> >>-----Message d'origine-----
> >>De : i-d-announce-bounces@ietf.org
> >>[mailto:i-d-announce-bounces@ietf.org]
> >>De la part de Internet-Drafts@ietf.org Envoy=E9 : jeudi 14 juillet=20
> >>2005 21:50 =C0 : i-d-announce@ietf.org Objet : I-D=20
> >>ACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
> >>
> >>A New Internet-Draft is available from the on-line Internet-Drafts=20
> >>directories.
> >>
> >>
> >>         Title           : RTP payload format for the future =
scalable and
> >>                           wideband extension of G.729 audio codec
> >>         Author(s)       : A. Sollaud
> >>         Filename        : =
draft-sollaud-avt-rtp-g729-scal-wb-ext-01.txt
> >>         Pages           : 15
> >>         Date            : 2005-7-14
> >>
> >>This document specifies a real-time transport protocol (RTP) payload
> >>    format to be used for the future scalable and wideband extension =
of
> >>    the International Telecommunication Union (ITU-T) G.729 audio =
codec.
> >>    A media type registration is included for this payload format.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-sollaud-avt-rtp-g729-scal-
> >>wb
> >>-ext-01.txt
> >>

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



From avt-bounces@ietf.org Wed Jul 27 04:40:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxhT1-0004s9-4h; Wed, 27 Jul 2005 04:40:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxhSz-0004rz-KD
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 04:40:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08064
	for <avt@ietf.org>; Wed, 27 Jul 2005 04:40:39 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxhyC-0003xA-RB
	for avt@ietf.org; Wed, 27 Jul 2005 05:12:58 -0400
Received: by rproxy.gmail.com with SMTP id r35so196594rna
	for <avt@ietf.org>; Wed, 27 Jul 2005 01:40:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=SWcwmM0r5zg2uxV0vVmQpFptMnkGZx1FTy2bWHD326teWKPunz9tClAxWfs9LqqhnGaFpF8lDiY47H2nMojStJn8Jm0jdHvXehbTR5ec2gT2sRCFVNi4J9SbF9CeJ1U31UE6/q+DZxuTA4p0HsL5epxpw1/vd0ZBUfX3Moc7ss0=
Received: by 10.38.151.59 with SMTP id y59mr380006rnd;
	Wed, 27 Jul 2005 01:40:39 -0700 (PDT)
Received: by 10.38.10.51 with HTTP; Wed, 27 Jul 2005 01:40:39 -0700 (PDT)
Message-ID: <dd76d40b0507270140515f29d7@mail.gmail.com>
Date: Wed, 27 Jul 2005 16:40:39 +0800
From: tk <tunkeat@gmail.com>
To: avt@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: quoted-printable
Subject: [AVT] rfc2833. rtp for dtmf. sending dtmf packets
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: tk <tunkeat@gmail.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

hi,

I have a question on sending dtmf packets.  under Section 3.6=20
of Rfc2833, it says that "...start transmitting event packets as soon
as it recognizes an event and every 50ms thereafter or the packet interval
for the audio codec used for this session, if known. ..."

Assuming that the packet interval has been negotiated
to be 20ms. Under section 3.1 "DTMF digits...MUST use the same sequence
number and time-stamp base as the regular audio channel..."
Given the above sentence, I don't see how one is able to fulfill the above
requirement (sending audio and event packets when the 2 packet sizes
are different.

pls advise.

thanks.
tk

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



From avt-bounces@ietf.org Wed Jul 27 04:45:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxhXE-00069M-OR; Wed, 27 Jul 2005 04:45:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxhXC-00068E-4K
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 04:45:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08278
	for <avt@ietf.org>; Wed, 27 Jul 2005 04:44:59 -0400 (EDT)
Received: from lon-del-02.spheriq.net ([195.46.50.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxi2N-00044O-RO
	for avt@ietf.org; Wed, 27 Jul 2005 05:17:18 -0400
Received: from lon-out-02.spheriq.net ([195.46.50.130])
	by lon-del-02.spheriq.net with ESMTP id j6R8iS2r029180
	for <avt@ietf.org>; Wed, 27 Jul 2005 08:44:28 GMT
Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37])
	by lon-out-02.spheriq.net with ESMTP id j6R8iRjV022405
	for <avt@ietf.org>; Wed, 27 Jul 2005 08:44:27 GMT
Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35])
	by lon-cus-01.spheriq.net with ESMTP id j6R8iH9Z002396
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK);
	Wed, 27 Jul 2005 08:44:23 GMT
Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9])
	by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP
	id 13DB6DA6A; Wed, 27 Jul 2005 08:43:40 +0000 (GMT)
Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012)
	id 1A1D2473C2; Wed, 27 Jul 2005 08:45:46 +0000 (GMT)
Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1])
	by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D2D7975994;
	Wed, 27 Jul 2005 08:45:45 +0000 (UTC)
Received: from mail1.agr.st.com (mail1.agr.st.com [164.130.4.71])
	by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D991D473AF;
	Wed, 27 Jul 2005 08:45:44 +0000 (GMT)
Received: from [10.50.13.70] (ws2586.agr.st.com [10.50.13.70])
	by mail1.agr.st.com (MOS 3.4.4-GR)
	with ESMTP id BOQ13623 (AUTH "andrea vitali");
	Wed, 27 Jul 2005 10:43:35 +0200 (CEST)
Message-ID: <42E74936.3000901@st.com>
Date: Wed, 27 Jul 2005 10:43:34 +0200
From: Andrea Lorenzo VITALI <andrea.vitali@st.com>
Organization: STMicroelectronics
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en,ru,zh
MIME-Version: 1.0
To: Adam Li <adamli@hyervision.com>
Subject: Re: [AVT] Comments on draft-ietf-avt-ulp-11
References: <42DE166E.4020706@ericsson.com>
In-Reply-To: <42DE166E.4020706@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-O-General-Status: No
X-O-Spam1-Status: Not Scanned
X-O-Spam2-Status: Not Scanned
X-O-URL-Status: Not Scanned
X-O-Virus1-Status: No
X-O-Virus2-Status: Not Scanned
X-O-Virus3-Status: No
X-O-Virus4-Status: No
X-O-Virus5-Status: Not Scanned
X-O-Image-Status: Not Scanned
X-O-Attach-Status: Not Scanned
X-SpheriQ-Ver: 2.2.3
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I have reviewed the draft and I have a couple of questions.

1) Have you considered the possibility to refer to non-consecutive RTP packets?

Currently, bits in the mask refer to consecutive RTP packets: starting from the
base sequence number SN: SN+0, SN+1, SN+2 ... SN+i, where 0<=i<24 in RFC2733 and
0<=i<16 or 0<=i<48 in ULP.

It has been proposed in the MPEG forum to refer to non-consecutive RTP packets
by specifying an offset L: SN+0*L, SN+1*L, ... SN+i*L, where 0<=i<24 as in RFC2733.

The document is available on the web at:
   http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf


2) What is the rational behind the costraint a) in par.7.5?

I copy it here for your convenience:
"     a. A media packet SHALL be protected only once at each
              protection level higher than level 0. A media packet MAY be
              protected more than once at level 0 by different packets,
              providing the protection lengths of level 0 of these packets
              are equal.
"

This poses constraints on raised bits in masks for level>0. But perhaps it would
be easier to let the user care and give an hint on the usefulness of the
constraint...

--

I have also a couple of remarks.

1) I was confused by reading in the introduction the following phrase:

"   Lower protection levels provide greater protection by using smaller
        group sizes (compared to higher protection levels) for generating
        the FEC packet.
"

"Lower protections levels" made me think about a low protection but then I read
"greater protection". The contradiction (low or great protection?) confused me.

Of course, this is a problem only for 1st time readers. However, it may be
useful to rephrase as follows:

"   High priority levels provide greater protection ...
        ... (compared to low priority levels ...
"

Then, it can be specified that levels are numbered from hi-pri to low-pri
starting from 0.


2) I appreciated the introduction and the reference to UXP.

It would be useful to include an extensive comparison, including:

   - XOR based FEC schemes as specified in RFC2733 and draft-ietf-avt-ULP-11

   - Reed-Solomon based schemes as specified in draft-ietf-avt-UXP-07, as 
proposed by Siemens/Nokia for 3GPP, as proposed for DVB-H (handheld) under the 
name "MPE_FEC".

   - LDPC (low density parity check codes) based schemes as proposed by INRIA

plus other schemes based on digital fountain codes.

Best regards,

       Andrea

-- 
      ______________________________________________________________

       Andrea VITALI                            andrea.vitali@st.com

       tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
       fax (+39) 039 603 6129

       STMicroelectronics
       Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
       20041 Agrate Brianza (MI) ITALY
      ______________________________________________________________





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



From avt-bounces@ietf.org Wed Jul 27 08:01:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dxkbg-0007RB-Ve; Wed, 27 Jul 2005 08:01:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxkbf-0007R3-2i
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 08:01:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20446
	for <avt@ietf.org>; Wed, 27 Jul 2005 08:01:49 -0400 (EDT)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxl6s-00029y-Rt
	for avt@ietf.org; Wed, 27 Jul 2005 08:34:09 -0400
Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59])
	by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with
	ESMTP id j6RC1OM18328; Wed, 27 Jul 2005 08:01:25 -0400 (EDT)
Received: from [127.0.0.1] (actft029.europe.nortel.com [47.164.193.66]) by
	zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet
	Mail Service Version 5.5.2653.13)
	id PT8N58WL; Wed, 27 Jul 2005 08:01:24 -0400
Message-ID: <42E77789.1040105@nortel.com>
Date: Wed, 27 Jul 2005 08:01:13 -0400
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: "Tom-PT Taylor" <taylor@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tk <tunkeat@gmail.com>
Subject: Re: [AVT] rfc2833. rtp for dtmf. sending dtmf packets
References: <dd76d40b0507270140515f29d7@mail.gmail.com>
In-Reply-To: <dd76d40b0507270140515f29d7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I think the assumption behind the RFC2833 requirement is that the events 
are being transmitted in the same stream as the audio.  There are two 
possibilities:

1) The sender stops transmitting audio and starts transmitting events. 
In this case, if the sequence number of the last audio packet was N, 
that of the first event packet is N+1.  The timestamp behaves similarly, 
even if the increment from the last audio packet to the first event 
packet is larger than the increment between successive audio packets.

2) The more complicated case is that the sender continues to transmit 
audio even as it sends events.  The logic still works.  Here's an 
example, where T is in ms units and timestamp increments at the rate of 
8000 per second.  Assume that we're talking about a single tone 
continuing through the period being depicted.

Time       Packet content      Seq No.     Timestamp

T          Audio                N             X

T          Event                N+1           X

T+20       Audio                N+2           X+160

T+40       Audio                N+3           X+320

T+50       Event update         N+4           X

T+60       Audio                N+5           X+480

etc.





tk wrote:
> hi,
> 
> I have a question on sending dtmf packets.  under Section 3.6 
> of Rfc2833, it says that "...start transmitting event packets as soon
> as it recognizes an event and every 50ms thereafter or the packet interval
> for the audio codec used for this session, if known. ..."
> 
> Assuming that the packet interval has been negotiated
> to be 20ms. Under section 3.1 "DTMF digits...MUST use the same sequence
> number and time-stamp base as the regular audio channel..."
> Given the above sentence, I don't see how one is able to fulfill the above
> requirement (sending audio and event packets when the 2 packet sizes
> are different.
> 
> pls advise.
> 
> thanks.
> tk
> 
> _______________________________________________
> 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 avt-bounces@ietf.org Wed Jul 27 08:15:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dxkoy-00038t-Oa; Wed, 27 Jul 2005 08:15:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxkox-00038o-4l
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 08:15:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21765
	for <avt@ietf.org>; Wed, 27 Jul 2005 08:15:33 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlKB-0002iY-B8
	for avt@ietf.org; Wed, 27 Jul 2005 08:47:53 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	773AC4F0001; Wed, 27 Jul 2005 14:15:29 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 14:15:28 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 14:15:28 +0200
Message-ID: <42E77AE0.7080300@ericsson.com>
Date: Wed, 27 Jul 2005 14:15:28 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jose Rey <Jose.Rey@eu.panasonic.com>
Subject: Re: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE:
	[AVT]	IESG comments on	draft-ietf-avr-rtp-retransmission-11.txt-	Issue
	4: more	parameters needed for RTX?)
References: <4D2F935F08D41A4C8866693F4F0D7C4F31EA0E@lan-ex-01.panasonic.de>
In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4F31EA0E@lan-ex-01.panasonic.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jul 2005 12:15:28.0486 (UTC)
	FILETIME=[E0455860:01C592A4]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129
Content-Transfer-Encoding: 7bit
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Jose,

I seem to have lost track of the actual question. Was it Marks question 
in regards to what the minimal required buffering for N possible 
retransmissions as server side?

I think you have made some errors in the calculations that are quite 
important. First of all I think that setting the RTCP_Interval and RTT 
to the same value is not really valid. The reason is that there is 
clearly bit-rate versus RTT cases that makes this fall on both sides. 
Also it is not obvious that trying to calculate this formula based on 
RTCP transmission interval is any simpler than using RTT. In fact I 
would think that RTCP_Interval is quite difficult to calculate and 
depends on a number of variables that needs to be included.

Secondly I think the average RTCP packet size you have used in 
calculations are way to small. A common RTCP average packet size is 
around 125 octets; remember the required CNAME string and the IP/UDP 
headers. Thus one can construct the following table of RTCP reporting 
intervals compared to BW.
BW	 RTCP_Reporting_Interval Deterministic
64000    0,625
128000   0,3125
256000   0,15625
5120000  0,0078125
10240000 0,00390625
5000000  0,008
10000000 0,004

This doesn't consider the normal minimal interval values. Which is a 
valid point of usage for AVPF. However it also fails to take something 
into account which concerns the retransmission use cases. That is the 
distribution of the sender and receiver classed SSRCs. If the 
retransmission is done using SSRC based multiplexing, then one has an 
RTP session with two senders and one receiver. That result in that the 
bandwidth sharing is the following: Receiver reporting is done using 1/3 
of (RR+RS) bandwidth. The sender side is then having two parts of RR+RS.

Thirdly I think the worst case wait for the next regular transmission is 
1.5*RTCP_Interval/1.21828. One can't ignore the randomization factor in 
this case as there can be requests that ends up being delayed the 
maximum time, not the average one.

In addition I think the consideration must be done for different RTTs. 
Both a very short one like 5 ms and much longer ones (1s) to ensure that 
RTT is correctly taken into consideration.

Regarding T4, the processing time on the server side. I think that 
should actually  be included in the formula as it is something that is 
implementation dependent. It is also a factor when one uses transmission 
scheduling of any type. Thus I think it should be consider to be 
maintained as a variable that has no given value.

Also I would like to introduce a T5 which is the client loss detection time:

        Sender
 >      +-+---------------------------------^-----\-----------------
 >       \ \                               /       \
 >        \ \                             |         |
 >  SN=0   \ \ SN=1                  SN=n /         \  RTX(SN=0)
 >          \ \                          /           \
 >           X \                        /             \
 >              `.                     /               \
 >                \                   /                 \
 >                 \                 |                   |
 >                  \                /                   \    ......
 >                   \              /                     \
 >      -------------V----D--------/-----------------------V--------
 >             T1    T5      T2        T3       T4     T1   ........
 >        Receiver
 >

Where T5 is the time between T1, when it should be have been delivered 
and point D where the client has positively identified a packet as being 
lost. This would at least be the jitter-buffer depth, to allow for 
reordering. However it might be that certain algorithms do add even more 
delay here.

Thus I think that we can revisit your T calculation. Note that T here is 
server side buffering time. Which can arguable be around the same if one 
assumes that client is simply buffering T1 time later than the server:

T=T1+T2+T3+T4+T5; T1+T3 ~= RTT
T=RTT + T2 + T4 +T5; T2 = 1.5/1.21828*RTCP_Interval
T=RTT + 1.2312*RTCP_Interval + T4 + T5;

RTCP_Interval = AVG_RTCP_SIZE * 8*(Senders + Receivers) / (RR+RS); In 
the considered deployment the Sender + Receivers = 3; RR+RS is then 
equal to 5% of Session BW; AVG_RTCP_SIZE = 125
Thus
T=RTT+ 1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW) + T4+T5

T(N) = N*(RTT+1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW)+T4+T5)


As both T4 and T5 are difficult to give specific values for I have set 
them equal to zero which results in underestimated values.

BW       RTT     AVG_RTCP_SIZE  N=1             N=2
64000    0,05    125            1,20425         2,4085
128000   0,05    125            0,627125        1,25425
256000   0,05    125            0,3385625       0,677125
512000   0,05    125            0,19428125      0,3885625
1024000  0,05    125            0,122140625     0,24428125
5000000  0,05    125            0,0647744       0,1295488
10000000 0,05    125            0,0573872       0,1147744


BW       RTT     AVG_RTCP_SIZE  N=1             N=2
64000    0,2     125            1,35425         2,7085
128000   0,2     125            0,777125        1,55425
256000   0,2     125            0,4885625       0,977125
512000   0,2     125            0,34428125      0,6885625
1024000  0,2     125            0,272140625     0,54428125
5000000  0,2     125            0,2147744       0,4295488
10000000 0,2     125            0,2073872       0,4147744


BW       RTT     AVG_RTCP_SIZE   1              2
64000    1       125            2,15425         4,3085
128000   1       125            1,577125        3,15425
256000   1       125            1,2885625       2,577125
512000   1       125            1,14428125      2,2885625
1024000  1       125            1,072140625     2,14428125
5000000  1       125            1,0147744       2,0295488
10000000 1       125            1,0073872       2,0147744

BW       RTCP_Interval_D
64000    0,9375
128000   0,46875
256000   0,234375
512000   0,11718755
1024000  0,05859375
5000000  0,012
10000000 0,006

Which to me looks significantly different. First of all I seem to have a 
longer time for the low bit-rate cases. Probably the errors in the RTCP 
transmission schedule. Secondly I seem to have reasonable values for 
higher bit-rates due to that I avoid the simplification between RTCP 
transmission intervals and RTT.

So should we try to improve my formula and provide some guiding numbers 
for certain of the variables? I think it might be worth reconsider the 
used AVG_RTCP_SIZE to a slightly bigger number, due to that I haven't 
fully taken the NACK vector into account.

Then the T4 and T5 values should probably be considered further. The 
unfortunate thing is that T5 is really problematic and highly variable. 
In fact it needs an adoptive mechanism to talk this correctly into 
account. The jitter can be highly variable.

Cheers

Magnus

> Numbers:
> ========
> 
> Some numerical examples for RTT~=200ms
> 
> Table 1
> 				RTCP_interval_client vs. N
> 
>                 		  1	2	5	7	10	
> RTP bps	RTCP bps	
> 64000	      1600	       0.3	0.32	0.38	0.42	0.48
> 128000	3200	       0.15 0.16	0.19	0.21	0.24	
> 256000	6400	       0.08	0.08	0.095	0.105	0.12	
> 512000	12800	       0.04 0.04	0.048	0.053	0.06	
> 
> 			Required Client Buffering Time vs. N [s]
> 
>                 		 1	2	5	7	10
> RTP bps	RTCP bps	
> 64000	      1600	       1.2	1.92	4.56	6.72	10.56
> 128000	3200	       0.6	0.96	2.28	3.36	5.28
> 256000	6400	       0.3	0.48	1.14	1.68	2.64
> 512000	12800	       0.15	0.24	0.57	0.84	1.32
> 
> 
> 
> 
> Table 2 presents basically the same result as in Table 1 *only* that
> those RTCP_intervals < RTT have been replaced with RTT!!
> 
> 				RTCP_interval_client vs. N	
>                 		  1	2	5	7	10	
> RTP bps	RTCP bps	
> 64000	      1600	        0.3	0.32	0.38	0.42	0.48	
> 128000	3200		  0.2	0.2	0.2	0.21	0.24	
> 256000	6400		  0.2	0.2	0.2	0.2	0.24	
> 512000	12800		  0.2	0.2	0.2	0.2	0.24	
> 
> 				Required Client Buffering Time vs. N [s]
> 
>                 		  1	2	5	7	10
> RTP bps	RTCP bps	
> 64000	      1600	        1.2	1.92	4.56	6.72	10.56
> 128000	3200		  0.8	1.2	2.4	3.36	5.28
> 256000	6400		  0.8	1.2	2.4	3.2	5.28
> 512000	12800		  0.8	1.2	2.4	3.2	5.28
> 
> 
> Summary
> =======
> 
> The conservative estimate for the number of possible retransmissions as
> a function of the client buffering time and the RTCP_client_interval,
> under the assumptions given would be then:
> 
> 	N= [Client-buffering-time / 2* RTCP_interval_client] -1 
> 
>>From the Tables it can be seen that the estimate does not result in
> excessive buffer requirements.  
> 
> Comments?
> 
> ---------------------------------------------
> Jose Rey     mailto:jose.rey@eu.panasonic.com
> P R D C G - Panasonic R&D Center Germany GmbH
> Phone/Fax: +49(0)6103766-134/166
> --------------------------------------------- 
> 


-- 

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 avt-bounces@ietf.org Wed Jul 27 08:27:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dxl0J-0007Bf-IK; Wed, 27 Jul 2005 08:27:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxl0I-0007Av-0f
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 08:27:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22603
	for <avt@ietf.org>; Wed, 27 Jul 2005 08:27:16 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlVX-00035o-NH
	for avt@ietf.org; Wed, 27 Jul 2005 08:59:36 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 42C3C570
	for <avt@ietf.org>; Wed, 27 Jul 2005 14:27:16 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 14:27:15 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 14:27:15 +0200
Message-ID: <42E77DA3.5090307@ericsson.com>
Date: Wed, 27 Jul 2005 14:27:15 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jul 2005 12:27:15.0296 (UTC)
	FILETIME=[858FFE00:01C592A6]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Content-Transfer-Encoding: 7bit
Subject: [AVT] Updated AVT agenda
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

We have updated the AVT agenda. We have added discussion of the ECRTP 
Reorder draft. This means that a few presenters has been moved around 
between the days. So please check again when you have your time slot.

Audio/Video Transport Working Group

CHAIRS: Colin Perkins     <csp@csperkins.org>
         Magnus Westerlund <magnus.westerlund@ericsson.com>

Tuesday, 2 August 2005, 10:30-12:30
====================================

10:30 Introduction and Status Update                          (Chairs)
                                                                 15 min
    Under development:
          draft-ietf-avt-mime-h224-02
          draft-ietf-avt-profile-savpf-02
          draft-ietf-avt-rtcpssm-09
          draft-ietf-avt-rfc2032-bis-06
          draft-ietf-avt-rfc2190-to-historic-03
          draft-ietf-avt-rfc2429-bis-05
          draft-ietf-avt-rfc2833bis-09
          draft-ietf-avt-rfc2833biscas-00
          draft-ietf-avt-rfc2833bisdata-02
          draft-ietf-avt-rfc3555bis-00
          draft-ietf-avt-rtcp-xr-mib-02
          draft-ietf-avt-rtp-amr-bis-01
          draft-ietf-avt-rtp-atrac-family-04
          draft-ietf-avt-rtp-jpeg2000-08
          draft-ietf-avt-rtp-jpeg2000-beam-01
          draft-ietf-avt-rtp-midi-format-10
          draft-ietf-avt-rtp-midi-guidelines-10
          draft-ietf-avt-rtp-no-op-00
          draft-ietf-avt-rtp-vmr-wb-extension-00
          draft-ietf-avt-tfrc-profile-04
          draft-ietf-avt-ulp-11

          draft-ietf-avt-rfc3119bis-03 (Expired)
          draft-finlayson-avt-mpa-robust-interoperability-01 (Expired)
          draft-ietf-avt-uxp-07 (Expired)
          draft-ietf-avt-variable-rate-audio-00     (Expired)

    AD or IESG Evaluation
          draft-ietf-avt-audio-t140c-00
          draft-ietf-avt-rtp-retransmission-11
          draft-ietf-avt-rtp-framing-contrans-05
          draft-ietf-avt-rtp-vmr-wb-10
          draft-ietf-avt-3gpp-timed-text-15
          draft-ietf-avt-rtp-ac3-07
          draft-ietf-avt-rtp-amrwbplus-06
          draft-jones-avt-audio-t38-05
          draft-garudadri-avt-3gpp2-mime-02
          draft-lim-mpeg4-mime-03

    RFC Editor:
          draft-ietf-avt-hc-mpls-reqs-03
          draft-ietf-avt-rtcp-feedback-11
          draft-burmeister-avt-rtcp-feedback-sim-06
          draft-ietf-avt-rtp-bv-03
          draft-ietf-avt-tcrtp-08
          draft-ietf-avt-uncomp-video-06

    Published RFCs
          draft-ietf-avt-rtp-clearmode-05      -> RFC 4040
          draft-ietf-avt-rtp-dsr-codecs-03     -> RFC 4060
          draft-ietf-avt-text-red-05           -> RFC 4102
          draft-ietf-avt-rfc2793bis-09         -> RFC 4103

    Individual drafts with AVT relation
          draft-ash-avt-hc-over-mpls-protocol-01
          draft-clark-avt-rtcpxr-bis-00
          draft-even-avt-rfc3047-bis-01
          draft-feiten-avt-bsacmode-for-rfc3640-00
          draft-kerr-avt-vorbis-rtp-04
          draft-klemets-avt-rtp-vc1-00
          draft-koren-avt-ecrtp-reorder-00
          draft-lennox-avt-app-sharing-00
          draft-lkchoi-avt-iptvdbs-req-00
          draft-perkins-avt-uncomp-video-ext-00
          draft-singer-rtp-hdrext-00
          draft-singer-smpte-rtp-01
          draft-sollaud-avt-rtp-g729-scal-wb-ext-01
          draft-stirbu-avt-lrdp-00
          draft-vitali-ietf-avt-mdc-lc-00
          draft-wenger-avt-avpf-ccm-00
          draft-xie-avt-compact-bundle-evrc-00
          draft-xie-avt-rtp-anti-shadow-01

Media Type Discussion                                           (chairs)
    draft-ietf-avt-rfc3555bis-00
    draft-freed-media-type-reg-04
    Mailing list discussion

10:45 Using the RTP Header Extension for SMTPE Timestamps       (Singer)
    draft-singer-rtp-hdrext-00                                      5 min
    draft-singer-smpte-rtp-01

10:50 RTCP XR VoIP Metrics Management Information Base           (Clark)
    draft-ietf-avt-rtcp-xr-mib-02                                  10 min

11:00 RTCP XR - New Parameter Extensions                         (Clark)
    draft-clark-avt-rtcpxr-bis-00                                  10 min

11:10 RTP Payload Format for ECN Probing                     (Alexander)
    draft-alexander-rtp-payload-for-ecn-probing-01                 10 min
    draft-babiarz-tsvwg-rtecn-04
    draft-alexander-rtecn-use-cases-00
    draft-alexander-congestion-status-preconditions-00

11:20 Packet reordering in Extended CRTP (ECRTP)                 (Koren)
    draft-koren-avt-ecrtp-reorder-01.txt                           10 min

11:30 Protocol Extensions for Header Compression over MPLS         (Ash)
    draft-ash-avt-hc-over-mpls-protocol-01                         15 min

11:45 RTP Profile for TCP Friendly Rate Control                 (Gharai)
    draft-ietf-avt-tfrc-profile-04                                 15 min

12:00 Strategies for Streaming Media Applications Using TFRC    (Phelan)
    draft-ietf-dccp-tfrc-media-00                                  15 min

12:15 FEC streaming framework                                   (Watson)
    draft-watson-tsvwg-fec-sf-00                                   15 min



Wednesday, 3 August 2005, 9:00-10:00
====================================

9:00 Compact Bundled RTP Format for EVRC Speech                    (Xie)
    draft-xie-avt-compact-bundle-evrc-00                           10 min

9:10 Update of ITU G.722.1 payload format                          (Even)
    draft-even-avt-rfc3047-bis-01                                  10 min

9:20 RTP Payload Format for Video Codec 1 (VC-1)                (Klemets)
    draft-klemets-avt-rtp-vc1-00                                   15 min

9:35 Open issues with Codec Control Messages in AVPF            (Wenger)
    draft-wenger-avt-avpf-ccm-00                                   15 min

9:50 RTCP Extensions for SSM sessions with unicast feedback        (Ott)
    draft-ietf-avt-rtcpssm-09                                      10 min



-- 

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 avt-bounces@ietf.org Wed Jul 27 08:44:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DxlH1-00035W-Bu; Wed, 27 Jul 2005 08:44:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlGz-00035M-Kk
	for avt@megatron.ietf.org; Wed, 27 Jul 2005 08:44:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23573
	for <avt@ietf.org>; Wed, 27 Jul 2005 08:44:31 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlmE-0003a5-Kz
	for avt@ietf.org; Wed, 27 Jul 2005 09:16:52 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C90AF643; 
	Wed, 27 Jul 2005 14:44:28 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 14:44:27 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 27 Jul 2005 14:44:27 +0200
Message-ID: <42E781AB.8080900@ericsson.com>
Date: Wed, 27 Jul 2005 14:44:27 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tmima Koren <tmima@cisco.com>, pruddy@cisco.com, andrjohn@cisco.com,
	IETF AVT WG <avt@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Jul 2005 12:44:27.0792 (UTC)
	FILETIME=[ECFA6100:01C592A8]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [AVT] Comments on draft-koren-avt-ecrtp-reorder-01.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi,

Chair hat off!

I would especially like a discussion on what the purpose of this draft 
is in Paris. I hope the header compression people can also provide 
further input.

I have reviewed the draft and have a few comments.

1. First of all I think this draft needs to define a few things, like 
what backwards reordering is. Also how the different N+1 measurements 
are calculated would benefit from a proper definition. I would suggest a 
new chapter containing the definitions. Preferable with figures etc that 
help explain this.

2. Then I have a really fundamental question about the purpose of this 
draft. It reads like: There is no problem with reordering in ECRTP, but 
it might be good to consider these things. Do you intend to change that. 
I don't think it really appropriate to publish such a draft. I think we 
should be much more straight forward. ECRTP can handle reordering up to 
a certain level that is dependent on the compressor and its state update 
strategy. Why not clear present the limitation and then provide the 
details that the implementor needs to think about to achieve this 
robustness. That would be something worth publishing.

3. Why does many of the examples say discard in them. If one would 
buffer in these cases most seems recoverable at later stage. Is this 
something that ECRTP forces or simple the easiest way of handling it?


Editorial:

E1: Please update the boiler plate, you have one paragraph there that 
references 3667 which after all is obsoleted.

E2: The draft is lacking page breaks.

E3. The chapters are very funny. All the descriptive text is in the 
introduction. Please restructure

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 avt-bounces@ietf.org Thu Jul 28 03:00:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dy2N7-0005TB-0n; Thu, 28 Jul 2005 03:00:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2N4-0005St-EB
	for avt@megatron.ietf.org; Thu, 28 Jul 2005 02:59:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00791
	for <avt@ietf.org>; Thu, 28 Jul 2005 02:59:56 -0400 (EDT)
Received: from ns6.sony.co.jp ([137.153.0.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy2sQ-0001Qu-Dh
	for avt@ietf.org; Thu, 28 Jul 2005 03:32:26 -0400
Received: from mail5.sony.co.jp ([43.0.1.204])
Received: from mail5.sony.co.jp (localhost [127.0.0.1])
	by mail5.sony.co.jp (R8/Sony) with ESMTP id j6S6xUXE021843
	for <avt@ietf.org>; Thu, 28 Jul 2005 15:59:30 +0900 (JST)
Received: from jptkyxim01.jp.sony.com (jptkyxim01.jp.sony.com [43.15.17.87])
	by mail5.sony.co.jp (R8/Sony) with ESMTP id j6S6xUHa021840
	for <avt@ietf.org>; Thu, 28 Jul 2005 15:59:30 +0900 (JST)
Received: from jptkyxwa03.jp.sony.com ([43.15.31.3]) by jptkyxim01.jp.sony.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 28 Jul 2005 15:59:30 +0900
Received: from [43.13.117.153] ([43.13.117.153]) by jptkyxwa03.jp.sony.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Thu, 28 Jul 2005 15:59:29 +0900
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CEB47C0E-0AD7-4FDD-9A06-3C0FE8DEA264@jp.sony.com>
Content-Transfer-Encoding: 7bit
From: Matthew Romaine <Matthew.Romaine@jp.sony.com>
Date: Thu, 28 Jul 2005 15:59:26 +0900
To: avt@ietf.org
X-Mailer: Apple Mail (2.733)
X-OriginalArrivalTime: 28 Jul 2005 06:59:29.0693 (UTC)
	FILETIME=[E65CDCD0:01C59341]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: Mitsuyuki Hatanaka <hatanaka@av.crl.sony.co.jp>,
	Jun Matsumoto <jun@av.crl.sony.co.jp>
Subject: [AVT] ATRAC SDK distribution
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


Fellow AVT-ers,

Thanks to a slight change in mentality within Sony regarding  
proprietary technology, we will be distributing an ATRAC SDK for free  
to interested members during the AVT sessions next week.  While the  
license only permits use for testing and evaluation purposes, the SDK  
is not handicapped in anyway and will allow encoding and decoding of  
ATRAC content.

The purpose for making the SDK available for free to the IETF  
audience is to bring awareness to the ATRAC Family Payload draft.   
You can find the latest version of this draft at the following link:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac- 
family-04.txt

This email is to simply let you know of the SDK's availability during  
next week's AVT sessions, and to encourage interested individuals to  
keep an eye out for where we'll be handing them out (likely at the  
back of the meeting rooms).

Thanks,
Matt

--------------------------------------------
Audio Codec Development Group
ITCNC, Sony Corporation
Tel: +81-3-5448-6065
--------------------------------------------



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



From avt-bounces@ietf.org Thu Jul 28 04:16:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dy3Z4-00026e-0a; Thu, 28 Jul 2005 04:16:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3Z0-00026Z-6q
	for avt@megatron.ietf.org; Thu, 28 Jul 2005 04:16:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04977
	for <avt@ietf.org>; Thu, 28 Jul 2005 04:16:20 -0400 (EDT)
Received: from cluster-d.mailcontrol.com ([217.69.20.190]
	helo=rly22d.srv.mailcontrol.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy44O-0003p6-BJ
	for avt@ietf.org; Thu, 28 Jul 2005 04:48:51 -0400
Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12])
	by rly22d.srv.mailcontrol.com (MailControl) with SMTP id
	j6S8G0QQ009353; Thu, 28 Jul 2005 09:16:00 +0100
Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via
	smtp id 06c2_11fc0540_ff40_11d9_96c4_0030482aac25;
	Thu, 28 Jul 2005 10:17:42 +0200
Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55])
	by eundadmi01.pan.eu (Lotus Domino Release 6.5.2)
	with ESMTP id 2005072810155381-216221 ;
	Thu, 28 Jul 2005 10:15:53 +0200 
Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de;
	Thu, 28 Jul 2005 10:17:35 +0200
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE:
	[AVT]	IESG comments
	on	draft-ietf-avr-rtp-retransmission-11.txt-	Issue 4:
	more	parameters needed for RTX?)
Date: Thu, 28 Jul 2005 10:13:19 +0200
Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F31ED0A@lan-ex-01.panasonic.de>
Thread-Topic: Re-send: Simple estimate for Nr. of retransmissions (WAS:RE:
	[AVT]	IESG comments
	on	draft-ietf-avr-rtp-retransmission-11.txt-	Issue 4:
	more	parameters needed for RTX?)
Thread-Index: AcWSpI6q1qMothhzTcaeH40JJc43hQAGXTIw
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
From: "Jose Rey" <Jose.Rey@eu.panasonic.com>
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="iso-8859-1"
X-Scanned-By: MailControl A-05-01-05 (www.mailcontrol.com)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Content-Transfer-Encoding: quoted-printable
Cc: IETF AVT WG <avt@ietf.org>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

=20
Hi Magnus,


> Hi Jose,
>=20
> I seem to have lost track of the actual question. Was it=20
> Marks question in regards to what the minimal required=20
> buffering for N possible retransmissions as server side?
>=20
His first question was what is the minimum number of retransmissions =
that should be attempted for a packet. A safe answer to that was one, =
otherwise don't do RTX.  My suggestion was then to derive a simple =
estimate for implementors as to what could be the order of magnitude of =
the buffering time, to which he said it would useful.

> I think you have made some errors in the calculations that=20
> are quite important. First of all I think that setting the=20
> RTCP_Interval and RTT to the same value is not really valid.=20

Yeah, the simplification is not correct.  I agree with your numbers =
below.

[snip]

>=20
> Thirdly I think the worst case wait for the next regular=20
> transmission is 1.5*RTCP_Interval/1.21828. One can't ignore=20
> the randomization factor in this case as there can be=20
> requests that ends up being delayed the maximum time, not the=20
> average one.
>
Good point.
=20
> In addition I think the consideration must be done for=20
> different RTTs.=20
> Both a very short one like 5 ms and much longer ones (1s) to=20
> ensure that RTT is correctly taken into consideration.
>=20
> Regarding T4, the processing time on the server side. I think=20
> that should actually  be included in the formula as it is=20
> something that is implementation dependent. It is also a=20
> factor when one uses transmission scheduling of any type.=20
> Thus I think it should be consider to be maintained as a=20
> variable that has no given value.
>=20
OK

> Also I would like to introduce a T5 which is the client loss=20
> detection time:

OK

[snip]
>=20
> T=3DT1+T2+T3+T4+T5; T1+T3 ~=3D RTT
> T=3DRTT + T2 + T4 +T5; T2 =3D 1.5/1.21828*RTCP_Interval T=3DRTT +=20
> 1.2312*RTCP_Interval + T4 + T5;
>=20
> RTCP_Interval =3D AVG_RTCP_SIZE * 8*(Senders + Receivers) /=20
> (RR+RS); In the considered deployment the Sender + Receivers=20
> =3D 3; RR+RS is then equal to 5% of Session BW; AVG_RTCP_SIZE =3D=20
> 125 Thus T=3DRTT+ 1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW) + T4+T5
>=20
> T(N) =3D N*(RTT+1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW)+T4+T5)
>=20
>=20
> As both T4 and T5 are difficult to give specific values for I=20
> have set them equal to zero which results in underestimated values.
>=20
> BW       RTT     AVG_RTCP_SIZE  N=3D1             N=3D2
> 64000    0,05    125            1,20425         2,4085
> 128000   0,05    125            0,627125        1,25425
> 256000   0,05    125            0,3385625       0,677125
> 512000   0,05    125            0,19428125      0,3885625
> 1024000  0,05    125            0,122140625     0,24428125
> 5000000  0,05    125            0,0647744       0,1295488
> 10000000 0,05    125            0,0573872       0,1147744
>=20
>=20
> BW       RTT     AVG_RTCP_SIZE  N=3D1             N=3D2
> 64000    0,2     125            1,35425         2,7085
> 128000   0,2     125            0,777125        1,55425
> 256000   0,2     125            0,4885625       0,977125
> 512000   0,2     125            0,34428125      0,6885625
> 1024000  0,2     125            0,272140625     0,54428125
> 5000000  0,2     125            0,2147744       0,4295488
> 10000000 0,2     125            0,2073872       0,4147744
>=20
>=20
> BW       RTT     AVG_RTCP_SIZE   1              2
> 64000    1       125            2,15425         4,3085
> 128000   1       125            1,577125        3,15425
> 256000   1       125            1,2885625       2,577125
> 512000   1       125            1,14428125      2,2885625
> 1024000  1       125            1,072140625     2,14428125
> 5000000  1       125            1,0147744       2,0295488
> 10000000 1       125            1,0073872       2,0147744
>=20
[snip]

> So should we try to improve my formula and provide some=20
> guiding numbers for certain of the variables? I think it=20
> might be worth reconsider the used AVG_RTCP_SIZE to a=20
> slightly bigger number, due to that I haven't fully taken the=20
> NACK vector into account.

Adding the NACK overhead would be good. What I thought is that we should =
assume 1) the RTP packet rate is so high that every RTCP_interval you =
need an additional NACK block and 2) that all lost packets exhaust their =
available number of retransmissions.  That would be the worstcase =
assumed.  This would mean that after N*RTCP_interval the average packet =
size would be 125 + (12 + 4*N) bytes.=20

In practice, applied to the numbers above, it means that not taking the =
NACK packets into account may result in a buffer estimation error of 2-5 =
seconds depending how many retransmissions.

w/ NACKs
RTP BW      	1    2	7    10
64000	    0.05  1.3   2.78  11.02  16.84
128000    0.05  0.70  1.44  5.68   8.67
256000    0.05  0.38  0.77  3.02   4.59
512000    0.05  0.21  0.43  1.68   2.54
1024000   0.05  0.13  0.27  1.02   1.52
5000000   0.05  0.07  0.13  0.49   0.71
10000000  0.05  0.06  0.12  0.42   0.60
					=09
64000	    0.2   1.50  3.08  12.07 18.34
128000    0.2   0.85  1.74  6.73  10.17
256000    0.2   0.53  1.07  4.07  6.09
512000    0.2   0.36  0.73  2.73  4.04
1024000   0.2   0.28  0.57  2.07  3.02
5000000   0.2   0.22  0.43  1.54  2.21
10000000  0.2   0.21  0.42  1.47  2.10
					=09
64000       1   2.30  4.68  17.67 26.34
128000      1   1.65  3.34  12.33 18.17
256000      1   1.33  2.67  9.67  14.09
512000      1   1.16  2.33  8.33  12.04
1024000	1   1.08  2.17  7.67  11.02
5000000	1   1.02  2.03  7.14  10.21
10000000	1   1.01  2.02  7.07  10.10


w/o NACKs

64000   	0.05  1.20	2.41  8.43	12.04
128000  	0.05  0.63	1.25  4.39	6.27
256000  	0.05  0.34	0.68  2.37	3.39
512000  	0.05  0.19	0.39  1.36	1.94
1024000 	0.05  0.12	0.24  0.85	1.22
5000000 	0.05  0.06	0.13  0.45	0.65
10000000	0.05  0.06	0.11  0.40	0.57
				=09
64000   	0.2  1.35	2.71  9.48	13.54
128000  	0.2  0.78	1.55  5.44	7.77
256000  	0.2  0.49	0.98  3.42	4.89
512000  	0.2  0.34	0.69  2.41	3.44
1024000 	0.2  0.27	0.54  1.90	2.72
5000000 	0.2  0.21	0.43  1.50	2.15
10000000	0.2  0.21	0.41  1.45	2.07
				=09
64000	    	1    2.15	4.31  15.08	21.54
128000	1    1.58	3.15  11.04	15.77
256000	1    1.29	2.58  9.02	12.89
512000	1    1.14	2.29  8.01	11.44
1024000	1    1.07	2.14  7.50	10.72
5000000	1    1.01	2.03  7.10	10.15
10000000	1    1.01	2.01  7.05	10.07

So, I think we should add it, at least to have it said that it may =
become important for multiple retransmissions...

=20

>=20
> Then the T4 and T5 values should probably be considered=20
> further. The unfortunate thing is that T5 is really=20
> problematic and highly variable.=20
> In fact it needs an adoptive mechanism to talk this correctly=20
> into account. The jitter can be highly variable.
>=20

OK we leave them in the formula.

T(N) =3D N*(RTT+1.2312*AVG_RTCP_SIZE * 8 * 3 /(0.05*BW)+T4+T5); where =
AVG_RTCP_SIZE=3D 125 + 12 + 4*N bytes,  if we account for General NACKs

Cheers,

Jos=E9



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



From avt-bounces@ietf.org Thu Jul 28 11:20:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DyAB7-0002qu-UL; Thu, 28 Jul 2005 11:20:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAB6-0002oy-2f
	for avt@megatron.ietf.org; Thu, 28 Jul 2005 11:20:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05074
	for <avt@ietf.org>; Thu, 28 Jul 2005 11:20:05 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAga-0000Jn-10
	for avt@ietf.org; Thu, 28 Jul 2005 11:52:40 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4E094ADD; 
	Thu, 28 Jul 2005 17:20:04 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 28 Jul 2005 17:20:03 +0200
Received: from [147.214.34.40] ([147.214.34.40]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 28 Jul 2005 17:20:03 +0200
Message-ID: <42E8F7A3.7010401@ericsson.com>
Date: Thu, 28 Jul 2005 17:20:03 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrea Lorenzo VITALI <andrea.vitali@st.com>
Subject: Re: [AVT] Comments on draft-ietf-avt-ulp-11
References: <42DE166E.4020706@ericsson.com> <42E74936.3000901@st.com>
In-Reply-To: <42E74936.3000901@st.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jul 2005 15:20:03.0361 (UTC)
	FILETIME=[D3D2E910:01C59387]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi

Please see below for my comments.

Andrea Lorenzo VITALI wrote:
> I have reviewed the draft and I have a couple of questions.
> 
> 1) Have you considered the possibility to refer to non-consecutive RTP packets?
> 
> Currently, bits in the mask refer to consecutive RTP packets: starting from the
> base sequence number SN: SN+0, SN+1, SN+2 ... SN+i, where 0<=i<24 in RFC2733 and
> 0<=i<16 or 0<=i<48 in ULP.
> 
> It has been proposed in the MPEG forum to refer to non-consecutive RTP packets
> by specifying an offset L: SN+0*L, SN+1*L, ... SN+i*L, where 0<=i<24 as in RFC2733.
> 
> The document is available on the web at:
>    http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf
> 

I have actually seen this proposal earlier and have quite mixed feelings 
about it. For a medium to high bandwidth application I can understand 
that 24 packets are to little. 48 makes it better but only goes half-way 
to the minimal 100 packets that the MPEG-PRO requires one to support.

As I see the solution is basically an interleaving scheme and could in 
it simplest form be implemented with a signalling attribute and a change 
to the derivation bit-mask to included packet algorithm.

However before changing the format I would like to know how big interest 
it really is of such a change. See also the next comment.

[snip]
> 
> 2) I appreciated the introduction and the reference to UXP.
> 
> It would be useful to include an extensive comparison, including:
> 
>    - XOR based FEC schemes as specified in RFC2733 and draft-ietf-avt-ULP-11
> 
>    - Reed-Solomon based schemes as specified in draft-ietf-avt-UXP-07, as 
> proposed by Siemens/Nokia for 3GPP, as proposed for DVB-H (handheld) under the 
> name "MPE_FEC".
> 
>    - LDPC (low density parity check codes) based schemes as proposed by INRIA
> 
> plus other schemes based on digital fountain codes.

On this topic I don't think the ULP draft is the right place to have a 
general overview of what possible solutions that exist. It is necessary 
to have a clear applicability section. Describing under which scenarios 
it makes sense to use this format.

When it comes to UXP their is some question if that work will progress 
or be replaced with a more generic framework based on RMT like building 
blocks (draft-watson-tsvwg-fec-sf-00). This will be discussed next week 
in Paris. So there is clearly interest of getting usage of some more 
advanced and better performing FEC codes.

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 avt-bounces@ietf.org Thu Jul 28 12:20:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DyB7u-0005WF-1u; Thu, 28 Jul 2005 12:20:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DyB7s-0005W3-9u
	for avt@megatron.ietf.org; Thu, 28 Jul 2005 12:20:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09882
	for <avt@ietf.org>; Thu, 28 Jul 2005 12:20:49 -0400 (EDT)
Received: from mailgate2.dslextreme.com ([66.51.199.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyBdK-0002Kk-Ot
	for avt@ietf.org; Thu, 28 Jul 2005 12:53:25 -0400
Received: from mail5.dslextreme.com (unknown [192.168.7.93])
	by mailgate2.dslextreme.com (Postfix) with SMTP id E78F93A63F4
	for <avt@ietf.org>; Thu, 28 Jul 2005 09:20:33 -0700 (PDT)
Received: (qmail 6933 invoked from network); 28 Jul 2005 16:20:28 -0000
Received: from unknown (HELO server.hyervision.com) (66.159.193.111)
	by mail5.dslextreme.com with (EDH-RSA-DES-CBC3-SHA encrypted) SMTP;
	Thu, 28 Jul 2005 09:20:28 -0700
Received: from elephant (adsl-66-159-193-142.dslextreme.com [66.159.193.142])
	by server.hyervision.com (8.13.3/8.12.11) with ESMTP id
	j6SGOH1h004035; Thu, 28 Jul 2005 09:24:24 -0700 (PDT)
Message-Id: <200507281624.j6SGOH1h004035@server.hyervision.com>
From: "Adam Li" <adamli@hyervision.com>
To: "'Andrea Lorenzo VITALI'" <andrea.vitali@st.com>
Subject: RE: [AVT] Comments on draft-ietf-avt-ulp-11
Date: Thu, 28 Jul 2005 09:20:21 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <42E5DEC1.6070706@st.com>
Thread-Index: AcWRr9USd0BHf8HSTU2iGS6t46z8PQB3HzcA
X-DSLExtreme-MailGate-Information: Please contact the ISP for more information
X-DSLExtreme-MailGate: Found to be clean
X-MailScanner-From: adamli@hyervision.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Andrea,

Thanks for the comments.

For your question (1), it will be doable technically, though it will greatly
increase the latency of the recovery operation in additional to increasing
the complexity and the memory requirement on the receiving end. At this
stage of this draft, a better solution may be to include your proposal in
other more complex schemes in development?

For your question (2), protecting data multiple times is not as
straightforward as it looks. The recovery criteria are complicated
especially at higher level where the data is only worth recovering when all
the lower level data are recoverable. In most cases, multiple protection in
higher level is not only helpless, but also wastes bandwidth. In view of
that, the multiple protection is not really useful for any level higher than
0. In additional protecting data multiple times would greatly complicate
both the protection process and recovery process. It puts more constraint on
the protection as the length has to stay constant for all the groups. That's
the rationale for that constraint.

For your remark (1), great suggestion. When that paragraph of the draft is
first read, it is can be a little confusing between the protection level
(which is just a number) and strength of protection. I will fix it as you
suggested.

For your remark (2), thanks for the information.

Adam

> -----Original Message-----
> From: Andrea Lorenzo VITALI [mailto:andrea.vitali@st.com]
> Sent: Monday, July 25, 2005 11:57 PM
> To: Adam Li
> Cc: avt@ietf.org
> Subject: Re: [AVT] Comments on draft-ietf-avt-ulp-11
> 
> I have reviewed the draft and I have a couple of questions.
> 
> 1) Have you considered the possibility to refer to non-consecutive RTP
> packets?
> 
> Currently, bits in the mask refer to consecutive RTP packets: starting
> from the
> base sequence number SN: SN+0, SN+1, SN+2 ... SN+i, where 0<=i<24 in
> RFC2733 and
> 0<=i<16 or 0<=i<48 in ULP.
> 
> It has been proposed in the MPEG forum to refer to non-consecutive RTP
> packets
> by specifying an offset L: SN+0*L, SN+1*L, ... SN+i*L, where 0<=i<24 as in
> RFC2733.
> 
> Please find attached a document on this extension to RFC2733.
> 
> 
> 2) What is the rational behind the costraint a) in par.7.5?
> 
> I copy it here for your convenience:
> "     a. A media packet SHALL be protected only once at each
>              protection level higher than level 0. A media packet MAY be
>              protected more than once at level 0 by different packets,
>              providing the protection lengths of level 0 of these packets
>              are equal.
> "
> 
> This poses constraints on raised bits in masks for level>0. But perhaps it
> would
> be easier to let the user care and give an hint on the usefulness of the
> constraint...
> 
> --
> 
> I have also a couple of remarks.
> 
> 1) I was confused by reading in the introduction the following phrase:
> 
> "   Lower protection levels provide greater protection by using smaller
>        group sizes (compared to higher protection levels) for generating
>        the FEC packet.
> "
> 
> "Lower protections levels" made me think about a low protection but then I
> read
> "greater protection". The contradiction (low or great protection?)
> confused me.
> 
> Of course, this is a problem only for 1st time readers. However, it may be
> useful to rephrase as follows:
> 
> "   High priority levels provide greater protection ...
>        ... (compared to low priority levels ...
> "
> 
> Then, it can be specified that levels are numbered from hi-pri to low-pri
> starting from 0.
> 
> 
> 2) I appreciated the introduction and the reference to UXP.
> 
> I think you may find it useful to have a look at the attached
presentation,
> which compares several proposed FEC schemes: RFC2733, ULP, UXP, etc.
> 
> 
> Best regards,
> 
>       Andrea
> 
> --
>      ______________________________________________________________
> 
>       Andrea VITALI                            andrea.vitali@st.com
> 
>       tel (+39) 039 603 7244             mobile (+39) 347 93 08 433
>       fax (+39) 039 603 6129
> 
>       STMicroelectronics
>       Centro Direzionale COLLEONI - Palazzo "DIALETTICA"
>       20041 Agrate Brianza (MI) ITALY
>      ______________________________________________________________
> 
> 




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



From avt-bounces@ietf.org Thu Jul 28 15:40:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DyEEd-0005dw-75; Thu, 28 Jul 2005 15:40:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEEb-0005dF-DP
	for avt@megatron.ietf.org; Thu, 28 Jul 2005 15:40:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24222
	for <avt@ietf.org>; Thu, 28 Jul 2005 15:39:59 -0400 (EDT)
Received: from ns.live.com ([66.80.62.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyEk5-000861-LT
	for avt@ietf.org; Thu, 28 Jul 2005 16:12:36 -0400
Received: from ns.live.com (localhost.live.com [127.0.0.1])
	by ns.live.com (8.13.3/8.12.11) with ESMTP id j6SJddgT029013;
	Thu, 28 Jul 2005 12:39:39 -0700 (PDT) (envelope-from rsf@ns.live.com)
Received: (from rsf@localhost)
	by ns.live.com (8.13.3/8.12.9/Submit) id j6SJddC4029012;
	Thu, 28 Jul 2005 12:39:39 -0700 (PDT) (envelope-from rsf)
Message-Id: <6.2.3.4.1.20050728123327.021573a0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 28 Jul 2005 12:35:52 -0700
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: [AVT] Updated AVT agenda
In-Reply-To: <42E77DA3.5090307@ericsson.com>
References: <42E77DA3.5090307@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org


>         draft-ietf-avt-rfc3119bis-03 (Expired)
>          draft-finlayson-avt-mpa-robust-interoperability-01 (Expired)

FYI, this work isn't dead - just dormant.  I need to update the 
"interoperability report" document to include additional test cases 
(asked for by the IESG).  But to date, other work has taken priority 
(you all know the story :-(

         Ross.



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



From avt-bounces@ietf.org Fri Jul 29 06:32:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DySAC-0002hr-Me; Fri, 29 Jul 2005 06:32:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DyB1I-00038e-5M; Thu, 28 Jul 2005 12:14:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09368;
	Thu, 28 Jul 2005 12:14:01 -0400 (EDT)
Received: from sophia.inria.fr ([138.96.64.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DyBWk-00029a-Ix; Thu, 28 Jul 2005 12:46:37 -0400
Received: from localhost (localhost [127.0.0.1])
	by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j6SFtGjJ032170;
	Thu, 28 Jul 2005 17:55:16 +0200
Received: from sophia.inria.fr (penguin.inria.fr [138.96.240.36])
	by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j6SFp9Bs030775;
	Thu, 28 Jul 2005 17:51:09 +0200
Message-ID: <42E8FEED.BCDCB162@sophia.inria.fr>
Date: Thu, 28 Jul 2005 17:51:09 +0200
From: Sara Alouf <Sara.Alouf@sophia.inria.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.23 i686)
X-Accept-Language: en, fr, pt
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
To: undisclosed-recipients:;
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6
	(sophia.inria.fr [138.96.64.20]);
	Thu, 28 Jul 2005 17:54:30 +0200 (MEST)
X-Virus-Scanned: by amavisd-new at sophia.inria.fr
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id
	j6SFtGjJ032170
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 29 Jul 2005 06:32:23 -0400
Subject: [AVT] Performance 2005: 2nd call for participation
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Dear colleague,

My sincere apologies if you receive multiple copies of this call for
participation. Would you please forward it to interested colleagues and
students?

Thank you,

Sara Alouf
Publicity chair of Performance 2005

------------------------------------------------------------------------

                =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=3D=3D
                C A L L  for  P A R T I C I P A T I O N
                =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=3D=3D

                       ***  PERFORMANCE 2005  ***

             The 24th IFIP WG7.3 International Symposium on
       Computer Performance Modeling, Measurement and Evaluation

                          Juan-les-Pins, France
                            October 3-7, 2005
            http://www-sop.inria.fr/maestro/performance2005/

           =20

The 24th IFIP WG7.3 International Symposium on Computer Performance
Modeling, Measurement and Evaluation (PERFORMANCE 2005) will be held in
Juan-les-Pins, France on October 5-7, 2005 (3 full days). The tutorials
will be held on October 3 and 4, 2005.

The Technical Program has been published
(http://www-sop.inria.fr/maestro/performance2005/program.html),
including the list of accepted posters. This year, there will be 2
keynote lectures given respectively by Profs. J.-P. Hubaux (EPFL) and
P.R. Kumar (University of Illinois at Urbana-Champaign).

** NEW **
There will be a work-in-progress session on Wednesday 5, 2005.
Presentations should last 5 to 10 minutes. To register to this session,
titles and abstracts are to be sent to the session chair
K.Avrachenkov@sophia.inria.fr. Presentations will be selected on a first
come first served basis, in the limit of slots available.

The conference registration form can be found on the conference website.
The early registration deadline is **September 3, 2005**.

Student travel grant:
A number of student travel grants will be available. Details on how to
apply can be found on the conference website. The student grants
applications are due by **August 1, 2005**.

Conference hotel:
Rooms have been reserved at a negotiated rate at
  Hotel Ambassador
  50-52, chemin des Sables
  B.P. 49 - 06160 Juan-Les-Pins Cedex
  FRANCE
  Tel: +33 (0)4 92 93 74 10 - Fax: +33 (0)4 93 67 79 85
  e-mail: manager@hotel-ambassadeur.com
  URL: http://www.hotel-ambassadeur.com/

A list of nearby hotels has been posted on the conference website.

------------------------------------------------------------------------
General Chair:
                Philippe Nain (INRIA, France)

Program Committee Co-Chairs:
                Cheng-Shang Chang (National Tsing Hua U., Taiwan)
                Daniel A. Menasc=E9 (George Mason U., USA)

Tutorial Co-Chairs:
                Eitan Altman (INRIA, France)
                Zhen Liu (IBM T. J. Watson Reseach Center, USA)

Proceedings Chair:
                Rudesindo Nunez Queija (CWI & U. Eindhoven, Netherlands)

Posters Chair:
                Thomas Bonald (France Telecom R&D, France)

Local arrangements:
                Ephie Deriche (INRIA, France)
                Dany Sergeant (INRIA, France)

Finance Chair:
                Dany Sergeant (INRIA, France)

Publicity Chair and webmaster:
                Sara Alouf (INRIA, France)


Corporate Sponsors:
        IBM T.J. Watson Research Center
        France Telecom R&D
        Texas Instruments

Institutional Sponsors:
        IFIP WG7.3
        Computer Performance Foundation
        INRIA
        Conseil R=E9gional de la R=E9gion Provence-Alpes-C=F4te-d'Azur
        Conseil G=E9n=E9ral des Alpes-Maritimes
------------------------------------------------------------------------

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



From avt-bounces@ietf.org Fri Jul 29 11:53:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DyXBO-0002Ea-Nb; Fri, 29 Jul 2005 11:53:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXBN-0002EP-6G
	for avt@megatron.ietf.org; Fri, 29 Jul 2005 11:53:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18689
	for <avt@ietf.org>; Fri, 29 Jul 2005 11:53:54 -0400 (EDT)
Received: from [217.33.106.234] (helo=adell.intra.psytechnics.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyXh2-0005hl-7b
	for avt@ietf.org; Fri, 29 Jul 2005 12:26:42 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
Date: Fri, 29 Jul 2005 16:54:11 +0100
Message-ID: <E186E3CEF52AFA428D4439E12F801406A73A7B@adell.intra.psytechnics.com>
Thread-Topic: Comments on draft-clark-avt-rtcpxr-bis-00.txt
thread-index: AcWUVcKgEp9N6qrYSYmv59l0KZTpQw==
From: "Simon Broom" <simon.broom@psytechnics.com>
To: "IETF AVT WG" <avt@ietf.org>, "Alan Clark" <alan.d.clark@telchemy.com>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [AVT] Comments on draft-clark-avt-rtcpxr-bis-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

Hi Alan,

I have reviewed your draft on New Parameter Extensions for RTCP XR. This
looks to be a useful extension to the XR reporting mechanism; I just
have a few questions/comments.

Section 3.7
- You include external delay, and external quality metrics; it would be
useful to include 'External Signal Level', 'External Noise Level' and
'External RERL' as well. Having information from both 'ends' of the
connection is useful when making conversational quality predictions.

Section 3.8
- I don't understand why a local endpoint would report information
related to a remote endpoint, especially information that may have
already been reported via RTCP XR.=20
- Also, it I'd have thought it would be more useful to report the
speech/noise levels after any level shifts, since this is far more
relevant to perceived voice quality.

Section 3.9
- What is your definition of a 'bridge'?
- In your example, am I correct in my understanding that mid-point
'bridge' sends an XR packet containing estimated values for R-LQ,
R-LQ-ExtIn and R-LQ-ExtOut? Or does it fill in these fields in the
packet sent from Phone B -> Phone A before forwarding it?


Best regards,
Simon

Simon Broom=20
Psytechnics=20
www.psytechnics.com

Voice and Video Quality Assessment



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



From avt-bounces@ietf.org Fri Jul 29 21:11:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dyft4-0005cg-2a; Fri, 29 Jul 2005 21:11:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyft1-0005cY-GU
	for avt@megatron.ietf.org; Fri, 29 Jul 2005 21:11:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22012
	for <avt@ietf.org>; Fri, 29 Jul 2005 21:11:33 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DygOn-0004tf-G7
	for avt@ietf.org; Fri, 29 Jul 2005 21:44:25 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 29 Jul 2005 18:11:26 -0700
X-IronPort-AV: i="3.95,154,1120460400"; 
	d="scan'208"; a="201608268:sNHT38725520"
Received: from vtg-um-e2k6.sj21ad.cisco.com (vtg-um-e2k6.cisco.com
	[171.70.93.77])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6U1BH6x013271
	for <avt@ietf.org>; Fri, 29 Jul 2005 18:11:24 -0700 (PDT)
Received: from klantz-w2k02.cisco.com ([10.82.218.182]) by
	vtg-um-e2k6.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 29 Jul 2005 18:11:21 -0700
Message-Id: <6.2.1.2.2.20050729135439.030d7980@vtg-um-e2k6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Fri, 29 Jul 2005 14:06:07 -0700
To: avt@ietf.org
From: Keith Lantz <klantz@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 30 Jul 2005 01:11:21.0777 (UTC)
	FILETIME=[99055210:01C594A3]
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Subject: [AVT] draft-wenger-avt-avpf-ccm-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request@ietf.org?subject=subscribe>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

I previously submitted an extensive review of this draft to the folks 
listed in the To: line below. Stephan asked me last week to redistribute an 
abridged version to avt, such that the larger community could comment in 
advance of IETF, but ... I failed to notice the request until now. :-( 
Nevertheless, in the event it's of any help, here's a quickly edited 
version of my previous comments. (The original recipients can of course 
reply to my previous message as they wish.)

Regards, Keith

-------------------

Date: Thu, 21 Jul 2005 18:40:56 -0700
To: <Stephan.Wenger@nokia.com>
From: Keith Lantz <klantz@cisco.com>
Subject: Re: Codec commands draft submitted
Cc: <Umesh.Chandra@nokia.com>,<jo@tzi.uni-bremen.de>,<csp@csperkins.org>,
  <klantz@cisco.com>,<oritl@microsoft.com>,<jdrosen@cisco.com>,
  <bo.burman@ericsson.com>,<timmoore@windows.microsoft.com>,
  <magnus.westerlund@ericsson.com>,<roni.even@polycom.co.il>
X-OriginalArrivalTime: 22 Jul 2005 01:41:01.0526 (UTC) 
FILETIME=[6A877760:01C58E5E]

Sorry for the delay in responding.

I'm happy to say that I am generally supportive of the draft. But I do have 
the following comments, in page order (against the -00 version as posted to 
AVT). These range from substantive (?) to editorial nits:

- In general, the "Introduction" seems to be much beefier than the average 
I-D or RFC -- constituting much more of an "executive summary" than is the 
norm. I don't have a particular problem with that ... other than it being 
unexpected.

<snip>

- p. 6 and elsewhere throughout the document: Is "decoder refresh point" a 
generally accepted label? I find it rather cumbersome ... but don't have 
anything better to suggest.

<snip>

- p. 8, first line: I'm not quite sure what "used congestion control 
algorithms" means. Perhaps you need to be specific, e.g. "The congestion 
control algorithms used in <x> and <y> (AMID and TFRC, respectively) probe ..."

         The last sentence of that list item is broken. I think you're 
trying to say the following: "To minimize disruption of service, especially 
in reduced-bandwidth environments, quick convergence is desired. This 
suggests the use of media path signalling." (???)

<snip>

- p. 10, first paragraph: You probably meant "implicitly" when writing 
"imlicitely", but then ... what does "not implicitly synchronized with the 
media stream" mean?

<snip>

- Section 3.2.4, top of p. 11: "bit-rate for a media to, or below," --> 
"bit-rate for a media stream to". I don't think you need emphasis the 
"below" part.

         In the rest of the document you then mention "stream thinning" 
quite a bit. I'm not sure this concept is well enough known as to *NOT* 
include a definition and/or some examples -- especially when referring to 
media-aware and media-unaware stream thinning. I at least am not sure what, 
specifically, you're talking about. :-( For example, on the next page, 
there appears to be an opportunity to reference layered coding as one 
potential mechanism to support stream thinning, but ... I'm not sure.

<snip>

- p. 11, last paragraph, before the list and/or in list and elsewhere: The 
discussion surrounding the need/decision to select the slowest reported 
rate is clearly only relevant if you're not doing "transrating". But rather 
than saying "transrating", you say you're not doing "transcoding". Well, 
right or wrong, some people thing those two things are different ... so you 
might want to be more specific. That is, you might want to say transrating, 
rather than transcoding?

<snip>

- pp. 15ff: Sections 4.3, 4.4, 4.5 and 4.6 seem overly redundant with 
Sections 3.2.2, 3.2.1, 3.2.3 and 3.2.4, respectively. Maybe this is 
sufficiently common practice as to leave it be, and I certainly don't have 
the cycles to suggest that significant a rewrite, but ... think about it.

<snip>

         3rd paragraph: I can't parse the last sentence. I understand why 
the freeze request should contain *a* timestamp ... but I'm not sure 
exactly what it's the timestamp of -- and can't tell from this sentence.

- Section 4.4: First, refer to comment about redundancy above. Beyond that:

         "sends an decoder" --> "send a decoder"
         "the SSRC of the" --> "the SSRCs of both the"

- Section 4.5: Refer to comment about redundancy above.

- Section 4.6: Refer to comment about redundancy above. (Am I being 
redundant enough? ;-))

<snip>

- p. 27: What are "group-external" threats?!

<snip>

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