From eckelcu@cisco.com Mon Dec 5 11:02:37 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DE11E80D5; Mon, 5 Dec 2011 11:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoM3OFk1rSsn; Mon, 5 Dec 2011 11:02:36 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AB5A311E80CD; Mon, 5 Dec 2011 11:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3707; q=dns/txt; s=iport; t=1323111756; x=1324321356; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/JQL0A7ogsLtgt7/gJzSa7gzmpNEF+uvH8l83Yu7c3A=; b=QWnGaDXDrU6tKCkQs7Xlr92OjLBtAiVua5qtXlKhwfW7GCo/s4srnZIx nx0McaoQmKdrQRNpb7e9LWiwICuJrpXNzet6jGLN/vSBe3K7sLooFrxko vbCu8AD+3EpYQnvpWWZmCMPVjfKmGufQ8NhtctfhXWsNIGt6MemwJr9uq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAAC8U3U6rRDoI/2dsb2JhbAA6CpoXkCmBBYFyAQEBBAEBAQ8BHQoxAxcEAgEIDgMEAQELBhcBBgEmHwkIAQEEARIIGodtlkkBnkcEh22CUWMEiC2eaA X-IronPort-AV: E=Sophos;i="4.71,300,1320624000"; d="scan'208";a="17910586" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 05 Dec 2011 19:02:34 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB5J2MoN016027; Mon, 5 Dec 2011 19:02:33 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Dec 2011 11:02:33 -0800 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 Date: Mon, 5 Dec 2011 11:02:32 -0800 Message-ID: In-Reply-To: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues Thread-Index: Acyvc2RtwWVYX+hjQRKCp5qjF7/iQQEC5eoQ References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> From: "Charles Eckel (eckelcu)" To: "Jochen Issing" , , X-OriginalArrivalTime: 05 Dec 2011 19:02:33.0894 (UTC) FILETIME=[72225460:01CCB380] Subject: Re: [payload] [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:02:37 -0000 Hi Jochen, I am not that familiar with the details of the variation modes. If you want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and HE-AACv2, it seems you could include multiple payload types in the m-line, and then specify the corresponding fmtp parameters for each. Is there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 within a single payload type? Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Jochen Issing > Sent: Wednesday, November 30, 2011 7:18 AM > To: payload@ietf.org; mmusic@ietf.org > Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >=20 > Dear experts, >=20 > I need to double-apologize before posting our findings: > 1) for cross-posting, as I do not know, where this issue has its exact home, which is hopefully not a > response killer. > 2) for the long mail, even though I tried to keep it short. >=20 > Now, here's the actual request: >=20 > We are referring to RFC3640 SDP fields only, as this is most often the stumbling block. Let's use the > following example: >=20 > m=3Daudio 49170 RTP/AVP 96 > a=3Drtpmap:96 mpeg4-generic/48000/2 > a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; config=3D1190; sizeLength=3D13; > indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024 >=20 > The fields of interest are in the fmtp line: 'profile-level-id' and 'config'. > In contrast to other codecs, e.g. G.XXX, AAC integrates many different types of sub codecs, which are > identified using the Audio Object Type (AOT). The AOT and some additional (codec internal) information > is stored in the Audio Specific Config (ASC), which is conveyed in the 'config' field. > The 'profile-level-id' points to a profile with a certain level. The profile comprises a set of one or > more AOTs and the level restricts the stream to a maximum sample rate and/or number channels. The > profile-level-ids, as specified in ISO 14496-3, are partly hierarchical and most often ambiguous. >=20 > Suppose the classic SIP use case that two clients want to exchange their codec capabilities. > The first client specifies some payload types in the SDP part of SIP INVITE which can differ in their > profile-level-id and/or config. > For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To signal these codecs/AOTs he could > either indicate all formats with the same profile-level-id (e.g., 48), which includes all these AOTs > or he could specify profile-level-ids, that are most 'narrow' to the actual specified AOT or he could > even mix this principle. > On the other hand, the ASC might use implicit signaling, explicit backwards-compatible, or explicit > non-backwards-compatible. > Bobs main problem would be to determine, whether the profile-level-id was chosen to really identify > the necessary (and applied) AAC AOTs or if he could rely on the ASC or if the profile-level-id was > just brawling about the encoders feature. >=20 > To clean up this mess of opportunities, we would like to specify a non-ambiguous way to utilize the > profile-level-id and config fields appropriately and provide a guide on how to accomplish clean and > easier signalization and thus improve interoperability. >=20 >=20 > But first of all we would like to make sure, that you agree to this problem statement or do we miss > something here? > Comments are as always highly appreciated. >=20 > Best Regards, > -- > jochen >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From iss@IEEE.ORG Mon Dec 5 14:50:55 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24AD21F86A0; Mon, 5 Dec 2011 14:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX3UbzsqNgz4; Mon, 5 Dec 2011 14:50:55 -0800 (PST) Received: from nesono.com (nesono.com [85.214.71.234]) by ietfa.amsl.com (Postfix) with ESMTP id D6E5B21F85F1; Mon, 5 Dec 2011 14:50:54 -0800 (PST) Received: from [192.168.178.27] (188-195-158-30-dynip.superkabel.de [188.195.158.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iss@nesono.com) by nesono.com (Postfix) with ESMTPSA id 7BC112B8022; Mon, 5 Dec 2011 23:50:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jochen Issing In-Reply-To: Date: Mon, 5 Dec 2011 23:50:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.1251.1) Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:50:55 -0000 Hi Charles, thanks for your response! However, the issue we identified is somewhat = different: The problem already takes place with a single fmtp line: For example, one client indicates that it can (decode and) encode an AAC = stream using the config field in fmtp. The other side, receiving this information, = then must check its decoder, if it can decode the ASC and needs to setup its = encoder, so that it uses the very same ASC. The problem occurs at the encoder of the caller (the receiver of the = first SDP): It might not be possible with reasonable effort to get an encoder = creating the same ASC as given in SDP (encoders are in general not initialized using = an ASC). I hope, this explained our problem much clearer. Best, jochen On 05.12.2011, at 20:02, Charles Eckel (eckelcu) wrote: > Hi Jochen, >=20 > I am not that familiar with the details of the variation modes. If you > want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. = and > HE-AACv2, it seems you could include multiple payload types in the > m-line, and then specify the corresponding fmtp parameters for each. = Is > there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 > within a single payload type? >=20 > Charles >=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Jochen Issing >> Sent: Wednesday, November 30, 2011 7:18 AM >> To: payload@ietf.org; mmusic@ietf.org >> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >>=20 >> Dear experts, >>=20 >> I need to double-apologize before posting our findings: >> 1) for cross-posting, as I do not know, where this issue has its = exact > home, which is hopefully not a >> response killer. >> 2) for the long mail, even though I tried to keep it short. >>=20 >> Now, here's the actual request: >>=20 >> We are referring to RFC3640 SDP fields only, as this is most often = the > stumbling block. Let's use the >> following example: >>=20 >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 mpeg4-generic/48000/2 >> a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; > config=3D1190; sizeLength=3D13; >> indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024 >>=20 >> The fields of interest are in the fmtp line: 'profile-level-id' and > 'config'. >> In contrast to other codecs, e.g. G.XXX, AAC integrates many = different > types of sub codecs, which are >> identified using the Audio Object Type (AOT). The AOT and some > additional (codec internal) information >> is stored in the Audio Specific Config (ASC), which is conveyed in = the > 'config' field. >> The 'profile-level-id' points to a profile with a certain level. The > profile comprises a set of one or >> more AOTs and the level restricts the stream to a maximum sample rate > and/or number channels. The >> profile-level-ids, as specified in ISO 14496-3, are partly > hierarchical and most often ambiguous. >>=20 >> Suppose the classic SIP use case that two clients want to exchange > their codec capabilities. >> The first client specifies some payload types in the SDP part of SIP > INVITE which can differ in their >> profile-level-id and/or config. >> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To > signal these codecs/AOTs he could >> either indicate all formats with the same profile-level-id (e.g., = 48), > which includes all these AOTs >> or he could specify profile-level-ids, that are most 'narrow' to the > actual specified AOT or he could >> even mix this principle. >> On the other hand, the ASC might use implicit signaling, explicit > backwards-compatible, or explicit >> non-backwards-compatible. >> Bobs main problem would be to determine, whether the profile-level-id > was chosen to really identify >> the necessary (and applied) AAC AOTs or if he could rely on the ASC = or > if the profile-level-id was >> just brawling about the encoders feature. >>=20 >> To clean up this mess of opportunities, we would like to specify a > non-ambiguous way to utilize the >> profile-level-id and config fields appropriately and provide a guide > on how to accomplish clean and >> easier signalization and thus improve interoperability. >>=20 >>=20 >> But first of all we would like to make sure, that you agree to this > problem statement or do we miss >> something here? >> Comments are as always highly appreciated. >>=20 >> Best Regards, >> -- >> jochen >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic --=20 jochen From iss@ieee.org Mon Dec 5 15:50:14 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF961F0C38; Mon, 5 Dec 2011 15:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBgXtKExat2a; Mon, 5 Dec 2011 15:50:13 -0800 (PST) Received: from nesono.com (nesono.com [85.214.71.234]) by ietfa.amsl.com (Postfix) with ESMTP id BD76021F8AB9; Mon, 5 Dec 2011 15:50:10 -0800 (PST) Received: from macpro01.fritz.box (188-195-158-30-dynip.superkabel.de [188.195.158.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iss@nesono.com) by nesono.com (Postfix) with ESMTPSA id F0E9A2B8022; Tue, 6 Dec 2011 00:49:43 +0100 (CET) Message-ID: <4EDD5894.9020100@ieee.org> Date: Tue, 06 Dec 2011 00:49:40 +0100 From: Jochen Issing User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: "Severa, Michael J (Mike)" References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "payload@ietf.org" , "mmusic@ietf.org" Subject: Re: [payload] [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:50:14 -0000 Hi Mike, as far as I understand the AAC codecs, ASCs of the same AOT (and channels and sample rate) are not necessarily 'compatible' to each other, especially when it comes to more recent codecs, like AAC-ELD, where critical information might be included in the ASC. Thus, for a uniform usage of ASCs, it should be bit-exact. I'm afraid the caller needs to add a payload type if he does not manage to reproduce the ASC indicated by the callee, which would be then used in one direction only. Regarding the signalization of SBR and PS (HE-AAC/HE-AACv2) you are right, that's another issue. However, with presence of SIP/SDP and offer/answer functionality, implicit and backwards-compatible signalization do not make sense at all IMHO. The legacy receiver can simply disregard the unsupported codecs. Anyhow, this is neither stated anywhere. Best, jochen Severa, Michael J (Mike) wrote: > My personal feeling is that the ASC need not be identical in syntax, just in semantics (one of the unfortunate aspects of AAC-related signaling is that there are a number of ways to signal the same bitstream). Another unfortunate aspect is that one of the options is to signal implicitly, which essentially means dont signal at all, rather 'detect' at decode time. That is obviously not useful for a capabilities exchange step. > > I think there might also be other open questions surrounding ambiguities in signaling AAC-LC/HE-AAC that should be worked through to generate a best or acceptable practices approach. > > Two of the ones that jump out at me are: > - the question of what timescale from the rtpmap line means when you intend to be using HE-AAC in a 3640 environment (3GPP has explicitly indicated this should be sampling frequency of the underlying, 'core' AAC-LC portion of an HE-AAC stream. I assume this is the same semantic in 3640 (though I didnt notice it specified explicitly)). This question is probably only relevant in cases where the goal is to assume HE-AAC (something the multiple fmtp line suggestion might be implying). > - how HE-AAC can be detected in implicit mode during negotiation (again, 3GPP added an SBR-Enabled flag to the SDP to allow HE-AAC to be detected ahead of time even with implicit signaling, im not sure there is an analogous solution for 3640). > > Both of these questions are probably irrelevant if implicit signaling is disallowed for HE-AAC (though in the first case that would require parsing the ASC during negotiation). Using multiple fmtp lines might be one way to 'disable' the implicit signaling requirement (since the backwards compatibility concern associated with implicit signaling can be dealt with by an explicit AAC-LC-only ftmp (and rtpmap)line). > > Sorry if that's a tangent. > > thanks, > > Mike > > ________________________________________ > From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Jochen Issing [iss@IEEE.ORG] > Sent: Monday, December 05, 2011 2:50 PM > To: Charles Eckel (eckelcu) > Cc: mmusic@ietf.org; payload@ietf.org > Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues > > Hi Charles, > > thanks for your response! However, the issue we identified is somewhat different: > > The problem already takes place with a single fmtp line: > For example, one client indicates that it can (decode and) encode an AAC stream using > the config field in fmtp. The other side, receiving this information, then must > check its decoder, if it can decode the ASC and needs to setup its encoder, > so that it uses the very same ASC. > > The problem occurs at the encoder of the caller (the receiver of the first SDP): > It might not be possible with reasonable effort to get an encoder creating the > same ASC as given in SDP (encoders are in general not initialized using an ASC). > > I hope, this explained our problem much clearer. > Best, > > jochen > > On 05.12.2011, at 20:02, Charles Eckel (eckelcu) wrote: > >> Hi Jochen, >> >> I am not that familiar with the details of the variation modes. If you >> want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and >> HE-AACv2, it seems you could include multiple payload types in the >> m-line, and then specify the corresponding fmtp parameters for each. Is >> there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 >> within a single payload type? >> >> Charles >> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Jochen Issing >>> Sent: Wednesday, November 30, 2011 7:18 AM >>> To: payload@ietf.org; mmusic@ietf.org >>> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >>> >>> Dear experts, >>> >>> I need to double-apologize before posting our findings: >>> 1) for cross-posting, as I do not know, where this issue has its exact >> home, which is hopefully not a >>> response killer. >>> 2) for the long mail, even though I tried to keep it short. >>> >>> Now, here's the actual request: >>> >>> We are referring to RFC3640 SDP fields only, as this is most often the >> stumbling block. Let's use the >>> following example: >>> >>> m=audio 49170 RTP/AVP 96 >>> a=rtpmap:96 mpeg4-generic/48000/2 >>> a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; >> config=1190; sizeLength=13; >>> indexLength=3; indexDeltaLength=3; constantDuration=1024 >>> >>> The fields of interest are in the fmtp line: 'profile-level-id' and >> 'config'. >>> In contrast to other codecs, e.g. G.XXX, AAC integrates many different >> types of sub codecs, which are >>> identified using the Audio Object Type (AOT). The AOT and some >> additional (codec internal) information >>> is stored in the Audio Specific Config (ASC), which is conveyed in the >> 'config' field. >>> The 'profile-level-id' points to a profile with a certain level. The >> profile comprises a set of one or >>> more AOTs and the level restricts the stream to a maximum sample rate >> and/or number channels. The >>> profile-level-ids, as specified in ISO 14496-3, are partly >> hierarchical and most often ambiguous. >>> Suppose the classic SIP use case that two clients want to exchange >> their codec capabilities. >>> The first client specifies some payload types in the SDP part of SIP >> INVITE which can differ in their >>> profile-level-id and/or config. >>> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To >> signal these codecs/AOTs he could >>> either indicate all formats with the same profile-level-id (e.g., 48), >> which includes all these AOTs >>> or he could specify profile-level-ids, that are most 'narrow' to the >> actual specified AOT or he could >>> even mix this principle. >>> On the other hand, the ASC might use implicit signaling, explicit >> backwards-compatible, or explicit >>> non-backwards-compatible. >>> Bobs main problem would be to determine, whether the profile-level-id >> was chosen to really identify >>> the necessary (and applied) AAC AOTs or if he could rely on the ASC or >> if the profile-level-id was >>> just brawling about the encoders feature. >>> >>> To clean up this mess of opportunities, we would like to specify a >> non-ambiguous way to utilize the >>> profile-level-id and config fields appropriately and provide a guide >> on how to accomplish clean and >>> easier signalization and thus improve interoperability. >>> >>> >>> But first of all we would like to make sure, that you agree to this >> problem statement or do we miss >>> something here? >>> Comments are as always highly appreciated. >>> >>> Best Regards, >>> -- >>> jochen >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic > > -- > jochen > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- jochen From stewe@stewe.org Wed Dec 7 08:09:11 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68F021F8B24; Wed, 7 Dec 2011 08:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j27XmSQaNnJY; Wed, 7 Dec 2011 08:09:11 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 458C121F858C; Wed, 7 Dec 2011 08:09:09 -0800 (PST) Received: from [192.168.1.58] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4446-1743317 for multiple; Wed, 07 Dec 2011 17:09:07 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 07 Dec 2011 08:08:40 -0800 From: Stephan Wenger To: Message-ID: Thread-Topic: Incoming liaison statement from MMUSIC Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3406090145_2752175" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Cc: avtext@ietf.org, avt@ietf.org, payload@ietf.org, xrblock@ietf.org Subject: [payload] Incoming liaison statement from MMUSIC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:09:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3406090145_2752175 Content-type: multipart/alternative; boundary="B_3406090145_2760267" --B_3406090145_2760267 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, mmusic has received an incoming liaison from MPEG, indicating that they have started on "codec independent media description code points". My understanding of this work is that these code points may be represented in SDP. My personal viewpoint is that this may well be sound architectural work, but it may be better conducted here in mmusic, at least when it comes to SDP representations and the related IANA work. However, I know nothing about this work beyond what's written in the statement, which is why I used "soft" language. Perhaps some of you can shed light into what's really going on. The assorted avt WGs are probably also affected, as some of the proposed code points sound like they are being described in payload formats, RTP extensions and perhaps even in xrblock. Let me suggest to use only the music list for discussions, as only mmusic is being addressed in the statement. As it is short, I have attached the statement in word format to this email. It will also appear shortly in the IETF liaison database. Regards, Stephan --B_3406090145_2760267 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
mmusic has= received an incoming liaison from MPEG, indicating that they have started o= n "codec independent media description code points".  My understanding = of this work is that these code points may be represented in SDP.
= My personal viewpoint is that this may well be sound architectural work, but= it may be better conducted here in mmusic, at least when it comes to SDP re= presentations and the related IANA work.  However, I know nothing = about this work beyond what's written in the statement, which is why I used = "soft" language.  Perhaps some of you can shed light into what's really= going on.
The assorted avt WGs are probably also affected, as som= e of the proposed code points sound like they are being described in payload= formats, RTP extensions and perhaps even in xrblock.  Let me suggest t= o use only the music list for discussions, as only mmusic is being addressed= in the statement.
As it is short, I have attached the statement i= n word format to this email.  It will also appear shortly in the IETF l= iaison database.
Regards,
Stephan
--B_3406090145_2760267-- --B_3406090145_2752175 Content-type: application/msword; name="29n124561.doc" Content-disposition: attachment; filename="29n124561.doc" Content-transfer-encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOAAAAAAA AAAAEAAAOgAAAAEAAAD+////AAAAADcAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAJ2AJBAAA8FK/AAAAAAAAEAAAAAAABgAA 7Q4AAA4AYmpiakxVTFUAAAAAAAAAAAAAAAAAAAAAAAARBBYAOB4AAC4/AQAuPwEA3wYAAAAA AAANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAEAFAAAAAAAAQAUAAEAFAAAAAAAAQAUAAAAAAABABQAA AAAAAEAFAAAAAAAAQAUAABQAAAAAAAAAAAAAAFQFAAAAAAAAOAsAAAAAAAA4CwAAAAAAADgL AAA4AAAAcAsAABQAAACECwAAJAAAAFQFAAAAAAAAkhgAAAICAAC0CwAAAAAAALQLAAAAAAAA tAsAAAAAAAC0CwAAAAAAALQLAAAAAAAACA0AAAAAAAAIDQAAAAAAAAgNAAAAAAAAERgAAAIA AAATGAAAAAAAABMYAAAAAAAAExgAAAAAAAATGAAAAAAAABMYAAAAAAAAExgAACQAAACUGgAA aAIAAPwcAACsAAAANxgAABUAAAAAAAAAAAAAAAAAAAAAAAAAQAUAAAAAAABxDwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIDQAAAAAAAAgNAAAAAAAAcQ8AAAAAAABxDwAAAAAAADcYAAAAAAAA AAAAAAAAAABABQAAAAAAAEAFAAAAAAAAtAsAAAAAAAAAAAAAAAAAALQLAABUAQAATBgAABYA AAAZEQAAAAAAABkRAAAAAAAAGREAAAAAAABxDwAAjgAAAEAFAAAAAAAAtAsAAAAAAABABQAA AAAAALQLAAAAAAAAERgAAAAAAAAAAAAAAAAAABkRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQ8AAAAAAAARGAAAAAAAAAAAAAAAAAAA GREAAAAAAAAZEQAAOgAAAC0WAAAsAAAAQAUAAAAAAABABQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkRYAAAAAAAC0CwAA AAAAAKgLAAAMAAAAwMI0ZN+zzAEAAAAAAAAAADgLAAAAAAAA/w8AAFIAAABZFgAACgAAAAAA AAAAAAAApRcAAGwAAABiGAAAMAAAAJIYAAAAAAAAYxYAAC4AAACoHQAAAAAAAFEQAAB2AAAA qB0AABQAAACRFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgdAAAAAAAAAAAAAAAAAABABQAA AAAAAJEWAAAUAQAACA0AAGgAAABwDQAASgAAABkRAAAAAAAAug0AADwAAAD2DQAAewEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA0AAAAAAAAIDQAAAAAAAAgNAAAAAAAA NxgAAAAAAAA3GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxxAAAFIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgNAAAAAAAACA0AAAAAAAAIDQAA AAAAAJIYAAAAAAAAcQ8AAAAAAABxDwAAAAAAAHEPAAAAAAAAcQ8AAAAAAAAAAAAAAAAAAFQF AAAAAAAAVAUAAAAAAABUBQAA5AUAADgLAAAAAAAAVAUAAAAAAABUBQAAAAAAAFQFAAAAAAAA OAsAAAAAAABUBQAAAAAAAFQFAAAAAAAAVAUAAAAAAABABQAAAAAAAEAFAAAAAAAAQAUAAAAA AABABQAAAAAAAEAFAAAAAAAAQAUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAElOVEVSTkFUSU9OQUwgT1JHQU5JU0FUSU9OIEZPUiBT VEFOREFSRElTQVRJT04NT1JHQU5JU0FUSU9OIElOVEVSTkFUSU9OQUxFIERFIE5PUk1BTElT QVRJT04NSVNPL0lFQyBKVEMxL1NDMjkvV0cxMQ1DT0RJTkcgT0YgTU9WSU5HIFBJQ1RVUkVT IEFORCBBVURJTw0NSVNPL0lFQyBKVEMxL1NDMjkvV0cxMSBOMTI0NDgNRGVjZW1iZXIgMjAx MSwgR2VuZXZhLCBTd2l0emVybGFuZA0NDVNvdXJjZQdDb252ZW5vcgcHVGl0bGUHTGlhaXNv biBzdGF0ZW1lbnQgdGVtcGxhdGUgb24gY29kZWMgaW5kZXBlbmRlbnQgbWVkaWEgZGVzY3Jp cHRpb24gY29kZXBvaW50cwcHVG8HBwcNIA1JU08vSUVDIEpUQyAxL1NDIDI5L1dHIDExIChN UEVHKSBoYXZlIG9ic2VydmVkIHRoYXQgd2UgaGF2ZSBhIG51bWJlciBvZiBjb2RlIHBvaW50 cyB0byBkZXNjcmliZSBtZWRpYSB0aGF0IGFyZSB1c2VkIGluIHNldmVyYWwgc3BlY2lmaWNh dGlvbnMsIG9mdGVuIGR1cGxpY2F0aW5nIHRleHQ7IHRoZXNlIGNvZGUgcG9pbnRzIGRvY3Vt ZW50IGFzcGVjdHMgb2YgbWVkaWEgc3RyZWFtcyB0aGF0IGFyZSBpbmRlcGVuZGVudCBvZiB0 aGUgY29tcHJlc3Npb24gZm9ybWF0IHVzZWQuIA0NV2UgaGF2ZSBkZWNpZGVkIHRvIG1ha2Ug YSBzaW5nbGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGRlZmluaXRpb24gb2YgdGhlc2UgY29k ZSBwb2ludHMsIGVuYWJsaW5nIG90aGVyIHNwZWNpZmljYXRpb25zIHRvIHJlZmVyIHRvIHRo aXMuICBXZSBiZWxpZXZlIHRoYXQgdGhpcyBzaG91bGQgaGVscCBub3Qgb25seSBpbiBwcm92 aWRpbmcgYSBjb25zaXN0ZW50IHNldCBvZiB2YWx1ZXMgZm9yIHRoZXNlIChtYW55IG9mIHdo aWNoIGFyZSBlbnVtZXJhdGlvbnMpIGJ1dCBhbHNvIGNvbnNpc3RlbnQgc2VtYW50aWNzLCBl bmFibGluZyB0aGVpciBjYXJyaWFnZSBhbmQgY29tcGFyaXNvbiBhY3Jvc3MgYW5kIGJldHdl ZW4gbXVsdGlwbGUgZm9ybWF0cyBhbmQgc3RyZWFtcy4NDVRoZSBpbml0aWFsIHdvcmtpbmcg ZHJhZnQgY29udGFpbnMgaW5pdGlhbCBjb2RlIHBvaW50cyBmb3IgdGhlIGZvbGxvd2luZyBt ZWRpYSBkZXNjcmlwdGlvbnM6DVZpZGVvIENvbG91ciBQcmltYXJpZXMNVmlkZW8gQ29sb3Vy IFRyYW5zZmVyIENoYXJhY3RlcmlzdGljcw1WaWRlbyBNYXRyaXggQ29sb3VyIENvZWZmaWNp ZW50cw1TdGVyZW8gVmlkZW8gRnJhbWUgUGFja2luZw1TdGVyZW8gVmlkZW8gVmlldyBBc3Np Z25tZW50DUF1ZGlvIENoYW5uZWwgQ29uZmlndXJhdGlvbg1BdWRpbyBDaGFubmVsIEFzc2ln bm1lbnQNQXVkaW8gRGlhbG9nIExldmVsDUF1ZGlvIER5bmFtaWMgUmFuZ2UNDVdlIGFyZSBh bHNvIGNvbnNpZGVyaW5nIHRoZSBhZGRpdGlvbiBvZiBjb2RlIHBvaW50cyBmb3IgY29kZWMg bmFtZXMsIGJ1dCBoYXZlIG5vdCByZWFjaGVkIGNvbmNsdXNpb24geWV0IGlmIHRoaXMgd2ls bCBiZSBzdWl0YWJsZS4NDVlvdXIgY29tbWVudHMgb24gdGhpcyBhcHByb2FjaCBhcmUgd2Vs Y29tZSwgYW5kIHdlIHdvdWxkIGFsc28gd2VsY29tZSBzdWdnZXN0aW9ucyBmb3IgY29kZSBw b2ludHMgZm9yIG1lZGlhIGRlc2NyaXB0aW9ucyB5b3UgZmVlbCBzaG91bGQgYmUgY29uc2lk ZXJlZCBmb3IgaW5jbHVzaW9uIGluIHN1Y2ggYSBzcGVjaWZpY2F0aW9uLCBpZGVhbGx5IHdp dGggYSBzdWdnZXN0aW9uIGZvciB0aGUgaW5pdGlhbCBkZWZpbml0aW9uIG9yIHBvaW50ZXIg dG8gc3BlY2lmaWNhdGlvbiB3aGVyZSBzdWNoIGNvZGUgcG9pbnRzIGFyZSBkZWZpbmVkLg0D DQ0EDQ0DDQ0EDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAYAAC8IAACWCAAArggAAK8IAACwCAAAtQgAALYIAAC+CAAA wQgAAMMIAADFCAAA2AgAANkIAADaCAAA2wgAAOIIAADqCAAA8ggAAD4JAABACQAAQgkAAEMJ AABECQAARQkAAEYJAADz7Ofi07+vqp+WjqqEjn11cHVodWN1WExIAAAAAAAAAAAAAAAAAAAA BhZo5TqxAAAXFWjhHqoAFmjhHqoAbkgRBG8oAXRIEQQUFWjhHqoAFmjhHqoAbkgRBHRIEQQA CRZolTFDADUIgQ8VaPFs3gAWaPFs3gA1CIEJFmjiVDkANQiBDxVomWNwABZo4R6qADUIgQwV aLIF3gAWaO5pbwAAEhVoKl2BABZo7mlvADUIgW8oAQAPFWgqXYEAFmjuaW8ANQiBERZoFCtl ADUIgW5IEQR0SBEEFBZo9kkXADUIgW5IEQRvKAF0SBEEAAkWaBQrZQA1CIEeFWjQJQ0AFmju aW8ANQiBUEoDAG5IEgRvKAF0SBIEACcVaNAlDQAWaPFs3gA1CIFCKgZQSgMAbkgSBG8oAXBo /wAAAHRIEgQdFmj2SRcANQiBQioGbkgRBG8oAXBo/wAAAHRIEQQJFmjhHqoANQiBCRZo7mlv ADUIgQ0WaO5pbwA1CIFDShwAFxVoixjAABZo7mlvADUIgUNKHABhShwAABkABgAALwgAAFwI AABzCAAAlwgAAJgIAAC2CAAA2QgAANoIAADbCAAA4ggAAOsIAADsCAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADg AAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAADQAAAAAAAAAAAAAAAAwgAA AAAAAAAAAAAAAMIAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAAAAAAAAAAFYAAGtkAAAAABYk ARckAUlmAQAAAAKWbAAI1jAAApT/zAP3JAAGOAQAAAAAAAAAAAAAAAAAAAAAAAYrIQAAAAAA AAAAAAAAAAAAAAAKdAAA4AEU9gEAABU2ARf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8A AAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABBQMAADTWBgABCgNsAGH2AwAAeXSZY3AA AA0AAAMkAxYkASokAUlmAQAAAGEkA2dkmWNwAAAHAAASZBD/AABnZO5pbwAABwAAAyQCYSQC Z2QqXYEAAAcAAAMkAmEkAmdk4R6qAAAOAAADJAENxgUAAQsVABJkEP8AAGEkAWdk7mlvAAAH AAADJAFhJAFnZO5pbwAADAAGAADfDgAA7A4AAP39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEC7AgAAPIIAAA/CQAA QAkAAEMJAABECQAA8QAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAgwAA AAAAAAAAAAAAAHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkFCtlAAkAABYkAUlmAQAAAGdk4R6qAABW AABrZGUAAAAWJAEXJAFJZgEAAAAClmwACNYwAAKU/8wD9yQABjgEAAAAAAAAAAAAAAAAAAAA AAAGKyEAAAAAAAAAAAAAAAAAAAAACnQAAOABFPYBAAAVNgEX9gMAABj2AwAAGtYIAAAA/wAA AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQUDAAA01gYAAQoDbABh 9gMAAHl0mWNwAAANAAADJAMWJAEqJAFJZgEAAABhJANnZJUxQwAADQAAAyQDFiQBKiQBSWYB AAAAYSQDZ2SZY3AAAAVECQAARQkAAEYJAABICQAAWQoAAFoKAADXCwAA2AsAADUMAABMDAAA cgwAAJMMAACuDAAAywwAAOcMAAAADQAAEw0AACcNAACoAAAAAAAAAAAAAAAApgAAAAAAAAAA AAAAAKAAAAAAAAAAAAAAAACbAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAJsAAAAAAAAAAAAA AACbAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAA kwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAJMA AAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAAAIAAAKJgALRgIAZ2TiVDkA AAQAAGdkzXH1AAYAAEAmAGdksgXeAAABAAAAVgAAa2TKAAAAFiQBFyQBSWYBAAAAApZsAAjW MAAClP/MA/ckAAY4BAAAAAAAAAAAAAAAAAAAAAAABishAAAAAAAAAAAAAAAAAAAAAAp0AADg ART2AQAAFTYBF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W CAAAAP8AAAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAB5dJljcAAAEUYJAABHCQAASAkAAFMJ AABUCQAAWAkAAFkJAABeCQAAXwkAAGkJAACcCQAAsgkAANcLAAD7CwAAAgwAACcNAAAoDQAA rA0AAA4OAAAlDgAAfw4AAN4OAADfDgAA4A4AAOIOAADjDgAA5Q4AAOYOAADoDgAA6Q4AAOwO AADtDgAA9uni2eLZ4tni1dHV0c3R1dHV0dXRycG9wb3BvcG9yQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYWaLh1/AAADwNqAAAA ABZouHX8AFUIAQYWaLIF3gAABhZoxVOhAAAGFmjiVDkAAAYWaM1x9QAAERZo2T5hAG5IEQRv KAF0SBEEDBVolTFDABZolTFDAAAYFWiyBd4AFmiyBd4AQ0oWAG1IBwRzSAcEABIWaLIF3gBD ShYAbUgHBHNIBwQfJw0AACgNAACrDQAArA0AAN8OAADhDgAA4g4AAOQOAADlDgAA5w4AAOgO AADqDgAA6w4AAOwOAADtDgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAGdk8WzeAAABAAAABAAAZ2TNcfUAAA42ACZQCQAxkGgBOnDZPmEA H7CDLiCwyEEhsG4EIrBuBCOQbgQkkIoFJbAAABewxQIYsMUCDJDQAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGMAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQABAzgENdYFAQIDKyEjdgAB OAQjdgECKyE6VgsAApZsAAp0AADgART2AQAAFTYBGPYDAAA11gUAAQM4BDXWBQECAysheXSZ Y3AAYwAWJAEXJAFJZgEAAAABlgAAIXYAAmgBNdYFAAEDOAQ11gUBAgMrISN2AAE4BCN2AQIr ITpWCwAClmwACnQAAOABFPYBAAAVNgEY9gMAADXWBQABAzgENdYFAQIDKyF5dJljcABjABYk ARckAUlmAQAAAAGWAAAhdgACaAE11gUAAQM4BDXWBQECAyshI3YAATgEI3YBAishOlYLAAKW bAAKdAAA4AEU9gEAABU2ARj2AwAANdYFAAEDOAQ11gUBAgMrIXl0mWNwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACGAhYAEgABAJwADwAEAAAABAAAAAAABAAIAAAACAAAAA4AAAAOAAAADgAAAA4AAAAOAAAA DgAAAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAA CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA4AABA8f8CADgADBAAAO5pbwAAAAIAGWqWbgAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNI CQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAJABBAPL/oQAkAAwBAAAAAAAAAAAGALVrPYTVMKkw 8zDIMAAAAABCAGlA8/+zAEIADAEAAAAAAAAAAAQAGWqWbm4waIgAABwAF/YDAAA01gYAAQoD bAA01gYAAQUDAABh9gMAAAIACwAAACQAawD0/8EAJAAAAQAAAAAAAAAABQDqMLkwyDBqMFcw AAACAAwAAAAAAGIAmgCzAPMAYgAMBAAA4R6qAAAABgBoiCAAKAA8aFBbKQAAADcAOlYPABPW MAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8A AAA8AJlAAQACATwADAQRAIUx/AAAAAQAOVRNMPpRVzAAAAIAEAAYAENKEgBPSgUAUUoFAGFK EgBtSAAAc0gAAEYA/k/y/xEBRgAMABAAhTH8AAAACwAgACgAh2VXWykAIAAoAIdlV1spADIA AAAYAENKEgBPSgUAUUoFAF5KBQBhShIAdEgJBDoAH0ABACIBOgAMBBMA8WzeAAAABADYMMMw wDD8MAAAEAASAA3GCAACoRFCIwECRyQACABtSAAAc0gAADoA/k/y/zEBOgAMABIA8WzeAAAA CwAgACgAh2VXWykAIAAoAIdlV1spADEAAAAMAENKGABhShgAdEgJBDoAIEABAEIBOgAMBBUA 8WzeAAAABADVMMMwvzD8MAAAEAAUAA3GCAACoRFCIwECRyQACABtSAAAc0gAADgA/k/y/1EB OAAMABQA8WzeAAAACgAgACgAh2VXWykAIAAoAIdlV1spAAAADABDShgAYUoYAHRICQQAAAAA 7QYAAAUAAB4AAAAA/////wAAAAAvAAAAXAAAAHMAAACXAAAAmAAAALYAAADZAAAA2gAAANsA AADiAAAA6wAAAOwAAADyAAAAPwEAAEABAABDAQAARAEAAEUBAABGAQAASAEAAFkCAABaAgAA 1wMAANgDAAA1BAAATAQAAHIEAACTBAAArgQAAMsEAADnBAAAAAUAABMFAAAnBQAAKAUAAKsF AACsBQAA3wYAAOEGAADiBgAA5AYAAOUGAADnBgAA6AYAAOoGAADrBgAA7gYAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAA IACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAA AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQ AAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA ANAAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA AQAA1AAAAAAgAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAAIAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIgADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAACIAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAIgADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAACIAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAIg ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAACIAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AiAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAqNEAMAAwAAAAAAAAAQAAAAAAAAAAAAAA AABEB6iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAARAeo0QAwADAAAAAAAAABAAAAAAAAAAAA AAAAAEQHqJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAABEB6jRADAAMAAAAAAAAAEAAAAAAAAA AAAAAAAARAeokQAwADAAAAAAAAABAAAAAAAAAAAAAAAAAEQHqNEAMAAwAAAAAAAAAQAAAAAA AAAAAAAAAABEB6iRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAARAeokQAwADAAAAAAAAABAAAA AAAAAAAAAABcMEQHAAAAAAMAAAAGAAAABgAAAAkAAAAMAAAADAAAAAwAAAAMAAAADAAAAAwA AAAMAAAADAAAAA8AAAAABgAARgkAAO0OAAAIAAAADQAAAAAGAADsCAAARAkAACcNAADtDgAA CQAAAAsAAAAMAAAADgAAAAAGAADsDgAACgAAAA8AAPBgAAAAAAAG8CAAAAACDAAAAwAAAAIA AAACAAAAAQAAAAIAAAACAAAAAQAAAEMAC/AYAAAAgQA3IgEAggC6IgAAgwA3IgEAhAC6IgAA QAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAQ8AAvBIAAAAIAAI8AgAAAABAAAAAAgAAA8AA/Aw AAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAAAA8A AvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4A AAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAD//wcAAAAGAD2d SQEQAAEA3Ap6CQYAPp1JAREAAQBcCnoJBgA/nUkBEQABAJwLegkGAECdSQEQAAEAJJ2ICQYA QZ1JAREAAQBknYgJBgBCnUkBEQABAKSdiAkGAEOdSQERAAEA5J2ICcUAAADFAAAAzQAAABMF AAATBQAAGQUAACEFAADuBgAAAQAAAAIAAAAAAAIAAgAAAAIABQAAAAIAAwAAAAIABAAAAAIA BgAAAAIAywAAANgAAADYAAAAGAUAACAFAAAmBQAAJgUAAO4GAAABAAEAAAAAAAIAAAAEAAEA BQABAAMAAAAGAAAABQAAAD0AAAABAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MJgFBsYWNlVHlwZQCAPQAAAAMAAAAqgHVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwmAUGxhY2VOYW1lAIBCAAAABQAAACqAdXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzDoBjb3VudHJ5LXJlZ2lvbgCA OAAAAAYAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwSA Q2l0eQCAOQAAAAcAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0 dGFncwWAcGxhY2UAgAwAAAGU3W0DAAAAAAcAAAAAAAYAAAAAAAUAAAAAAAcAAAAAAAMAAAAA AAMAAAAAAAEAAAAAAAAAAADiAAAA6gAAADQBAAA+AQAAOwQAAEEEAABSBAAAWAQAAH8EAACF BAAA3wYAAN8GAADhBgAA4QYAAOIGAADiBgAA5AYAAOUGAADnBgAA6AYAAOoGAADrBgAA7gYA AAcAHAAHABwABwAcAAcAHAAHABwABwAEAAcABAACAAQABwAEAAcABAAHAAQAAgAAAAAA3wYA AN8GAADhBgAA4QYAAOIGAADiBgAA5AYAAOUGAADnBgAA6AYAAOoGAADrBgAA7gYAAAcABAAH AAQAAgAEAAcABAAHAAQABwAEAAIAAAAAALYAAADyAAAAQAEAAEMBAAA1BAAAKAUAAN8GAADf BgAA4QYAAOEGAADiBgAA4gYAAOQGAADlBgAA5wYAAOgGAADqBgAA6wYAAO4GAAAHAAUABwAF AAcABQAHAAQABwAEAAIABAAHAAQABwAEAAcABAACAAAAAADfBgAA3wYAAOEGAADhBgAA4gYA AOIGAADkBgAA5QYAAOcGAADoBgAA6gYAAOsGAADuBgAABwAEAAcABAACAAQABwAEAAcABAAH AAQAAgACAB3///8cuPYB/w//D/8P/w//D/8P/w//D/8PAAB/T9M7oESa9P8P/w//D/8P/w// D/8P/w//DxAAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EAAARhAAAFcYFAAEAAAZe hAAAYIQAAE9KAQBRSgEAbygAAAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Q4BBGE mP4VxgUAAdACBl6EOARghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+ECAcRhJj+FcYFAAGgBQZehAgHYISY/k9KBgBRSgYAXkoGAG8oAAEAbwABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TYCRGEmP4VxgUAAXAIBl6E2AlghJj+T0oHAFFK BwBvKAABAKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EqAwRhJj+FcYFAAFACwZe hKgMYISY/k9KBwBRSgcAbygAAQD68AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHgP EYSY/hXGBQABEA4GXoR4D2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RIEhGEmP4VxgUAAeAQBl6ESBJghJj+T0oGAFFKBgBeSgYAbygAAQBvAAEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBgVEYSY/hXGBQABsBMGXoQYFWCEmP5PSgcA UUoHAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4ToFxGEmP4VxgUAAYAW Bl6E6BdghJj+T0oHAFFKBwBvKAABAPrwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+E 0AIRhJj+XoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAAGRAAAA+EoAURhJj+XoSgBWCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACISAAA AQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhHAIEYSY/l6EcAhghJj+T0oHAFFK BwBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhEALEYSY /l6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAABkQAAAPhBAOEYSY/l6EEA5ghJj+T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwAB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TgEBGEmP5ehOAQYISY/k9KBwBRSgcAbygA h2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4SwExGEmP5ehLAT YISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZ EAAAD4SAFhGEmP5ehIAWYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EUBkRhJj+XoRQGWCEmP5PSgcAUUoHAG8oAIdoAAAA AIhIAAABAKfwAgAAAB3///8AAAAAAAAAAAAAAAB/T9M7AAAAAAAAAAAAAAAA//////////// /wIAAAAAAAAA//8CAAAAAAASAAEABwQDAAcEBQAHBAEABwQDAAcEBQAHBAEABwQDAAcEBQAH BD8AAAAEAAAACAAAAOUAAAAAAAAAPgAAAAx1AABpZwUA0CUNAPZJFwAAZxcAlAMlALBfJwDX TioAHTAsACAQMwByLDkA4lQ5ANQ7PgCVMUMAzGJSAAJSVwDYUFsA2T5hAJB3ZAAUK2UAYEBt AO5pbwCZY3AA0DdxAAp9cwC3OHQAmSx2AFYkeQDhKXkAtwp9ACpdgQB0YYEAqQ6EABAYjgAp EpQAzGOXAKd7mQASG5oAX2icAMVToQDdMqQAQlekAOEeqgDlOrEAYnq3AFQkugD7Bb0AeQ29 AIhOvQBcE74AnCDHAGV2zQBYKNoAcX3dALIF3gDxbN4AzXH1ANlQ+AC8RfsAhTH8ALh1/ABX O/0A2kP/AAAAAADaAAAA2wAAAOIAAADrAAAA7AAAAPIAAAA/AQAAQAEAAEMBAABEAQAARQEA AN4GAADuBgAAAAAAAHmANQAIAAAAAgEAAAIBAACeAQAAAgEAAAIBAACeAQAAAgEAAAIBAACW AQAAAQAAAP9AAYABADECAAAxAgAAHExtAwEAAQAxAgAAAAAAADECAACU/8B7AhAAAAAAAAAA 7QYAAFAAABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEA AAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAgAAABHFpABAAACAgYDBQQFAgME7zoA4EF4 AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpAB AgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB AAACCwYEAgICAgIE/zoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAQyaQAYEA AgsFAwIAAAIABK8CAJD7fNcJEgAAAAAAAAABAAgAAAAAAE0AYQBsAGcAdQBuACAARwBvAHQA aABpAGMAAABHFZABgAYCAgYJBAIFCAME/wIA4Pv9x2oSAAAAAAAAAJ8AAgAAAAAALf8z/yAA DmYdZwAATQBTACAATQBpAG4AYwBoAG8AAABDBpABAAACCwYABAUCAgIE7woA4f+hAFAAAAAA AAAAAL8BAAAAAAAATAB1AGMAaQBkAGEAIABHAHIAYQBuAGQAZQAAAD81kAEAAAIHAwkCAgUC BAT/OgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7BpAB AgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMA AAAiAAQAMQiIGADw0AIAAGgBAAAAALoT/KbWM/xGAAAAAAQABAAAAAYBAADZBQAAAQADAAAA BAADEAwAAAAGAQAA2QUAAAEAAwAAAAwAAAAAAAAAwQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbgRuBHgAtACCghI0AAAAAAAAAAAAAAAAAADcBgAA 3AYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIAAAAAAAAAAAAMMoNxAPAQAAgA//0BAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEhYAAAAAAnw/w8BAAE/AACkAwAA////f////3////9/////f////3////9/////f+U6 sQAABAAAMgAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAC4ASQBOAFQARQBSAE4AQQBUAEkA TwBOAEEATAAgAE8AUgBHAEEATgBJAFMAQQBUAEkATwBOACAARgBPAFIAIABTAFQAQQBOAEQA QQBSAEQASQBTAEEAVABJAE8ATgAAAAAAAAAFAG8AZwB1AHIAYQAOAFkAbwBrAG8AIABIAGkA ZwBhAHMAaABpAGQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAGAAAAAgAAAAAADAABAAwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABgACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAACMAQAAEAAAAAEAAACIAAAAAgAAAJAAAAADAAAAyAAAAAQAAADUAAAABQAAAOQA AAAHAAAA8AAAAAgAAAAEAQAACQAAABwBAAASAAAAKAEAAAoAAABIAQAADAAAAFQBAAANAAAA YAEAAA4AAABsAQAADwAAAHQBAAAQAAAAfAEAABMAAACEAQAAAgAAAKQDAAAeAAAAMAAAAElO VEVSTkFUSU9OQUwgT1JHQU5JU0FUSU9OIEZPUiBTVEFOREFSRElTQVRJT04AAB4AAAAEAAAA AAAAAB4AAAAIAAAAb2d1cmEAAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1hbC5kb3QAAB4A AAAQAAAAWW9rbyBIaWdhc2hpZGEAAB4AAAAEAAAANAAAAB4AAAAYAAAATWljcm9zb2Z0IE9m ZmljZSBXb3JkAAAAQAAAAAAYDY8AAAAAQAAAAADkqli3sMwBQAAAAAB0oFzfs8wBAwAAAAEA AAADAAAABgEAAAMAAADZBQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAYAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA HAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIAAAAAGAAAAiAAAABEAAACQAAAAFwAAAJgA AAALAAAAoAAAABAAAACoAAAAEwAAALAAAAAWAAAAuAAAAA0AAADAAAAADAAAAPsAAAACAAAA pAMAAB4AAAAIAAAASVRTQ0oAAAADAAAADAAAAAMAAAADAAAAAwAAANwGAAADAAAADycLAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAvAAAASU5URVJOQVRJT05B TCBPUkdBTklTQVRJT04gRk9SIFNUQU5EQVJESVNBVElPTgAMEAAAAgAAAB4AAAAGAAAAVGl0 bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAAP7///8RAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA/v///xkAAAAaAAAAGwAAABwA AAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA/v///ygAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAD+////MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAAP7/ ///9////OQAAAP7////+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAsAw3ZN+zzAE7AAAAgAAAAAAAAABEAGEAdABhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAA AAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGAAAALwdAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOB4AAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACcAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARhsAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQglbaPkQAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --B_3406090145_2752175-- From mike.severa@alcatel-lucent.com Mon Dec 5 15:28:40 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3A61F0C35; Mon, 5 Dec 2011 15:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFX6O4ULIjy8; Mon, 5 Dec 2011 15:28:39 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6B21F8AB8; Mon, 5 Dec 2011 15:28:39 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pB5NSZVI025954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Dec 2011 17:28:36 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB5NSAHN014387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Dec 2011 17:28:35 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 5 Dec 2011 17:28:13 -0600 From: "Severa, Michael J (Mike)" To: Jochen Issing , "Charles Eckel (eckelcu)" Date: Mon, 5 Dec 2011 17:28:12 -0600 Thread-Topic: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues Thread-Index: AcyzoFuYc4j93X9LSH28/0OYEAD6/gAAh68u Message-ID: References: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 X-Mailman-Approved-At: Fri, 09 Dec 2011 20:16:49 -0800 Cc: "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:28:40 -0000 My personal feeling is that the ASC need not be identical in syntax, just i= n semantics (one of the unfortunate aspects of AAC-related signaling is tha= t there are a number of ways to signal the same bitstream). Another unfortu= nate aspect is that one of the options is to signal implicitly, which essen= tially means dont signal at all, rather 'detect' at decode time. That is ob= viously not useful for a capabilities exchange step.=20 I think there might also be other open questions surrounding ambiguities in= signaling AAC-LC/HE-AAC that should be worked through to generate a best o= r acceptable practices approach.=20 Two of the ones that jump out at me are: - the question of what timescale from the rtpmap line means when you intend= to be using HE-AAC in a 3640 environment (3GPP has explicitly indicated th= is should be sampling frequency of the underlying, 'core' AAC-LC portion of= an HE-AAC stream. I assume this is the same semantic in 3640 (though I did= nt notice it specified explicitly)). This question is probably only relevan= t in cases where the goal is to assume HE-AAC (something the multiple fmtp = line suggestion might be implying).=20 - how HE-AAC can be detected in implicit mode during negotiation (again, 3G= PP added an SBR-Enabled flag to the SDP to allow HE-AAC to be detected ahea= d of time even with implicit signaling, im not sure there is an analogous s= olution for 3640).=20 Both of these questions are probably irrelevant if implicit signaling is di= sallowed for HE-AAC (though in the first case that would require parsing th= e ASC during negotiation). Using multiple fmtp lines might be one way to 'd= isable' the implicit signaling requirement (since the backwards compatibili= ty concern associated with implicit signaling can be dealt with by an expli= cit AAC-LC-only ftmp (and rtpmap)line).=20 Sorry if that's a tangent.=20 thanks,=20 Mike ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Jochen= Issing [iss@IEEE.ORG] Sent: Monday, December 05, 2011 2:50 PM To: Charles Eckel (eckelcu) Cc: mmusic@ietf.org; payload@ietf.org Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues Hi Charles, thanks for your response! However, the issue we identified is somewhat diff= erent: The problem already takes place with a single fmtp line: For example, one client indicates that it can (decode and) encode an AAC st= ream using the config field in fmtp. The other side, receiving this information, then = must check its decoder, if it can decode the ASC and needs to setup its encoder, so that it uses the very same ASC. The problem occurs at the encoder of the caller (the receiver of the first = SDP): It might not be possible with reasonable effort to get an encoder creating = the same ASC as given in SDP (encoders are in general not initialized using an = ASC). I hope, this explained our problem much clearer. Best, jochen On 05.12.2011, at 20:02, Charles Eckel (eckelcu) wrote: > Hi Jochen, > > I am not that familiar with the details of the variation modes. If you > want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and > HE-AACv2, it seems you could include multiple payload types in the > m-line, and then specify the corresponding fmtp parameters for each. Is > there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2 > within a single payload type? > > Charles > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Jochen Issing >> Sent: Wednesday, November 30, 2011 7:18 AM >> To: payload@ietf.org; mmusic@ietf.org >> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues >> >> Dear experts, >> >> I need to double-apologize before posting our findings: >> 1) for cross-posting, as I do not know, where this issue has its exact > home, which is hopefully not a >> response killer. >> 2) for the long mail, even though I tried to keep it short. >> >> Now, here's the actual request: >> >> We are referring to RFC3640 SDP fields only, as this is most often the > stumbling block. Let's use the >> following example: >> >> m=3Daudio 49170 RTP/AVP 96 >> a=3Drtpmap:96 mpeg4-generic/48000/2 >> a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; > config=3D1190; sizeLength=3D13; >> indexLength=3D3; indexDeltaLength=3D3; constantDuration=3D1024 >> >> The fields of interest are in the fmtp line: 'profile-level-id' and > 'config'. >> In contrast to other codecs, e.g. G.XXX, AAC integrates many different > types of sub codecs, which are >> identified using the Audio Object Type (AOT). The AOT and some > additional (codec internal) information >> is stored in the Audio Specific Config (ASC), which is conveyed in the > 'config' field. >> The 'profile-level-id' points to a profile with a certain level. The > profile comprises a set of one or >> more AOTs and the level restricts the stream to a maximum sample rate > and/or number channels. The >> profile-level-ids, as specified in ISO 14496-3, are partly > hierarchical and most often ambiguous. >> >> Suppose the classic SIP use case that two clients want to exchange > their codec capabilities. >> The first client specifies some payload types in the SDP part of SIP > INVITE which can differ in their >> profile-level-id and/or config. >> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To > signal these codecs/AOTs he could >> either indicate all formats with the same profile-level-id (e.g., 48), > which includes all these AOTs >> or he could specify profile-level-ids, that are most 'narrow' to the > actual specified AOT or he could >> even mix this principle. >> On the other hand, the ASC might use implicit signaling, explicit > backwards-compatible, or explicit >> non-backwards-compatible. >> Bobs main problem would be to determine, whether the profile-level-id > was chosen to really identify >> the necessary (and applied) AAC AOTs or if he could rely on the ASC or > if the profile-level-id was >> just brawling about the encoders feature. >> >> To clean up this mess of opportunities, we would like to specify a > non-ambiguous way to utilize the >> profile-level-id and config fields appropriately and provide a guide > on how to accomplish clean and >> easier signalization and thus improve interoperability. >> >> >> But first of all we would like to make sure, that you agree to this > problem statement or do we miss >> something here? >> Comments are as always highly appreciated. >> >> Best Regards, >> -- >> jochen >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic -- jochen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From singer@apple.com Wed Dec 7 09:29:28 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF0321F85CE; Wed, 7 Dec 2011 09:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9mihU3M89XP; Wed, 7 Dec 2011 09:29:27 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 047EA21F8BB1; Wed, 7 Dec 2011 09:29:22 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A)" Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LVU002JJGKBECE0@mail-out.apple.com>; Wed, 07 Dec 2011 09:29:20 -0800 (PST) X-AuditID: 11807112-b7b54ae000001626-1a-4edfa270b729 Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by relay17.apple.com (Apple SCV relay) with SMTP id D0.06.05670.072AFDE4; Wed, 07 Dec 2011 09:29:20 -0800 (PST) From: David Singer In-reply-to: Date: Wed, 07 Dec 2011 09:29:20 -0800 Message-id: References: To: Stephan Wenger X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUieFSBW7dg0X0/g+Z7qhYve1ayW3y8d4PV YuryxywWly6eZbK43riJ3WLKhUcsDmweS5b8ZPJYvP49YwBTFJdNSmpOZllqkb5dAlfG/O2l Bat8Kv5Mns/YwLjIoYuRk0NCwETiyIYFbBC2mMSFe+uBbC4OIYHNjBJfOv+CJYQFbCUeNPxl BLF5BYwl1tx6xwJiMwskSLx4cwjMZhNQlXgw5xhYDaeArsTsA8/BbBYBFYmTB7qYIerjJN7e WskGMcdG4vDUPWC2kICOxOKD+1lBbBGg+kM3f7BAHCQv0fL1DtsERr5ZSFbPQrIawtaWWLbw NfMsRg4gW0di8kJGVGEI++P5I0wLGNlWMQoWpeYkVhqa6yUWFOSk6iXn525iBIVyQ6HQDsb7 u/QOMQpwMCrx8G5wuOcnxJpYVlyZe4hRgoNZSYT3y6z7fkK8KYmVValF+fFFpTmpxYcYpTlY lMR5j2y77ickkJ5YkpqdmlqQWgSTZeLglGpg9E0tV7C3zCux2+fy4H9ibt6Xp6oV56ImPV7O zBG15q9QXsfN+24Mbzv63a5XqauyZs1MDgjbzpO1QiGvKfX6qpklu4pjNhcWX3H5Z3h58TJW bsnX/rmT5xSxLXKca5u1+uMDO8sNGctDr7bo+1x8dMTbQeb1wtsrnqbGrvK14nHqNXPcLn9X iaU4I9FQi7moOBEAaZVXV2ECAAA= X-Mailman-Approved-At: Fri, 09 Dec 2011 20:16:48 -0800 Cc: avtext@ietf.org, xrblock@ietf.org, mmusic@ietf.org, payload@ietf.org, avt@ietf.org Subject: Re: [payload] [AVTCORE] Incoming liaison statement from MMUSIC X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:29:28 -0000 --Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Stephan I can explain a bit. We noticed in systems work at MPEG two things a) we wanted to say something about the signal that was being compressed (audio or video) that was nothing to do with the compression, and we ended up having to 'pick' a codec document and point at it, because the codes we wanted were always documented with codecs. b) the codes are also copied from spec. to spec. in many cases (so they happen to have values having the same meanings); in a few cases, each codec has 'invented its own' and the codes needlessly differ from spec. to spec. Examples: the 'classic three' values used to describe video color: color_primaries, transfer_characteristics, matrix_coefficients. These are copied from spec. to spec., with the more recent specs having more values. Recently there was a mistake noticed in an equation, and I think it had to be corrected in several places. Another example is 'frame packing' (stereo packed into a mono video stream); the specs actually don't always align on the definitions here. The variation of semantics for some points could be a problem; different values for the same semantics is a nuisance, e.g. when wanting to be codec-independent or when transcoding. Different numbers of values for the same code in different specs is a nuisance, and raises questions, and so on. The basic idea is to collect a whole bunch of these, document them in one place, and remove the definitions from a whole bunch of specs. So, for example, in a video spec. one might be able to say "this 8-bit field carries a color_primaries value as defined in [[this new spec]]; if absent, the default value is 23". Correspondingly, in say SDP, one might be able to say "if this field is 0, the video is mono; otherwise, it carries a frame_packing values as defined in [[this new spec]]". Makes sense? On Dec 7, 2011, at 8:08 , Stephan Wenger wrote: > Hi all, > mmusic has received an incoming liaison from MPEG, indicating that they have started on "codec independent media description code points". My understanding of this work is that these code points may be represented in SDP. > My personal viewpoint is that this may well be sound architectural work, but it may be better conducted here in mmusic, at least when it comes to SDP representations and the related IANA work. However, I know nothing about this work beyond what's written in the statement, which is why I used "soft" language. Perhaps some of you can shed light into what's really going on. > The assorted avt WGs are probably also affected, as some of the proposed code points sound like they are being described in payload formats, RTP extensions and perhaps even in xrblock. Let me suggest to use only the music list for discussions, as only mmusic is being addressed in the statement. > As it is short, I have attached the statement in word format to this email. It will also appear shortly in the IETF liaison database. > Regards, > Stephan > <29n124561.doc>_______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt David Singer Multimedia and Software Standards, Apple Inc. --Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = Stephan

I can explain a bit.  We noticed in = systems work at MPEG two things
a) we wanted to say something = about the signal that was being compressed (audio or video) that was = nothing to do with the compression, and we ended up having to 'pick' a = codec document and point at it, because the codes we wanted were always = documented with codecs.
b) the codes are also copied from = spec. to spec. in many cases (so they happen to have values having the = same meanings); in a few cases, each codec has 'invented its own' and = the codes needlessly differ from spec. to = spec.

Examples: the 'classic three' values used = to describe video color: color_primaries, transfer_characteristics, = matrix_coefficients.  These are copied from spec. to spec., with = the more recent specs having more values. Recently there was a mistake = noticed in an equation, and I think it had to be corrected in several = places.  Another example is 'frame packing' (stereo packed into a = mono video stream); the specs actually don't always align on the = definitions here.

The variation of semantics = for some points could be a problem; different values for the same = semantics is a nuisance, e.g. when wanting to be codec-independent or = when transcoding. Different numbers of values for the same code in = different specs is a nuisance, and raises questions, and so = on.

The basic idea is to collect a whole bunch = of these, document them in one place, and remove the definitions from a = whole bunch of specs.  So, for example, in a video spec. one might = be able to say "this 8-bit field carries a color_primaries value as = defined in [[this new spec]]; if absent, the default value is 23". =  Correspondingly, in say SDP, one might be able to say "if this = field is 0, the video is mono; otherwise, it carries a frame_packing = values as defined in [[this new spec]]".

Makes = sense?


On Dec 7, 2011, at 8:08 , = Stephan Wenger wrote:

Hi all,
mmusic = has received an incoming liaison from MPEG, indicating that they have = started on "codec independent media description code points".  My = understanding of this work is that these code points may be represented = in SDP.
My personal viewpoint is that this may well be sound = architectural work, but it may be better conducted here in mmusic, at = least when it comes to SDP representations and the related IANA work. =  However, I know nothing about this work beyond what's written = in the statement, which is why I used "soft" language.  Perhaps = some of you can shed light into what's really going on.
The = assorted avt WGs are probably also affected, as some of the proposed = code points sound like they are being described in payload formats, RTP = extensions and perhaps even in xrblock.  Let me suggest to use only = the music list for discussions, as only mmusic is being addressed in the = statement.
As it is short, I have attached the statement in = word format to this email.  It will also appear shortly in the IETF = liaison database.
Regards,
Stephan
= <29n124561.doc>________________________________________= _______
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mail= man/listinfo/avt

David Singer
Multimedia and = Software Standards, Apple = Inc.

= --Boundary_(ID_CtRC7gm2oU3HeqUBm5UV3A)-- From internet-drafts@ietf.org Thu Dec 15 06:45:58 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BCA21F8AF3; Thu, 15 Dec 2011 06:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KretGfuVMYO; Thu, 15 Dec 2011 06:45:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94921F8AD1; Thu, 15 Dec 2011 06:45:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111215144558.9398.64451.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2011 06:45:58 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 14:45:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for Bluetooth's SBC audio codec Author(s) : Christian Hoene Frans de Bont Filename : draft-ietf-payload-rtp-sbc-01.txt Pages : 24 Date : 2011-12-15 This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-01.txt From hoene@uni-tuebingen.de Thu Dec 15 06:50:43 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1021F8AD1 for ; Thu, 15 Dec 2011 06:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20pb643Lnd8f for ; Thu, 15 Dec 2011 06:50:43 -0800 (PST) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id AD86721F8AF1 for ; Thu, 15 Dec 2011 06:50:42 -0800 (PST) Received: from hoeneT60 (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id pBFEoei3002778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Dec 2011 15:50:41 +0100 From: "Christian Hoene" To: References: <20111215144558.9398.64451.idtracker@ietfa.amsl.com> In-Reply-To: <20111215144558.9398.64451.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2011 15:51:13 +0100 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <012f01ccbb38$fdfab350$f9f019f0$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEzqmR2VHOaT+tJoXcykzEurEuND5cPHCCw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx08) Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 14:50:43 -0000 Hello, we would like to ask for WGLC if possible. The Bluetooth SBC is a quite nice codec ranging from wideband speech, CD quality up to distributed ensembles as it has ultra-low delay. The complexity is very low and last not least, to the best of my knowledge it is patent free. We have one implementation of this draft in libopal. With best regards, Christian Hoene > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Thursday, December 15, 2011 3:46 PM > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working > Group of the IETF. > > Title : RTP Payload Format for Bluetooth's SBC audio codec > Author(s) : Christian Hoene > Frans de Bont > Filename : draft-ietf-payload-rtp-sbc-01.txt > Pages : 24 > Date : 2011-12-15 > > This document specifies a Real-time Transport Protocol (RTP) payload > format to be used for the low complexity subband codec (SBC), which > is the mandatory audio codec of the Advanced Audio Distribution > Profile (A2DP) Specification written by the Bluetooth(r) Special > Interest Group (SIG). The payload format is designed to be able to > interoperate with existing Bluetooth A2DP devices, to provide high > streaming audio quality, interactive audio transmission over the > internet, and ultra-low delay coding for jam sessions on the > internet. This document contains also a media type registration > which specifies the use of the RTP payload format. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-01.txt > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From csp@csperkins.org Mon Dec 19 08:42:15 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895BC21F84CE for ; Mon, 19 Dec 2011 08:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG3Znj4CxvtV for ; Mon, 19 Dec 2011 08:42:14 -0800 (PST) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7350B21F84B0 for ; Mon, 19 Dec 2011 08:42:14 -0800 (PST) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RcgI1-0005he-ap; Mon, 19 Dec 2011 16:42:13 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <012f01ccbb38$fdfab350$f9f019f0$@uni-tuebingen.de> Date: Mon, 19 Dec 2011 16:42:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111215144558.9398.64451.idtracker@ietfa.amsl.com> <012f01ccbb38$fdfab350$f9f019f0$@uni-tuebingen.de> To: Christian Hoene X-Mailer: Apple Mail (2.1251.1) Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:42:15 -0000 Christian, Some comments on this version: - Section 3 is background, but is written in a way that could be = interpreted as making a series of normative requirements (e.g., =93SBC = can use four or eight subbands. The decoder shall support both; the = encoder shall support at least 8 subbands=94). Be clear whether these = are normative requirements made by this document, or by the SBC codec = specification or the SBC A2DP profile. - The draft uses =93CAN=94 throughout, but this is not an RFC 2119 = keyword. What is meant? - Need to mandate the behaviour if the fields in the frame header don=92t = match the SDP negotiated values. It would be better if these parameters = were only specified in the SDP, rather than duplicating them in-band and = in the signalling. - Media type registration: =93MIME type=94 -> =93Media type=94, since = this is more general than Internet mail. - The formatting of the =93optional parameters=94 section of the media = type registration is unclear. Is this supposed to include the = capabilities parameter? Is the capabilities parameter really optional? = Section 7.2 seems to require it. - The change controller cannot be the AVT working group, since that no = longer exists - Section 7.1.1 refers to the =93a=3Drtpmap:=94 attribute for the rate = and channel parameters, but section 7.1 doesn=92t define these = parameters. Need to add them in the required parameters section of the = media type registration. Colin On 15 Dec 2011, at 14:51, Christian Hoene wrote: > Hello, >=20 > we would like to ask for WGLC if possible. >=20 > The Bluetooth SBC is a quite nice codec ranging from wideband speech, = CD > quality up to distributed ensembles as it has ultra-low delay. The > complexity is very low and last not least, to the best of my knowledge = it is > patent free. We have one implementation of this draft in libopal. >=20 > With best regards, >=20 > Christian Hoene >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of internet-drafts@ietf.org >> Sent: Thursday, December 15, 2011 3:46 PM >> To: i-d-announce@ietf.org >> Cc: payload@ietf.org >> Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-01.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Audio/Video Transport Payloads = Working >> Group of the IETF. >>=20 >> Title : RTP Payload Format for Bluetooth's SBC audio = codec >> Author(s) : Christian Hoene >> Frans de Bont >> Filename : draft-ietf-payload-rtp-sbc-01.txt >> Pages : 24 >> Date : 2011-12-15 >>=20 >> This document specifies a Real-time Transport Protocol (RTP) = payload >> format to be used for the low complexity subband codec (SBC), which >> is the mandatory audio codec of the Advanced Audio Distribution >> Profile (A2DP) Specification written by the Bluetooth(r) Special >> Interest Group (SIG). The payload format is designed to be able to >> interoperate with existing Bluetooth A2DP devices, to provide high >> streaming audio quality, interactive audio transmission over the >> internet, and ultra-low delay coding for jam sessions on the >> internet. This document contains also a media type registration >> which specifies the use of the RTP payload format. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-01.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-sbc-01.txt >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins http://csperkins.org/ From wwwrun@rfc-editor.org Fri Dec 23 14:31:15 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0825021F8AF1; Fri, 23 Dec 2011 14:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDbYm3pMwIM4; Fri, 23 Dec 2011 14:31:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D18421F8AEA; Fri, 23 Dec 2011 14:31:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0704D6217D; Fri, 23 Dec 2011 14:29:35 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111223222935.0704D6217D@rfc-editor.org> Date: Fri, 23 Dec 2011 14:29:35 -0800 (PST) Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 6469 on RTP Payload Format for DV (IEC 61834) Video X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 22:31:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6469 Title: RTP Payload Format for DV (IEC 61834) Video Author: K. Kobayashi, K. Mishima, S. Casner, C. Bormann Status: Standards Track Stream: IETF Date: December 2011 Mailbox: ikob@riken.jp, three@sfc.wide.ad.jp, casner@acm.org, cabo@tzi.org Pages: 18 Characters: 38041 Obsoletes: RFC3189 I-D Tag: draft-ietf-payload-rfc3189bis-03.txt URL: http://www.rfc-editor.org/rfc/rfc6469.txt This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Even.roni@huawei.com Sun Dec 25 23:44:29 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12F421F8ABD for ; Sun, 25 Dec 2011 23:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0kgHW7d8hR5 for ; Sun, 25 Dec 2011 23:44:28 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DF0C621F8ABB for ; Sun, 25 Dec 2011 23:44:27 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS009CYW504F@szxga05-in.huawei.com> for payload@ietf.org; Mon, 26 Dec 2011 15:43:48 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWS003QLW4OQI@szxga05-in.huawei.com> for payload@ietf.org; Mon, 26 Dec 2011 15:43:48 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA30390; Mon, 26 Dec 2011 15:43:47 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Dec 2011 15:43:46 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.136]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Mon, 26 Dec 2011 15:43:45 +0800 Date: Mon, 26 Dec 2011 07:43:44 +0000 From: Roni even X-Originating-IP: [172.24.1.70] To: "ietf-types@iana.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jwTZTQ8zx7a5ZPdGRjRp4A)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype Thread-index: AQHMw6IYFHGBhQEdbUK2ukl7vCSsKg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "payload@ietf.org" Subject: [payload] registeration of audio EVRCNW, EVRCNW0 and EVRCNW1 media subtype X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 07:44:29 -0000 --Boundary_(ID_jwTZTQ8zx7a5ZPdGRjRp4A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, draft-ietf-avt-rtp-evrc-nw-05 has passed Working Group Last Call in the Payload Working Group. The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-05#section-9.1 The information is also available below. Comments on the registration are welcome. Roni Even Payload co-chair This document introduces a new EVRC-NW 'audio' media subtypes. 9.1. Media Type Registrations Following the guidelines in RFC 4855 [8] and RFC 4288 [9], this section registers new 'audio' media subtypes for EVRC-NW. 9.1.1. Registration of Media Type audio/EVRCNW Type name: audio Subtype names: EVRCNW Required parameters: None Optional parameters: These parameters apply to RTP transfer only. mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. Absence of this parameter signals the mode set {1,2,3,4,5,6,7}. ptime: see RFC 4566 [10]. maxptime: see RFC 4566. maxinterleave: Maximum number for interleaving length (field LLL in the Interleaving Octet)[0..7]. The interleaving lengths used in the entire session MUST NOT exceed this maximum value. If not signaled, the maxinterleave length MUST be 5. silencesupp: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788. Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the Interleaved/Bundled packet format specified in RFC 3558 [6]. Security considerations: See Section 15. Interoperability considerations: None Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer method with the Interleaved/Bundled packet format via RTP is specified in RFC 3558 [6]. See Section 6 for details for EVRC-NW. Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: The following applies to stored-file transfer methods: Magic number: #!EVRCNW\n (see Section 8) File extensions: enw, ENW Macintosh file type code: None Object identifier or OID: None EVRC-NW speech frames may also be stored in the file format "3g2" defined in 3GPP2 C.S0050-B, which is identified using the media types "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11]. Person & email address to contact for further information: Zheng Fang > Intended usage: COMMON Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be used. In all other contexts, the file format defined in Section 8 SHALL be used. See Section 6 for details for EVRC-NW. Author: Zheng Fang > Change controller: IETF Payload working group delegated from the IESG. 9.1.2. Registration of Media Type audio/EVRCNW0 Type name: audio Subtype names: EVRCNW0 Required parameters: None Optional parameters: These parameters apply to RTP transfer only. mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. Absence of this parameter signals the mode set {1,2,3,4,5,6,7}. ptime: see RFC 4566. silencesupp: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788. Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the Header-Free packet format specified in RFC 3558 [6]. Security considerations: See Section 15. Interoperability considertaions: None Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer method with the Header-Free packet format via RTP is specified in RFC 3558 [6]. Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: None Person & email address to contact for further information: Zheng Fang > Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [5], the RTP payload format specified in Section 4.2 of RFC 3558 [6] SHALL be used. This media type SHALL NOT be used for storage or file transfer, instead audio/EVRCNW SHALL be used. Author: Zheng Fang > Change controller: IETF Payload working group delegated from the IESG. 9.1.3. Registration of Media Type audio/EVRCNW1 Type name: audio Subtype names: EVRCNW1 Required parameters: None Optional parameters: These parameters apply to RTP transfer only. mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma separated list of modes from the set {0,1} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes. A value of 0 signals the support for wideband fixed rate (full or half rate, depending on the value of 'fixedrate' parameter). A value of 1 signals narroband fixed rate (full or half rate, depending on the value of 'fixedrate' parameter). Absence of this parameter signals the mode 1. ptime: see RFC 4566. maxptime: see RFC 4566. fixedrate: Indicates the EVRC-NW rate of the session while in single rate operation. Valid values include: 0.5 and 1, where a value of 0.5 indicates the 1/2 rate while a value of 1 indicates the full rate. If this parameter is not present, 1/2 rate is assumed. silencesupp: see Section 6.1 in RFC 4788. dtxmax: see Section 6.1 in RFC 4788. dtxmin: see Section 6.1 in RFC 4788. hangover: see Section 6.1 in RFC 4788. Encoding considerations: This media type is framed binary data (see RFC 4288, Section 4.8) and is defined for transfer of EVRC-NW encoded data via RTP using the Compact Bundled packet format specified in RFC 4788. Security considerations: See Section 15 Interoperability considertaions: None Published specification: The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D. The transfer method with the Compact Bundled packet format via RTP is specified in RFC 4788. Applications that use this media type: It is expected that many VoIP applications (as well as mobile applications) will use this type. Additional information: None Person & email address to contact for further information: Zheng Fang > Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [5], the RTP payload format specified in Section 4 of RFC 4788 SHALL be used. This media type SHALL NOT be used for storage or file transfer, instead audio/EVRCNW SHALL be used. Author: Zheng Fang > Change controller: IETF Payload working group delegated from the IESG. --Boundary_(ID_jwTZTQ8zx7a5ZPdGRjRp4A) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi,

 

draft-ietf-avt-rtp-evrc-nw-05 has passed Working Group Last Call in the Payload Working Group.

 

 

The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-05#section-9.1

 

The information is also available below.

 

 

 

Comments on the registration are welcome.

 

Roni Even

Payload co-chair

 

 

This document introduces a new EVRC-NW 'audio' media subtypes.

 

9.1.  Media Type Registrations

   Following the guidelines in RFC 4855 [8] and RFC 4288 [9], this
   section registers new 'audio' media subtypes for EVRC-NW.

 

9.1.1.  Registration of Media Type audio/EVRCNW

   Type name: audio

   Subtype names: EVRCNW

   Required parameters: None

   Optional parameters:

   These parameters apply to RTP transfer only.

   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see
   Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this
   attribute to inform an encoder of its preference to operate in a
   specified subset of modes.  Absence of this parameter signals the
   mode set {1,2,3,4,5,6,7}.

   ptime: see RFC 4566 [10].

   maxptime: see RFC 4566.

   maxinterleave: Maximum number for interleaving length (field LLL in
   the Interleaving Octet)[0..7].  The interleaving lengths used in the
   entire session MUST NOT exceed this maximum value.  If not signaled,
   the maxinterleave length MUST be 5.

   silencesupp: see Section 6.1 in RFC 4788.

   dtxmax: see Section 6.1 in RFC 4788.

   dtxmin: see Section 6.1 in RFC 4788.

   hangover: see Section 6.1 in RFC 4788.

   Encoding considerations:

   This media type is framed binary data (see RFC 4288, Section 4.8) and

   is defined for transfer of EVRC-NW encoded data via RTP using the
   Interleaved/Bundled packet format specified in RFC 3558 [6].

   Security considerations: See Section 15.

   Interoperability considerations: None

   Published specification:

   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Interleaved/Bundled packet format via RTP is
   specified in RFC 3558 [6].  See Section 6 for details for EVRC-NW.

   Applications that use this media type:

   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.

   Additional information:

   The following applies to stored-file transfer methods:

   Magic number: #!EVRCNW\n (see Section 8)

   File extensions: enw, ENW

   Macintosh file type code: None

   Object identifier or OID: None

   EVRC-NW speech frames may also be stored in the file format "3g2"
   defined in 3GPP2 C.S0050-B, which is identified using the media types
   "audio/3gpp2" or "video/3gpp2" registered by RFC 4393 [11].

   Person & email address to contact for further information:

   Zheng Fang <zfang@qualcomm.com>

   Intended usage: COMMON

   Restrictions on usage:

   When this media type is used in the context of transfer over RTP, the
   RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
   used.  In all other contexts, the file format defined in Section 8
   SHALL be used.  See Section 6 for details for EVRC-NW.

   Author:

   Zheng Fang <zfang@qualcomm.com>

   Change controller:

   IETF Payload working group delegated from the IESG.

 

9.1.2.  Registration of Media Type audio/EVRCNW0

   Type name: audio

   Subtype names: EVRCNW0

   Required parameters: None

   Optional parameters:

   These parameters apply to RTP transfer only.

   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1,2,3,4,5,6,7} (see
   Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this
   attribute to inform an encoder of its preference to operate in a
   specified subset of modes.  Absence of this parameter signals the
   mode set {1,2,3,4,5,6,7}.

   ptime: see RFC 4566.

   silencesupp: see Section 6.1 in RFC 4788.

   dtxmax: see Section 6.1 in RFC 4788.

   dtxmin: see Section 6.1 in RFC 4788.

   hangover: see Section 6.1 in RFC 4788.

   Encoding considerations:

   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Header-Free packet format specified in RFC 3558 [6].

   Security considerations: See Section 15.

   Interoperability considertaions: None

   Published specification:

   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer

   method with the Header-Free packet format via RTP is specified in RFC
   3558 [6].

   Applications that use this media type:

   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.

   Additional information: None

   Person & email address to contact for further information:

   Zheng Fang <zfang@qualcomm.com>

   Intended usage: COMMON

   Restrictions on usage:

   This media type depends on RTP framing, and hence is only defined for
   transfer via RTP [5], the RTP payload format specified in Section 4.2
   of RFC 3558 [6] SHALL be used.  This media type SHALL NOT be used for
   storage or file transfer, instead audio/EVRCNW SHALL be used.

   Author:

   Zheng Fang <zfang@qualcomm.com>

   Change controller:

   IETF Payload working group delegated from the IESG.

 

 

9.1.3.  Registration of Media Type audio/EVRCNW1

   Type name: audio

   Subtype names: EVRCNW1

   Required parameters: None

   Optional parameters:

   These parameters apply to RTP transfer only.

   mode-set-recv: A subset of EVRC-NW modes.  Possible values are a
   comma separated list of modes from the set {0,1} (see Table 2.6.1.2-4
   in 3GPP2 C.S0014-D).  A decoder can use this attribute to inform an
   encoder of its preference to operate in a specified subset of modes.
   A value of 0 signals the support for wideband fixed rate (full or

   half rate, depending on the value of 'fixedrate' parameter).  A value
   of 1 signals narroband fixed rate (full or half rate, depending on
   the value of 'fixedrate' parameter).  Absence of this parameter
   signals the mode 1.

   ptime: see RFC 4566.

   maxptime: see RFC 4566.

   fixedrate: Indicates the EVRC-NW rate of the session while in single
   rate operation.  Valid values include: 0.5 and 1, where a value of
   0.5 indicates the 1/2 rate while a value of 1 indicates the full
   rate.  If this parameter is not present, 1/2 rate is assumed.

   silencesupp: see Section 6.1 in RFC 4788.

   dtxmax: see Section 6.1 in RFC 4788.

   dtxmin: see Section 6.1 in RFC 4788.

   hangover: see Section 6.1 in RFC 4788.

   Encoding considerations:

   This media type is framed binary data (see RFC 4288, Section 4.8) and
   is defined for transfer of EVRC-NW encoded data via RTP using the
   Compact Bundled packet format specified in RFC 4788.

   Security considerations: See Section 15

   Interoperability considertaions: None

   Published specification:

   The EVRC-NW vocoder is specified in 3GPP2 C.S0014-D.  The transfer
   method with the Compact Bundled packet format via RTP is specified in
   RFC 4788.

   Applications that use this media type:

   It is expected that many VoIP applications (as well as mobile
   applications) will use this type.

   Additional information: None

   Person & email address to contact for further information:

   Zheng Fang <zfang@qualcomm.com>

   Intended usage: COMMON

   Restrictions on usage:

   This media type depends on RTP framing, and hence is only defined for
   transfer via RTP [5], the RTP payload format specified in Section 4
   of RFC 4788 SHALL be used.  This media type SHALL NOT be used for
   storage or file transfer, instead audio/EVRCNW SHALL be used.

   Author:

   Zheng Fang <zfang@qualcomm.com>

   Change controller:

   IETF Payload working group delegated from the IESG.

--Boundary_(ID_jwTZTQ8zx7a5ZPdGRjRp4A)--