From owner-IPTEL@lists.research.bell-labs.com Fri Jan 1 16:28:30 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08314 for ; Fri, 1 Jan 1999 16:28:29 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id LAA15031 for iptel-outgoing; Fri, 1 Jan 1999 11:49:17 -0500 (EST) Message-ID: <000f01bf3c11$5b958760$8f01e1c8@soho> From: "Reinaldo Penno Filho" To: , "Noah, Matt" Cc: , Subject: Re: Date: Wed, 1 Dec 1999 13:32:47 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Another approach... "In spite of the apparent simplicity of MOS tests, there are a number of important issues that must be carefully addressed. In order to avoid biasing when designing the test, you must keep in mind issues such as test results; number and type of speakers; number, type and training of listeners; and presentation of the listening material. Issues that need attention during processing of the results are: score distributions, standard deviation, and confidence intervals. Unfortunately, in spite of the care exercised in the design of a MOS test, MOS numbers tend to vary significantly from test to test. As such, the current wisdom suggests that MOS numbers should not be seen as absolute values, but should be used for relative ranking of various coders used in a given test. In the pursuit of speech quality measures that would not vary much from test to test, an alternate method called MNRU has recently become popular. In this approach, clean speech is degraded by incorporating known amounts of "waveform distortion." These speech samples are evaluated in a MOS test along with candidate coders. By comparing the MOS of the degraded speech material and the candidate coded speech material, the equivalent distortion level is determined for the candidate coder. Often, this distortion is expressed in dB and is seen to be less variable from test to test. A drawback of MOS tests is that the listener is forced to rate all types of signal degradations (such as sounding nasal, fluttering, muffled, interrupted, thin, and rasping) as well as noise types (hissing, buzzing, babbling, and rumbling) in a single measure. This can lead to a large variance in the scores due to the variances in each listener's perceptual sensitivity and training. Thus a test called the dynamic acceptability (DAM) test was developed that allows listeners to score on several signal quality and noise effects and then averages the results. DAM scores vary from 0 to 100, with "good" coders having a score of about 50. While this test does provide a more scientific measure of speech quality, it is also more involved to administer. Although speech quality measurement strictly requires subjective tests such as those described above, having quantitative measurements of speech quality can be useful in the development of new algorithms, and in comparative analysis of two different coders. Two of the more commonly used objective measures are time domain segmental SNR and spectral distance measure. Both these tests compare transcoded speech to the original speech and are not absolute quality measures. The segmental SNR is computed by splitting the signal into 20ms to 30ms segments, and SNR is computed for each segment, then averaged. Segments with no speech are not used in calculations. The spectral distance measures are based on the theory that human hearing is more sensitive to the magnitude spectrum of the signal and less to the phase spectrum. Thus time domain SNR measures can be misleading, and therefore spectral measures have been developed. " Multimedia Systems Design 02/98 Best Regards, _________________________________ Reinaldo Penno Filho Consultor Tecnico SAGA Sistemas e Computadores S.A. tel: 55-21-5508506 e-mail : reinaldo@saga.com.br Universidade Federal do Rio de Janeiro Nucleo de Computacao Eletronica / Instituto de Matematica Grupo de Redes de Alta Velocidade e-mail : reinaldo@posgrad.nce.ufrj.br ACM Member reinaldo@acm.org ________________________________ -----Original Message----- From: gregboop@us.ibm.com To: Noah, Matt Cc: 'tacheron@doim6.monmouth.army.mil' ; iptel@lists.research.bell-labs.com Date: 31 de Dezembro de 1998 09:23 Subject: RE: > > >Hello, > >The most commonly accepted measure of Voice Quality associated >with VoIP is the Mean Opinion Score. In this measurement system, >POTS (regular phone) is considered a 4. G.723.1 comes in at 3.98. >Anything above 3.5 is considered acceptable. > >More information can probably be found at sites of companies that >license DSP code for encoding voice ... e.g. the DSP Group at >http://www.dspg.com > >Best Regards, > >- Greg Boop > Mgr - VoIP Development > IBM - NHD > RTP, NC, USA > Phone: +1 919 254 0319 > gregboop@us.ibm.com > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sat Jan 2 10:00:50 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20707 for ; Sat, 2 Jan 1999 10:00:50 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id FAA16609 for iptel-outgoing; Sat, 2 Jan 1999 05:07:15 -0500 (EST) Message-ID: <368DEF50.D3B129D3@radvision.rad.co.il> Date: Sat, 02 Jan 1999 12:05:04 +0200 From: Ami Amir X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Reinaldo Penno Filho CC: gregboop@us.ibm.com, "Noah, Matt" , tacheron@doim6.monmouth.army.mil, iptel@lists.research.bell-labs.com Subject: Re: References: <99Jan1.200502ist.113796@firewall.radvision.rad.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Reinaldo, MOS is only one measure - since the transport of other media types - e.g. DTMF, Music on Hold, Modem and FAX are not considered (are should be supported in some networks). In addition, some services - e.g. 3 way calls - require encodings that are clsoe to linear. It all comes back to the call model and the applications/services that need to be supported. As an aside - on backbone networks, the bandwidth savings achieved by high audio compression ratios are not that significant, especially if one balances the added cost of the special means needed to handle the other media types (e.g. mdoems and fax). To summarize - MOS has limited applicability to the problem at hand and is only one of the parameters to be used. Ami Reinaldo Penno Filho wrote: > > ---------- > > From: Reinaldo Penno Filho[SMTP:REINALDO@SAGA.COM.BR] > > Sent: Wednesday, December 01, 1999 5:32:47 PM > > To: gregboop@us.ibm.com; Noah, Matt > > Cc: tacheron@doim6.monmouth.army.mil; iptel@lists.research.bell-labs.com > > Subject: Re: > > Auto forwarded by a Rule > > > Another approach... > > "In spite of the apparent simplicity of MOS tests, there are a number of > important issues that must be carefully addressed. In order to avoid biasing > when designing the test, you must keep in mind issues such as test results; > number and type of speakers; number, type and training of listeners; and > presentation of the listening material. Issues that need attention during > processing of the results are: score distributions, standard deviation, and > confidence intervals. > > Unfortunately, in spite of the care exercised in the design of a MOS test, > MOS numbers tend to vary significantly from test to test. As such, the > current wisdom suggests that MOS numbers should not be seen as absolute > values, but should be used for relative ranking of various coders used in a > given test. In the pursuit of speech quality measures that would not vary > much from test to test, an alternate method called MNRU has recently become > popular. In this approach, clean speech is degraded by incorporating known > amounts of "waveform distortion." These speech samples are evaluated in a > MOS test along with candidate coders. By comparing the MOS of the degraded > speech material and the candidate coded speech material, the equivalent > distortion level is determined for the candidate coder. Often, this > distortion is expressed in dB and is seen to be less variable from test to > test. > > A drawback of MOS tests is that the listener is forced to rate all types of > signal degradations (such as sounding nasal, fluttering, muffled, > interrupted, thin, and rasping) as well as noise types (hissing, buzzing, > babbling, and rumbling) in a single measure. This can lead to a large > variance in the scores due to the variances in each listener's perceptual > sensitivity and training. Thus a test called the dynamic acceptability (DAM) > test was developed that allows listeners to score on several signal quality > and noise effects and then averages the results. DAM scores vary from 0 to > 100, with "good" coders having a score of about 50. While this test does > provide a more scientific measure of speech quality, it is also more > involved to administer. > > Although speech quality measurement strictly requires subjective tests such > as those described above, having quantitative measurements of speech quality > can be useful in the development of new algorithms, and in comparative > analysis of two different coders. Two of the more commonly used objective > measures are time domain segmental SNR and spectral distance measure. Both > these tests compare transcoded speech to the original speech and are not > absolute quality measures. The segmental SNR is computed by splitting the > signal into 20ms to 30ms segments, and SNR is computed for each segment, > then averaged. Segments with no speech are not used in calculations. The > spectral distance measures are based on the theory that human hearing is > more sensitive to the magnitude spectrum of the signal and less to the phase > spectrum. Thus time domain SNR measures can be misleading, and therefore > spectral measures have been developed. " > > Multimedia Systems Design 02/98 > > Best Regards, > > _________________________________ > Reinaldo Penno Filho > Consultor Tecnico > SAGA Sistemas e Computadores S.A. > tel: 55-21-5508506 > e-mail : reinaldo@saga.com.br > > Universidade Federal do Rio de Janeiro > Nucleo de Computacao Eletronica / Instituto de Matematica > Grupo de Redes de Alta Velocidade > e-mail : reinaldo@posgrad.nce.ufrj.br > > ACM Member > reinaldo@acm.org > ________________________________ > > -----Original Message----- > From: gregboop@us.ibm.com > To: Noah, Matt > Cc: 'tacheron@doim6.monmouth.army.mil' ; > iptel@lists.research.bell-labs.com > Date: 31 de Dezembro de 1998 09:23 > Subject: RE: > > > > > > >Hello, > > > >The most commonly accepted measure of Voice Quality associated > >with VoIP is the Mean Opinion Score. In this measurement system, > >POTS (regular phone) is considered a 4. G.723.1 comes in at 3.98. > >Anything above 3.5 is considered acceptable. > > > >More information can probably be found at sites of companies that > >license DSP code for encoding voice ... e.g. the DSP Group at > >http://www.dspg.com > > > >Best Regards, > > > >- Greg Boop > > Mgr - VoIP Development > > IBM - NHD > > RTP, NC, USA > > Phone: +1 919 254 0319 > > gregboop@us.ibm.com > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Wed Jan 6 22:19:31 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA14566 for ; Wed, 6 Jan 1999 22:19:31 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA25072 for iptel-outgoing; Wed, 6 Jan 1999 16:59:39 -0500 (EST) Message-ID: <3693DC09.9E810363@dnrc.bell-labs.com> Date: Wed, 06 Jan 1999 16:56:25 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: list iptel Subject: Minutes available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Folks, Minutes of the Orlando meeting are now available at our web site: http://www.bell-labs.com/mailing-lists/iptel/ Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 7 06:26:41 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA25637 for ; Thu, 7 Jan 1999 06:26:40 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id BAA26567 for iptel-outgoing; Thu, 7 Jan 1999 01:28:51 -0500 (EST) Message-ID: <369453D4.204B6D44@dnrc.bell-labs.com> Date: Thu, 07 Jan 1999 01:27:32 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Dean Willis CC: Conference Control List , list iptel Subject: Re: Capability-based routing in SIP References: <001701be39c3$e0d1bbc0$67e323a6@dwillispc3.mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Dean Willis wrote: > > I could perhaps work around this problem by defining a different > username for each device, associating capabilities with usernames in my > ULS configuration, but this seems rather a complex kludge. > > To summarize the issues: > > 1) Capability-based routing seems to require parsing the SDP to decide > what the session type is. This is problematic for fast setups. Not really. Parsing SDP is pretty fast when you don't need everything; just quickly read through the lines until you find the m= lines, and look for fax, audio, video, or whatever. > Am I missing something obvious here, or do we really need a richer > capability description and handling mechanism to handle these scenarios? This is an excellent point, Dean. The right way to handle this becomes clearer when you extend the requirements a bit more. What you are asking for is that a user should be able to direct the call routing of a proxy. In this case, its based on the SDP in the INVITE. More generally, it might be based on time of day, caller, subject, method, etc. SO, how do we devise a means for allowing a user to instruct a SIP server on call routing? The answer is the call processing language in iptel! It is for exactly this purpose. I think what you have come up with is another requirement as input for the language: You would then upload the CPL to the server in the REGISTER message. Conceivably, a REGISTER message could contain SDP, in which case the registrar would interpret it as a capabilities description for call routing. Its messy, but it works and this is what pint is doing. It quickly breaks down when you want to add other routing logic, in which case the CPL is clearly a better choice. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 7 15:24:28 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA11229 for ; Thu, 7 Jan 1999 15:24:28 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id KAA26876 for iptel-outgoing; Thu, 7 Jan 1999 10:43:17 -0500 (EST) Message-ID: <87830212CCB1D011881300A0245175F5558F34@VANTS02> From: Jerry Skene To: sigtran@BayNetworks.COM, list iptel , "'tsg16q13@itu.int'" , "'stg16q14@itu.int'" , "'Taylor, Tom-PT [SKY:B318-I:EXCH]'" , "'TIPHON_WG6@LIST.ETSI.FR'" , "'TIPHON_WG2@LIST.ETSI.FR'" , "'TIPHON_WG5@LIST.ETSI.FR'" Subject: Notice of Meeting and Call for Contributions on new ITU question on Internet Gateway Equipment Date: Thu, 7 Jan 1999 10:40:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Notice of Meeting and Call for Contributions on new ITU question on Internet Gateway Equipment In October, the Telecommunications Standardization Bureau of the International Telecommunications Union, (ITU-T) Study Group 15 (Transport Networks, Systems and Equipment)approved a new Question dealing with interconnection equipment between the GSTN and IP Networks. The first meeting of this new Question (Q21/15)will be held in conjunction with the Study Group 15/Working Party 2 interim meeting on 16 - 19 February, 1999. ITU members can find the full text of the question on the ITU Informal FTP Area, at: http://ftp.itu.int/u/tsg15/sg15/wp2/q21/q21_index.htm Note that this site is password protected, and is accessible to ITU members only. Non-ITU members can find the text of the Question at: http://www.coherent.com/itu This message is a call for contributions on this important new work. The goal of the February meeting is to establish working methods for the Question, the baseline structure for the Recommendation, a timetable for completion of the work, and to begin drafting text. The Recommendation being developed in this Question will be of interest to the following parties: - GSTN telephony carriers interfacing or planning to interface their networks to the Internet - Internet Service Providers carrying or planning to carry telephony traffic originating or terminating on the GSTN - Network equipment vendors providing or developing Internet Telephony interface equipment Meeting Registration ITU and interested non-ITU members may attend this meeting. Details on registration for the interim meeting may be obtained from the host, Tom Oshidari [toshidari@ditechcorp.com]. The venue for the meeting is the Sheraton on Fisherman's Wharf, San Francisco. The meeting will be one day long, and will be held during the week of February 15-19. The specific day will be known by January 15. Contributions If you plan to attend this meeting, please let the Rapporteur, Mr. Jerry Skene and the host, Mr. Oshidari know. If you plan to submit a contribution on this topic, please email it to the Rapporteur, and it will be included in the discussion. If you are a non ITU member, you are most welcome to attend and to submit contributions. Please contact the rapporteur for guidance on this. To ensure proper consideration of a contribution, the title of the contribution must be received by the rapporteur no later than January 8, 1999. Sincerely; Jerry Skene Rapporteur, Q21/15 _________________________________________________ Jerry Skene | Tellabs, Inc. Director, | 45085 University Drive International Standards | Ashburn, VA 20147.2745 USA tel:+1 703 724-7302 | URL: www.tellabs.com fax: +1 703 724-7202 | email: jerry.skene@tellabs.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 7 16:41:34 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA12369 for ; Thu, 7 Jan 1999 16:41:34 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id MAA27018 for iptel-outgoing; Thu, 7 Jan 1999 12:07:17 -0500 (EST) Cc: sigtran@BayNetworks.COM, list iptel , "'tsg16q13@itu.int'" , "'stg16q14@itu.int'" , "'Taylor, Tom-PT [SKY:B318-I:EXCH]'" , "'TIPHON_WG6@LIST.ETSI.FR'" , "'TIPHON_WG2@LIST.ETSI.FR'" , "'TIPHON_WG5@LIST.ETSI.FR'" Message-ID: <3694E986.D134ABC@lucent.com> Date: Thu, 07 Jan 1999 12:06:14 -0500 From: Binshi Cao Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (Win95; U) MIME-Version: 1.0 To: Jerry Skene Original-CC: sigtran@BayNetworks.COM, list iptel , "'tsg16q13@itu.int'" , "'stg16q14@itu.int'" , "'Taylor, Tom-PT [SKY:B318-I:EXCH]'" , "'TIPHON_WG6@LIST.ETSI.FR'" , "'TIPHON_WG2@LIST.ETSI.FR'" , "'TIPHON_WG5@LIST.ETSI.FR'" Subject: QUESTION 21/15 - Transport Network Equipment for Interconnecting GSTN and IP Networks References: <87830212CCB1D011881300A0245175F5558F34@VANTS02> Content-Type: multipart/mixed; boundary="------------57048CFAB4E7B2538FFE673D" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------57048CFAB4E7B2538FFE673D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In the section of Relationship of Q 21/15, we should put TIA which defines TDMA and CDMA standard. Binshi Cao. Jerry Skene wrote: > > Notice of Meeting and Call for Contributions on new ITU question on > Internet Gateway Equipment > > In October, the Telecommunications Standardization Bureau of the > International Telecommunications Union, (ITU-T) Study Group 15 > (Transport Networks, Systems and Equipment)approved a new Question > dealing with interconnection equipment between the GSTN and IP Networks. > The first meeting of this new Question (Q21/15)will be held in > conjunction with the Study Group 15/Working Party 2 interim meeting on > 16 - 19 February, 1999. > > ITU members can find the full text of the question on the ITU Informal > FTP Area, at: > http://ftp.itu.int/u/tsg15/sg15/wp2/q21/q21_index.htm > Note that this site is password protected, and is accessible to ITU > members only. > > Non-ITU members can find the text of the Question at: > http://www.coherent.com/itu > > This message is a call for contributions on this important new work. The > goal of > the February meeting is to establish working methods for the Question, > the baseline structure for the Recommendation, a timetable for > completion of the work, and to begin > drafting text. > > The Recommendation being developed in this Question will be of interest > to the following parties: > - GSTN telephony carriers interfacing or planning to interface their > networks to the Internet > - Internet Service Providers carrying or planning to carry telephony > traffic originating or terminating on the GSTN > - Network equipment vendors providing or developing Internet > Telephony interface equipment > > Meeting Registration > ITU and interested non-ITU members may attend this meeting. Details on > registration for the interim meeting may be obtained from the host, Tom > Oshidari [toshidari@ditechcorp.com]. The venue for the meeting is the > Sheraton on Fisherman's Wharf, San Francisco. The meeting will be one > day long, and will be held during the week of February 15-19. The > specific day will be known by January 15. > > Contributions > If you plan to attend this meeting, please let the Rapporteur, Mr. Jerry > Skene and the host, Mr. Oshidari know. If you plan to submit a > contribution on this topic, please email it to the Rapporteur, and it > will be included in the discussion. > > If you are a non ITU member, you are most welcome to attend and to > submit contributions. Please contact the rapporteur for guidance on > this. > > To ensure proper consideration of a contribution, the title of the > contribution must be received by the rapporteur no later than January 8, > 1999. > > Sincerely; > > Jerry Skene Rapporteur, Q21/15 > > _________________________________________________ > Jerry Skene | Tellabs, Inc. > Director, | 45085 University Drive > International Standards | Ashburn, VA 20147.2745 USA > tel:+1 703 724-7302 | URL: www.tellabs.com > fax: +1 703 724-7202 | email: jerry.skene@tellabs.com > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------------57048CFAB4E7B2538FFE673D Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Binshi Cao Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Binshi Cao n: Cao;Binshi org: jk12eaj00 adr: Room 2C-122, Lucent Technologies;;600, Mountain Av.;Murray Hill;NJ;07974;USA email;internet: bcao@lucent.com title: Member of Technical Staff tel;work: (908) 582 5824 tel;fax: (908) 582 6729 tel;home: (908) 541 9774 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------57048CFAB4E7B2538FFE673D-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 7 16:50:36 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA12537 for ; Thu, 7 Jan 1999 16:50:36 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id MAA27121 for iptel-outgoing; Thu, 7 Jan 1999 12:45:23 -0500 (EST) From: "Dean Willis" To: "Jonathan Rosenberg" Cc: "Conference Control List" , "list iptel" Subject: RE: Capability-based routing in SIP Date: Thu, 7 Jan 1999 11:13:39 -0600 Message-ID: <000e01be3a61$11a1aec0$67e323a6@dwillispc3.mcit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <369453D4.204B6D44@dnrc.bell-labs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Jonathan Rosenberg wrote > Dean Willis wrote: > > Am I missing something obvious here, or do we really need a richer > > capability description and handling mechanism to handle > these scenarios? . . . > requirement as input for the language (CPL): > > > > > > > > > > > > > You would then upload the CPL to the server in the REGISTER message. A very thought provoking suggestion, Jonathan. Adding the media type to the CPL certainly enables user-controlled media routing and sounds like a reasonable way to handle it. Of course, my server developer friends here don't like the idea of having to interpret code to route a call -- they think in fairly large scales -- but the basic idea is sound. They have decided that parsing the SDP is probably required and are willing to think about it. However, uploading the CPL in the REGISTER doesn't sound reasonable -- that would seem to require every dynamic device to know enough of the state of other dynamic devices to be able to construct a full CPL. This is clearly intractable in larger scenarios. We rather envision the ULS call routing setup being managed from a user interface -- Web and/or IVR, and letting SIP endpoints have a more "incremental" impact on routing. It might be more effective to have the CPL (or other mechanism) direct the sessions to a "class" of endpoints based on capability, perhaps with some sort of priority weighting within the class (q?). Then an endpoint would simply need to include enough information in a REGISTER that the ULS could add the endpoint to the correct class with an appropriate priority. One could build the class as a priority-ordered list of URIs, which would be useful for both sequential redirects and forking proxies. I believe one could implement the scenarios I had in mind with this sort of arrangement. The trick, though, becomes defining the set of classes, and specifying the REGISTER mechanism for class membership. I think I wish I could do it all in the Contact header of the REGISTER. Perhaps there is some meat to Dan Wing's suggestion that the CONNEG WG's work will help here -- guess I need to go read it ;-). On a related note -- I'm thinking that some of this behaviour collides with the current draft (sec 4.2.6), which states that the REGISTERS's URI is compared to existing registrations, and replaces equivalent current registrations subject to values of q and ttl. Oddly enough, the behavior for a REGISTER of equivalent URI with matching q and ttl seems undefined. The real problem here is that a registration for class FAX would collide with (and replace) a registration for class VOICE if the q and ttls matched . . . -- Dean --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 8 00:52:00 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01473 for ; Fri, 8 Jan 1999 00:51:57 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id UAA27539 for iptel-outgoing; Thu, 7 Jan 1999 20:21:15 -0500 (EST) Message-ID: <36955D6C.82296999@cs.columbia.edu> Date: Thu, 07 Jan 1999 20:20:44 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , Conference Control List , list iptel Subject: Re: Capability-based routing in SIP References: <001701be39c3$e0d1bbc0$67e323a6@dwillispc3.mcit.com> <369453D4.204B6D44@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Jonathan Rosenberg wrote: > > > You would then upload the CPL to the server in the REGISTER message. Or it would be generated automatically by the cgi script or servlet running on the customer configuration web server. It remains to be discussed whether CPL scripts can be generated incrementally, so that one could just upload a "media subroutine". -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 8 07:15:53 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA10257 for ; Fri, 8 Jan 1999 07:15:53 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id CAA29027 for iptel-outgoing; Fri, 8 Jan 1999 02:09:56 -0500 (EST) Message-ID: <3695AEE0.65145616@dnrc.bell-labs.com> Date: Fri, 08 Jan 1999 02:08:16 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Dean Willis CC: Conference Control List , list iptel Subject: Re: Capability-based routing in SIP References: <000e01be3a61$11a1aec0$67e323a6@dwillispc3.mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Dean Willis wrote: > > Adding the media type to the CPL certainly enables user-controlled media > routing and sounds like a reasonable way to handle it. Of course, my > server developer friends here don't like the idea of having to interpret > code to route a call -- they think in fairly large scales -- but the > basic idea is sound. They have decided that parsing the SDP is probably > required and are willing to think about it. You don't neccesarily need to interpret the code to route the call. Thats an implementation decision. An optimizied implementation might "compile" it in some fashion or otherwise store it locally in a more optimized form. There are ways to even push the CPL processing into separate boxes from the SIP processing and proxying box. iptel is not going to standardize such interfaces right now, but its not such a stretch to see how SIP CGI or even an IN call-model/INAP solution could work there. > > However, uploading the CPL in the REGISTER doesn't sound reasonable -- > that would seem to require every dynamic device to know enough of the > state of other dynamic devices to be able to construct a full CPL. This > is clearly intractable in larger scenarios. I have been thinking about this also, in fact, and came to the same conclusion. The fundamental problem is that the SIP REGISTER message, as currently specified, is a *terminal* registration function (i.e., it specifies call routing state for just a terminal), while the CPL specifies a *user* registration function, potentially encapsulating many terminals. I came up with several scenarios where the wrong thing happens, forgetting even the scaling and communications issues: I'm at home, and upload a CPL in a REGISTER that says to try me at home then work. I then go to work, and leave the PC at home on. At work, I send a CPL which says try me at work then home. Now, since REGISTER's are retransmitted periodically (before they expire), the call routing logic will oscillate between home-then-work and work-then-home as my home and work PC's both continue to refresh the registration. This begs an important question - should a CPL be "soft-state" and eventually expire? A SIP REGISTER certainly should; a terminal may be turned off and thus no longer be available. But, the CPL isn't really representing a terminal, they are my preferences. The expiration of these preferences doesn't really seem tied to terminal on/off status. They may expire since the service provider may want to flush out really old stuff. But, the timescales here seem very different - weeks probably for a CPL timeout, if it times out at all. > > We rather envision the ULS call routing setup being managed from a user > interface -- Web and/or IVR, and letting SIP endpoints have a more > "incremental" impact on routing. As Henning pointed out, the web/IVR could then generate the CPL and then send it. The advantage of using the CPL in the back-end is that it provides a consistent interface for the call routing logic. Whether the logic is generated by a web form, IVR system, or written by a user, its all the same. It also supports cross-vendor compatibility for these services. > > It might be more effective to have the CPL (or other mechanism) direct > the sessions to a "class" of endpoints based on capability, perhaps with > some sort of priority weighting within the class (q?). Then an endpoint > would simply need to include enough information in a REGISTER that the > ULS could add the endpoint to the correct class with an appropriate > priority. One could build the class as a priority-ordered list of URIs, > which would be useful for both sequential redirects and forking proxies. I think what you mean is something like this: Then, a SIP REGISTER from my home PC would effectively bind the "class" home to the URL in the COntact of the register. Is that what you mean? > > I believe one could implement the scenarios I had in mind with this sort > of arrangement. > > The trick, though, becomes defining the set of classes, and specifying > the REGISTER mechanism for class membership. I think I wish I could do > it all in the Contact header of the REGISTER. Perhaps there is some meat > to Dan Wing's suggestion that the CONNEG WG's work will help here -- > guess I need to go read it ;-). Hmm. Your suggestion is a neat idea, but it changes the way REGISTER works. I don't think you need to do it quite this way. How about this: 1. The CPL is like it is now, and forwards to URI's (like sip:jdrosen@bell-labs.com). 2. When a server decides to forward a call to sip:jdrosen@bell-labs.com, it can either (1) attempt to look up the domain name and locate a server there, or (2) try to translate sip:jdrosen@bell-labs.com using information learned from REGISTER's or any other locator service (really REGISTER is a way of building up a location service DB). THe CPL could specify which. I think this solves your problem. An example will help. My CPL is: This could be uploaded in a REGISTER, but the semantics of it (in terms of updating Contact headers, etc) would be different due to the presence of the body. What this says is that when its Monday, I proxy the call to sip:jdrosen@home.bell-labs.com, but before I do, I try to translate this URL using the REGISTER locator service. Now, I'll need to configure my PC at home to send a SIP REGISTER message that looks like: REGISTER sip:bell-labs.com SIP/2.0 To: sip:jdrosen@home.bell-labs.com From: sip:jdrosen@bell-labs.com Contact: sip:jdrosen@home-pc.dnrc.bell-labs.com So, the REGISTER message binds the URL sip:jdrosen@home.bell-labs.com to the current address of my home PC. Basically, instead of defining new classes, we use different SIP addresses as different classes. No solution is perfect; this one might be harder to configure and be less intuitive. Also, it sort of distorts the meaning of the SIP URI in a way that makes me a bit queasy (home.bell-labs.com is a completely invalid domain name and only exists as an intermediate address) But, it maintains the current REGISTER semantics since they are what they are. I'm open to other suggestions, of course. These issues are critical for the CPL framework document, since that will need to discuss transport/interaction issues and its interaction with signaling protocols like SIP and H.323. > > On a related note -- I'm thinking that some of this behaviour collides > with the current draft (sec 4.2.6), which states that the REGISTERS's > URI is compared to existing registrations, and replaces equivalent > current registrations subject to values of q and ttl. Oddly enough, the > behavior for a REGISTER of equivalent URI with matching q and ttl seems > undefined. The real problem here is that a registration for class FAX > would collide with (and replace) a registration for class VOICE if the q > and ttls matched . . . You won't have this problem with my solution above since the URL's look different. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 8 22:07:11 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA22388 for ; Fri, 8 Jan 1999 22:07:10 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id SAA29468 for iptel-outgoing; Fri, 8 Jan 1999 18:07:52 -0500 (EST) Message-ID: <36968FBB.8E0AE581@cs.columbia.edu> Date: Fri, 08 Jan 1999 18:07:39 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , Conference Control List , list iptel Subject: Re: Capability-based routing in SIP References: <000e01be3a61$11a1aec0$67e323a6@dwillispc3.mcit.com> <3695AEE0.65145616@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This raises, I believe, a possible requirement/feature for the CPL: It should be possible to proxy calls based on the current list of registrations matching a certain feature. The call control spec, for example, defines the 'class' and 'media' tags for describing SIP locations. Thus, a request like 'proxy class=business' would proxy an incoming call to all registrations that are registered under that class. Same for the media type; this would avoid parsing the SDP and be more uniform. Note that the feature negotiation work (see recent IETF last call) may be applicable here, as the simple model above can't really express things like: 'proxy to all my registrations that are of class business and support video or audio' Note that this is different from conditioning actions on the call itself, as currently described. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Wed Jan 13 21:26:51 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA23329 for ; Wed, 13 Jan 1999 21:26:51 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA11199 for iptel-outgoing; Wed, 13 Jan 1999 16:15:21 -0500 (EST) From: Jiri Kuthan Message-Id: <199901132112.WAA23068@jobe.fokus.gmd.de> Subject: A new website on the Internet telephony To: iptel@lists.research.bell-labs.com, confctrl@isi.edu, pint@lists.research.bell-labs.com, sigtran@BayNetworks.COM, megaco@BayNetworks.COM, TIPHON@list.etsi.fr Date: Wed, 13 Jan 1999 22:12:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello, let me announce a new website which concentrates on the Internet telephony. The goal of the web-site is to document the current state of art and to collect links to useful resources on the Internet telephony. Links to standardization bodies, products, research contributions, tutorials and other relevant web sites are provided. Selected drafts and standards are mirrored. The address is http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ Comments and tips are solicited. Jiri -- Jiri Kuthan Phone: ++49 / (0)30 / 3463 - 7 271 GMD FOKUS Fax : ++49 / (0)30 / 3463 - 8 271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sun Jan 17 15:12:48 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03604 for ; Sun, 17 Jan 1999 15:12:48 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id KAA18332 for iptel-outgoing; Sun, 17 Jan 1999 10:45:11 -0500 (EST) Content-return: allowed Date: Thu, 14 Jan 1999 14:22:22 +0000 From: "Hardie, Paul" Subject: G.726 codec availability To: "'iptel@lists.research.bell-labs.com'" Message-id: <35FD99E42C68D211AA0100A0C99583ED096F0D@BEEX03.sgcs.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-type: text/plain Content-transfer-encoding: 7BIT Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, Does anyone know where I might find a G.726 (16-kbit) ACM codec to run on a Pentium? Thanks. ____________________________________________ Paul Hardie Siemens Communications Limited Nottingham UK tel: +44 115 943 2494 fax: +44 115 943 4969 mailto:paul.hardie@siemenscomms.co.uk --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Mon Jan 18 02:44:58 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA14836 for ; Mon, 18 Jan 1999 02:44:58 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id WAA19106 for iptel-outgoing; Sun, 17 Jan 1999 22:13:13 -0500 (EST) From: "Mark Hewitt" To: Subject: New Telephony Web Site Date: Sun, 17 Jan 1999 22:12:10 -0500 Message-ID: <000001be4290$5684cc20$de085292@mark> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk New non-commercial Telephony and Multi Media Web site. http://www.telephony.net Mark Hewitt mark@hewitt.net "A man is literally what he thinks." (James Allen) --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Mon Jan 18 16:19:49 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25668 for ; Mon, 18 Jan 1999 16:19:33 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id JAA20708 for iptel-outgoing; Mon, 18 Jan 1999 09:23:14 -0500 (EST) Message-ID: <36A346B2.EBBEF8A3@usa.net> Date: Mon, 18 Jan 1999 20:05:32 +0530 From: Avikal Jain X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: IPtel Mailing List Subject: H.323 Security Hazards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi all, I am studying the security issues related to H.323 proxy. I need to find out more about the security issues posed by a H.323 proxy. I believe that the H.323 proxies such as those developed by TIS, Checkpoint and Cisco, although permitting H.323 traffic, are not considered very secure. What are the possible security hazards one must be aware of? Thanks. Avikal Jain Center for Development of Advanced Computing, Pune 411007, India. e-mail: avikal@usa.net --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Mon Jan 18 16:23:47 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25727 for ; Mon, 18 Jan 1999 16:23:45 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id IAA20676 for iptel-outgoing; Mon, 18 Jan 1999 08:23:25 -0500 (EST) Message-ID: <002101be42e2$2c528440$b5454a0a@xmzhao> From: "xmzhao" To: Subject: CPL based logic or IN service logic? Date: Mon, 18 Jan 1999 20:57:57 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01BE4325.39F8A500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BE4325.39F8A500 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I'm doing research on deploying Intelligent Services on IP telephony = systems as my doctorate's subject.=20 After reading former messages, I feel that the goal of Call = Processing Language is to provide the same capabilities to IP telephony = users just as traditional Intelligent Network does to PSTN users. Is = that true? If it is, since IN systems are much more sophisticated and = are wildly deployed today, why don't we just connect the IP telephony = systems with IN SCPs to access traditional IN services? Is building = service logics based on a brand-new CPL necessary? Thank you! Xiaoming Zhao. xmzhao@990.net Institute of Communications Engineering.=20 P.R. of China. ------=_NextPart_000_001E_01BE4325.39F8A500 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    I'm doing = research on=20 deploying Intelligent Services on IP telephony systems as my doctorate's = subject.
    After reading = former=20 messages, I feel that the goal of Call Processing Language is to provide = the=20 same capabilities to IP telephony users just as traditional Intelligent = Network=20 does to PSTN users. Is that true? If it is, since IN systems are much = more=20 sophisticated and are wildly deployed today, why don't we just connect = the IP=20 telephony systems with IN SCPs to access traditional IN services? Is = building=20 service logics based on a brand-new CPL necessary?
    Thank = you!
 
Xiaoming Zhao.
xmzhao@990.net
Institute of Communications = Engineering.=20
P.R. of = China.
------=_NextPart_000_001E_01BE4325.39F8A500-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Tue Jan 19 00:58:27 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA02020 for ; Tue, 19 Jan 1999 00:58:26 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id UAA21189 for iptel-outgoing; Mon, 18 Jan 1999 20:35:25 -0500 (EST) Message-ID: <36A3E116.20019265@dnrc.bell-labs.com> Date: Mon, 18 Jan 1999 20:34:14 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: xmzhao CC: iptel@lists.research.bell-labs.com Subject: Re: CPL based logic or IN service logic? References: <002101be42e2$2c528440$b5454a0a@xmzhao> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Xiaoming, You ask a good and important question. While the CPL provides services similar in style to the IN CS1 services, there are some significant differences. Most notably, the CPL is for *Internet* telephony services, and so concepts like URLs, IP addresses, and email are foreign to IN, as they are Internet specific. However, these form an integral part of the services provided by the CPL, which will allow things like redirection to email or proxying to SIP or H.323 URL's. Secondly, the goal of the CPL is to expose these services to end users in a platform independent, secure fashion. The fact that the services are defined by end users puts constraints on the solution. This is not to say that there is no value in connecting traditional IN systems to the Internet for services; quite the contrary. I think doing so is very useful, and will eventually become one of many solutions for service creation and programming of IP telephony services. There's lots of work to do before we can just "connect" them, though. -Jonathan R. > xmzhao wrote: > > I'm doing research on deploying Intelligent Services on IP > telephony systems as my doctorate's subject. > After reading former messages, I feel that the goal of Call > Processing Language is to provide the same capabilities to IP > telephony users just as traditional Intelligent Network does to PSTN > users. Is that true? If it is, since IN systems are much more > sophisticated and are wildly deployed today, why don't we just connect > the IP telephony systems with IN SCPs to access traditional IN > services? Is building service logics based on a brand-new CPL > necessary? > Thank you! > > Xiaoming Zhao. > xmzhao@990.net > Institute of Communications Engineering. > P.R. of China. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Tue Jan 19 13:04:21 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA19213 for ; Tue, 19 Jan 1999 13:04:20 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id IAA22848 for iptel-outgoing; Tue, 19 Jan 1999 08:25:16 -0500 (EST) Date: Tue, 19 Jan 1999 21:20:47 +0800 (CST) From: Wan-jiun Liao To: iptel@lists.research.bell-labs.com Subject: some questions on Internet telephony Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, I have some questions on Internet telephony. Is there someone kindly to help me on them or direct me to some references? Thanks a lot. My questions are: 1. where I can find IMTC VOIP documents? 2. where I can find TIPHON documents? 3. what is TPKP? 4. whta is AC2000? 5. What are IPDC and SGCP? 6 .Is there any competitor for H.323? 7. Does any one concern VoIP/VPN? Thanks again Regards, Wanjiun Liao National Taiwan University Taipei, Taiwan --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Tue Jan 19 13:25:49 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA20679 for ; Tue, 19 Jan 1999 13:25:48 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id IAA22875 for iptel-outgoing; Tue, 19 Jan 1999 08:55:16 -0500 (EST) From: "Henry Sinnreich" To: "Wan-jiun Liao" , Subject: RE: some questions on Internet telephony Date: Tue, 19 Jan 1999 07:51:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > 6 .Is there any competitor for H.323? Please see: http://www.cs.columbia.edu/~hgs/sip/ and http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ Thanks, Henry Henry Sinnreich MCI WorldCom 1489/041 400 International Parkway Richardson, Texas 75081 > 7. Does any one concern VoIP/VPN? > > Thanks again > > Regards, > > Wanjiun Liao > > National Taiwan University > Taipei, Taiwan > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Tue Jan 19 17:35:27 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01299 for ; Tue, 19 Jan 1999 17:35:26 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id NAA23097 for iptel-outgoing; Tue, 19 Jan 1999 13:31:33 -0500 (EST) Message-ID: <36A4CEEB.43873EFF@dnrc.bell-labs.com> Date: Tue, 19 Jan 1999 13:28:59 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Aishling CC: iptel@lists.research.bell-labs.com Subject: Re: SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This question is best handled by the mmusic group, the mailing list is confctrl@isi.edu. In any case, the answer to your question is that proxy and redirect servers are optional. Two user agents can directly communicate with SIP. -Jonathan R. Aishling wrote: > > Hi > > I'm studying Internet Telephony for a final year project, and I was > wondering if it is necessary to have a proxy or redirect server. Can an > application be SIP complient if it does not have a proxy or redirect > server. > > Thanks > Aishling > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Tue Jan 19 17:43:16 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01534 for ; Tue, 19 Jan 1999 17:43:16 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id MAA23053 for iptel-outgoing; Tue, 19 Jan 1999 12:55:27 -0500 (EST) Date: Tue, 19 Jan 1999 17:54:06 +0000 (GMT) From: Aishling To: iptel@lists.research.bell-labs.com Subject: SIP In-Reply-To: <000001be4290$5684cc20$de085292@mark> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi I'm studying Internet Telephony for a final year project, and I was wondering if it is necessary to have a proxy or redirect server. Can an application be SIP complient if it does not have a proxy or redirect server. Thanks Aishling --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Tue Jan 19 20:24:34 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA03405 for ; Tue, 19 Jan 1999 20:24:33 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id PAA23190 for iptel-outgoing; Tue, 19 Jan 1999 15:50:50 -0500 (EST) Message-Id: <3.0.5.32.19990119154107.008b5eb0@hotair.hobl.lucent.com> X-Sender: louise@hotair.hobl.lucent.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 19 Jan 1999 15:41:07 -0500 To: Wan-jiun Liao From: "Louise F. A. Spergel" Subject: Re: some questions on Internet telephony Cc: iptel@lists.research.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 09:20 PM 1/19/99 +0800, Wan-jiun Liao wrote: >Hi, > > I have some questions on Internet telephony. Is there someone kindly >to help me on them or direct me to some references? Thanks a lot. My >questions are: > >1. where I can find IMTC VOIP documents? >2. where I can find TIPHON documents? http://www.etsi.org/tiphon and http://docbox.etsi.org/tech-org/tiphon/Document/tiphon Louise >3. what is TPKP? >4. whta is AC2000? >5. What are IPDC and SGCP? >6 .Is there any competitor for H.323? >7. Does any one concern VoIP/VPN? > > Thanks again > >Regards, > >Wanjiun Liao > >National Taiwan University >Taipei, Taiwan >--------- >This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Wed Jan 20 00:18:47 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07720 for ; Wed, 20 Jan 1999 00:18:47 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id TAA23377 for iptel-outgoing; Tue, 19 Jan 1999 19:55:20 -0500 (EST) From: Hanlin_Fang@3com.com X-Lotus-FromDomain: 3COM To: Jonathan Rosenberg cc: Aishling , iptel@lists.research.bell-labs.com Message-ID: <882566FF.000481D5.00@hqoutbound.ops.3com.com> Date: Tue, 19 Jan 1999 16:54:17 -0800 Subject: Re: SIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk My question is that: if you don't use proxy server in SIP, how can you get control and management capability comparing with H.323 gatekeeper system? If you use proxy server model, is there any significant difference between H.323 and SIP? Thanks for any comments! Hanlin --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Wed Jan 20 15:36:15 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25689 for ; Wed, 20 Jan 1999 15:36:15 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id JAA25104 for iptel-outgoing; Wed, 20 Jan 1999 09:55:22 -0500 (EST) Message-ID: From: "Nancy-M Greene" To: Wan-jiun Liao Cc: iptel@lists.research.bell-labs.com Subject: RE: some questions on Internet telephony Date: Wed, 20 Jan 1999 09:52:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > At 09:20 PM 1/19/99 +0800, Wan-jiun Liao wrote: > >Hi, > > > > I have some questions on Internet telephony. Is there someone kindly > >to help me on them or direct me to some references? Thanks a lot. My > >questions are: > > > >1. where I can find IMTC VOIP documents? > >2. where I can find TIPHON documents? > >3. what is TPKP? > >4. whta is AC2000? > >5. What are IPDC and SGCP? IPDC and SGCP were device control proposals that led to the creation of a new IETF WG called Media Gateway Control (megaco). The mailing list for this WG is megaco@baynetworks.com, and to join you send a msg to majordomo@baynetworks.com with subscribe megaco in the message body. > >6 .Is there any competitor for H.323? > >7. Does any one concern VoIP/VPN? > > > > Thanks again > > > >Regards, > > > >Wanjiun Liao > > > >National Taiwan University > >Taipei, Taiwan > >--------- > >This message came from the IETF IPTEL Working Group Mailing List. > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Wed Jan 20 21:43:55 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA00129 for ; Wed, 20 Jan 1999 21:43:55 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA25536 for iptel-outgoing; Wed, 20 Jan 1999 16:51:20 -0500 (EST) Message-Id: <3.0.3.32.19990121084934.01314158@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 21 Jan 1999 08:49:34 +1100 To: "GÂran AP Eriksson" , From: Douglas Clowes Subject: RE: about Inter-gatekeeper operation In-Reply-To: <000b01bdee1a$1ea62fd0$b162d693@rcur98nbn145.ericsson.se> References: <3.0.3.32.19980928092209.00e56b70@mail.ozemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by fep9.mail.ozemail.net id IAA01098 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by paperless.dnrc.bell-labs.com id QAA25530 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Göran, What am I doing in mail so old, .... someone else referred me to it. anyway, you had questions: At 17:34 02/10/98 +0200, Göran AP Eriksson wrote: > >Hi Douglas, cc: others. > >You wrote: > >Indeed, the Location Server Client Access Protocol should be encapsulated >wrt how a Location Server does its job - i.e. whether it *has* the required >information, has to go and get it, ior just invents it as it goes along. It >should be independent, as far as possible, from whether the client is a PC, >black IP phone, gateway or gatekeeper (although SIP/H.323 independence >might be more of a problem). > >To put it differently, I see the Location Server being co-resident with a >Back-End-Server that (logically) provides other services, such as >authentication, authorisation, usage-recording and call-accounting. Your >view may differ. > > >Allowing for a situation in which the Location Server is not co-located with >the gate keeper seems appropriate. Location Management can be many things, >and solved in many ways. One should allow for that. > >However, what's your view on the need to secure the communication between >the LM and the Gk? That depends very much on what you put in the protocol. The location translation may well be regarded as commercial property, and must be paid for. That may be a reason for some to secure it. Then there is the privacy issue. Some people are sensitive to others knowing who they called, and when, and how long, etc.. Some are sensitive to others knowing when they were called, or when their number was looked up. I think it needs to be secure. >Also, about the Back- End server; You mention that it may have several >services, such >as location management, AAA, etc? I assume that this implies different >protocols as >well, one for each service? This issue has come up a number of times, and some people feel strongly either way. There are those who say "maximum use of existing protocols" and, since there are protocols that can be used for various functions, advocate using a lot of different protocols. Others are sensitive to things such as call setup time, number of round trips, etc.. These people advocate a special "purpose built" protocol. Who's right? It depends who you ask. And, even then, you can get conflicting answers from the same individual. >Regards, > >G AP Eriksson >Ericsson Radio > > Regards, Douglas --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 01:43:38 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA04237 for ; Thu, 21 Jan 1999 01:43:38 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id VAA25694 for iptel-outgoing; Wed, 20 Jan 1999 21:01:15 -0500 (EST) Reply-To: From: "Christian J. van den Branden Lambrecht" To: "Christian J. van den Branden Lambrecht" Subject: Session on Internet Telephony at the '99 SPIE Intl Symposium on Voice, Video, and Data Communications Date: Wed, 20 Jan 1999 17:59:29 -0800 Message-ID: <000d01be44e1$ae898110$a358040f@hplvdb.hpl.hp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01BE449E.A0557830" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MS-TNEF-Correlator: 00000000ED3442077888D11197E20060B08672E0A4796200 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BE449E.A0557830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SPIE's International Symposium on Voice, Video, and Data Communications Conference on Multimedia Systems and Applications II (vv06) Session on Standards and Systems for Internet Telephony Dear Colleagues, We are organizing a session to be held within the conference on Multimedia Systems and Applications II of the SPIE's International Symposium on Voice, Video, and Data Communications. The session is intended to gather topical papers discussing Internet Telephony systems and standards. The session is meant to be tutorial and discuss all the aspects of internet telephony systems, including but not limited to: - H.323 protocol stack, - IETF standards for internet telephony, - Network management for internet telephony, - Signaling, - Audio compression, - Gateways/Gatekeepers, - Quality of Service management, - Interoperability. We are seeking to bring together researchers and practitioners and we are looking for review or tutorial papers as well as contributions describing original work. We are now soliciting contributions for this particular session. The timetable is as follows: Abstract due date: February 22, 1999 Abstract due date for on-site proceedings: February 8, 1999 Manuscript due date: August 23, 1999 Manuscript due date for on-site proceedings: June 28, 1999 The conference will be held in Boston, MA, September 19-22, 1999 at the Hynes Convention Center. Further information, call for papers, etc. can be found at http://www.spie.org/info/vv/. Further information for this session can be obtained by email to vdb@hpl.hp.com. Please feel free to forward this announcement to any interested person. ============================================================= Christian J. van den Branden Lambrecht Voice: 650-857-7658 Hewlett-Packard Laboratories Fax: 650-857-4691 1501 Page Mill Road, MS 1U20 Email: vdb@hpl.hp.com Palo Alto, CA 94304 vdb@ieee.org ============================================================= ------=_NextPart_000_000A_01BE449E.A0557830 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ih0BAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAAM8HAQAUABEAOwAAAAMAOgEB A5AGAFgKAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAZgAAAFNlc3Npb24gb24gSW50ZXJuZXQgVGVsZXBob255IGF0IHRoZSAnOTkgU1BJRSBJbnRs IFN5bXBvc2l1bSBvbiBWb2ljZSwgVmlkZW8sIGFuZCBEYXRhIENvbW11bmljYXRpb25zAAAAAgFx AAEAAAAWAAAAAb5E4a2PuDPHUrDSEdKYigBgsIZy4AAAAgEdDAEAAAAUAAAAU01UUDpWREJASFBM LkhQLkNPTQALAAEOAAAAAEAABg4ACq+c4US+AQIBCg4BAAAAGAAAAAAAAADtNEIHeIjREZfiAGCw hnLgwoAAAAsAHw4BAAAAAwAGEOvSyYgDAAcQdAYAAB4ACBABAAAAZQAAAFNQSUVTSU5URVJOQVRJ T05BTFNZTVBPU0lVTU9OVk9JQ0UsVklERU8sQU5EREFUQUNPTU1VTklDQVRJT05TQ09ORkVSRU5D RU9OTVVMVElNRURJQVNZU1RFTVNBTkRBUFBMSUMAAAAAAgEJEAEAAACiBQAAngUAAA0KAABMWkZ1 2fkvkQMACgByY3BnMTI1FjIA+Atgbg4QMDMz6QFVMzYB6CACpANjAgCIcHJxDlBmY2gKwOBzZXQw IAdtAoMAUP8EVRFzE8ER9whVB7ICgxHBbwPjEdkHEwKAfQqACMggqjsJbzAY72UOMDUCgFkKgXVj AFALA2MAQXU0bG4CIGULpgYAUEk0RScEIEkCMASRYXSeaQIgB0AGAAbAcG8AkDh1bSACIAqiCoBW b0EN4GUsIFZpAQBvoyAwAHBkIEQeQGEVUehtbXUDAGMeQxbQH5PzH4QIUG5mBJAJ8CAQH1FvBdAc gB5QB4BkBzAesXPNHgBtBCAgwkFwC1AhtgEd0EkgKHZ2MDa+KSI6BmAEEB5hI5JTAZD/INALESTk JIYCEAXAHeQSQEEScGVsZXBoAiB5WSI6RGUKwQhQbCpgYdJnClBzLCI6VyOACsBJI4FyZwBwaXoL gGcNILAgEjAnhHRvIGKdI4BoKlAg4APwdGgLgHsvAC9wIAWgIx8kLyU/b/5mMCMdfx6OIEAf/yEP AID+LhJwMEEulgQAOXA0sTdAvwmALwIt4DAxBcAvEHAhsXsDIAqwcASQBCAxwATwdfcngS5BKb95 LoAyGTIgKDWfOK8HgABwBUAvFHR1LxA/ByI3IzvVNyAsADAjYXP5O4BjdAQgM8E5sinzNMB3PT02 oAuAYwpAMcAuQWLdQOAgHKAFQCVwbS/QOhMCOh+ELSBILjMyPjM7UANgLxAI4T5iY2vnLIVHQDRQ VEY+aCljQ1+meUinB8B0dwWwa0AAfwBwLDAyQAnwBUBKL0s8U9xpZx6BLjFIp0FFUS8g3wWgHuAZ ACeDSKdHNQAH0OphMhAvUfJrCeA7gkindFF1T3F0PZAzwQZhdv82cUyJSKg0sjrwBJABoAMQ/VQB LiyfOOJSsC4yLxIFEP9Ys0zQOpNQ8SuhEfA7kjcy3xGQANA1EDUSWoZ3LWQJAP5vWJMpchkAVKAH 0QWxQNe/O2VCoFwRQjFe8TBxdAUQf0WxJcMBAATyVsAuQUEBZ38LgB6RTEI/AC1VHKAH4HP/BvAN 4FtRLkFfrClyL+EEIP8KsTUQPAALYAXALpU/BDGCfwGRKmA5cl7xAhAsAGKgc/NG1R+EQWIyIFsS O8AKUB87wFIBRtAMk2n4IEZlS1kQU9ByPZAyMjagMb45a8BoX2lkKWMCIC0AkH9tQUfBNoAxsQ8g Z9Fqbzj9a5pNAHA8EAUEaU9u91BQ9yxAMiBrYDNwL3E8bW9uf/ZKIZAxADJwGx+EOMIwee8D8EIx L0YwAUIfAC8QUVD9BdBBNqAGYAUwMkAvQAXAPWuwLWt2NyBAUTBBSHm3HMAEICLxdk0BJ6JDTQH7 BJBXK0YIcDqTC4ApcQDA/zUSNqA7IQMgKXI7ZDagEkD+Yz8AIcADoC9BAhAhkDdQP31xHDEOUByA L2ACQHA6aC8vd4TALkKwCJAuVS3BL4CiLyZQLxw5ID8/AIAvMSFkZy6WgtVvYvcBkAuAOhFiPZAy QAtwQkFBLyB2ZGJAaAtQLu2LQC5QsVcrUCwREjApYP8J4IGhCdEvAilxUjALIGSU/wBwHKAhkDaA TPMvEQBwPZD/TYMHkEZyO4Jl8SI1AEEiSb49kn+Tj5SflTcilWgFENcyIAcwA6BKPwB2A5EBAM97 MVagOfEDoExhBtAZAAcR8AVANkQ6IDY1MEAtODU3LTeZkDidH4RIB9AqYAJALVBIcX+OMphwBuBW oEDyB5Gce0ZEYXiZeDQ2OZGlMfmZoDEgmzBM0AXQemIIAMxhZHuxBfAxVR1BnHl+RYqCmXCLDIxV B0AvIEEDMXA3AUNBIDk0M/wwNJx8nHyLAgiQCeCFQv+SH6evqL+VT5E1C8OaRRvmXwLRFmIMAR+T GAEArcAAAAMAEBAAAAAAAwAREAAAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA AoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA APATAAAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA4LjUAAwAmgAggBgAAAAAA wAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAI IAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA AAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAA AAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAA AQAAAAAAAAALAMaACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsAyIALIAYAAAAAAMAAAAAA AABGAAAAAAWIAAAAAAAACwDqgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAPCACCAGAAAA AADAAAAAAAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAO00Qgd4iNERl+IAYLCGcuACAfoPAQAA ABAAAADtNEIHeIjREZfiAGCwhnLgAgH7DwEAAABaAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBT VFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcdXNlcnNcdmRiXG91dGxvb2tcbWFp bGJveC5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBFRDM0NDIwNzc4 ODhEMTExOTdFMjAwNjBCMDg2NzJFMEE0Nzk2MjAwAAAAACup ------=_NextPart_000_000A_01BE449E.A0557830-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 19:50:23 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03882 for ; Thu, 21 Jan 1999 19:50:23 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id OAA27623 for iptel-outgoing; Thu, 21 Jan 1999 14:53:13 -0500 (EST) Date: Thu, 21 Jan 1999 11:51:02 -0800 (PST) From: Sujatha Balaraman To: Jonathan Rosenberg cc: xmzhao , iptel@lists.research.bell-labs.com Subject: IP Telphony Gateway Pricing In-Reply-To: <36A3E116.20019265@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, I"m trying to formulate a pricing model for the Telephony Gateway based on QOS offered. I am pretty confused on the type of topology to use to simulate the same. Does anyone out there have any idea on the type of topology/traffic to simulate to test the same. Can you also suggest any papers which study Gateway Location and pricing using simulation results with description of simulation model. Thanks Sujatha. ****************************************************************************** Sujatha Balaraman * Networks Lab * UC Davis. * e-mail :sujathab@ece.ucdavis.edu 609, Anderson Road * sbalaraman@ucdavis.edu Apt: 287, * Davis * Ph: 530-750-3897 CA 95616 * ******************************************************************************* --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 20:29:33 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA04241 for ; Thu, 21 Jan 1999 20:29:33 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA27701 for iptel-outgoing; Thu, 21 Jan 1999 16:07:21 -0500 (EST) Message-ID: <36A7969E.66418EF6@cs.columbia.edu> Date: Thu, 21 Jan 1999 16:05:34 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Paul E. Jones" CC: Hanlin_Fang@3com.com, Jonathan Rosenberg , Aishling , iptel@lists.research.bell-labs.com Subject: Re: SIP References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk "Paul E. Jones" wrote: > > Hanlin, > > This is one of the very issues that I have struggled with. In the Internet > environment, protocols consume bandwidth as they need. Latency can be high, > but it is tolerable. The idea of introducing voice and video into the IP > network means that there must be some control over the bandwidth, otherwise > the quality of the call (if the call can be placed at all) will suffer. > > Imagine this scenario: an earthquake strikes California. Everybody in the > state and out of the state attempts to place calls in and out of the > earthquake zone to check on friends and family. Today's telephone equipment > will allow a certain number of calls to succeed-- all other attempts will > fail due to busy circuits. With the use of SIP in an IP telephone device, > there is nothing (that I can see) that would prevent everyone from > attempting to place calls simultaneously. The end result is that all of the > calls would suffer to the point that nobody could understand anything said > on the call. Something must control the traffic. > > Surely the SIP designers have planned for this scenario. I would love to > know how the situation would be handled in a SIP environment. SIP does not control network resource usage; that's the role of RSVP, diff-serv, etc. Indeed, it likely avoids the signaling overload problem encountered by traditional PSTN services as it may bypass all but the final end system. Since SIP can transmit limited out-of-band data, the California earthquake situation would actually handled much more readily by SIP: INVITE joe@sf.ca.us From: mary@sj.ca.us Subject: I'm fine but all the china is in pieces -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 20:30:41 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA04264 for ; Thu, 21 Jan 1999 20:30:41 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id PAA27673 for iptel-outgoing; Thu, 21 Jan 1999 15:51:18 -0500 (EST) Message-ID: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> From: "Paul E. Jones" To: , "Jonathan Rosenberg" Cc: "Aishling" , Subject: Re: SIP Date: Thu, 21 Jan 1999 15:45:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hanlin, This is one of the very issues that I have struggled with. In the Internet environment, protocols consume bandwidth as they need. Latency can be high, but it is tolerable. The idea of introducing voice and video into the IP network means that there must be some control over the bandwidth, otherwise the quality of the call (if the call can be placed at all) will suffer. Imagine this scenario: an earthquake strikes California. Everybody in the state and out of the state attempts to place calls in and out of the earthquake zone to check on friends and family. Today's telephone equipment will allow a certain number of calls to succeed-- all other attempts will fail due to busy circuits. With the use of SIP in an IP telephone device, there is nothing (that I can see) that would prevent everyone from attempting to place calls simultaneously. The end result is that all of the calls would suffer to the point that nobody could understand anything said on the call. Something must control the traffic. Surely the SIP designers have planned for this scenario. I would love to know how the situation would be handled in a SIP environment. Best Regards, Paul -----Original Message----- From: Hanlin_Fang@3com.com To: Jonathan Rosenberg Cc: Aishling ; iptel@lists.research.bell-labs.com Date: Wednesday, January 20, 1999 12:34 AM Subject: Re: SIP >My question is that: if you don't use proxy server in SIP, how can you get >control and management capability comparing with H.323 gatekeeper system? >If you use proxy server model, is there any significant difference between >H.323 and SIP? >Thanks for any comments! > >Hanlin > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 21:10:19 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA04463 for ; Thu, 21 Jan 1999 21:10:18 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA27727 for iptel-outgoing; Thu, 21 Jan 1999 16:29:17 -0500 (EST) Message-ID: <36A79B95.4A0D344F@dnrc.bell-labs.com> Date: Thu, 21 Jan 1999 16:26:45 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Paul E. Jones" CC: Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com Subject: Re: SIP References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Paul E. Jones wrote: > > Imagine this scenario: an earthquake strikes California. Everybody in the > state and out of the state attempts to place calls in and out of the > earthquake zone to check on friends and family. Today's telephone equipment > will allow a certain number of calls to succeed-- all other attempts will > fail due to busy circuits. With the use of SIP in an IP telephone device, > there is nothing (that I can see) that would prevent everyone from > attempting to place calls simultaneously. The end result is that all of the > calls would suffer to the point that nobody could understand anything said > on the call. Something must control the traffic. > > Surely the SIP designers have planned for this scenario. I would love to > know how the situation would be handled in a SIP environment. There are several issues here that are being roled into one. SIP does not address network QoS. That is left to other mechanisms, such as RSVP and/or diffserv. With RSVP, routers would reject reservations once the capacity in a router is reached. With diffserv, border routers will have policers to make sure that people abide by their SLA's; other mechanisms might be put in place to deal with overloads. The problem you mention is not SIP specific at all (which is why network QoS is not addressed in SIP). What happens if everyone tries to send email? Or enter chat rooms? Or make H.323 calls? Given that, there are certainly mechanisms within SIP which allow you to restrict call volumes, independent of whether there is sufficient network capacity. A proxy can simply reject calls after the number of calls through it exceed some maximum, or if the request rate exceeds some peak. Any criteria, at the discretion of the implementor, can be used to reject a call. In SIP, the call is rejected by having the server send a 600 class response. Given that SIP INVITE's usually carry SDP (which contains media parameters, like codec types and possibly bandwidth usage), a server could also use this information to try to restrict "total bandwidth usage" in some abstract, topology independent definition of the term. What if there are no servers? What if users try and contact each other directly? In that case, you will need to make use of network QoS management techniques. This is also not SIP specific. If two H.323 terminals communicate directly, you'll have the same problem. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 23:28:01 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA06960 for ; Thu, 21 Jan 1999 23:28:00 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id SAA27837 for iptel-outgoing; Thu, 21 Jan 1999 18:30:06 -0500 (EST) Posted-Date: Thu, 21 Jan 1999 16:27:47 -0700 (MST) Message-ID: <36A7B859.395D7777@agcs.com> Date: Thu, 21 Jan 1999 16:29:29 -0700 From: Nagaraj Vn Organization: AG Communication Systems X-Mailer: Mozilla 4.06 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: POTS-IP access gateway Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Does anybody know about a commercial terminal adaptor OR an access gateway for analog phones such that analog signalling such as offhook, flash, digits (DTMF) etc are converted to appropriate H.225 OR H.245 IP message (Ex: offhook -> SETUP, hookflash -> H.245 userInputIndication ) ? --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 23:35:35 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA07406 for ; Thu, 21 Jan 1999 23:35:35 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id SAA27846 for iptel-outgoing; Thu, 21 Jan 1999 18:31:16 -0500 (EST) Message-ID: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> From: "Paul E. Jones" To: "Henning Schulzrinne" Cc: , "Jonathan Rosenberg" , "Aishling" , Subject: Re: SIP Date: Thu, 21 Jan 1999 18:25:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Henning Schulzrinne wrote: >SIP does not control network resource usage; that's the role of RSVP, >diff-serv, etc. Indeed, it likely avoids the signaling overload problem >encountered by traditional PSTN services as it may bypass all but the >final end system. Since SIP can transmit limited out-of-band data, the >California earthquake situation would actually handled much more readily >by SIP: > >INVITE joe@sf.ca.us >From: mary@sj.ca.us >Subject: I'm fine but all the china is in pieces It is certainly acceptable to say that SIP should not manage the network resources given that its function is a "Session Initiation Protocol". My question really was directed more at the overall solution, which involves SIP, than SIP by itself-- and you have answered that question. However, there are other, similar questions that need addressing as well. Are there any efforts going on inside the IETF or in other groups to define a complete IP telephony solution using SIP? That is, are there any documents in existence or under construction that provide guidance to implementers or service providers that address bandwidth issues, user location, security, roaming, etc. Is anyone addressing the issues of lawful interception or access to emergency services in the SIP environment? In order to deploy a global IP telephony solution based on SIP and related technologies, we must have a standard that addresses the "loose ends" that the protocols by themselves do not. Best Regards, Paul --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Thu Jan 21 23:53:49 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA07559 for ; Thu, 21 Jan 1999 23:53:48 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id SAA27862 for iptel-outgoing; Thu, 21 Jan 1999 18:53:16 -0500 (EST) Message-Id: <3.0.3.32.19990122105229.00769e48@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 22 Jan 1999 10:52:29 +1100 To: Jonathan Rosenberg , "Paul E. Jones" From: Douglas Clowes Subject: Re: SIP Cc: Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com In-Reply-To: <36A79B95.4A0D344F@dnrc.bell-labs.com> References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 16:26 1999-01-21 -0500, Jonathan Rosenberg wrote: >Paul E. Jones wrote: >> >> Imagine this scenario: an earthquake strikes California. Everybody in the >> state and out of the state attempts to place calls in and out of the >> earthquake zone to check on friends and family. Today's telephone equipment >> will allow a certain number of calls to succeed-- all other attempts will >> fail due to busy circuits. With the use of SIP in an IP telephone device, >> there is nothing (that I can see) that would prevent everyone from >> attempting to place calls simultaneously. The end result is that all of the >> calls would suffer to the point that nobody could understand anything said >> on the call. Something must control the traffic. >> >> Surely the SIP designers have planned for this scenario. I would love to >> know how the situation would be handled in a SIP environment. > >There are several issues here that are being roled into one. SIP does >not address network QoS. That is left to other mechanisms, such as RSVP >and/or diffserv. With RSVP, routers would reject reservations once the >capacity in a router is reached. With diffserv, border routers will have >policers to make sure that people abide by their SLA's; other mechanisms >might be put in place to deal with overloads. The problem you mention is >not SIP specific at all (which is why network QoS is not addressed in >SIP). What happens if everyone tries to send email? Or enter chat rooms? >Or make H.323 calls? Well, H.323 bandwidth management in the H.323 gatekeeper will come into play. Of course, it will only limit H.323 calls and all the SIP, email and chat traffic will make it meaningless. I expect similar controls, introduced into SIP to have a similar lack of intended effect. > >What if there are no servers? What if users try and contact each other >directly? In that case, you will need to make use of network QoS >management techniques. This is also not SIP specific. If two H.323 >terminals communicate directly, you'll have the same problem. At least H.323 mandates the use of the gatekeeper, if present. But Jonathan is absolutely correct. Well, at least relatively correct. Some sort of bandwidth management, and payload prioritization, is required to offer some level of control over QoS. That is, and ought to be, outside of SIP/H.323 and firmly within the underlying transport system which, at least for H.323 (and I suspect for SIP), can be something other than IP. As I understand it, and Jonathan will correct me if I'm wrong, RSVP is supposed to "gurantee" bandwidth, while diffserv will prioritize the traffic. In the former case, the call should be good or fail while in the latter, if there is too much "high priority" traffic it will all be bad. Douglas >-Jonathan R. >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen >--------- >This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 00:23:13 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07776 for ; Fri, 22 Jan 1999 00:23:13 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id TAA27954 for iptel-outgoing; Thu, 21 Jan 1999 19:45:16 -0500 (EST) Message-Id: <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> X-Sender: jtoga@ibeam.intel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Jan 1999 16:42:01 -0800 To: Jonathan Rosenberg , "Paul E. Jones" From: Jim Toga Subject: Re: SIP Cc: Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com In-Reply-To: <36A79B95.4A0D344F@dnrc.bell-labs.com> References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk A couple of comments - jimt. At 1/21/99 -0500, Jonathan Rosenberg wrote: [SNIP] >There are several issues here that are being roled into one. SIP does >not address network QoS. That is left to other mechanisms, such as RSVP >and/or diffserv. With RSVP, routers would reject reservations once the >capacity in a router is reached. With diffserv, border routers will have >policers to make sure that people abide by their SLA's; other mechanisms >might be put in place to deal with overloads. The problem you mention is >not SIP specific at all (which is why network QoS is not addressed in >SIP). What happens if everyone tries to send email? Or enter chat rooms? >Or make H.323 calls? Call admission by H.323 Gatekeepers can be used in this case to match provisioning with capacity. The behaviour might exactly mimic the current PSTN. > [SNIP] >What if there are no servers? What if users try and contact each other >directly? In that case, you will need to make use of network QoS >management techniques. This is also not SIP specific. If two H.323 >terminals communicate directly, you'll have the same problem. This is exactly why the standard stipulates that _if_ Gatekeepers are present, they must be utilized. > >-Jonathan R. >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen >--------- >This message came from the IETF IPTEL Working Group Mailing List. > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 00:25:18 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07893 for ; Fri, 22 Jan 1999 00:25:17 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id TAA27975 for iptel-outgoing; Thu, 21 Jan 1999 19:53:21 -0500 (EST) Message-ID: <36A7CB79.5A17B9DF@cs.columbia.edu> Date: Thu, 21 Jan 1999 19:51:05 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Clowes CC: Jonathan Rosenberg , "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com Subject: Re: SIP References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122105229.00769e48@mail.ozemail.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas Clowes wrote: > > > Some sort of bandwidth management, and payload prioritization, is required > to offer some level of control over QoS. That is, and ought to be, outside > of SIP/H.323 and firmly within the underlying transport system which, at > least for H.323 (and I suspect for SIP), can be something other than IP. Transport can be IP, IPX, X.25, PSTN (see the PINT work), ATM or anything else that has an address of some sort. You may have to define the address format for SDP carriage, however. Currently, PSTN and IP is all we got there. > > As I understand it, and Jonathan will correct me if I'm wrong, RSVP is > supposed to "gurantee" bandwidth, while diffserv will prioritize the > traffic. In the former case, the call should be good or fail while in the > latter, if there is too much "high priority" traffic it will all be bad. With a somewhat more gradual degradation, since you can tolerate anywhere between 1 and 10% packet loss (more with FEC, but then your bandwidth goes up) while still being able to communicate. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 00:59:40 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA08163 for ; Fri, 22 Jan 1999 00:59:39 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id UAA28006 for iptel-outgoing; Thu, 21 Jan 1999 20:11:10 -0500 (EST) Message-ID: <36A7CFE7.BE49C6D8@dnrc.bell-labs.com> Date: Thu, 21 Jan 1999 20:09:59 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "Paul E. Jones" CC: Henning Schulzrinne , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: Re: SIP References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Paul E. Jones wrote: > > Henning Schulzrinne wrote: > >SIP does not control network resource usage; that's the role of RSVP, > >diff-serv, etc. Indeed, it likely avoids the signaling overload problem > >encountered by traditional PSTN services as it may bypass all but the > >final end system. Since SIP can transmit limited out-of-band data, the > >California earthquake situation would actually handled much more readily > >by SIP: > > > >INVITE joe@sf.ca.us > >From: mary@sj.ca.us > >Subject: I'm fine but all the china is in pieces > > Are there any efforts going on inside the IETF or in other groups to define > a complete IP telephony solution using SIP? That is, are there any > documents in existence or under construction that provide guidance to > implementers or service providers that address bandwidth issues, user > location, security, roaming, etc. Is anyone addressing the issues of lawful > interception or access to emergency services in the SIP environment? Some of these issues are being addressed; SIP itself addresses security, relying in part on existing mechanisms, such as TLS or IPSEC. User location is one of the features of SIP; work is going on in the enum group (not yet a working group) around doing it for telephone numbers. I know of efforts regarding roaming services and emergency services (a REALLY hard problem in an Internet context), but nothing at the standards level. However, there is currently no IETF effort to specify a "complete solution" for IP telephony. In general, this is not something IETF does. It is good at making nice, general purpose, modular protocols, and the job of putting it all together for a complete solution is something that the service providers and vendors do, as there is more than one right way, and it leaves room for growth and value add. Seems to have worked so far; there are many applications on the net which involve a mix of protocols. THe web is certainly one example - it relies on http, of course, but also on back end directory services for dynamic content, HTML, Java, Javascript, HTTP-CGI, cache replication protocols, and lots of media types and plugins. There is no one spec which tells vendors what to implement in their servers. > > In order to deploy a global IP telephony solution based on SIP and related > technologies, we must have a standard that addresses the "loose ends" that > the protocols by themselves do not. I'm not yet convinced that we "MUST" have such a standard. I agree there must be solutions to the various component problems, but not all in one, birthday wrapped solution. Grandiose, all encompassing solutions have a bad habit of never making it. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 01:55:15 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA08577 for ; Fri, 22 Jan 1999 01:55:14 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id VAA28106 for iptel-outgoing; Thu, 21 Jan 1999 21:04:10 -0500 (EST) Message-ID: <36A7DC53.D1CA449B@dnrc.bell-labs.com> Date: Thu, 21 Jan 1999 21:02:59 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Jim Toga CC: "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: Re: SIP References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Jim Toga wrote: > > >There are several issues here that are being roled into one. SIP does > >not address network QoS. That is left to other mechanisms, such as RSVP > >and/or diffserv. With RSVP, routers would reject reservations once the > >capacity in a router is reached. With diffserv, border routers will have > >policers to make sure that people abide by their SLA's; other mechanisms > >might be put in place to deal with overloads. The problem you mention is > >not SIP specific at all (which is why network QoS is not addressed in > >SIP). What happens if everyone tries to send email? Or enter chat rooms? > >Or make H.323 calls? > > Call admission by H.323 Gatekeepers can be used in this case to match > provisioning with capacity. The behaviour might exactly mimic the current > PSTN. SIP servers can also do "admission control", by rejecting requests (see my previous message). So, whatever logic you have behind the admission decisions in RAS, you could put in a SIP server too. However, its not clear how either a SIP server or H.323 gatekeeper would be able to actually make a decision which mimics the PSTN. In the PSTN, the circuits flow through the switch which makes the admission decision, and the switch sees every setup message for a circuit that goes through it. In the Internet, media doesn't flow through gatekeepers or SIP servers, and neither will have knowledge of network topologies or other applications. So, if there is lots of web traffic on an intranet, I don't really see how a single application specific box could know how much bandwidth is actually available on all links between a caller and callee. Only routers can do that, and thats why QoS control is done with things like RSVP and diffserv. > >What if there are no servers? What if users try and contact each other > >directly? In that case, you will need to make use of network QoS > >management techniques. This is also not SIP specific. If two H.323 > >terminals communicate directly, you'll have the same problem. > > This is exactly why the standard stipulates that _if_ Gatekeepers are > present, they must be utilized. Question: besides the specification, what prevents a client from ignoring them anyway? A big theme on another thread has been that clients often disobey or misimplement portions of a spec. IP is IP, and two hosts with globally routable IP addresses can always communicate. Seems like a bullet item for a feature in fact: no call rejections - the user's software just tries to call the other user directly, ignoring the admission rejections. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 01:56:46 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA08589 for ; Fri, 22 Jan 1999 01:56:45 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id UAA28082 for iptel-outgoing; Thu, 21 Jan 1999 20:51:48 -0500 (EST) Message-ID: <36A7D96B.758462A2@dnrc.bell-labs.com> Date: Thu, 21 Jan 1999 20:50:35 -0500 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Douglas Clowes CC: "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: Re: SIP References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122105229.00769e48@mail.ozemail.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas Clowes wrote: > > >There are several issues here that are being roled into one. SIP does > >not address network QoS. That is left to other mechanisms, such as RSVP > >and/or diffserv. With RSVP, routers would reject reservations once the > >capacity in a router is reached. With diffserv, border routers will have > >policers to make sure that people abide by their SLA's; other mechanisms > >might be put in place to deal with overloads. The problem you mention is > >not SIP specific at all (which is why network QoS is not addressed in > >SIP). What happens if everyone tries to send email? Or enter chat rooms? > >Or make H.323 calls? > > Well, H.323 bandwidth management in the H.323 gatekeeper will come into > play. Of course, it will only limit H.323 calls and all the SIP, email and > chat traffic will make it meaningless. > > I expect similar controls, introduced into SIP to have a similar lack of > intended effect. Yup. Controls in a SIP server are good for localized policy decisions, (Joe can't make video calls), but for decisions based on global network state - well, thats really not feasible. > Some sort of bandwidth management, and payload prioritization, is required > to offer some level of control over QoS. That is, and ought to be, outside > of SIP/H.323 and firmly within the underlying transport system which, at > least for H.323 (and I suspect for SIP), can be something other than IP. > > As I understand it, and Jonathan will correct me if I'm wrong, RSVP is > supposed to "gurantee" bandwidth, while diffserv will prioritize the > traffic. In the former case, the call should be good or fail while in the > latter, if there is too much "high priority" traffic it will all be bad. Actually, its not if there's too much high priority, its if the amount of high priority traffic reaches link bandwidths. If you implement the EF PHB using a priority queue, and you expect on average 10% of the network bandwidth to be voice (which the ISP marks as EF), in an absolute catastrophe there is still 90% of the bandwidth left that the priority queue could usurp. If a priority queue isn't used it might be less. So, in a network with lots more data traffic than voice, things might work quite nicely - except for the poor folks trying to send email :) -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 02:18:12 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA15000 for ; Fri, 22 Jan 1999 02:18:11 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id WAA28230 for iptel-outgoing; Thu, 21 Jan 1999 22:05:33 -0500 (EST) Message-ID: From: Guocai Deng To: Sujatha Balaraman , Jonathan Rosenberg Cc: xmzhao , iptel@lists.research.bell-labs.com Subject: RE: IP Telphony Gateway Pricing Date: Fri, 22 Jan 1999 11:01:30 +0800 X-Mailer: Internet Mail Service (5.0.1460.8) Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Dear Sujatha, I think that pricing is Gatekeeper-Centered instead of Gateway-Centered. Whenever IP User or PSTN user to use IP telephone, they must pay for some QoS calling. Current vendors mainly offer a solution with one-tier pricing model, i. e. one Operation Center Offer traffic table about all Gateway or Gatekeeper. There is a serious scabability problem. I think that pricing need leaf-gatekeepers to negotiate during Capability-Exchanging. Pricing procedure should result some info about Fee/QoS, the settlement Point( Accouting Server). These info can be arranged in Tree-Table format. But I am not sure how those affect the performance and traffic. -----Original Message----- From: Sujatha Balaraman [SMTP:sujathab@ece.ucdavis.edu] Sent: Friday, January 22, 1999 3:51 AM To: Jonathan Rosenberg Cc: xmzhao; iptel@lists.research.bell-labs.com Subject: IP Telphony Gateway Pricing Hi, I"m trying to formulate a pricing model for the Telephony Gateway based on QOS offered. I am pretty confused on the type of topology to use to simulate the same. Does anyone out there have any idea on the type of topology/traffic to simulate to test the same. Can you also suggest any papers which study Gateway Location and pricing using simulation results with description of simulation model. Thanks Sujatha. **************************************************************************** ** Sujatha Balaraman * Networks Lab * UC Davis. * e-mail :sujathab@ece.ucdavis.edu 609, Anderson Road * sbalaraman@ucdavis.edu Apt: 287, * Davis * Ph: 530-750-3897 CA 95616 * **************************************************************************** *** --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 02:56:55 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA15220 for ; Fri, 22 Jan 1999 02:56:54 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id VAA28216 for iptel-outgoing; Thu, 21 Jan 1999 21:59:23 -0500 (EST) Message-Id: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 22 Jan 1999 13:57:30 +1100 To: Jonathan Rosenberg , "Paul E. Jones" From: Douglas Clowes Subject: Re: SIP Cc: Henning Schulzrinne , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu In-Reply-To: <36A7CFE7.BE49C6D8@dnrc.bell-labs.com> References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 20:09 1999-01-21 -0500, Jonathan Rosenberg wrote: >Paul E. Jones wrote: >> >> Are there any efforts going on inside the IETF or in other groups to define >> a complete IP telephony solution using SIP? That is, are there any >> documents in existence or under construction that provide guidance to >> implementers or service providers that address bandwidth issues, user >> location, security, roaming, etc. Is anyone addressing the issues of lawful >> interception or access to emergency services in the SIP environment? > >Some of these issues are being addressed; SIP itself addresses security, >relying in part on existing mechanisms, such as TLS or IPSEC. User >location is one of the features of SIP; work is going on in the enum >group (not yet a working group) around doing it for telephone numbers. I >know of efforts regarding roaming services and emergency services (a >REALLY hard problem in an Internet context), but nothing at the >standards level. > >However, there is currently no IETF effort to specify a "complete >solution" for IP telephony. In general, this is not something IETF does. >It is good at making nice, general purpose, modular protocols, and the >job of putting it all together for a complete solution is something that >the service providers and vendors do, as there is more than one right >way, and it leaves room for growth and value add. And there are any number of almost, but not quite, entirely non-interoperable implementations. While there is more than one way that might be right, there are far more that are not right. Product-differentiation, market-fragmentation, or customer-lockin: call it what you will. >Seems to have worked so far; there are many applications on the net >which involve a mix of protocols. THe web is certainly one example - it >relies on http, of course, but also on back end directory services for >dynamic content, HTML, Java, Javascript, HTTP-CGI, cache replication >protocols, and lots of media types and plugins. There is no one spec >which tells vendors what to implement in their servers. And there are so many ways that these things can and do break. With the latest browser version available, I still got a site that told me my browser was too old and I should get an update before I come back. It breaks. >> >> In order to deploy a global IP telephony solution based on SIP and related >> technologies, we must have a standard that addresses the "loose ends" that >> the protocols by themselves do not. > >I'm not yet convinced that we "MUST" have such a standard. I agree there >must be solutions to the various component problems, but not all in one, >birthday wrapped solution. Grandiose, all encompassing solutions have a >bad habit of never making it. The solution seems to be the "Implementation Agreement" where, instead of the standards body picking and choosing, a group of vendors, implementors, or customers (or all three) get together and make the choices. Sometimes each group gets together separately and we get three or more IAs. IMTC has an IA on VoIP telephony. ETSI TIPHON is a selection and tightening of the standards. There's also iNOW! and TIPIA. And some others that escape me ... From the box builder's POV, he wants to build boxes with any damn standard he want to, and update to the latest protocols to remain "whiz bang". From the box buyers POV, he wnats to buy boxes from different vendors and have them work in his existing installation. He doesn't want to find that of the two new boxes he bought, one uses RADIUS while the other one, with the higher serial number uses DIAMETER and that neither works with the same models he bought last year from the same vendor that use TACACS+. Some people want to sell boxes. Some people want to buy systems. Douglas >-Jonathan R. > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen >--------- >This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 03:25:12 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA15386 for ; Fri, 22 Jan 1999 03:25:11 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id WAA28268 for iptel-outgoing; Thu, 21 Jan 1999 22:37:25 -0500 (EST) Message-Id: <3.0.3.32.19990122143531.01530df4@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 22 Jan 1999 14:35:31 +1100 To: Jonathan Rosenberg , Jim Toga From: Douglas Clowes Subject: Re: SIP Cc: "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu In-Reply-To: <36A7DC53.D1CA449B@dnrc.bell-labs.com> References: <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk >Question: besides the specification, what prevents a client from >ignoring them anyway? A big theme on another thread has been that >clients often disobey or misimplement portions of a spec. IP is IP, and >two hosts with globally routable IP addresses can always communicate. >Seems like a bullet item for a feature in fact: no call rejections - the >user's software just tries to call the other user directly, ignoring the >admission rejections. > >-Jonathan R. Of course, if it doesn't implement the spec, it doesn't conform to the spec. People could ignore the standards and implement their own protocol. I think that's happened before. Once or twice. Let's see now, a firewall with proxies that only let through known protocols and check with the gatekeeper for H.323 admission. Scarey! Regards, Douglas --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 03:27:12 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA15398 for ; Fri, 22 Jan 1999 03:27:11 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id WAA28277 for iptel-outgoing; Thu, 21 Jan 1999 22:40:51 -0500 (EST) Message-ID: <36A7F3A2.D9E1BB56@dnrc.bell-labs.com> Date: Thu, 21 Jan 1999 22:42:26 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Douglas Clowes CC: Jonathan Rosenberg , Henning Schulzrinne , iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: Re: SIP References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas Clowes wrote: > > >From the box builder's POV, he wants to build boxes with any damn standard > he want to, and update to the latest protocols to remain "whiz bang". From > the box buyers POV, he wnats to buy boxes from different vendors and have > them work in his existing installation. He doesn't want to find that of the > two new boxes he bought, one uses RADIUS while the other one, with the > higher serial number uses DIAMETER and that neither works with the same > models he bought last year from the same vendor that use TACACS+. > Sure. That's why some of us (from multiple vendors) are working hard toward a single standard protocol that can provide accounting, authentication and admission control for many emerging internet applications (IP telephony included). Actually, some of us are not interested in "whiz bang", rather the market itself. > Some people want to sell boxes. Some people want to buy systems. > Yep, we want to sell the boxes now so that the customers can get into the service games as soon as possible. As the protocol and development evolving, the sellers can always send software versions to keep the customers up to date. > Douglas > Regards, -- Ping Pan phone: (732)-332-6744 fax: (732)-834-5379 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 09:26:51 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19305 for ; Fri, 22 Jan 1999 09:26:51 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id EAA29969 for iptel-outgoing; Fri, 22 Jan 1999 04:31:15 -0500 (EST) Date: Fri, 22 Jan 1999 04:29:11 -0500 (EST) From: John Kristoff Newsgroups: news.announce.newgroups,news.groups,comp.dcom.sys.cisco,comp.dcom.telecom.tech,comp.protocols.tcp-ip,alt.dcom.telecom.ip Subject: RFD: comp.dcom.voice-over-ip Followup-To: news.groups Message-ID: <916997349.5431@isc.org> To: iptel@lists.research.bell-labs.com Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk REQUEST FOR DISCUSSION (RFD) unmoderated group comp.dcom.voice-over-ip This is a formal Request For Discussion (RFD) for the creation of the Voice Over IP group in the comp.dcom.* hierarchy. This is not a Call for Votes (CFV); you cannot vote at this time. Procedural details are below. Newsgroups line: comp.dcom.voice-over-ip Voice Over IP technology. RATIONALE: comp.dcom.voice-over-ip Voice Over IP is a burgeoning technology which is bringing real-time, interactive voice communications to end users via the underlying protocol of the Internet, namely the Internet Protocol (IP). Discussions in other mailing lists and newsgroups seem to warrant the creation of a generic Voice Over IP newsgroup (see the ITMC Voice Over IP mailing list archives and alt.dcom.telecom.ip). The IETF, IMTC, and ETSI each run a mailing list in which the focus is on developing technical standards. This in depth focus is primarily of interest only to developers and manufacturers. While interest, trials and products in this field are racing ahead at a phenomenal pace, a plethora of issues such as quality of service, support, cost provisioning, capacity management, standards, implementation and legacy system integration are areas that will always need serious attention. The comp.dcom.voice-over-ip group will be free from any limits or narrow focus of a single organization's mailing list. Further, the comp.dcom.voice-over-ip newsgroup will allow the above aforementioned issues to be discussed without the control of a governing body. A recent search for the phrase "voice over ip" turned up over 6500 web pages at . Even the relatively new acronym "voip" turned up 2400 documents from the dejanews archives dating from January 1, 1998 to December 15, 1998. In some of the comp.* newsgroups that occasionally discuss Voice Over IP technology, there can easily be hundreds of messages a day. A separate group dedicated to just this topic would be significantly more manageable for those only interested in Voice Over IP technology. See the comp.dcom.sys.cisco and comp.dcom.telecom.tech newsgroups for an idea of the discussions taking placing. In the interest of helping to bring together the researchers, network managers, developers and others simply curious about the technology, a new newsgroup with a Voice Over IP focus is proposed. CHARTER: comp.dcom.voice-over-ip The comp.dcom.voice-over-ip newsgroup is intended to foster the communication among users, managers, developers and researchers of Voice Over IP technology. All layers of the network model from the physical layer on up to the applications layer are applicable items of discussion for this newsgroup. Topics may include, but are not limited to Voice Over IP issues such as the following: o General questions about Voice Over IP o Voice Over IP network architecture o Deployment of Voice Over IP networks o Managing Voice Over IP networks o Standards and Specifications The posting of binaries to comp.dcom.voice-over-ip is prohibited. The posting of employment opportunities to comp.dcom.voice-over-ip is prohibited. Announcements of new products or services related to Voice Over IP technology will be tolerated in comp.dcom.voice-over-ip. comp.dcom.voice-over-ip will not be moderated. END CHARTER. PROCEDURE: This is a request for discussion, not a call for votes. In this phase of the process, any potential problems with the proposed newsgroup should be raised and resolved. The discussion period will continue for a minimum of 21 days (starting from when the first RFD for this proposal is posted to news.announce.newgroups), after which a Call For Votes (CFV) will be posted by a neutral vote taker. Please do not attempt to vote until this happens. All discussion of this proposal should be posted to news.groups. This RFD attempts to comply fully with the Usenet newsgroup creation guidelines outlined in "How to Create a New Usenet Newsgroup" and "How to Format and Submit a New Group Proposal". Please refer to these documents (available in news.announce.newgroups) if you have any questions about the process. DISTRIBUTION: This RFD has been posted to the following newsgroups: news.announce.newgroups, news.groups, comp.dcom.sys.cisco,comp.dcom.telecom.tech, comp.protocols.tcp-ip alt.dcom.telecom.ip and the following mailing lists: voip@imtc.org (International Multimedia Teleconferencing Consortium) subscribe via majordomo@imtc.org tiphon@list.etsi.fr (European Telecommunications Standard Institute) subscribe via listserv@list.etsi.fr iptel@lists.research.bell-labs.com (Internet Engineering Task Force) subscribe via iptel-request@lists.research.bell-labs.com and the following web page: http://homepage.interaccess.com/~jkristof/voip-rfd.txt Proponent: John Kristoff --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 12:48:29 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA24416 for ; Fri, 22 Jan 1999 12:48:28 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id HAA00115 for iptel-outgoing; Fri, 22 Jan 1999 07:49:22 -0500 (EST) Message-ID: From: Francois Menard Distribution List Management Account To: "'Douglas Clowes'" , Jonathan Rosenberg , Jim Toga Cc: "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: RE: SIP Date: Fri, 22 Jan 1999 07:54:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > Let's see now, a firewall with proxies that only let through known protocols and check with the gatekeeper for H.323 admission. Scarey! No no, The whole H.323 hypothesis is that you can control the end-points and force them to use a given gatekeeper. This is as long as the end-users are not capable of figuring out how to change the config of the end-points to bypass the GK... I've always maintained that on the Internet, it is not because you route a call that you can bill for it. In H.323 on the Internet, you can bill for: 1. QOS for all apps at the same time on the host 2. PSTN access through a metered H.323 PSTN gateway 3. Apps on GKs. (i.e. there is some value in a GK translating a phone number to a dynamic IP address) So I do not believe that basic H.RAS stuff actually makes it possible to derive a bill. GK-routed call models are a billing mechanism, not a bandwidth preserving thing. So IMHO, by definition, it is only possible as long as you can force the end-points to collaborate. Same for a SIP server-routed call models too. But then, SIP makes no assumption about the rationality of SIP-server call routed models to create illusions about the real problems of IP telephony. -=Francois=- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 14:07:00 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28456 for ; Fri, 22 Jan 1999 14:07:00 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id IAA00183 for iptel-outgoing; Fri, 22 Jan 1999 08:37:16 -0500 (EST) Message-ID: <36A87E89.D298FF97@cs.columbia.edu> Date: Fri, 22 Jan 1999 08:35:05 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Clowes CC: iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: Re: SIP References: <02ea01be4596$160638b0$aec965c0@pjones.databeam.com> <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas Clowes wrote: > > And there are any number of almost, but not quite, entirely > non-interoperable implementations. While there is more than one way that > might be right, there are far more that are not right. > Product-differentiation, market-fragmentation, or customer-lockin: call it > what you will. There may well be value in agreements beyond protocol specs. However, there's often the suspicion that many of these industry bodies are clean-up crews for standards that could have been clearer, been based on more implementation experience or more layered/modular to begin with. The abundance of these organizations also raises the cost of entry, so they are probably at best a necessary evil, not a model to strive for. Note also that the traditional telecom world is hardly a model to emulate here, if you recall trivial things like the number of different phone plugs, dialing plans or ringing patterns (see a previous discussion on rem-conf) in the world or the number of ISUP/TUP/other signaling variants. At least email and web access from India to the US works without gateways and translators and interoperability agreements and I don't have to be certified as compliant in each of those countries :-) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 15:18:04 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA01038 for ; Fri, 22 Jan 1999 15:18:02 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id JAA00245 for iptel-outgoing; Fri, 22 Jan 1999 09:17:28 -0500 (EST) Reply-To: From: "James Verlare" To: "'Jim Toga'" Cc: Subject: RE: SIP Date: Fri, 22 Jan 1999 07:17:18 -0700 Message-ID: <000001be4611$ec35f4e0$fd3c25a6@jverlare.mcit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-reply-to: <36A7DC53.D1CA449B@dnrc.bell-labs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk It seems to me that the answer lies in GateKeepers that provide admission control with the help of external network monitoring serives. RSVP is responsible for capacity from segment to segment, diffserv for prioritizing up to the last 100 meters, end stations NIC drivers in comnination with diffserv determine CoS for that end station. An external load monitoring service keeps the GateKeeper informed so it can respond intelligently to admission requests. JLV. -----Original Message----- From: owner-iptel@lists.research.bell-labs.com [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Thursday, January 21, 1999 7:03 PM To: Jim Toga Cc: Paul E. Jones; Hanlin_Fang@3com.com; Aishling; iptel@lists.research.bell-labs.com; confctrl@isi.edu Subject: Re: SIP Jim Toga wrote: > > >There are several issues here that are being roled into one. SIP does > >not address network QoS. That is left to other mechanisms, such as RSVP > >and/or diffserv. With RSVP, routers would reject reservations once the > >capacity in a router is reached. With diffserv, border routers will have > >policers to make sure that people abide by their SLA's; other mechanisms > >might be put in place to deal with overloads. The problem you mention is > >not SIP specific at all (which is why network QoS is not addressed in > >SIP). What happens if everyone tries to send email? Or enter chat rooms? > >Or make H.323 calls? > > Call admission by H.323 Gatekeepers can be used in this case to match > provisioning with capacity. The behaviour might exactly mimic the current > PSTN. SIP servers can also do "admission control", by rejecting requests (see my previous message). So, whatever logic you have behind the admission decisions in RAS, you could put in a SIP server too. However, its not clear how either a SIP server or H.323 gatekeeper would be able to actually make a decision which mimics the PSTN. In the PSTN, the circuits flow through the switch which makes the admission decision, and the switch sees every setup message for a circuit that goes through it. In the Internet, media doesn't flow through gatekeepers or SIP servers, and neither will have knowledge of network topologies or other applications. So, if there is lots of web traffic on an intranet, I don't really see how a single application specific box could know how much bandwidth is actually available on all links between a caller and callee. Only routers can do that, and thats why QoS control is done with things like RSVP and diffserv. > >What if there are no servers? What if users try and contact each other > >directly? In that case, you will need to make use of network QoS > >management techniques. This is also not SIP specific. If two H.323 > >terminals communicate directly, you'll have the same problem. > > This is exactly why the standard stipulates that _if_ Gatekeepers are > present, they must be utilized. Question: besides the specification, what prevents a client from ignoring them anyway? A big theme on another thread has been that clients often disobey or misimplement portions of a spec. IP is IP, and two hosts with globally routable IP addresses can always communicate. Seems like a bullet item for a feature in fact: no call rejections - the user's software just tries to call the other user directly, ignoring the admission rejections. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 19:32:44 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA10232 for ; Fri, 22 Jan 1999 19:32:43 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id OAA00589 for iptel-outgoing; Fri, 22 Jan 1999 14:31:19 -0500 (EST) From: Hanlin_Fang@3com.com X-Lotus-FromDomain: 3COM To: "Paul E. Jones" cc: "Jonathan Rosenberg" , "Aishling" , iptel@lists.research.bell-labs.com Message-ID: <88256701.006A6F25.00@hqoutbound.ops.3com.com> Date: Fri, 22 Jan 1999 11:30:22 -0800 Subject: Re: SIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk One more question about the management capability of SIP and H.323: Even SIP can use RSVP for some QoS issues. For conference control, SIP can do nothing, right? Without MC in H.323, SIP endpoints actually don't get any control information about the conference they are attending, right? Or RSVP also can be used for this purpose? Thanks for any comments! Hanlin "Paul E. Jones" on 01/21/99 12:45:13 PM To: Hanlin Fang/HQ/3Com, "Jonathan Rosenberg" cc: "Aishling" , iptel@lists.research.bell-labs.com Subject: Re: SIP Hanlin, This is one of the very issues that I have struggled with. In the Internet environment, protocols consume bandwidth as they need. Latency can be high, but it is tolerable. The idea of introducing voice and video into the IP network means that there must be some control over the bandwidth, otherwise the quality of the call (if the call can be placed at all) will suffer. Imagine this scenario: an earthquake strikes California. Everybody in the state and out of the state attempts to place calls in and out of the earthquake zone to check on friends and family. Today's telephone equipment will allow a certain number of calls to succeed-- all other attempts will fail due to busy circuits. With the use of SIP in an IP telephone device, there is nothing (that I can see) that would prevent everyone from attempting to place calls simultaneously. The end result is that all of the calls would suffer to the point that nobody could understand anything said on the call. Something must control the traffic. Surely the SIP designers have planned for this scenario. I would love to know how the situation would be handled in a SIP environment. Best Regards, Paul -----Original Message----- From: Hanlin_Fang@3com.com To: Jonathan Rosenberg Cc: Aishling ; iptel@lists.research.bell-labs.com Date: Wednesday, January 20, 1999 12:34 AM Subject: Re: SIP >My question is that: if you don't use proxy server in SIP, how can you get >control and management capability comparing with H.323 gatekeeper system? >If you use proxy server model, is there any significant difference between >H.323 and SIP? >Thanks for any comments! > >Hanlin > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 20:18:16 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA11072 for ; Fri, 22 Jan 1999 20:18:16 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id PAA00686 for iptel-outgoing; Fri, 22 Jan 1999 15:19:27 -0500 (EST) From: pOsTmAsTeR@benfica.etfce.br Date: Fri, 22 Jan 1999 09:40:06 -0200 Message-Id: <199901221140.JAA06232@benfica.etfce.br> To: you989@usa.net Subject: Immediate Buy Alert! Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Thursday January 21st, Company Press Release African Resources, Inc. - Micro Cap - Ticker (AFRI) Company Litigating Against Nations's Third Largest Bank for Unauthorized Trading of Corporate Securities TORONTO--(BUSINESS WIRE)--Jan. 4, 1999--AFRICAN RESOURCES, INC. (OTC BB: AFRI) (AFRI) - a natural resource development company - with gold and diamond concessions located in the Republic of Guinea and gold mining operations in the State of Arizona - announced today, that it is preparing legal action against Chase Manhattan Bank - the nation's third largest bank for sustained damages as a result of unauthorized trading of the company's securities. On April 28, 1998, the company alleges that Chase Manhattan Bank engaged in unauthorized trading of 1,000,000 common shares of AFRI wherein the bank's securities division sold the stock into the open market within a 30 minute period - and depressed the trading value of the shares from $0.60/share to $0.01/share. At the time of the incident, the Company's tradable float was less than 600,000 common shares. The alleged unauthorized traded shares had been entrusted to the legal counsel of a credit facilitator that agreed to maintain the shares in escrow at Chase Manhattan Bank. The Bank allegedly executed the trade without receiving authorization from the account holder. Chase Manhattan Bank executives have failed to return the shares to the account holder, in spite of demands and refusal by the account holder to access the proceeds placed in the account from the sale of the 1,000,000 shares. Over 200 pages of supportive documentation, which the company and account holder believe clearly establishes the facts of this unauthorized transaction, have been reported to the Securities Exchange Commission. The account holder has made a formal demand for the return of the 1,000,000 shares. In the event of non-compliance by Chase Manhattan Bank, the account holder's attorneys intend to seek immediate relief from National Association of Securities Dealers (NASD) arbitration and the Initiation of a law suit against Chase Manhattan Bank. Mr. Rick Brodzik, president of AFRICAN RESOURCES, INC., stated: ``The Company and its shareholders have incurred severe harm by the alleged unauthorized trading action conducted by Chase Manhattan Bank and intends to file appropriate litigation in the courts - in support of the account holder - while seeking monetary restitution for loss of revenues and other damages caused by this irresponsible action.'' Mr. Brodzik went on to state, ``The Company's funding programs sustained a temporary set-back as a result of the trading price of the company's securities being plunged to an all-time low of $0.01/share. However, the Company is in the process of fiscal recovery via the completion of requisite funding programs to implement its gold and diamond mining operations - scheduled to go on-line in the near future. Contact: Newtrends International. Stuart Gray,- Canada & U.S. 1-888-990-9252 All other 250-712-9425 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 20:36:51 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA11397 for ; Fri, 22 Jan 1999 20:36:50 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA00921 for iptel-outgoing; Fri, 22 Jan 1999 16:03:17 -0500 (EST) From: "Henry Sinnreich" To: "Guocai Deng" , "Sujatha Balaraman" , "Jonathan Rosenberg" Cc: "xmzhao" , Subject: RE: IP Telphony Gateway Pricing Date: Fri, 22 Jan 1999 14:59:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > I think that pricing is Gatekeeper-Centered instead of > Gateway-Centered. Whenever IP User or PSTN user to use IP telephone, they > must pay for some QoS calling. This is an interesting problem. Billing data and call admission can be done in the gateway controller, be it a call agent, SIP server, or H.323 gatekeeper, but these devices do not control QoS in the network nor do they guarantee QoS. Let's use the term call agent. The call agent has first to check with a policy server and also to find out if the QoS is indeed provided by the transport layer, the routers and L2 elements underneath, before charging for QoS. Would need actually to develop sort of a "call flow" showing the interactions between the client requesting a call, the call agent requesting QOS from the policy server, the reponses and exception handling. Any thoughts on the message exchange regarding QoS for a call and for policy decision (PDP and PEP - policy decision point and policy enforcement point) and enforcement ? See http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-00.txt Or can it be done in a simpler way, without requiring the tight coupling envisaged above? Thanks, Henry > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Guocai > Deng > Sent: Thursday, January 21, 1999 10:02 PM > To: Sujatha Balaraman; Jonathan Rosenberg > Cc: xmzhao; iptel@lists.research.bell-labs.com > Subject: RE: IP Telphony Gateway Pricing > > > Dear Sujatha, > > I think that pricing is Gatekeeper-Centered instead of > Gateway-Centered. Whenever IP User or PSTN user to use IP telephone, they > must pay for some QoS calling. > > Current vendors mainly offer a solution with one-tier > pricing model, i. > e. one Operation Center Offer traffic table about all Gateway or > Gatekeeper. > There is a serious scabability problem. > > I think that pricing need leaf-gatekeepers to negotiate during > Capability-Exchanging. Pricing procedure should result some info about > Fee/QoS, the settlement Point( Accouting Server). These info can > be arranged > in Tree-Table format. > > But I am not sure how those affect the performance and traffic. > > -----Original Message----- > From: Sujatha Balaraman [SMTP:sujathab@ece.ucdavis.edu] > Sent: Friday, January 22, 1999 3:51 AM > To: Jonathan Rosenberg > Cc: xmzhao; iptel@lists.research.bell-labs.com > Subject: IP Telphony Gateway Pricing > > > Hi, > I"m trying to formulate a pricing model for the Telephony > Gateway > based on QOS offered. I am pretty confused on the type of topology > to use > to simulate the same. Does anyone out there have any idea on the > type of > topology/traffic to simulate to test the same. Can you also suggest > any > papers which study Gateway Location and pricing using simulation > results > with description of simulation model. > > Thanks > Sujatha. > > > ****************************************************************** > ********** > ** > Sujatha Balaraman * Networks Lab > * UC Davis. > * e-mail :sujathab@ece.ucdavis.edu > 609, Anderson Road * sbalaraman@ucdavis.edu > Apt: 287, * > Davis * Ph: 530-750-3897 > CA 95616 * > > ****************************************************************** > ********** > *** > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 20:40:06 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA11455 for ; Fri, 22 Jan 1999 20:40:06 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA00912 for iptel-outgoing; Fri, 22 Jan 1999 16:01:17 -0500 (EST) From: "Henry Sinnreich" To: "Douglas Clowes" , "Jonathan Rosenberg" , "Paul E. Jones" Cc: "Henning Schulzrinne" , , "Aishling" , , Subject: RE: SIP Date: Fri, 22 Jan 1999 14:59:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal In-Reply-To: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas writes: > The solution seems to be the "Implementation Agreement" where, instead of > the standards body picking and choosing, a group of vendors, implementors, > or customers (or all three) get together and make the choices. Sometimes > each group gets together separately and we get three or more IAs. We exchange here e-mail and web pages by using IETF standard protocols. Am not aware that our applications, whatever they are, went through implementor agreements and the like. Henry > IMTC has an IA on VoIP telephony. ETSI TIPHON is a selection and > tightening > of the standards. There's also iNOW! and TIPIA. And some others > that escape > me ... > > From the box builder's POV, he wants to build boxes with any damn standard > he want to, and update to the latest protocols to remain "whiz bang". From > the box buyers POV, he wnats to buy boxes from different vendors and have > them work in his existing installation. He doesn't want to find > that of the > two new boxes he bought, one uses RADIUS while the other one, with the > higher serial number uses DIAMETER and that neither works with the same > models he bought last year from the same vendor that use TACACS+. > > Some people want to sell boxes. Some people want to buy systems. > > Douglas > > >-Jonathan R. > > > >-- > >Jonathan D. Rosenberg Lucent Technologies > >Member of Technical Staff 101 Crawfords Corner Rd. > >High Speed Networks Research Holmdel, NJ 07733 > >FAX: (732) 834-5379 Rm. 4C-526 > >EMAIL: jdrosen@bell-labs.com > >URL: http://www.cs.columbia.edu/~jdrosen > >--------- > >This message came from the IETF IPTEL Working Group Mailing List. > > > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 22:08:34 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA12496 for ; Fri, 22 Jan 1999 22:08:33 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id SAA01034 for iptel-outgoing; Fri, 22 Jan 1999 18:01:17 -0500 (EST) Date: Fri, 22 Jan 1999 14:49:11 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: IP Telphony Gateway Pricing To: Henry Sinnreich Cc: Guocai Deng , Sujatha Balaraman , Jonathan Rosenberg , xmzhao , iptel@lists.research.bell-labs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > > I think that pricing is Gatekeeper-Centered instead of > > Gateway-Centered. Whenever IP User or PSTN user to use IP telephone, they > > must pay for some QoS calling. > > This is an interesting problem. Billing data and call admission can be done > in the gateway controller, be it a call agent, SIP server, or H.323 > gatekeeper, but these devices do not control QoS in the network nor do they > guarantee QoS. Let's use the term call agent. The call agent has first to > check with a policy server and also to find out if the QoS is indeed > provided by the transport layer, the routers and L2 elements underneath, > before charging for QoS. Would need actually to develop sort of a "call > flow" showing the interactions between the client requesting a call, the > call agent requesting QOS from the policy server, the reponses and exception > handling. Presumably, when the policy engine is asked to authenticate and authorize the user, it can determine whether QOS is required for the user. The Policy Server can then "push" the QOS information to the network. This is one of the reasons why an AAA protocol must be able to allow the server to send unsolicited messages down to the clients. PatC > > Any thoughts on the message exchange regarding QoS for a call and for policy > decision (PDP and PEP - policy decision point and policy enforcement point) > and enforcement ? > See http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-00.txt > Or can it be done in a simpler way, without requiring the tight coupling > envisaged above? > > Thanks, Henry > > > > -----Original Message----- > > From: owner-iptel@lists.research.bell-labs.com > > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Guocai > > Deng > > Sent: Thursday, January 21, 1999 10:02 PM > > To: Sujatha Balaraman; Jonathan Rosenberg > > Cc: xmzhao; iptel@lists.research.bell-labs.com > > Subject: RE: IP Telphony Gateway Pricing > > > > > > Dear Sujatha, > > > > I think that pricing is Gatekeeper-Centered instead of > > Gateway-Centered. Whenever IP User or PSTN user to use IP telephone, they > > must pay for some QoS calling. > > > > Current vendors mainly offer a solution with one-tier > > pricing model, i. > > e. one Operation Center Offer traffic table about all Gateway or > > Gatekeeper. > > There is a serious scabability problem. > > > > I think that pricing need leaf-gatekeepers to negotiate during > > Capability-Exchanging. Pricing procedure should result some info about > > Fee/QoS, the settlement Point( Accouting Server). These info can > > be arranged > > in Tree-Table format. > > > > But I am not sure how those affect the performance and traffic. > > > > -----Original Message----- > > From: Sujatha Balaraman [SMTP:sujathab@ece.ucdavis.edu] > > Sent: Friday, January 22, 1999 3:51 AM > > To: Jonathan Rosenberg > > Cc: xmzhao; iptel@lists.research.bell-labs.com > > Subject: IP Telphony Gateway Pricing > > > > > > Hi, > > I"m trying to formulate a pricing model for the Telephony > > Gateway > > based on QOS offered. I am pretty confused on the type of topology > > to use > > to simulate the same. Does anyone out there have any idea on the > > type of > > topology/traffic to simulate to test the same. Can you also suggest > > any > > papers which study Gateway Location and pricing using simulation > > results > > with description of simulation model. > > > > Thanks > > Sujatha. > > > > > > ****************************************************************** > > ********** > > ** > > Sujatha Balaraman * Networks Lab > > * UC Davis. > > * e-mail :sujathab@ece.ucdavis.edu > > 609, Anderson Road * sbalaraman@ucdavis.edu > > Apt: 287, * > > Davis * Ph: 530-750-3897 > > CA 95616 * > > > > ****************************************************************** > > ********** > > *** > > > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Fri Jan 22 22:53:21 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA14517 for ; Fri, 22 Jan 1999 22:53:20 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id SAA01075 for iptel-outgoing; Fri, 22 Jan 1999 18:37:17 -0500 (EST) Message-ID: <01a801be465f$e668d520$aec965c0@pjones.databeam.com> From: "Paul E. Jones" To: "Henry Sinnreich" , "Douglas Clowes" , "Jonathan Rosenberg" Cc: "Henning Schulzrinne" , , "Aishling" , , Subject: Re: SIP Date: Fri, 22 Jan 1999 18:34:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Henry Sinnreich wrote: >Douglas writes: >> The solution seems to be the "Implementation Agreement" where, instead of >> the standards body picking and choosing, a group of vendors, implementors, >> or customers (or all three) get together and make the choices. Sometimes >> each group gets together separately and we get three or more IAs. > >We exchange here e-mail and web pages by using IETF standard protocols. Am >not aware that our applications, whatever they are, went through implementor >agreements and the like. > But even mail and web services are not without problems. Take a web browser written in 1995 and visit some of today's more elaborate web sites. Create an e-mail with Microsoft's Outlook Express using HTML and send it to a user with a mail client written in 1995 (heck, send it to a Netscape user with up-to-date software). It is true that most of today's mail clients can understand SMTP, POP3, IMAP, HTML, MIME, etc. It is also true that most of today's web browsers can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc. However, it has not been without pain on the users-- they have had to upgrade their software every time a new "whiz-bang" feature was added. Be prepared to upgrade your web browsers again soon as XML and XSL displace much of HTML and CSS and MP3 becomes a new important audio format on the web. We cannot and should not expect our telephone system to act this way. People will be investing billions of dollars into IP telephony solutions-- they had better talk to each other. We must agree on how to authorize users when delivering calls to gateways. We must agree on how to locate users or resolve addresses. We must agree on QoS issues (use RSVP?), billing, roaming, access to emergency services, etc., etc. When I go to the store to by my IP phone, bring it home, and plug it into my hub, it should allow me to dial my grandmother's phone number and her phone should ring. The mechanics of accomplishing that are complex, and we must have agreements on how that should be done at every step of the way. In addition, I expect that my IP telephone will continue to work for more than four years. Creating an "Implementation Agreement" as Douglas suggests is not a bad idea. It was not necessary with other protocols because they were simple, the implementations were software-based and free (so cost was no issue), and developed without interest from parties investing billions of dollars. The last point is the key-- when people spend billions of dollars, they expect it to work. Specifying a bunch of loosely related protocols and letting people build several implementations, picking and choosing incompatible components to address requirements, and waiting to see which one is "coolest" and declaring it the winning combination will not work in the IP telephony space. Best Regards, Paul --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sat Jan 23 00:01:50 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA15371 for ; Sat, 23 Jan 1999 00:01:49 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id TAA01150 for iptel-outgoing; Fri, 22 Jan 1999 19:37:21 -0500 (EST) Message-Id: <3.0.5.32.19990122163533.00810a50@ibeam.intel.com> X-Sender: jtoga@ibeam.intel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 22 Jan 1999 16:35:33 -0800 To: "pcalhoun@eng.sun.com" From: Jim Toga Subject: RE: IP Telphony Gateway Pricing Cc: iptel@lists.research.bell-labs.com In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is one of the reasons that the admission request in H.323 has a generic QOS flag to indicate client or GK control. (Subsequent to that some form of RSVP or its ilk occurs along with SBM or some other policy engine....) jimt. At 02:49 PM 1/22/99 -0800, you wrote: >> > I think that pricing is Gatekeeper-Centered instead of >> > Gateway-Centered. Whenever IP User or PSTN user to use IP telephone, they >> > must pay for some QoS calling. >> >> This is an interesting problem. Billing data and call admission can be done >> in the gateway controller, be it a call agent, SIP server, or H.323 >> gatekeeper, but these devices do not control QoS in the network nor do they >> guarantee QoS. Let's use the term call agent. The call agent has first to >> check with a policy server and also to find out if the QoS is indeed >> provided by the transport layer, the routers and L2 elements underneath, >> before charging for QoS. Would need actually to develop sort of a "call >> flow" showing the interactions between the client requesting a call, the >> call agent requesting QOS from the policy server, the reponses and exception >> handling. > >Presumably, when the policy engine is asked to authenticate and authorize the >user, it can determine whether QOS is required for the user. The Policy Server >can then "push" the QOS information to the network. > >This is one of the reasons why an AAA protocol must be able to allow the >server to send unsolicited messages down to the clients. > >PatC >> [SNIP] +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sat Jan 23 00:08:14 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA15386 for ; Sat, 23 Jan 1999 00:08:14 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id TAA01162 for iptel-outgoing; Fri, 22 Jan 1999 19:45:17 -0500 (EST) Message-Id: <199901230036.QAA14315@mailman.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 22 Jan 1999 19:42:23 -0500 To: "Henry Sinnreich" From: John Schnizlein Subject: RE: IP Telphony Gateway Billing Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Subtle change in the title because technical mechanisms for billing are appropriate for IETF discussion while pricing is a business function, which the IETF avoids because it could touch on anti-trust issues. At 02:59 PM 1/22/99 -0500, Henry Sinnreich wrote: > >This is an interesting problem. It is interesting largely because the historical coincidence of call establishment, resource reservation, bandwidth consumption, and billing which occurs in traditional telephony does not apply to IP telephony. IP telephony can support calls that make no reservation (at the risk of poor quality), consume no bandwidth (during silence suppression), or incur no billing beyond that for IP-network access (when both ends are IP stations). >Billing data and call admission can be done >in the gateway controller, be it a call agent, SIP server, or H.323 >gatekeeper, but these devices do not control QoS in the network nor do they >guarantee QoS. In contrast to telephony's reservation by the call originator (and subsequent call-leg originating switches), resource reservation is made by the receiver in IP networks. This is a fundamental complication, but not necessarily one that demands new protocols. >Let's use the term call agent. The call agent has first to >check with a policy server and also to find out if the QoS is indeed >provided by the transport layer, the routers and L2 elements underneath, >before charging for QoS. Would need actually to develop sort of a "call >flow" showing the interactions between the client requesting a call, the >call agent requesting QOS from the policy server, the reponses and exception >handling. > >Any thoughts on the message exchange regarding QoS for a call and for policy >decision (PDP and PEP - policy decision point and policy enforcement point) >and enforcement ? ... >Or can it be done in a simpler way, without requiring the tight coupling >envisaged above? "Simpler way" is in the eye of the beholder. Is this simple enough? The call agent must choose if the call is to have the QoS that requires admission control. If it does, it requires RSVP both ways between gateways, and it accounts for the call based on the QoS it required. If RSVP is invoked, the policy server that provides (via COPS) administrative admission control based on ability to pay may accumulate charges based on the reservation. Since reservations due to RSVP allocate the limited resource of the high priority bandwidth, they should incur charges even if used for applications other than IP telephony. Call agents would be well-advised to use something like the Open Settlement Protocol to apportion or accumulate charges for call legs in multiple IP-telephony domains. The charges for calls should be sufficient to cover the charges for the underlying (RSVP) resource allocations (unless the business model has chosen a loss-leader for some business reason beyond what we discuss in IETF circles). John Schnizlein Consulting Engineer --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sat Jan 23 18:02:54 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27364 for ; Sat, 23 Jan 1999 18:02:53 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id NAA03081 for iptel-outgoing; Sat, 23 Jan 1999 13:33:16 -0500 (EST) From: TDorcey@ixl.com To: paul.jones@ties.itu.int Cc: iptel@lists.research.bell-labs.com, confctrl@ISI.EDU X-Sender: tdorcey@exchange.lax.ixl.com Message-Id: In-Reply-To: <01a801be465f$e668d520$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Jan 1999 18:51:40 -0700 Subject: Re: SIP Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 4:34 PM -0700 1/22/99, Paul E. Jones wrote: > >When I go to the store to by my IP phone, bring it home, and plug it into my >hub, it should allow me to dial my grandmother's phone number and her phone >should ring. The mechanics of accomplishing that are complex, and we must >have agreements on how that should be done at every step of the way. In >addition, I expect that my IP telephone will continue to work for more than >four years. > >Creating an "Implementation Agreement" as Douglas suggests is not a bad >idea. It was not necessary with other protocols because they were simple, >the implementations were software-based and free (so cost was no issue), and >developed without interest from parties investing billions of dollars. The >last point is the key-- when people spend billions of dollars, they expect >it to work. Specifying a bunch of loosely related protocols and letting >people build several implementations, picking and choosing incompatible >components to address requirements, and waiting to see which one is >"coolest" and declaring it the winning combination will not work in the IP >telephony space. I dunno, I think it could work out pretty well that way. If my IP phone works just like my current telephone, then I don't want one. I can't speak for the people spending the billions of dollars, but I am most interested in IP telephony for the innovations it will bring. And, I don't think anyone would suggest that standards committees are fertile ground for innovation; it's just not their mission. Also, let's not forget that it took many years for the existing telephone system to reach it's current level of maturity. Tim Tim Dorcey iXL-Los Angeles tdorcey@ixl.com (310) 235-3928 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sat Jan 23 20:02:01 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA27951 for ; Sat, 23 Jan 1999 20:02:01 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id PAA03125 for iptel-outgoing; Sat, 23 Jan 1999 15:29:18 -0500 (EST) Message-ID: From: "Hoefelmeyer, Ralph (MCI)" To: "'John Schnizlein'" , "Sinnreich, Heinrich" Cc: iptel@lists.research.bell-labs.com Subject: RE: IP Telphony Gateway Billing Date: Sat, 23 Jan 1999 20:28:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE470E.E8264910" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE470E.E8264910 Content-Type: text/plain Hello, Why not do flat rate billing based solely on QoS? The user signs up for a certain QoS level, and all of their traffic is carried with at least that level of QoS, with an allowable small deviation. This would take billing out of the gateway arena. Ralph > -----Original Message----- > From: John Schnizlein [SMTP:jschnizl@cisco.com] > Sent: Friday, January 22, 1999 5:42 PM > To: Sinnreich, Heinrich > Cc: iptel@lists.research.bell-labs.com > Subject: RE: IP Telphony Gateway Billing > > Subtle change in the title because technical mechanisms for billing are > appropriate for IETF discussion while pricing is a business function, > which > the IETF avoids because it could touch on anti-trust issues. > > At 02:59 PM 1/22/99 -0500, Henry Sinnreich wrote: > > > >This is an interesting problem. > > It is interesting largely because the historical coincidence of call > establishment, resource reservation, bandwidth consumption, and billing > which occurs in traditional telephony does not apply to IP telephony. IP > telephony can support calls that make no reservation (at the risk of poor > quality), consume no bandwidth (during silence suppression), or incur no > billing beyond that for IP-network access (when both ends are IP > stations). > > >Billing data and call admission can be done > >in the gateway controller, be it a call agent, SIP server, or H.323 > >gatekeeper, but these devices do not control QoS in the network nor do > they > >guarantee QoS. > > In contrast to telephony's reservation by the call originator (and > subsequent call-leg originating switches), resource reservation is made by > the receiver in IP networks. This is a fundamental complication, but not > necessarily one that demands new protocols. > > >Let's use the term call agent. The call agent has first to > >check with a policy server and also to find out if the QoS is indeed > >provided by the transport layer, the routers and L2 elements underneath, > >before charging for QoS. Would need actually to develop sort of a "call > >flow" showing the interactions between the client requesting a call, the > >call agent requesting QOS from the policy server, the reponses and > exception > >handling. > > > >Any thoughts on the message exchange regarding QoS for a call and for > policy > >decision (PDP and PEP - policy decision point and policy enforcement > point) > >and enforcement ? ... > >Or can it be done in a simpler way, without requiring the tight coupling > >envisaged above? > > "Simpler way" is in the eye of the beholder. Is this simple enough? > > The call agent must choose if the call is to have the QoS that requires > admission control. If it does, it requires RSVP both ways between > gateways, > and it accounts for the call based on the QoS it required. If RSVP is > invoked, the policy server that provides (via COPS) administrative > admission control based on ability to pay may accumulate charges based on > the reservation. Since reservations due to RSVP allocate the limited > resource of the high priority bandwidth, they should incur charges even if > used for applications other than IP telephony. > > Call agents would be well-advised to use something like the Open > Settlement > Protocol to apportion or accumulate charges for call legs in multiple > IP-telephony domains. The charges for calls should be sufficient to cover > the charges for the underlying (RSVP) resource allocations (unless the > business model has chosen a loss-leader for some business reason beyond > what we discuss in IETF circles). > > John Schnizlein > Consulting Engineer > --------- > This message came from the IETF IPTEL Working Group Mailing List. ------_=_NextPart_001_01BE470E.E8264910 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IP Telphony Gateway Billing

Hello,

Why not do flat rate billing = based solely on QoS?  The user signs up for a certain QoS level, = and all of their traffic is carried with at least that level of QoS, = with an allowable small deviation.

This would take billing out = of the gateway arena.

Ralph

    -----Original Message-----
    From:   John Schnizlein = [SMTP:jschnizl@cisco.com]
    Sent:   Friday, January 22, 1999 5:42 PM
    To:     Sinnreich, Heinrich
    Cc:     iptel@lists.research.bell-labs.com
    Subject:       = RE: IP Telphony Gateway = Billing

    Subtle change = in the title because technical mechanisms for billing are
    appropriate = for IETF discussion while pricing is a business function, which
    the IETF = avoids because it could touch on anti-trust issues.

    At 02:59 PM = 1/22/99 -0500, Henry Sinnreich wrote:
    >
    >This is = an interesting problem.

    It is = interesting largely because the historical coincidence of call
    establishment, resource reservation, bandwidth consumption, and = billing
    which occurs = in traditional telephony does not apply to IP telephony. IP
    telephony can = support calls that make no reservation (at the risk of poor
    quality), = consume no bandwidth (during silence suppression), or incur no
    billing = beyond that for IP-network access (when both ends are IP = stations).

    >Billing = data and call admission can be done
    >in the = gateway controller, be it a call agent, SIP server, or H.323
    >gatekeeper, but these devices do not control QoS in the = network nor do they
    >guarantee = QoS.

    In contrast to = telephony's reservation by the call originator (and
    subsequent = call-leg originating switches), resource reservation is made by
    the receiver = in IP networks. This is a fundamental complication, but not
    necessarily = one that demands new protocols.

    >Let's use = the term call agent. The call agent has first to
    >check = with a policy server and also to find out if the QoS is indeed
    >provided = by the transport layer, the routers and L2 elements underneath,
    >before = charging for QoS. Would need actually to develop sort of a = "call
    >flow" showing the interactions between the client = requesting a call, the
    >call = agent requesting QOS from the policy server, the reponses and = exception
    >handling.
    >
    >Any = thoughts on the message exchange regarding QoS for a call and for = policy
    >decision = (PDP and PEP - policy decision point and policy enforcement = point)
    >and = enforcement ? ...
    >Or can it = be done in a simpler way, without requiring the tight coupling
    >envisaged = above?

    "Simpler = way" is in the eye of the beholder. Is this simple enough?

    The call agent = must choose if the call is to have the QoS that requires
    admission = control. If it does, it requires RSVP both ways between = gateways,
    and it = accounts for the call based on the QoS it required. If RSVP is
    invoked, the = policy server that provides (via COPS) administrative
    admission = control based on ability to pay may accumulate charges based on
    the = reservation. Since reservations due to RSVP allocate the limited
    resource of = the high priority bandwidth, they should incur charges even if
    used for = applications other than IP telephony.

    Call agents = would be well-advised to use something like the Open Settlement
    Protocol to = apportion or accumulate charges for call legs in multiple
    IP-telephony = domains. The charges for calls should be sufficient to cover
    the charges = for the underlying (RSVP) resource allocations (unless the
    business = model has chosen a loss-leader for some business reason beyond
    what we = discuss in IETF circles).

    John = Schnizlein
    Consulting = Engineer
    ---------
    This message = came from the IETF IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE470E.E8264910-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sat Jan 23 21:02:17 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28250 for ; Sat, 23 Jan 1999 21:02:17 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id QAA03180 for iptel-outgoing; Sat, 23 Jan 1999 16:49:20 -0500 (EST) From: "Henry Sinnreich" To: , Cc: , Subject: RE: SIP Date: Sat, 23 Jan 1999 15:47:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Tim Dorcey writes: > I dunno, I think it could work out pretty well that way. If my IP phone > works just like my current telephone, then I don't want one. I > can't speak > for the people spending the billions of dollars, but I am most interested > in IP telephony for the innovations it will bring. Agree, it is not imitating the telephone network, but the platform for innovations that makes sense. Also, then it will not be IP telephony any more, but rather a rich mix of services, of which voice is just another component IMHO. Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of > TDorcey@ixl.com > Sent: Friday, January 22, 1999 8:52 PM > To: paul.jones@ties.itu.int > Cc: iptel@lists.research.bell-labs.com; confctrl@ISI.EDU > Subject: Re: SIP > > > At 4:34 PM -0700 1/22/99, Paul E. Jones wrote: > > > >When I go to the store to by my IP phone, bring it home, and > plug it into my > >hub, it should allow me to dial my grandmother's phone number > and her phone > >should ring. The mechanics of accomplishing that are complex, > and we must > >have agreements on how that should be done at every step of the way. In > >addition, I expect that my IP telephone will continue to work > for more than > >four years. > > > >Creating an "Implementation Agreement" as Douglas suggests is not a bad > >idea. It was not necessary with other protocols because they > were simple, > >the implementations were software-based and free (so cost was no > issue), and > >developed without interest from parties investing billions of > dollars. The > >last point is the key-- when people spend billions of dollars, > they expect > >it to work. Specifying a bunch of loosely related protocols and letting > >people build several implementations, picking and choosing incompatible > >components to address requirements, and waiting to see which one is > >"coolest" and declaring it the winning combination will not work > in the IP > >telephony space. > > I dunno, I think it could work out pretty well that way. If my IP phone > works just like my current telephone, then I don't want one. I > can't speak > for the people spending the billions of dollars, but I am most interested > in IP telephony for the innovations it will bring. And, I don't think > anyone would suggest that standards committees are fertile ground for > innovation; it's just not their mission. Also, let's not forget that it > took many years for the existing telephone system to reach it's current > level of maturity. > > Tim > > Tim Dorcey > iXL-Los Angeles > tdorcey@ixl.com > (310) 235-3928 > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-IPTEL@lists.research.bell-labs.com Sun Jan 24 05:02:53 1999 Received: from paperless.dnrc.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA01170 for ; Sun, 24 Jan 1999 05:02:52 -0500 (EST) Received: (from majordom@localhost) by paperless.dnrc.bell-labs.com (8.8.8/8.8.8) id AAA03757 for iptel-outgoing; Sun, 24 Jan 1999 00:17:45 -0500 (EST) From: "Dean Willis" To: "Hoefelmeyer, Ralph (MCI)" Cc: Subject: RE: IP Telphony Gateway metering Date: Sat, 23 Jan 1999 23:12:10 -0600 Message-ID: <001501be4758$184016a0$a9a22ca6@dwillispc3.mcit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Note the further slight change in subject. Billing, like pricing, is a business issue. Metering is an engineering problem, and Lord Kelvin would have it that measurement is a scientific one. Ralph asked: > Hello, > Why not do flat rate billing based solely on QoS? > The user signs up for a certain QoS level, and all > of their traffic is carried with at least that > level of QoS, with an allowable small deviation. > This would take billing out of the gateway arena. I believe the answer is "regulatory". US regulations require IXCs to pay LECS on a per-minute basis for call termination. This fee is a MAJOR component of the cost of a PSTN Long Distance call. Similar charges apply for international calls. Bypassing such fees is the main goal of near-term arbitrage players. I believe there is also a turnaround charge where LECs are paying ISPs for local calls terminated by the ISP. A gateway brings a call from Internet into PSTN or vice versa, which is probably going to make it full into the same regulatory kettle. So, we really need to meter gateway time. How it is charged/billed/priced is really a business discussion best held in another forum. If there is not gateway, then really the only meterable service delivered to a plain IP phone call is the QoS -- so we really need to be able to meter QoS too. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sun Jan 24 22:36:42 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA08418 for ; Sun, 24 Jan 1999 22:36:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A54C07FC8; Sun, 24 Jan 1999 22:31:18 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0097F7FC9; Sun, 24 Jan 1999 22:31:17 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.3.32.19990125142750.013b9c18@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 25 Jan 1999 14:27:50 +1100 To: "Henry Sinnreich" , "Jonathan Rosenberg" , "Paul E. Jones" From: Douglas Clowes Subject: RE: SIP Cc: "Henning Schulzrinne" , , "Aishling" , , In-Reply-To: References: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Henry, The number of people that I hear cursing Microsoft, and Netscape too, because they don't implement each other's features *today* is not small. Each browser only gets best effect when used with their own server. What works in a Netscape browser, only when served by a Netscape server (and v.v.) is an implementation agreement within the vendors browser and server teams - same for MS. Often, when I send a message to a mail exploder, I get back one or more non-delivery notices. Sometimes I get one mail message more than once. I suspect I get some messages not at all. On the latest available version of MS Explorer, I loaded a web page last week that told me my browser was too old. It was wrong. It was broken, just like the mail system. I can't send SMTP mail messages when I'm "off-net" because my provider will not allow it, because it has inadequate security. I can't use NTP/SNTP through firewalls because people block it. There are no end of ways the Internet, and IETF protocols, break or are broken. It really depends on your expectations, and those of your paying customers, whoever they may be. From consumers who expect to pick up a handset, push a button and talk to mom, without retarting their handset and redialling three times. From service providers who want to be able to buy a new box, and just plug it in, without hiring a consultant to tell them what support servers they will need and will it be compatible with their existing infrastructure. Incidentally, e-mail and web exchanges only occur under two specific circumstances: either you are lucky that there is a chain of commonality, or your software has implemented a great number of almost, but not quite the same protocols. My old POP/UUENCODE mail client has problems with the IMAP post office, and the MIME attachments. The free mail clients that support them are brain dead, so one day I'll fork out for a new one. Until then, I'll plod on and curse these IETF protocols. [The nice thing about standards is that there are so many of them from which to choose.] Douglas At 14:59 1999-01-22 -0500, Henry Sinnreich wrote: >Douglas writes: >> The solution seems to be the "Implementation Agreement" where, instead of >> the standards body picking and choosing, a group of vendors, implementors, >> or customers (or all three) get together and make the choices. Sometimes >> each group gets together separately and we get three or more IAs. > >We exchange here e-mail and web pages by using IETF standard protocols. Am >not aware that our applications, whatever they are, went through implementor >agreements and the like. > >Henry > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 10:55:36 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21081 for ; Mon, 25 Jan 1999 10:55:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F39D57FB8; Mon, 25 Jan 1999 09:49:34 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CFD0C7FCB; Mon, 25 Jan 1999 09:49:29 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Mon, 25 Jan 1999 06:03:22 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: IP Telphony Gateway Billing To: "Hoefelmeyer, Ralph (MCI)" Cc: "'John Schnizlein'" , "Sinnreich, Heinrich" , iptel@lists.research.bell-labs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Actually, the IETF-accepted term (as far as I can tell) is "collection of usage data", which can be used for capacity planning (of course, if you happen to feed the data into your billing system, that's up to you :). PatC > Hello, > > Why not do flat rate billing based solely on QoS? The user signs up for a > certain QoS level, and all of their traffic is carried with at least that > level of QoS, with an allowable small deviation. > This would take billing out of the gateway arena. > > Ralph > > > -----Original Message----- > > From: John Schnizlein [SMTP:jschnizl@cisco.com] > > Sent: Friday, January 22, 1999 5:42 PM > > To: Sinnreich, Heinrich > > Cc: iptel@lists.research.bell-labs.com > > Subject: RE: IP Telphony Gateway Billing > > > > Subtle change in the title because technical mechanisms for billing are > > appropriate for IETF discussion while pricing is a business function, > > which > > the IETF avoids because it could touch on anti-trust issues. > > > > At 02:59 PM 1/22/99 -0500, Henry Sinnreich wrote: > > > > > >This is an interesting problem. > > > > It is interesting largely because the historical coincidence of call > > establishment, resource reservation, bandwidth consumption, and billing > > which occurs in traditional telephony does not apply to IP telephony. IP > > telephony can support calls that make no reservation (at the risk of poor > > quality), consume no bandwidth (during silence suppression), or incur no > > billing beyond that for IP-network access (when both ends are IP > > stations). > > > > >Billing data and call admission can be done > > >in the gateway controller, be it a call agent, SIP server, or H.323 > > >gatekeeper, but these devices do not control QoS in the network nor do > > they > > >guarantee QoS. > > > > In contrast to telephony's reservation by the call originator (and > > subsequent call-leg originating switches), resource reservation is made by > > the receiver in IP networks. This is a fundamental complication, but not > > necessarily one that demands new protocols. > > > > >Let's use the term call agent. The call agent has first to > > >check with a policy server and also to find out if the QoS is indeed > > >provided by the transport layer, the routers and L2 elements underneath, > > >before charging for QoS. Would need actually to develop sort of a "call > > >flow" showing the interactions between the client requesting a call, the > > >call agent requesting QOS from the policy server, the reponses and > > exception > > >handling. > > > > > >Any thoughts on the message exchange regarding QoS for a call and for > > policy > > >decision (PDP and PEP - policy decision point and policy enforcement > > point) > > >and enforcement ? ... > > >Or can it be done in a simpler way, without requiring the tight coupling > > >envisaged above? > > > > "Simpler way" is in the eye of the beholder. Is this simple enough? > > > > The call agent must choose if the call is to have the QoS that requires > > admission control. If it does, it requires RSVP both ways between > > gateways, > > and it accounts for the call based on the QoS it required. If RSVP is > > invoked, the policy server that provides (via COPS) administrative > > admission control based on ability to pay may accumulate charges based on > > the reservation. Since reservations due to RSVP allocate the limited > > resource of the high priority bandwidth, they should incur charges even if > > used for applications other than IP telephony. > > > > Call agents would be well-advised to use something like the Open > > Settlement > > Protocol to apportion or accumulate charges for call legs in multiple > > IP-telephony domains. The charges for calls should be sufficient to cover > > the charges for the underlying (RSVP) resource allocations (unless the > > business model has chosen a loss-leader for some business reason beyond > > what we discuss in IETF circles). > > > > John Schnizlein > > Consulting Engineer > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 11:27:36 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21972 for ; Mon, 25 Jan 1999 11:27:33 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0938C7FC9; Mon, 25 Jan 1999 11:11:19 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 37F1F7FCB; Mon, 25 Jan 1999 11:11:18 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <4.1.19990125095810.00a77100@pop.netway.com> X-Sender: jayb@pop.netway.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 25 Jan 1999 11:02:07 -0500 To: "Paul E. Jones" , "Henry Sinnreich" , "Douglas Clowes" , "Jonathan Rosenberg" From: Jay Batson Subject: Re: SIP Cc: , , "Aishling" , , In-Reply-To: <01a801be465f$e668d520$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This thread is effectively pointing out the fact that there are philosophical differences between people. Not that one is "right" and one is "wrong." And that the protocol must allow accomodation. The issue is flexibility vs. degree of effort. When everyone is forced to agree and do precisely the same thing, progress speed slows from the speed of innovation to the speed of agreement. I, for one, *prefer* to live with some imperfection in exchange for faster innovation and change. I prefer Internet-speed to Telecom-speed. The very fact that two end nodes can agree to do whatever they want across an IP network, and that the IP network provides simple transport (hopefully soon with a QoS component), permits an incredible rate technology advancement. Last Thursday I learned about ImagineRadio -- a 'net-based "radio station" that I can customize to my tastes, and listen to with a Real Audio player. Supported by text ads (no voice-ads.) Some guy thought of it, and I simply added RealAudio to my web browser to support him. I didn't need UUNET to "agree on a implementation of personalized radio station traffic carriage." And no, it isn't as good as FM quality sound... yet. But I listen to it anyway because the music choice fits me better than anything I can get over the airwaves. And it all happened in a few months simply because the basic protocols existed -- not a standardization of how the protocols are supposed to be used. Where's PSTN "radio?" Non-existent. Today, I can choose to deploy to my company an email application that does *straight* text in a predictable, reliable, manageable way. Or I can choose to deploy Netscape/Outlook email and have graphics/rich-text displayed in-line, and pay for a higher degree of management/software cost in the process. Or get some other feature that some vendor provides, simply because POP and MIME are so elegantly extensible -- X-mynewfeature: application/mynew-whizbang-thing. We here at Pingtel have chose the innovative email, despite its warts. Of course, in either case, email gets through.... In contrast, look at how telco/cable-driven "interactive network" experiments have gone. Closed environments in limited regions with bogus, thinly disguised restaurant advertisements substituting for "entertainment" guides. Ask any business manager who has been in the "Smart Phone" business about telco-driven "interactive phone" trials where the telco provided the "content," email servers, .... (Minitel notwithstanding.) Compare that to boston.sidewalk.com, or www.boston.com, where there is competition, incredible innovation on how to organize information. This all works because of the genius of HTML/HTTP/Javascript/... on an "open," public IP network. Extensible, simple, text-based protocols that anybody can innovate around. And (let me cast a barb here) do without buying an expensive ASN.1 compiler... ;-) Paul may rightly feel that he wants a higher degree of stability and predictability. That the protocols should provide the same experience as the PSTN. This is his choice. He should find service providers who *focus* on this, and *eliminate* products from their network (and those to whom they connect) that would replicate the PSTN experience using IP technology. His service providers should *prohibit* technology that contains the degree of freedom that *I* would choose. However, *I* should be able to choose from service providers and products that are to IP Telephony what UUNET and Netscape are to the Internet: they provide reliable, basic, and extensible infrastructure that can be extended at will between consenting parties. I *want* things to work the way HTTP, HTML, SMTP/POP, ..., all work today, warts and all, because I want the innovation. I *want* an ITSP that will, at some point in the future, provide me with the ability to buy/install (at my site) my own leading-edge application that will take in my SMTP mail, and use "3rd party signalling" with my ITSP (via SIP/MGCP/whatever) to set up a voice phone call between me on my IP wireless (premises) phone (from Symbol Technologies) and the sender of a SMTP message, via a service-provider-run IP/PSTN gateway, all because the words "CALL ME" were in the subject line of the SMTP message. And I want the protocol open enough so that Joe's Software in Palo Alto can write the application, sell it to me, and have it work with my ITSP's (probably Henry's, er, MCI/Worldcom's ;-) IP/PSTN voice network. And if it doesn't work occasionally because it's still immature, I'll put up with it because the infrastructure -- read "the protocols" -- permitted the extensibility *without* requiring absolute, rigid adherence to the *way* in which they should be used. Paul Jones says: >We cannot and should not expect our telephone system to act this way. There is another "we" who feels an entirely contrary way: We cannot and should not constrain the IP voice systems of the future -- they can, and *should* work the way web browsers/email/... all work today, with the need to upgrade/install software to get the new whiz-bang features. The price of innovation is that you have to work to keep up. Give me the work anyday as long as you give me the innovation. Give me choices in how to locate users. Give me choices in how to select IP/PSTN gateways. Let me choose which QoS choice I want (by giving ITSPs choices in products to deploy.) I want a *choice* in *what happens* when I pick up the phone to call grandma. I *do* want it to connect. I do want some base level functionality -- just as HTML/SMTP/... all do their basic job on the 'net. But let extensibility roam free. If in the process, products don't work with each other, fix 'em. Everything does *not* need to be perfect day-one. This has plenty of precedent in the IP world. Back in the early days of IP dialup, when we called it "Remote Access," various dialup servers didn't all work with the same client software. We all used PPP, but "differently." The market didn't buy it. Customers demanded that a Mac PPP, a Win 3.1 PPP, and a Win95 PPP all be able to dial into the same server. So we created the "PPP Forum," and did PPP "bakeoffs." (Just like the VoIP Forum....) Today, do you have any *clue* whether you're dialing into an Ascend box or a 3Com/USR box at your ISP? No. This is not intended as derogatory, but to my mind, this is a pure "bell-head vs. net-head" discussion. The net-head approach to protocols has certainly created some great new innovations in the last 5-10 years. I'd sure hate to take that away from IP telphony's future. Cheers -jb At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote: >Henry Sinnreich wrote: >>Douglas writes: >>> The solution seems to be the "Implementation Agreement" where, instead of >>> the standards body picking and choosing, a group of vendors, implementors, >>> or customers (or all three) get together and make the choices. Sometimes >>> each group gets together separately and we get three or more IAs. >> >>We exchange here e-mail and web pages by using IETF standard protocols. Am >>not aware that our applications, whatever they are, went through implementor >>agreements and the like. > >But even mail and web services are not without problems.... >However, it has not been without pain on the users-- they have had to >upgrade their software every time a new "whiz-bang" feature was added.... > >We cannot and should not expect our telephone system to act this way. ---------- Jay Batson President, CEO Pingtel Corp. jbatson@pingtel.com 781-938-5306 (office) 781-938-9650 (fax) --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 11:30:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22032 for ; Mon, 25 Jan 1999 11:30:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 06FC67FCF; Mon, 25 Jan 1999 09:50:00 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 854567FCD; Mon, 25 Jan 1999 09:49:44 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36ABF179.323460FE@lucent.com> Date: Sun, 24 Jan 1999 23:22:17 -0500 From: Grenville Armitage Reply-To: gja@lucent.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Clowes Cc: iptel@lists.research.bell-labs.com Subject: Re: SIP References: <3.0.3.32.19990122135730.015a62ac@mail.ozemail.com.au> <3.0.3.32.19990125142750.013b9c18@mail.ozemail.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas, Douglas Clowes wrote: [..] > The free mail clients that > support them are brain dead, so one day I'll fork out for a new one. Until > then, I'll plod on and curse these IETF protocols. [The nice thing about > standards is that there are so many of them from which to choose.] Yeah, the world's a pretty rough place. I remember a time when TV signals used different formats in many countries around the world, you couldn't simply travel to another country and plug your appliances or phones in (lest the plug and/or voltage be wrong), and even the people insisted on speaking different languages (unless you were lucky enough to meet someone who implemented a local variation of English or something that partially interworked with your preferred tongue) Now I've forgotten what the point of the thread was..... :) cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Multiservice Core Data Networks http://www.lucent.com/dns --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 11:54:51 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22854 for ; Mon, 25 Jan 1999 11:54:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3F5447FCB; Mon, 25 Jan 1999 11:49:17 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6BA7B7FCC; Mon, 25 Jan 1999 11:49:16 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "David R. Oran" To: "Jim Toga" , "Jonathan Rosenberg" , "Paul E. Jones" Cc: , "Aishling" , Subject: RE: SIP Date: Mon, 25 Jan 1999 11:47:09 -0500 Message-ID: <002d01be4882$598cca60$08d245ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > >What if there are no servers? What if users try and contact > each other > >directly? In that case, you will need to make use of network QoS > >management techniques. This is also not SIP specific. If two H.323 > >terminals communicate directly, you'll have the same problem. > > This is exactly why the standard stipulates that _if_ Gatekeepers are > present, they must be utilized. > I just hide when the protocol police come knocking. Lucky I haven't been caught yet. Whew. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 14:16:23 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA25051 for ; Mon, 25 Jan 1999 14:16:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5B8EE7FB7; Mon, 25 Jan 1999 09:53:40 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1B5507FC9; Mon, 25 Jan 1999 09:51:18 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Mohammed Atiquzzaman" To: iptel@lists.research.bell-labs.com Date: Mon, 25 Jan 1999 09:35:21 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: CFP: Internet Telephony Reply-To: atiq@engr.udayton.edu Message-Id: <19990125143503.85C9E7FEA@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Call for Papers Special Issue of IEEE COMMUNICATION MAGAZINE on Internet Telephony Due to the potential economic advantages, the integration of several media is desirable and very attractive. Today, however, voice over IP remains somewhat of a technical novelty, hindred by a number of existing problems to provide an assured voice quality. The likely prognosis is that over the next year or two, the advent of Resource Reservation Protocol (RSVP) and increased enterprise network bandwidth (achieved with ATM WAN services) could give a boost to voice over IP. This special issue is to bring experts in the field to share with IEEE COMMUNICATION MAGAZINE readers the current problems, components, and experiments in "Internet Telephony". Desirable features of a voice-over-IP system include: * Optimal use of bandwidth. * Capacity management. * Support of speech quality. * Flexible integration into voice environment (e.g., PBX). * Enterprise network ready (support LAN/WAN/Internet protocols for direct attachment). * System-level scalability: must be easy to add PBX-side interfaces to support growth in requirements and appropriate links. * Network-level scalability: must be able to support mapping of a sufficient number of extensions (perhaps several thousands) to the respective IP addresses of the destination gateway. A master database with distributed upgrade may be desirable. IEEE COMMUNICATION MAGAZINE announces a forthcoming issue on "Internet Telephony". Prospective authors should follow IEEE COMMUNICATION MAGAZINE guidelines and submit an electronic (PDF file or a PostScript file viewable by Ghostview) copy of the manuscript to one of the Guest Editors listed below. Articles addressing both traditional and innovative products will be given preference. Topics include, but are not limited to: * Voice over IP/ATM * IP over ATM/FR for Multimedia * Traffic Control for Multimedia/Internet Telephony * QoS Control of Voice over IP * Evolution of the VPN and PBX environment * Traffic Capacity Management and Routing Algorithms for Multimedia. Full manuscript submission deadline June 30, 1999 Notification of acceptance October 30, 1999 Publication Schedule April 2000 Mohsen Guizani Ammar Rayes Mohammed Atiquzzaman Elec. & Comp. Engr. Director, Solution Arch. Elec. & Comp. Engr. Univ. of Missouri-Columbia Traffic Capacity Manag. 300 College Park 5605 Troost Avenue & Planning University of Dayton Kansas City, Bellcore, 444 Hoes Lane Dayton, MO 64110-2823, USA. Piscataway, NJ 08854, USA. Ohio 45469-0226, USA. Tel: (816) 235-1550 Tel: (732) 699-3669 Tel. (937) 229 3183 Fax: (816) 235-1260 arayes@notes.cc.bellcore.com Fax. (937) 229-4529 guizanim@umkc.edu atiq@engr.udayton.edu --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 14:37:13 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA25490 for ; Mon, 25 Jan 1999 14:37:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A56657FCC; Mon, 25 Jan 1999 14:31:09 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EFEE47FCD; Mon, 25 Jan 1999 14:31:08 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36ACC5E8.F66115CC@dnrc.bell-labs.com> Date: Mon, 25 Jan 1999 14:28:40 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Dean Willis Cc: "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com Subject: Re: IP Telphony Gateway metering References: <001501be4758$184016a0$a9a22ca6@dwillispc3.mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Dean Willis wrote: > > Note the further slight change in subject. Billing, like pricing, is a > business issue. Metering is an engineering problem, and Lord Kelvin > would have it that measurement is a scientific one. > > Ralph asked: > > > Hello, > > Why not do flat rate billing based solely on QoS? > > The user signs up for a certain QoS level, and all > > of their traffic is carried with at least that > > level of QoS, with an allowable small deviation. > > This would take billing out of the gateway arena. > > I believe the answer is "regulatory". US regulations require IXCs to pay > LECS on a per-minute basis for call termination. This fee is a MAJOR > component of the cost of a PSTN Long Distance call. Similar charges > apply for international calls. Bypassing such fees is the main goal of > near-term arbitrage players. I believe there is also a turnaround charge > where LECs are paying ISPs for local calls terminated by the ISP. > > A gateway brings a call from Internet into PSTN or vice versa, which is > probably going to make it full into the same regulatory kettle. I think that there is really more than one thing to bill for here, and that different models (and metering requirements) apply to the various components. The things you might pay for in an IP telephony environnment are: 1. Qos in the IP network 2. gateway services 3. database queries (like name lookups) 4. execution of service logic (ala CPL) 5. proxy services (like some kind of mobility service in SIP) Perhaps flat rate makes sense of QoS (I pay $29.95 a month for gold service, $19.95 for regular, best effort). Dean gives good reasons why flat rate might not make sense for gateways. For services like database queries, things like per-minute billing don't even make sense, so flat rate or per-transaction probably is more appropriate. Note that not all of these components would be in every call; there are no gateways for an IP to IP call. Nothing prevents your service provider from rolling up these various services into one bill, but I think it would be nice to get these different components from different providers if the customer wants. Each, of course, requires monitoring and some means of reporting usage statistics to some servers that collect the data and generate bills or whatever. Based on this, it would make sense that (1) gateways report usage statistics for gateway usage, (2) COPS servers or bandwidth brokers or border elements provide QoS usage statistics, (3) and SIP servers/gatekeepers provide proxy, service logic, and perhaps database query usage. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 15:02:28 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA26051 for ; Mon, 25 Jan 1999 15:02:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7E9D87FCD; Mon, 25 Jan 1999 14:57:19 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D5E1B7FCE; Mon, 25 Jan 1999 14:57:18 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Mon, 25 Jan 1999 11:55:23 -0800 (PST) From: Sujatha Balaraman Reply-To: Sujatha Balaraman To: Jonathan Rosenberg Cc: iptel@lists.research.bell-labs.com Subject: Re: IP Telphony Gateway metering In-Reply-To: <36ACC5E8.F66115CC@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Would it be fair to meter a user's call on basis of his proximity to the Gateway ? For instance, if a user utilises a gateway closer to him for a destination which is pretty far from the gateway(say useing a longer trunk) would he actually be charged more by the gateway, in addition to being charged more by the PSTN ? Also, considering that the longer the distance covered on the IP in contrast to the PSTN, the quality of the call is expected to be lower..., so would it be fair to assume that the lesser number of hops or distance,a call uses IP the network , the more expensive the call becomes. This is just a thought, I want to know if it sounds reasonable ? Sujatha. ------------------------------ On Mon, 25 Jan 1999, Jonathan Rosenberg wrote: > Date: Mon, 25 Jan 1999 14:28:40 -0500 > From: Jonathan Rosenberg > To: Dean Willis > Cc: "Hoefelmeyer, Ralph (MCI)" , > iptel@lists.research.bell-labs.com > Subject: Re: IP Telphony Gateway metering > > Dean Willis wrote: > > > > Note the further slight change in subject. Billing, like pricing, is a > > business issue. Metering is an engineering problem, and Lord Kelvin > > would have it that measurement is a scientific one. > > > > Ralph asked: > > > > > Hello, > > > Why not do flat rate billing based solely on QoS? > > > The user signs up for a certain QoS level, and all > > > of their traffic is carried with at least that > > > level of QoS, with an allowable small deviation. > > > This would take billing out of the gateway arena. > > > > I believe the answer is "regulatory". US regulations require IXCs to pay > > LECS on a per-minute basis for call termination. This fee is a MAJOR > > component of the cost of a PSTN Long Distance call. Similar charges > > apply for international calls. Bypassing such fees is the main goal of > > near-term arbitrage players. I believe there is also a turnaround charge > > where LECs are paying ISPs for local calls terminated by the ISP. > > > > A gateway brings a call from Internet into PSTN or vice versa, which is > > probably going to make it full into the same regulatory kettle. > > I think that there is really more than one thing to bill for here, and > that different models (and metering requirements) apply to the various > components. The things you might pay for in an IP telephony environnment > are: > > 1. Qos in the IP network > 2. gateway services > 3. database queries (like name lookups) > 4. execution of service logic (ala CPL) > 5. proxy services (like some kind of mobility service in SIP) > > Perhaps flat rate makes sense of QoS (I pay $29.95 a month for gold > service, $19.95 for regular, best effort). Dean gives good reasons why > flat rate might not make sense for gateways. For services like database > queries, things like per-minute billing don't even make sense, so flat > rate or per-transaction probably is more appropriate. Note that not all > of these components would be in every call; there are no gateways for an > IP to IP call. > > Nothing prevents your service provider from rolling up these various > services into one bill, but I think it would be nice to get these > different components from different providers if the customer wants. > Each, of course, requires monitoring and some means of reporting usage > statistics to some servers that collect the data and generate bills or > whatever. Based on this, it would make sense that (1) gateways report > usage statistics for gateway usage, (2) COPS servers or bandwidth > brokers or border elements provide QoS usage statistics, (3) and SIP > servers/gatekeepers provide proxy, service logic, and perhaps database > query usage. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > ****************************************************************************** Sujatha Balaraman * e-mail :sujathab@ece.ucdavis.edu 609, Anderson Road * sbalaraman@ucdavis.edu Apt: 287, * Davis * Ph: 530-750-3897 CA 95616 * ******************************************************************************* --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 16:16:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27339 for ; Mon, 25 Jan 1999 16:16:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 236357FCE; Mon, 25 Jan 1999 15:07:16 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 932297FD0; Mon, 25 Jan 1999 15:07:15 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Dean Willis" To: "Jonathan Rosenberg" Cc: Subject: RE: IP Telphony Gateway metering Date: Mon, 25 Jan 1999 14:04:39 -0600 Message-ID: <000001be489d$f08584a0$67e323a6@dwillispc3.mcit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <36ACC5E8.F66115CC@dnrc.bell-labs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Jonathan listed: > I think that there is really more than one thing to bill for here, and > that different models (and metering requirements) apply to the various > components. The things you might pay for in an IP telephony > environnment > are: > > 1. Qos in the IP network > 2. gateway services > 3. database queries (like name lookups) > 4. execution of service logic (ala CPL) > 5. proxy services (like some kind of mobility service in SIP) which is a nice summary. But, methinks he left one category off: Media services. Storage, retrieval, transcoding, splitting, recognition, ad nauseata are all nifty things that can be metered, packaged, bartered and so on to add value to basic call services. There is no reason why any one call might not combine many services across all (6) categories from many vendors, with different call participants paying for separate subsets of the services utilized and potentially with settlements between carriers/providers for some of the services. Wow. -- Dean --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 16:20:18 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27392 for ; Mon, 25 Jan 1999 16:20:17 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8172E7FD0; Mon, 25 Jan 1999 15:20:53 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B963C7FD1; Mon, 25 Jan 1999 15:20:52 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <5CB32D2B7DECD111AEA200805F95D60F01C9E0A1@NJ0117EXCH001U> From: "Rollender, Douglas Harold (Douglas)" To: Jonathan Rosenberg , Sujatha Balaraman Cc: iptel@lists.research.bell-labs.com Subject: RE: IP Telphony Gateway metering Date: Mon, 25 Jan 1999 15:20:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk And if the call is wireless and the user is moving...... ---------- From: Sujatha Balaraman [SMTP:sujathab@ece.ucdavis.edu] Sent: Monday, January 25, 1999 2:55 PM To: Jonathan Rosenberg Cc: iptel@lists.research.bell-labs.com Subject: Re: IP Telphony Gateway metering Would it be fair to meter a user's call on basis of his proximity to the Gateway ? For instance, if a user utilises a gateway closer to him for a destination which is pretty far from the gateway(say useing a longer trunk) would he actually be charged more by the gateway, in addition to being charged more by the PSTN ? Also, considering that the longer the distance covered on the IP in contrast to the PSTN, the quality of the call is expected to be lower..., so would it be fair to assume that the lesser number of hops or distance,a call uses IP the network , the more expensive the call becomes. This is just a thought, I want to know if it sounds reasonable ? Sujatha. ------------------------------ On Mon, 25 Jan 1999, Jonathan Rosenberg wrote: > Date: Mon, 25 Jan 1999 14:28:40 -0500 > From: Jonathan Rosenberg > To: Dean Willis > Cc: "Hoefelmeyer, Ralph (MCI)" , > iptel@lists.research.bell-labs.com > Subject: Re: IP Telphony Gateway metering > > Dean Willis wrote: > > > > Note the further slight change in subject. Billing, like pricing, is a > > business issue. Metering is an engineering problem, and Lord Kelvin > > would have it that measurement is a scientific one. > > > > Ralph asked: > > > > > Hello, > > > Why not do flat rate billing based solely on QoS? > > > The user signs up for a certain QoS level, and all > > > of their traffic is carried with at least that > > > level of QoS, with an allowable small deviation. > > > This would take billing out of the gateway arena. > > > > I believe the answer is "regulatory". US regulations require IXCs to pay > > LECS on a per-minute basis for call termination. This fee is a MAJOR > > component of the cost of a PSTN Long Distance call. Similar charges > > apply for international calls. Bypassing such fees is the main goal of > > near-term arbitrage players. I believe there is also a turnaround charge > > where LECs are paying ISPs for local calls terminated by the ISP. > > > > A gateway brings a call from Internet into PSTN or vice versa, which is > > probably going to make it full into the same regulatory kettle. > > I think that there is really more than one thing to bill for here, and > that different models (and metering requirements) apply to the various > components. The things you might pay for in an IP telephony environnment > are: > > 1. Qos in the IP network > 2. gateway services > 3. database queries (like name lookups) > 4. execution of service logic (ala CPL) > 5. proxy services (like some kind of mobility service in SIP) > > Perhaps flat rate makes sense of QoS (I pay $29.95 a month for gold > service, $19.95 for regular, best effort). Dean gives good reasons why > flat rate might not make sense for gateways. For services like database > queries, things like per-minute billing don't even make sense, so flat > rate or per-transaction probably is more appropriate. Note that not all > of these components would be in every call; there are no gateways for an > IP to IP call. > > Nothing prevents your service provider from rolling up these various > services into one bill, but I think it would be nice to get these > different components from different providers if the customer wants. > Each, of course, requires monitoring and some means of reporting usage > statistics to some servers that collect the data and generate bills or > whatever. Based on this, it would make sense that (1) gateways report > usage statistics for gateway usage, (2) COPS servers or bandwidth > brokers or border elements provide QoS usage statistics, (3) and SIP > servers/gatekeepers provide proxy, service logic, and perhaps database > query usage. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > **************************************************************************** ** Sujatha Balaraman * e-mail :sujathab@ece.ucdavis.edu 609, Anderson Road * sbalaraman@ucdavis.edu Apt: 287, * Davis * Ph: 530-750-3897 CA 95616 * **************************************************************************** *** --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 16:46:28 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27853 for ; Mon, 25 Jan 1999 16:46:28 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 939057FD1; Mon, 25 Jan 1999 16:41:16 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E4C407FD2; Mon, 25 Jan 1999 16:41:15 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.5.32.19990125133851.00801a70@orsmsx30> X-Sender: jtoga@orsmsx30 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 25 Jan 1999 13:38:51 -0800 To: "David R. Oran" , "Jonathan Rosenberg" , "Paul E. Jones" From: Jim Toga Subject: RE: SIP Cc: , "Aishling" , In-Reply-To: <002d01be4882$598cca60$08d245ab@cisco.com> References: <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk From within a PDU, no one can hear you scream..... At 11:47 AM 1/25/99 -0500, David R. Oran wrote: >> >What if there are no servers? What if users try and contact >> each other >> >directly? In that case, you will need to make use of network QoS >> >management techniques. This is also not SIP specific. If two H.323 >> >terminals communicate directly, you'll have the same problem. >> >> This is exactly why the standard stipulates that _if_ Gatekeepers are >> present, they must be utilized. >> >I just hide when the protocol police come knocking. Lucky I haven't been >caught yet. Whew. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 17:09:49 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28240 for ; Mon, 25 Jan 1999 17:09:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C23BC7FD2; Mon, 25 Jan 1999 17:05:18 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 357F67FD3; Mon, 25 Jan 1999 17:05:17 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Henry Sinnreich" To: "Jonathan Rosenberg" , "Dean Willis" Cc: "Hoefelmeyer, Ralph (MCI)" , Subject: RE: IP Telphony Gateway metering Date: Mon, 25 Jan 1999 16:02:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-reply-to: <36ACC5E8.F66115CC@dnrc.bell-labs.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Importance: Normal Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk It appears that for Internet-wide standard AA(A) and metering (instead of the 3rd (A)), there is some work cut out for a possible BOF -> WG to agree on * Data excahnge with the AA(A) system, * Data exchange with the policy server using COPS, * Gateway metering, * RSVP and/or DiffServ metering, * IMHO a data format, why not XML? Would be nice to agree on a framework and see if there is something missing or has to be written. Any interest in this? Thanks, Henry Jonathan Rosenberg wrote: >it would make sense that (1) gateways report > usage statistics for gateway usage, (2) COPS servers or bandwidth > brokers or border elements provide QoS usage statistics, (3) and SIP > servers/gatekeepers provide proxy, service logic, and perhaps database > query usage. and John Schnizlein has similar thoughts: >The call agent must choose if the call is to have the QoS that requires >admission control. If it does, it requires RSVP both ways between gateways, >and it accounts for the call based on the QoS it required. If RSVP is >invoked, the policy server that provides (via COPS) administrative >admission control based on ability to pay may accumulate charges based on >the reservation. Since reservations due to RSVP allocate the limited >resource of the high priority bandwidth, they should incur charges even if >used for applications other than IP telephony. >Call agents would be well-advised to use something like the Open Settlement >Protocol to apportion or accumulate charges for call legs in multiple >IP-telephony domains. The charges for calls should be sufficient to cover >the charges for the underlying (RSVP) resource allocations (unless the >business model has chosen a loss-leader for some business reason beyond >what we discuss in IETF circles). Pat Calhoun's perspective >Actually, the IETF-accepted term (as far as I can tell) is "collection of >usage data", which can be used for capacity planning (of course, if you happen >to feed the data into your billing system, that's up to you :). has IMHO the outlook that for what usage you cannot bill, that usage is still usefull for traffic statistics, and I tend to agree that such data can be the obejct of a value added service. > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Monday, January 25, 1999 2:29 PM > To: Dean Willis > Cc: Hoefelmeyer, Ralph (MCI); iptel@lists.research.bell-labs.com > Subject: Re: IP Telphony Gateway metering > > > Dean Willis wrote: > > > > Note the further slight change in subject. Billing, like pricing, is a > > business issue. Metering is an engineering problem, and Lord Kelvin > > would have it that measurement is a scientific one. > > > > Ralph asked: > > > > > Hello, > > > Why not do flat rate billing based solely on QoS? > > > The user signs up for a certain QoS level, and all > > > of their traffic is carried with at least that > > > level of QoS, with an allowable small deviation. > > > This would take billing out of the gateway arena. > > > > I believe the answer is "regulatory". US regulations require IXCs to pay > > LECS on a per-minute basis for call termination. This fee is a MAJOR > > component of the cost of a PSTN Long Distance call. Similar charges > > apply for international calls. Bypassing such fees is the main goal of > > near-term arbitrage players. I believe there is also a turnaround charge > > where LECs are paying ISPs for local calls terminated by the ISP. > > > > A gateway brings a call from Internet into PSTN or vice versa, which is > > probably going to make it full into the same regulatory kettle. > > I think that there is really more than one thing to bill for here, and > that different models (and metering requirements) apply to the various > components. The things you might pay for in an IP telephony environnment > are: > > 1. Qos in the IP network > 2. gateway services > 3. database queries (like name lookups) > 4. execution of service logic (ala CPL) > 5. proxy services (like some kind of mobility service in SIP) > > Perhaps flat rate makes sense of QoS (I pay $29.95 a month for gold > service, $19.95 for regular, best effort). Dean gives good reasons why > flat rate might not make sense for gateways. For services like database > queries, things like per-minute billing don't even make sense, so flat > rate or per-transaction probably is more appropriate. Note that not all > of these components would be in every call; there are no gateways for an > IP to IP call. > > Nothing prevents your service provider from rolling up these various > services into one bill, but I think it would be nice to get these > different components from different providers if the customer wants. > Each, of course, requires monitoring and some means of reporting usage > statistics to some servers that collect the data and generate bills or > whatever. Based on this, it would make sense that (1) gateways report > usage statistics for gateway usage, (2) COPS servers or bandwidth > brokers or border elements provide QoS usage statistics, (3) and SIP > servers/gatekeepers provide proxy, service logic, and perhaps database > query usage. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 17:55:56 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA28836 for ; Mon, 25 Jan 1999 17:55:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3E1BC7FD3; Mon, 25 Jan 1999 17:49:23 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6C7177FD6; Mon, 25 Jan 1999 17:49:22 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Authentication-Warning: renown: ts009d45.cht-ma.concentric.net [206.173.20.201] didn't use HELO protocol Message-Id: <4.0.1.19990125115546.00df9f10@pop3.metatel.com> Message-Id: <4.0.1.19990125115546.00df9f10@pop3.metatel.com> X-Sender: scott.petrack@metatel.com@pop3.metatel.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 25 Jan 1999 17:46:18 -0500 To: Jim Toga , Jonathan Rosenberg , "Paul E. Jones" From: Scott Petrack Subject: Re: SIP Cc: Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com In-Reply-To: <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> References: <36A79B95.4A0D344F@dnrc.bell-labs.com> <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 04:42 PM 1/21/99 -0800, Jim Toga wrote: > >Call admission by H.323 Gatekeepers can be used in this case to match >provisioning with capacity. The behaviour might exactly mimic the current >PSTN. > There is unfortunately a fundamental difference between the PSTN behavior and what an H.323 network can do. When the PSTN decides that there isn't enough capacity, the end user gets a Network Busy signal and there is nothing else s/he can do to affect the telephone network. This is because of the fundamental distinction made in the PSTN between "NNI" (network-network interfaces) and "UNI" (user-network interfaces). The signalling which tells the switch "No you may NOT make that call" stays entirely inside the network, and the business contracts and regulation that bind operators guarantee that when that happens, the end user will not get anything but a busy signal. He will not be able to mess things up for anyone else. But H.323 signalling is not NNI -- it goes all the way out the endpoint. So if a gatekeeper tells an endpoint (which might be a terminal) "No you may NOT make that call", and the endpoint can get via other means (say email) the RTP address of the remote endpoint. He can blast away. It may sound bad, and not many packets might get through, but he can certainly inject the packets into the network and still mess things up for everybody else. There is no way within H.323 to connect the permission that a gatekeeper might or might not give, with the opening and closing of IP connectivity to the endpoint, and there is in the PSTN. Note that even if such a connection existed, it would not really help, because there are many different kinds of traffic which affect capacity, not just H.323: even if the Gatekeeper really could stop me from sending RTP traffic from being sent when it forbids an H.323 call to complete, it won't be able to stop me from sending Email, ftp, etc. The bottom line is that Gatekeepers are not enough, unfortunately, although the analogous mechanism is enough in the PSTN -- because the business contracts and laws are there and because there is only one single application running (voice). >>What if there are no servers? What if users try and contact each other >>directly? In that case, you will need to make use of network QoS >>management techniques. This is also not SIP specific. If two H.323 >>terminals communicate directly, you'll have the same problem. > >This is exactly why the standard stipulates that _if_ Gatekeepers are >present, they must be utilized. > Yes, and _if_ seatbelts are present, they must be utilized. The law says so. But as long as there are cars which go on the highways even if you don't buckle up, then innocent people are not going to get their very precious little packets trashed because of people who don't listen when the red "gatekeeper" light flashes on their dashboards. Scott --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 18:03:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA29058 for ; Mon, 25 Jan 1999 18:03:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 827B67FD4; Mon, 25 Jan 1999 17:51:37 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 115A37FD5; Mon, 25 Jan 1999 17:50:14 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Authentication-Warning: renown: ts009d45.cht-ma.concentric.net [206.173.20.201] didn't use HELO protocol Message-Id: <4.0.1.19990125122746.00df9be0@pop3.metatel.com> X-Sender: scott.petrack@metatel.com@pop3.metatel.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 25 Jan 1999 12:44:32 -0500 To: Douglas Clowes , Jonathan Rosenberg , Jim Toga From: Scott Petrack Subject: Re: SIP Cc: "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu In-Reply-To: <3.0.3.32.19990122143531.01530df4@mail.ozemail.com.au> References: <36A7DC53.D1CA449B@dnrc.bell-labs.com> <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 02:35 PM 1/22/99 +1100, Douglas Clowes wrote: >Let's see now, a firewall with proxies that only let through known >protocols and check with the gatekeeper for H.323 admission. Scarey! In H.323 you would probably use "gatekeeper routed calls" - that is, the gatekeeper itself is the signalling proxy that only lets though known and permitted signalling, and tells the relevant RTP firewall what to let through. (But this is just quibbling with the words you use). And if the signalling is SIP then you replace "gatekeeper" with "SIP proxy server." Although you can do it this way, unfortunately you have created -- the phone system! That is, the RTP firewall looks a lot like a switch, because you have to make certain that all the RTP traffic goes through that box. The originating endpoint will never see the RTP address of the remote endpoint, but only the address of the RTP firewall. So all of end-to-end routing has been thrown away -- just like in the phone system. Of course, similarly, we will need, SMTP firewalls and special DNS servers which can give out addresses of MX machines which can do QoS email, and other special DNS servers and HTTP firewalls which can do QoS web-browsing, etc. etc. etc. In the end we will have overlaid 1000 different parallel Internets on top of the current Internet. I know many people who share this "dream". A better, more scaleable, goal, is to separate out the QoS infrastructure from the needs of any particular application, and instead of having H.323 Gatekeepers, HTTP Gatekeepers, SMTP gatekeepers, etc. etc. etc., just having an infrastructure for QoS that allows applications to seize the required Internet resources without any reference to any particular application. It may end up being impossible to do, but it's the only hope that we'll get QoS for all the Internet applications that need it. It may well be that there is still a need for the single-application servers, in order to enable really dumb hard-coded appliances that will not want to deal with the QoS signalling themselves. But these servers will need to hand-off decision-making to the real QoS infrastructure. Scott --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 18:13:58 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA29255 for ; Mon, 25 Jan 1999 18:13:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6442A7FD8; Mon, 25 Jan 1999 18:07:48 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F3BAC7FDF; Mon, 25 Jan 1999 18:07:46 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36ACF98D.167BA5A9@dnrc.bell-labs.com> Date: Mon, 25 Jan 1999 18:09:01 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Henry Sinnreich Cc: Jonathan Rosenberg , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com Subject: Re: IP Telphony Gateway metering References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Henry Sinnreich wrote: > > It appears that for Internet-wide standard AA(A) and metering (instead of > the 3rd (A)), there is some work cut out for a possible BOF -> WG to agree > on > > * Data excahnge with the AA(A) system, > * Data exchange with the policy server using COPS, > * Gateway metering, > * RSVP and/or DiffServ metering, > * IMHO a data format, why not XML? > Hentry, More importantly, we need to correlate metering information from different applications. For example, SIP session duration is monitored via some policy servers. However, the actual user data (with RSVP enabled) may take a path that is completely different from what SIP messages are going. The policy servers hence need to collect the data information and map it to the corresponding SIP session to accounting purposes. As for the data format, I have no problem with XML format if all network components are a bunch of Unix/NT servers. For the conventional routers, I doubt that they have spare CPU cycles to process XML messages. In the future, I don't care if all routers run JAVA, but not for now, please. :-) Why cannot we simply send more traditional protocol messages? > Would be nice to agree on a framework and see if there is something missing > or has to be written. > Any interest in this? > Isn't AAA group trying to put one together? > Thanks, Henry > > Regards, - Ping --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 18:18:12 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA29385 for ; Mon, 25 Jan 1999 18:18:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2A6A57FD7; Mon, 25 Jan 1999 17:49:48 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 86DA57FD4; Mon, 25 Jan 1999 17:49:39 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Authentication-Warning: renown: ts009d45.cht-ma.concentric.net [206.173.20.201] didn't use HELO protocol Message-Id: <4.0.1.19990125124817.00dfc270@pop3.metatel.com> X-Sender: scott.petrack@metatel.com@pop3.metatel.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 25 Jan 1999 13:02:02 -0500 To: "Paul E. Jones" , "Henry Sinnreich" , "Douglas Clowes" , "Jonathan Rosenberg" From: Scott Petrack Subject: Re: SIP Cc: "Henning Schulzrinne" , , "Aishling" , , In-Reply-To: <01a801be465f$e668d520$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote: > >But even mail and web services are not without problems. Take a web browser >written in 1995 and visit some of today's more elaborate web sites. Create >an e-mail with Microsoft's Outlook Express using HTML and send it to a user >with a mail client written in 1995 (heck, send it to a Netscape user with >up-to-date software). > >It is true that most of today's mail clients can understand SMTP, POP3, >IMAP, HTML, MIME, etc. It is also true that most of today's web browsers >can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc. >However, it has not been without pain on the users-- they have had to >upgrade their software every time a new "whiz-bang" feature was added. Be >prepared to upgrade your web browsers again soon as XML and XSL displace >much of HTML and CSS and MP3 becomes a new important audio format on the >web. > >We cannot and should not expect our telephone system to act this way. > With all due respect, this is really just because we are in the absolute infancy of "Internet Based communication". The Web is less than 6 years old, for goodness sake, and the PSTN is well over 100 years old. I believe that there was quite a long time in the early days of the telephone when you needed to have 2 or more phones on your desk if you wanted to talk to people on different networks. (Actually, I have been looking for a long time for a good history of the telephone communication up till about 1900-1920. If someone can recommend something I'd be very grateful.) You are absolutely correct that things are still changing much too fast, and there is too much which does not yet exist, to imagine that we are ready for a final global solution to IP based communications. This does not mean that we shouldn't think very hard about how to acheive that goal, however. I do believe that a certain number of things are more stable than others, and I would suggest that you confine your billions to those things in the meantime (happily enough I have just formed a dynamite new startup which takes traveller's checks ;-)). Scott --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 19:29:38 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01190 for ; Mon, 25 Jan 1999 19:29:38 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 219037FD5; Mon, 25 Jan 1999 19:25:23 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 69E717FD6; Mon, 25 Jan 1999 19:25:22 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36AD0B52.9977E7B0@cs.columbia.edu> Date: Mon, 25 Jan 1999 19:24:50 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott Petrack Cc: iptel@lists.research.bell-labs.com, confctrl@isi.edu Subject: Re: SIP References: <4.0.1.19990125124817.00dfc270@pop3.metatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Scott Petrack wrote: > > At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote: > > > (Actually, I have been looking for a long time for a good history of the > telephone communication up till about 1900-1920. If someone can recommend > something I'd be very grateful.) See (Costs $10 and has tons of references, plus is a pretty good read:) @BOOK{Frie95:Natural, AUTHOR="Amy Friedlander", TITLE="Natural Monopoly and Universal Service: Telephones and Telegraphs in the U.S. Communications Infrastructure, 1837-1940", PUBLISHER="CNRI", ADDRESS="Washington, DC", YEAR=1995, KEYWORDS="telephone; telegraph; history", ABSTRACT="This study examines the history of the telegraph and telephone industries in the United States from the perspectives of technology, corporate strategy, politics, and economics. Under the aegis of the Bell Company and its successors, the telephone followed a path similar to that pioneered in the 1860s by the telegraph giant, Western Union. Indeed, the telephone itself was invented in the 1870s as an unanticipated product of efforts to solve technological limitations of telegraphy. Like Western Union, Bell targeted communications among urban, commercial interests (as opposed to private residential and/or ...", URL="http://www.cnri.reston.va.us/series.html#teltel", ENTRYBY=Sc } -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 21:10:27 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02311 for ; Mon, 25 Jan 1999 21:10:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 87F667FD6; Mon, 25 Jan 1999 21:05:23 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D89C97FD9; Mon, 25 Jan 1999 21:05:22 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: Guocai Deng To: Ping Pan , Henry Sinnreich Cc: Jonathan Rosenberg , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com Subject: RE: IP Telphony Gateway metering Date: Tue, 26 Jan 1999 10:02:16 +0800 X-Mailer: Internet Mail Service (5.0.1460.8) Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Ping Pan wrote: > > As for the data format, I have no problem with XML format if all network > components are a bunch of Unix/NT servers. For the conventional routers, > I doubt that they have spare CPU cycles to process XML messages. In the > future, I don't care if all routers run JAVA, but not for now, please. > :-) Why cannot we simply send more traditional protocol messages? I think you perference to Access Router. If the Acess Router integrited some components like gatekeeper, they do need to precess XML messages because they usually have enough resource to do this. if the Access Router does not integrite any components like gatekeeper, they need not to process XML message, it can leave the job to gatekeeper or others. It just need to act as an proxy authentication server and need simple info to get the QoS parameters. it is the response to gatekeeper to translate the info from XML format to some other simple message format. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon Jan 25 21:48:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02577 for ; Mon, 25 Jan 1999 21:48:30 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 658607FD9; Mon, 25 Jan 1999 21:43:06 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C23B37FDA; Mon, 25 Jan 1999 21:43:05 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36AD2C10.7871FC0E@dnrc.bell-labs.com> Date: Mon, 25 Jan 1999 21:44:32 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Guocai Deng Cc: Henry Sinnreich , Jonathan Rosenberg , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com Subject: Re: IP Telphony Gateway metering References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Guocai Deng wrote: > > I think you perference to Access Router. If the Acess Router > integrited some components like gatekeeper, they do need to precess XML > messages because they usually have enough resource to do this. if the Access > Router does not integrite any components like gatekeeper, they need not to > process XML message, it can leave the job to gatekeeper or others. It just > need to act as an proxy authentication server and need simple info to get > the QoS parameters. it is the response to gatekeeper to translate the info > from XML format to some other simple message format. But the AAA protocol work for many applications outside access networks. We can envision the protocol is used to exchange information between carrier routers. Many peer-to-peer applications may take place between border routers. In that sense, I hope we are not restricting ourselves with some sophisticated format like XML. -- Ping Pan phone: (732)-332-6744 fax: (732)-834-5379 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 08:31:13 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA16020 for ; Tue, 26 Jan 1999 08:31:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 245827FEC; Tue, 26 Jan 1999 08:21:51 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E7BE67FE1; Tue, 26 Jan 1999 08:21:03 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: Francois Menard Distribution List Management Account To: "'iptel@lists.research.bell-labs.com'" Subject: www.openh323.org Date: Tue, 26 Jan 1999 07:37:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk FYI. It seems that this information was not well disseminated among the IETF activists. -=Francois=- ---------- The following letter was sent on December 5 1998 to a small number of people who had contacted me regarding working on the OpenH323 project. It was intended to kickoff the OpenH323 project by explaining where the project had come from, and raising some issues to get everyone thinking along the same lines. If you want join the fun, I suggest you read the letter, join the mailing list and start thinking! To those interested in participating in an effort to create Open Source H.323 Protocol suite. 5 December 1998 Dear Internet User, You've received this email because you have previously expressed interest in participating in an Open Source effort to create a H.323 protocol stack call the Linux Voxilla H.323 Project. I thought you might be interested in hearing about some recent changes to this project, and being involved in getting the project off the ground. History I started this project after seeing an article on http://slashdot.org about Rich Bodo's Voxilla project at http://www.voxilla.org. My company, Equivalence, had been contemplating starting an Open Source H.323 project for some time, and this looked like a good way to start it off. Rich was very supportive of the whole idea, and I created a new web site at http://www.voxillaequival.net to be the home site for the Linux Voxilla H.323 Project. Unfortunately, things seem to stall soon after that, and not a lot of progress has been made since then. Also unfortunately, Rich Bodo seems to have dropped out of contact. The moderated "voxilla" mailing list does not seem to be be issuing any new messages, and Rich isn't answering his emails. http://www.voxilla.org hasn't been changed for a while either. (UPDATE - 7 Dec 98: Rich received a copy of this message, and is now back in contact. Click here for more information ) So, I've decided that the time has come to move on. We wish Rich well, and I would like to personally thank him for making me get off my butt and do something about Open Source H.323. If you ever read this email, Rich, please don't take this as a criticism of your efforts or ideas, or think we are trying to throw you out of the project. You will always be welcome! OpenH323 The Linux Voxilla H.323 Project has been renamed OpenH323 to reflect the current trend in Open Source projects, and has a new home at http://www.openh323.equival.net . This site has been updated to reflect the new name and the new contact email addresses. The old http://www.voxilla.equival.net URL still works, but just maps straight to the new site. The domain name "openh323.org" has also been applied for by Equivalence on behalf of the OpenH323 project and http://www.openh323.org will be up and running shortly. A new, unmoderated, majordomo mailing list has also been created for this project. Thist list is called "openh323" and is hosted at majordom@equival.net You have already been subscribed to this list - to get more information see http://www.openh323.equival.net/list.html. Getting started I would like to discuss some issues regarding the start of OpenH323 with some people who have time to spare and are interested in contributing to the early, hard stages of getting something going. The original concept behind Equivalence being involved in an OpenH323 project was that we would make our multi-platform, C++ code library Open Source, and hence freely available to all OpenH323 contributors. We have developed this code library, called PwLib, over the past four years, and it allows developers to write applications that are portable across Linux x86, Linux PPC, Solaris Sparc, Windows 95/98, Windows NT, and FreeBSD x86. By "portable", we mean just recompile the application source code, link with the appropriate platform specific library, and run the program. No ifdefs, no other changes required. It fully supports all major system facilities such as multithreading (it does cooroperative multi-tasking on platforms that don't have threads) and TCP/IP sockets, and has a full C++ container library with support for abstract data structures such as queues, arrays and sorted lists. We have found this library invaluable, and we use it in all of our commercial products. It compiles with MSVC C++ 5.0 on Windows, and uses GCC with GLIBC on the various Unices. Included with this library would be our ASN parser which is capable of converting the standard H.323 and H.225 ASN specifications in C++ classes that can be compiled and linked with the PWLib class library. We have PER encoding and decoding functions, and the resultant code has been used in our own H.323 product, PhonePatch, so we know the H.323 and H.225 PDU encoding/decoding works correctly. Questions for Discussion 1) Is using PwLib a good idea? We think it is, because it gives us platform independence for stuff like threads and because we like C++. It also means we have a "ready to go" ASN compiler (a non-trivial task for those who've tried to write one!). Others might not like it because it is yet more code to come to grips with, and they don't like C++. Also, someone else might have a better ASN compiler that can be thrown into the ring. I'd like to see some discussion of this before we go much further. 2) What sort of approach should we use? I don't think there is any doubt about creating a library, rather than just creating a full-blown app, but should this library be multi-threaded? Single-threaded? What sort of API should be used? People with experience in other H.323 stacks will undoubtedly have some ideas here - let's hear them and get them down on paper (HTML?) where other can see them. Regards Craig Southeren craigs@equival.com.au --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 18:21:44 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07971 for ; Tue, 26 Jan 1999 18:21:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5D37980D4; Tue, 26 Jan 1999 18:19:30 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9DB2E80D5; Tue, 26 Jan 1999 18:19:28 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.3.32.19990127101456.013fc220@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 27 Jan 1999 10:14:56 +1100 To: Scott Petrack , "Paul E. Jones" , "Henry Sinnreich" , "Jonathan Rosenberg" From: Douglas Clowes Subject: Re: SIP Cc: "Henning Schulzrinne" , , "Aishling" , , In-Reply-To: <4.0.1.19990125124817.00dfc270@pop3.metatel.com> References: <01a801be465f$e668d520$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 13:02 1999-01-25 -0500, Scott Petrack wrote: >At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote: > >> >>But even mail and web services are not without problems. Take a web browser >>written in 1995 and visit some of today's more elaborate web sites. Create >>an e-mail with Microsoft's Outlook Express using HTML and send it to a user >>with a mail client written in 1995 (heck, send it to a Netscape user with >>up-to-date software). >> >>It is true that most of today's mail clients can understand SMTP, POP3, >>IMAP, HTML, MIME, etc. It is also true that most of today's web browsers >>can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc. >>However, it has not been without pain on the users-- they have had to >>upgrade their software every time a new "whiz-bang" feature was added. Be >>prepared to upgrade your web browsers again soon as XML and XSL displace >>much of HTML and CSS and MP3 becomes a new important audio format on the >>web. >> >>We cannot and should not expect our telephone system to act this way. >> > >With all due respect, this is really just because we are in the absolute >infancy of "Internet Based communication". The Web is less than 6 years >old, for goodness sake, and the PSTN is well over 100 years old. I believe >that there was quite a long time in the early days of the telephone when >you needed to have 2 or more phones on your desk if you wanted to talk to >people on different networks. Hey Scott, I used to work at a place (not that long ago) where I had those two phones on my desk. The reason was not that they were not compatible, just that they were not that connected. The internal phone system was a dial it yourself one, while the external one was a lady with plugs and cords and you asked her to dial your number for you. Amazing! But with that antique phone system, she could still dial me on my GSM mobile, which is about the same age as the Web. And it would work - much better that the email system, or many parts of the web. Try replying to "=A0=A0=A0=A0=A0.Fred.Bloggs[mailto:fbloggs@somewhere.com.au]=20" to tell them that you can't read their HTML crap - I mean "message". And see your mail client "spit the dummy" yet again. >(Actually, I have been looking for a long time for a good history of the >telephone communication up till about 1900-1920. If someone can recommend >something I'd be very grateful.) Actually, I think that the "answer" to all of this organized chaos was the CCITT, now the ITU. >You are absolutely correct that things are still changing much too fast, >and there is too much which does not yet exist, to imagine that we are >ready for a final global solution to IP based communications. This does not >mean that we shouldn't think very hard about how to acheive that goal, >however. A lot of people tollerate change very well. Hey, some of us actually enjoy it - something new to play with every day. But, there is a big slice of the consuming public out there who don't want to upgrade every Thursday. They don't want to find out that their new IP phone can't talk to any other phone that was built outside the window of two weeks of the date that theirs was built. The sort of phone that these consumers are wanting to pay for is --- an ITU phone (just like the black one, only cheaper to run). >I do believe that a certain number of things are more stable than others, >and I would suggest that you confine your billions to those things in the >meantime (happily enough I have just formed a dynamite new startup which >takes traveller's checks ;-)). And when the market for "whiz-bang" settles down, and stabilizes, it too will become commodity. But, there will be a minimum set of common capabilities which will allow all of them with the compliance sticker to interwork (as per the implementation agreement and compliance test requirements). Douglas >Scott > > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From tal@lists.research.bell-labs.com Tue Jan 26 18:53:59 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA08405 for ; Tue, 26 Jan 1999 18:53:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix, from userid 21643) id A385F8678; Tue, 26 Jan 1999 17:27:45 -0500 (EST) To: iptel-archive@ietf.org Subject: subscription check (iptel@lists.research.bell-labs.com: iptel-archive@lists.ietf.org) From: listcheck@lists.research.bell-labs.com Reply-To: listcheck@lists.research.bell-labs.com Message-Id: <19990126222745.A385F8678@lists.research.bell-labs.com> Date: Tue, 26 Jan 1999 17:27:45 -0500 (EST) Sender: tal@lists.research.bell-labs.com This is a subscription check. Automatically generated by ListCheck. DO NOT REPLY UNLESS SOME OF THE INFORMATION BELOW IS INCORRECT. On the mailing list called: iptel@lists.research.bell-labs.com You are subscribed by the name: iptel-archive@lists.ietf.org [ Note to Nortel/BayNetworks employees and companies involved in recent mergers: Is your email address going to change? This message tells you how to update your subscription to this mailing list! Save it for reference! ] DO YOU WANT TO BE REMOVED FROM THIS MAILING LIST? If this is so, please send email to majordomo@lists.research.bell-labs.com with the words unsubscribe iptel iptel-archive@lists.ietf.org on the first line of the message. A program will read this and remove you from the list. It isn't a smart program, so you have to type exactly what is above. The program also doesn't read the "Subject:" header, so put anything there. If this does not work, please send email to tal@lists.research.bell-labs.com and he will manually process the request. He can not read your mind so please give him explicit instructions like: "Please remove iptel-archive@lists.ietf.org from iptel@lists.research.bell-labs.com" You can make it even easier if you forward this message to him with the words "please remove me" at the top of the message. IF YOUR EMAIL ADDRESS IS WRONG: If you are receiving this message, the address is in some ways correct or is forwarded to you. Maybe mail to an old account is being forwarded or your company name has changed and the old address is working temporarily. We would prefer to have your new address. TO CORRECT/CHANGE YOUR EMAIL ADDRESS: Please send email to majordomo@lists.research.bell-labs.com with these two lines of text: unsubscribe iptel iptel-archive@lists.ietf.org subscribe iptel YOURNEWADDRESS@HOST (replace YOURNEWADDRESS@HOST with your new email address) A program will read this and remove you from the list. It isn't a smart program, so you have to type exactly what is above. The program also doesn't read the "Subject:" header, so put anything there. If the above confuses you, please send email to tal@lists.research.bell-labs.com and request that the change be made. He is not psychic, so please give him explicit instructions like: "I am on iptel@lists.research.bell-labs.com as iptel-archive@lists.ietf.org but I would rather be on as so_and_so@where.com" LOCAL RE-FORWARDING TO MULTIPLE PEOPLE: You may get this message because someone forwards it to you (and maybe a couple friends) automatically. If this is so, you should talk to them if you want to discontinue your subscription or change your address. IF YOU GET EVERY MESSAGE TWICE: Please send email to tal@lists.research.bell-labs.com ...we'd love to fix the problem. It will be most helpful if you forward the COMPLETE headers from both copies. (Including all those "Received:" headers!) IF YOU ARE GOING ON AN EXTENDED VACATION: If you would like to be removed for a month or more and then be re-added automatically, send the "start and stop" dates and name of the list to tal@lists.research.bell-labs.com and he will do his best to accommodate you. (Students: Please remember this in the spring!) Otherwise, please delete this message. You do not need to reply. You will receive this message once for each mailing list that you are on via this server. We will be sending this message about three times a year. Thank you, ListCheck From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 20:13:59 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA09597 for ; Tue, 26 Jan 1999 20:13:58 -0500 (EST) Received: from lists.research.bell-labs.com ([135.180.161.172]) by dirty; Tue Jan 26 20:12:56 EST 1999 Received: by lists.research.bell-labs.com (Postfix) id 755C87FDC; Tue, 26 Jan 1999 08:51:15 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C5F2C7FDD; Tue, 26 Jan 1999 08:51:14 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Tue, 26 Jan 1999 05:49:38 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: IP Telphony Gateway metering To: Guocai Deng Cc: Ping Pan , Henry Sinnreich , Jonathan Rosenberg , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > Ping Pan wrote: > > > > As for the data format, I have no problem with XML format if all > network > > components are a bunch of Unix/NT servers. For the conventional > routers, > > I doubt that they have spare CPU cycles to process XML messages. > In the > > future, I don't care if all routers run JAVA, but not for now, > please. > > :-) Why cannot we simply send more traditional protocol messages? > > I think you perference to Access Router. If the Acess Router > integrited some components like gatekeeper, they do need to precess XML > messages because they usually have enough resource to do this. if the Access > Router does not integrite any components like gatekeeper, they need not to > process XML message, it can leave the job to gatekeeper or others. It just > need to act as an proxy authentication server and need simple info to get > the QoS parameters. it is the response to gatekeeper to translate the info > from XML format to some other simple message format. I beg to differ. As soon as the access router finds itself with more CPU we either increase the ingress or egress trunk speeds (i.e. 33.6->56k), add more services to the box (i.e. IP Telephony), or increase its port density. Rarely have I ever heard of an access router with extra CPU capacity. PatC > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 20:14:00 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA09608 for ; Tue, 26 Jan 1999 20:14:00 -0500 (EST) Received: from lists.research.bell-labs.com ([135.180.161.172]) by dirty; Tue Jan 26 20:13:12 EST 1999 Received: by lists.research.bell-labs.com (Postfix) id 75F9D7FDD; Tue, 26 Jan 1999 09:30:30 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BB5F47FDF; Tue, 26 Jan 1999 09:30:29 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36ADD0ED.3F79F8A5@dnrc.bell-labs.com> Date: Tue, 26 Jan 1999 09:27:57 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" Cc: Ping Pan , Henry Sinnreich , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com Subject: Re: IP Telphony Gateway metering References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk pcalhoun@eng.sun.com wrote: > > > Henry Sinnreich wrote: > > > > > > It appears that for Internet-wide standard AA(A) and metering (instead of > > > the 3rd (A)), there is some work cut out for a possible BOF -> WG to agree > > > on > > > > > > * Data excahnge with the AA(A) system, > > > * Data exchange with the policy server using COPS, > > > * Gateway metering, > > > * RSVP and/or DiffServ metering, > > > * IMHO a data format, why not XML? > > Henry, > > I know your feelings about XML, and perhaps you are correct, but I have a > question. Is it really necessary for the router to spew out XML (pages?), as > opposed to a much simpler (and easier to parse) protocol, and have the AAA > server simply record the information in an XML format? It seems like this > would be much simpler for the embedded devices, and it would solve your > real-time usage viewing requirements. > > Perhaps this thread really belongs in the AAA list. Yup. iptel isn't doing billing, pricing, or metering. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 20:14:01 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA09619 for ; Tue, 26 Jan 1999 20:14:01 -0500 (EST) Received: from lists.research.bell-labs.com ([135.180.161.172]) by dirty; Tue Jan 26 20:13:15 EST 1999 Received: by lists.research.bell-labs.com (Postfix) id 880857FDF; Tue, 26 Jan 1999 09:37:17 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C739C7FE0; Tue, 26 Jan 1999 09:37:16 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Henry Sinnreich" To: "pcalhoun@eng.sun.com" , "Ping Pan" , Cc: "Jonathan Rosenberg" , "Dean Willis" , "Hoefelmeyer, Ralph (MCI)" , Subject: RE: IP Telphony Gateway metering Date: Tue, 26 Jan 1999 08:36:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Pat wrote: >Is it really necessary for the router to spew out XML > (pages?), as > opposed to a much simpler (and easier to parse) protocol, and have the AAA > server simply record the information in an XML format? I believe you have it right here, since changing the data format in routers is simply not doable. We also don't yet understand or simply don't know the computational load required by XML during peak traffic loads. Or the scalability when handling 100k's of calls in the peak of the busy hour. If however, XML is delivered by the AAA servers IMHO, we get the best of both worlds. >It seems like this > would be much simpler for the embedded devices, and it would solve your > real-time usage viewing requirements. Next generation embedded devices could possibly use a common parser for HTML, SIP and XML over a very thin operating system. Would need to involve embedded device and protocol designers to explore the best web-like approach. Any other opinions on the list? > Perhaps this thread really belongs in the AAA list. > > PatC Agree and have addedd in the header to see if of interest. Thanks, Henry > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Tuesday, January 26, 1999 8:46 AM > To: Ping Pan > Cc: Henry Sinnreich; Jonathan Rosenberg; Dean Willis; Hoefelmeyer, Ralph > (MCI); iptel@lists.research.bell-labs.com > Subject: Re: IP Telphony Gateway metering > > > > Henry Sinnreich wrote: > > > > > > It appears that for Internet-wide standard AA(A) and metering > (instead of > > > the 3rd (A)), there is some work cut out for a possible BOF > -> WG to agree > > > on > > > > > > * Data excahnge with the AA(A) system, > > > * Data exchange with the policy server using COPS, > > > * Gateway metering, > > > * RSVP and/or DiffServ metering, > > > * IMHO a data format, why not XML? > > Henry, > > I know your feelings about XML, and perhaps you are correct, but I have a > question. Is it really necessary for the router to spew out XML > (pages?), as > opposed to a much simpler (and easier to parse) protocol, and have the AAA > server simply record the information in an XML format? It seems like this > would be much simpler for the embedded devices, and it would solve your > real-time usage viewing requirements. > > Perhaps this thread really belongs in the AAA list. > > PatC > > > > > > > Hentry, > > > > More importantly, we need to correlate metering information from > > different applications. For example, SIP session duration is monitored > > via some policy servers. However, the actual user data (with RSVP > > enabled) may take a path that is completely different from what SIP > > messages are going. The policy servers hence need to collect the data > > information and map it to the corresponding SIP session to accounting > > purposes. > > > > As for the data format, I have no problem with XML format if all network > > components are a bunch of Unix/NT servers. For the conventional routers, > > I doubt that they have spare CPU cycles to process XML messages. In the > > future, I don't care if all routers run JAVA, but not for now, please. > > :-) Why cannot we simply send more traditional protocol messages? > > > > > Would be nice to agree on a framework and see if there is > something missing > > > or has to be written. > > > Any interest in this? > > > > > > > Isn't AAA group trying to put one together? > > > > > Thanks, Henry > > > > > > > > > > Regards, > > > > - Ping > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 20:14:03 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA09630 for ; Tue, 26 Jan 1999 20:14:02 -0500 (EST) Received: from lists.research.bell-labs.com ([135.180.161.172]) by dirty; Tue Jan 26 20:13:31 EST 1999 Received: by lists.research.bell-labs.com (Postfix) id E8C578013; Tue, 26 Jan 1999 16:57:19 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3CC2B8019; Tue, 26 Jan 1999 16:57:19 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Henry Sinnreich" To: "pcalhoun@eng.sun.com" , "Ping Pan" , , Cc: "Jonathan Rosenberg" , "Dean Willis" , "Hoefelmeyer, Ralph (MCI)" , Subject: RE: IP Telphony Gateway metering Date: Tue, 26 Jan 1999 15:54:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Pat wrote: >Is it really necessary for the router to spew out XML > (pages?), as > opposed to a much simpler (and easier to parse) protocol, and have the AAA > server simply record the information in an XML format? I believe you have it right here, since changing the data format in routers is simply not doable. We also don't yet understand or simply don't know the computational load required by XML during peak traffic loads. Or the scalability when handling 100k's of calls in the peak of the busy hour. If however, XML is delivered by the AAA servers IMHO, we get the best of both worlds. >It seems like this > would be much simpler for the embedded devices, and it would solve your > real-time usage viewing requirements. Next generation embedded devices could possibly use a common parser for HTML, SIP and XML over a very thin operating system. Would need to involve embedded device and protocol designers to explore the best web-like approach. Any other opinions on the list? > Perhaps this thread really belongs in the AAA list. > > PatC Agree and have addedd and in the header to see if of interest. Thanks, Henry > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Tuesday, January 26, 1999 8:46 AM > To: Ping Pan > Cc: Henry Sinnreich; Jonathan Rosenberg; Dean Willis; Hoefelmeyer, Ralph > (MCI); iptel@lists.research.bell-labs.com > Subject: Re: IP Telphony Gateway metering > > > > Henry Sinnreich wrote: > > > > > > It appears that for Internet-wide standard AA(A) and metering > (instead of > > > the 3rd (A)), there is some work cut out for a possible BOF > -> WG to agree > > > on > > > > > > * Data excahnge with the AA(A) system, > > > * Data exchange with the policy server using COPS, > > > * Gateway metering, > > > * RSVP and/or DiffServ metering, > > > * IMHO a data format, why not XML? > > Henry, > > I know your feelings about XML, and perhaps you are correct, but I have a > question. Is it really necessary for the router to spew out XML > (pages?), as > opposed to a much simpler (and easier to parse) protocol, and have the AAA > server simply record the information in an XML format? It seems like this > would be much simpler for the embedded devices, and it would solve your > real-time usage viewing requirements. > > Perhaps this thread really belongs in the AAA list. > > PatC > > > > > > > Hentry, > > > > More importantly, we need to correlate metering information from > > different applications. For example, SIP session duration is monitored > > via some policy servers. However, the actual user data (with RSVP > > enabled) may take a path that is completely different from what SIP > > messages are going. The policy servers hence need to collect the data > > information and map it to the corresponding SIP session to accounting > > purposes. > > > > As for the data format, I have no problem with XML format if all network > > components are a bunch of Unix/NT servers. For the conventional routers, > > I doubt that they have spare CPU cycles to process XML messages. In the > > future, I don't care if all routers run JAVA, but not for now, please. > > :-) Why cannot we simply send more traditional protocol messages? > > > > > Would be nice to agree on a framework and see if there is > something missing > > > or has to be written. > > > Any interest in this? > > > > > > > Isn't AAA group trying to put one together? > > > > > Thanks, Henry > > > > > > > > > > Regards, > > > > - Ping > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 20:17:58 1999 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.8.5/8.8.7a) with SMTP id UAA09650 for ; Tue, 26 Jan 1999 20:17:57 -0500 (EST) Received: from lists.research.bell-labs.com ([135.180.161.172]) by dirty; Tue Jan 26 20:16:36 EST 1999 Received: by lists.research.bell-labs.com (Postfix) id C5DC67FE3; Tue, 26 Jan 1999 08:21:15 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8524E7FE9; Tue, 26 Jan 1999 08:20:57 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: Guocai Deng To: Ping Pan Cc: Henry Sinnreich , Jonathan Rosenberg , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com Subject: RE: IP Telphony Gateway metering Date: Tue, 26 Jan 1999 17:21:05 +0800 X-Mailer: Internet Mail Service (5.0.1460.8) Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Ping Pan wrote: >Guocai Deng wrote: >> >> I think you perference to Access Router. If the Acess Router > >> integrited some components like gatekeeper, they do need to precess > XML > >> messages because they usually have enough resource to do this. if the > Access > >> Router does not integrite any components like gatekeeper, they need > not to > >> process XML message, it can leave the job to gatekeeper or others. It > just > >> need to act as an proxy authentication server and need simple info to > get > >> the QoS parameters. it is the response to gatekeeper to translate the > info > >> from XML format to some other simple message format. > > But the AAA protocol work for many applications outside access networks. > We can envision the protocol is used to exchange information between > carrier routers. Many peer-to-peer applications may take place between > border routers. In that sense, I hope we are not restricting ourselves > with some sophisticated format like XML. I think that AAA for Network Infra Providers and AAA for ITSPs Services to end customer are different. They are in different node in a business link. ITSPs should pay to Network Infra Providers, and VoIP users should pay to ITSPs. If ITSP and Network Infra Provider are the same carrier, It can process the AAA for end customer and AAA Between Network Infro Provider (Such as DS Domains) in different sectors. AAA Between Network Infra Provider may be more aggr. than AAA between ITSP and end users, and when VoIP users care of voice quality and price, they don't care of how to obtain the QoS, how to offer the QoS leave to ITSP to care. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 21:25:35 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA10221 for ; Tue, 26 Jan 1999 21:25:34 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 75C9B7FEA; Tue, 26 Jan 1999 11:37:16 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CAA4E7FED; Tue, 26 Jan 1999 11:37:15 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.5.32.19990126083444.0084c800@orsmsx30> X-Sender: jtoga@orsmsx30 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 26 Jan 1999 08:34:44 -0800 To: Scott Petrack , Douglas Clowes , Jonathan Rosenberg From: Jim Toga Subject: Re: SIP Cc: "Paul E. Jones" , Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com, confctrl@isi.edu In-Reply-To: <4.0.1.19990125122746.00df9be0@pop3.metatel.com> References: <3.0.3.32.19990122143531.01530df4@mail.ozemail.com.au> <36A7DC53.D1CA449B@dnrc.bell-labs.com> <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Scott, A couple of quick comments... 1) The 'switch' does not live in the 'network'. The reason for existence (in this discussion,) I thought, was for security aspects. The whole point is that you _want_ to keep the addressing/direct access isolated (or at least monitored). If you have a completely armored protocol(s)/box then you don't need it. ('course try and convince any IT dept...) 2) You can certainly reserve/deliver QOS on a 'generic' IP level. It would seem that if you want to allocate the QOS on an application basis (so that we get "QOS for all the applications that need it") -- somebody has to be coordinating at this level. If this maps into an abstraction like DIFSRV that's fine, but it still can't be a free-for-all with reservations.... Otherwise you simply end up with WinSock2 calls to RSVP... ;-) jiimt. At 12:44 PM 1/25/99 -0500, Scott Petrack wrote: >At 02:35 PM 1/22/99 +1100, Douglas Clowes wrote: > >>Let's see now, a firewall with proxies that only let through known >>protocols and check with the gatekeeper for H.323 admission. Scarey! > >In H.323 you would probably use "gatekeeper routed calls" - that is, the >gatekeeper itself is the signalling proxy that only lets though known and >permitted signalling, and tells the relevant RTP firewall what to let >through. (But this is just quibbling with the words you use). > >And if the signalling is SIP then you replace "gatekeeper" with "SIP proxy >server." > >Although you can do it this way, unfortunately you have created -- the >phone system! That is, the RTP firewall looks a lot like a switch, because >you have to make certain that all the RTP traffic goes through that box. >The originating endpoint will never see the RTP address of the remote >endpoint, but only the address of the RTP firewall. So all of end-to-end >routing has been thrown away -- just like in the phone system. > >Of course, similarly, we will need, SMTP firewalls and special DNS servers >which can give out addresses of MX machines which can do QoS email, and >other special DNS servers and HTTP firewalls which can do QoS web-browsing, >etc. etc. etc. In the end we will have overlaid 1000 different parallel >Internets on top of the current Internet. I know many people who share this >"dream". > >A better, more scaleable, goal, is to separate out the QoS infrastructure >from the needs of any particular application, and instead of having H.323 >Gatekeepers, HTTP Gatekeepers, SMTP gatekeepers, etc. etc. etc., just >having an infrastructure for QoS that allows applications to seize the >required Internet resources without any reference to any particular >application. > >It may end up being impossible to do, but it's the only hope that we'll get >QoS for all the Internet applications that need it. > >It may well be that there is still a need for the single-application >servers, in order to enable really dumb hard-coded appliances that will not >want to deal with the QoS signalling themselves. But these servers will >need to hand-off decision-making to the real QoS infrastructure. > >Scott > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 21:25:53 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA10241 for ; Tue, 26 Jan 1999 21:25:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 78AA47FDA; Tue, 26 Jan 1999 08:47:16 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C03A87FDC; Tue, 26 Jan 1999 08:47:15 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Tue, 26 Jan 1999 05:46:21 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: IP Telphony Gateway metering To: Ping Pan Cc: Henry Sinnreich , Jonathan Rosenberg , Dean Willis , "Hoefelmeyer, Ralph (MCI)" , iptel@lists.research.bell-labs.com In-Reply-To: "Your message with ID" <36ACF98D.167BA5A9@dnrc.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > Henry Sinnreich wrote: > > > > It appears that for Internet-wide standard AA(A) and metering (instead of > > the 3rd (A)), there is some work cut out for a possible BOF -> WG to agree > > on > > > > * Data excahnge with the AA(A) system, > > * Data exchange with the policy server using COPS, > > * Gateway metering, > > * RSVP and/or DiffServ metering, > > * IMHO a data format, why not XML? Henry, I know your feelings about XML, and perhaps you are correct, but I have a question. Is it really necessary for the router to spew out XML (pages?), as opposed to a much simpler (and easier to parse) protocol, and have the AAA server simply record the information in an XML format? It seems like this would be much simpler for the embedded devices, and it would solve your real-time usage viewing requirements. Perhaps this thread really belongs in the AAA list. PatC > > > > Hentry, > > More importantly, we need to correlate metering information from > different applications. For example, SIP session duration is monitored > via some policy servers. However, the actual user data (with RSVP > enabled) may take a path that is completely different from what SIP > messages are going. The policy servers hence need to collect the data > information and map it to the corresponding SIP session to accounting > purposes. > > As for the data format, I have no problem with XML format if all network > components are a bunch of Unix/NT servers. For the conventional routers, > I doubt that they have spare CPU cycles to process XML messages. In the > future, I don't care if all routers run JAVA, but not for now, please. > :-) Why cannot we simply send more traditional protocol messages? > > > Would be nice to agree on a framework and see if there is something missing > > or has to be written. > > Any interest in this? > > > > Isn't AAA group trying to put one together? > > > Thanks, Henry > > > > > > Regards, > > - Ping > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 21:26:25 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA10252 for ; Tue, 26 Jan 1999 21:26:25 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 381BA7FEE; Tue, 26 Jan 1999 12:01:18 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8B5977FF0; Tue, 26 Jan 1999 12:01:17 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.5.32.19990126085845.00810cd0@orsmsx30> X-Sender: jtoga@orsmsx30 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 26 Jan 1999 08:58:45 -0800 To: Scott Petrack , Jonathan Rosenberg , "Paul E. Jones" From: Jim Toga Subject: Re: SIP Cc: Hanlin_Fang@3com.com, Aishling , iptel@lists.research.bell-labs.com In-Reply-To: <4.0.1.19990125115546.00df9f10@pop3.metatel.com> References: <3.0.5.32.19990121164201.0085de20@ibeam.intel.com> <36A79B95.4A0D344F@dnrc.bell-labs.com> <025d01be457f$98ac62b0$aec965c0@pjones.databeam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Scott, some more (with all due respect :-) ) rebuttal.... (this could be start of some many long discussions.....) jimt. At 05:46 PM 1/25/99 -0500, Scott Petrack wrote: >At 04:42 PM 1/21/99 -0800, Jim Toga wrote: >> >>Call admission by H.323 Gatekeepers can be used in this case to match >>provisioning with capacity. The behaviour might exactly mimic the current >>PSTN. >> > >There is unfortunately a fundamental difference between the PSTN behavior >and what an H.323 network can do. When the PSTN decides that there isn't >enough capacity, the end user gets a Network Busy signal and there is >nothing else s/he can do to affect the telephone network. This is because >of the fundamental distinction made in the PSTN between "NNI" >(network-network interfaces) and "UNI" (user-network interfaces). The >signalling which tells the switch "No you may NOT make that call" stays >entirely inside the network, and the business contracts and regulation that >bind operators guarantee that when that happens, the end user will not get >anything but a busy signal. He will not be able to mess things up for >anyone else. > >But H.323 signalling is not NNI -- it goes all the way out the endpoint. Not if it doesn't get the address resolved from the GK. >So >if a gatekeeper tells an endpoint (which might be a terminal) "No you may >NOT make that call", and the endpoint can get via other means (say email) >the RTP address of the remote endpoint. He can blast away. Only if the two are in colusion with the same 'illegal' protocols. I can do all sorts of things if I were sufficiently sophisticated and have access to the shared medium. I'm not saying that every implementation is 'correctly' written or behaves well, simply that the protocol (even SIP) doesn't disallow from creating a working, tight system. >It may sound >bad, and not many packets might get through, but he can certainly inject >the packets into the network and still mess things up for everybody else. YADOSA (yet another denial-of-service attack) > >There is no way within H.323 to connect the permission that a gatekeeper >might or might not give, with the opening and closing of IP connectivity to >the endpoint, and there is in the PSTN. In a re-programmable system - agreed. > >Note that even if such a connection existed, it would not really help, >because there are many different kinds of traffic which affect capacity, >not just H.323: even if the Gatekeeper really could stop me from sending >RTP traffic from being sent when it forbids an H.323 call to complete, it >won't be able to stop me from sending Email, ftp, etc. Agreed. Two different sides to the QOS coin. Make sure application X doesn't step on applications A, B, C.... Make sure application X doesn't get stepped on by appications A, B, C.... > >The bottom line is that Gatekeepers are not enough, unfortunately, although >the analogous mechanism is enough in the PSTN -- because the business >contracts and laws are there and because there is only one single >application running (voice). I agree that GKs are not enough - by themselves. I'm not sure that I agree that this has anything to do with protocols or single media. The PSTN model works because the barrier to connections (physical) is pretty high. I _have_ to have a wire (or cell site). If I climb the pole outside my neighbors house or put alligator clips on his NID, I've 'hacked' the network and done denial of service on his phone. Obviously I can't get 'services' that aren't allocated to that line, but whatever resources aren't strictly 'monitored' I can appropriate. > >>>What if there are no servers? What if users try and contact each other >>>directly? In that case, you will need to make use of network QoS >>>management techniques. This is also not SIP specific. If two H.323 >>>terminals communicate directly, you'll have the same problem. >> >>This is exactly why the standard stipulates that _if_ Gatekeepers are >>present, they must be utilized. >> > >Yes, and _if_ seatbelts are present, they must be utilized. The law says >so. But as long as there are cars which go on the highways even if you >don't buckle up, then innocent people are not going to get their very >precious little packets trashed because of people who don't listen when the >red "gatekeeper" light flashes on their dashboards. > Entirely agree that there are no standards police. This is why there is a public key/checksum in cable boxes. It may be that that is what is requred by IP applications some day to authenticate tamper-proofing. Car analogy is kind of weak ;-) but, to carry it further; I'll take a head-on with a five-point harness against you with a flashing red light any day... (This implies that routers etc... act as the laws of physics in this case) > >Scott > > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jan 26 22:05:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA10487 for ; Tue, 26 Jan 1999 22:05:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C90257FDB; Tue, 26 Jan 1999 21:49:19 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1C6107FDE; Tue, 26 Jan 1999 21:49:19 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Henry Sinnreich" To: "Douglas Clowes" , "Scott Petrack" , "Paul E. Jones" , "Jonathan Rosenberg" Cc: "Henning Schulzrinne" , , "Aishling" , , Subject: RE: SIP Date: Tue, 26 Jan 1999 20:46:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-reply-to: <3.0.3.32.19990127101456.013fc220@mail.ozemail.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Douglas wrote: The sort of phone that these consumers are > wanting to pay > for is --- an ITU phone (just like the black one, only cheaper to run). Why don't you just keep it and let us do IP? Henry > -----Original Message----- > From: Douglas Clowes [mailto:dclowes@ozemail.com.au] > Sent: Tuesday, January 26, 1999 6:15 PM > To: Scott Petrack; Paul E. Jones; Henry Sinnreich; Jonathan Rosenberg > Cc: Henning Schulzrinne; Hanlin_Fang@3com.com; Aishling; > iptel@lists.research.bell-labs.com; confctrl@isi.edu > Subject: Re: SIP > > > At 13:02 1999-01-25 -0500, Scott Petrack wrote: > >At 06:34 PM 1/22/99 -0500, Paul E. Jones wrote: > > > >> > >>But even mail and web services are not without problems. Take > a web browser > >>written in 1995 and visit some of today's more elaborate web > sites. Create > >>an e-mail with Microsoft's Outlook Express using HTML and send > it to a user > >>with a mail client written in 1995 (heck, send it to a Netscape > user with > >>up-to-date software). > >> > >>It is true that most of today's mail clients can understand SMTP, POP3, > >>IMAP, HTML, MIME, etc. It is also true that most of today's > web browsers > >>can support HTML 4.0, CSS, GIF, JPG, PNG, WAV, AU, MPEG, RealAudio, etc. > >>However, it has not been without pain on the users-- they have had to > >>upgrade their software every time a new "whiz-bang" feature was > added. Be > >>prepared to upgrade your web browsers again soon as XML and XSL displace > >>much of HTML and CSS and MP3 becomes a new important audio format on the > >>web. > >> > >>We cannot and should not expect our telephone system to act this way. > >> > > > >With all due respect, this is really just because we are in the absolute > >infancy of "Internet Based communication". The Web is less than 6 years > >old, for goodness sake, and the PSTN is well over 100 years old. > I believe > >that there was quite a long time in the early days of the telephone when > >you needed to have 2 or more phones on your desk if you wanted to talk to > >people on different networks. > > Hey Scott, > > I used to work at a place (not that long ago) where I had those two phones > on my desk. The reason was not that they were not compatible, just that > they were not that connected. The internal phone system was a dial it > yourself one, while the external one was a lady with plugs and cords and > you asked her to dial your number for you. Amazing! > > But with that antique phone system, she could still dial me on my GSM > mobile, which is about the same age as the Web. And it would work - much > better that the email system, or many parts of the web. > > Try replying to > "=A0=A0=A0=A0=A0.Fred.Bloggs[mailto:fbloggs@somewhere.com.au]=20" to tell > them that you can't read their HTML crap - I mean "message". And see your > mail client "spit the dummy" yet again. > > >(Actually, I have been looking for a long time for a good history of the > >telephone communication up till about 1900-1920. If someone can recommend > >something I'd be very grateful.) > > Actually, I think that the "answer" to all of this organized chaos was the > CCITT, now the ITU. > > >You are absolutely correct that things are still changing much too fast, > >and there is too much which does not yet exist, to imagine that we are > >ready for a final global solution to IP based communications. > This does not > >mean that we shouldn't think very hard about how to acheive that goal, > >however. > > A lot of people tollerate change very well. Hey, some of us actually enjoy > it - something new to play with every day. But, there is a big > slice of the > consuming public out there who don't want to upgrade every Thursday. They > don't want to find out that their new IP phone can't talk to any other > phone that was built outside the window of two weeks of the date that > theirs was built. The sort of phone that these consumers are > wanting to pay > for is --- an ITU phone (just like the black one, only cheaper to run). > > >I do believe that a certain number of things are more stable than others, > >and I would suggest that you confine your billions to those things in the > >meantime (happily enough I have just formed a dynamite new startup which > >takes traveller's checks ;-)). > > And when the market for "whiz-bang" settles down, and stabilizes, it too > will become commodity. But, there will be a minimum set of common > capabilities which will allow all of them with the compliance sticker to > interwork (as per the implementation agreement and compliance test > requirements). > > Douglas > > >Scott > > > > > > > > > >--------- > >This message came from the IETF IPTEL Working Group Mailing List. > > > > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 02:09:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA20424 for ; Wed, 27 Jan 1999 02:09:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4050D8008; Wed, 27 Jan 1999 01:25:19 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8D547800B; Wed, 27 Jan 1999 01:25:18 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <01BE49EB.A12EBE90@hss056.hss.hns.com> From: Alok Mittal To: "'iptel@lists.research.bell-labs.com'" Subject: Intelligent Services in H.323 Networks Date: Wed, 27 Jan 1999 11:53:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi I have a query that hopefully belongs to this list -- Is there any effort underway to provide IN/AIN like services in H.323 networks in a standardized manner, and to inter- operate with similar services in PSTN? Thanks! Alok ----------------------------------------------------------------- Alok Mittal Technical Leader, Hughes Software Systems Prestige Opal, 146 Infantry Road, Bangalore - 560001 Tel: +91-80-2286390,91,92 Fax: +91-80-2286393 ----------------------------------------------------------------- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 13:53:07 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA02271 for ; Wed, 27 Jan 1999 13:53:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AB7978021; Wed, 27 Jan 1999 10:59:16 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 16B248023; Wed, 27 Jan 1999 10:59:15 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Hoefelmeyer, Ralph (MCI)" To: "'Alok Mittal'" Cc: "'iptel@lists.research.bell-labs.com'" Subject: RE: Intelligent Services in H.323 Networks Date: Wed, 27 Jan 1999 08:58:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE4A0D.E2B67F16" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE4A0D.E2B67F16 Content-Type: text/plain Alok, Yes, there are efforts to provide IN/AIN services in H.323 networks and to interoperate with PSTN services, but I do not believe there is any "standard" approach yet. Erricsson has set up an H.323 network in Norway, you might check with them and see what they are doing. Ralph > -----Original Message----- > From: Alok Mittal [SMTP:amittal@hss.hns.com] > Sent: Wednesday, January 27, 1999 4:53 AM > To: 'iptel@lists.research.bell-labs.com' > Subject: Intelligent Services in H.323 Networks > > Hi > > I have a query that hopefully belongs to this list -- > > Is there any effort underway to provide IN/AIN like services > in H.323 networks in a standardized manner, and to inter- > operate with similar services in PSTN? > > Thanks! > Alok > > ----------------------------------------------------------------- > Alok Mittal > Technical Leader, Hughes Software Systems > Prestige Opal, 146 Infantry Road, Bangalore - 560001 > Tel: +91-80-2286390,91,92 Fax: +91-80-2286393 > ----------------------------------------------------------------- > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. ------_=_NextPart_001_01BE4A0D.E2B67F16 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Intelligent Services in H.323 Networks

Alok,

Yes, there are efforts to = provide IN/AIN services in H.323 networks and to interoperate with PSTN = services, but I do not believe there is any "standard" = approach yet.  Erricsson has set up an H.323 network in Norway, = you might check with them and see what they are doing.

Ralph

    -----Original Message-----
    From:   Alok Mittal [SMTP:amittal@hss.hns.com]
    Sent:   Wednesday, January 27, 1999 4:53 AM
    To:     'iptel@lists.research.bell-labs.com'
    Subject:       = Intelligent Services in H.323 = Networks

    Hi
     
     I have = a query that hopefully belongs to this list --

     Is there = any effort underway to provide IN/AIN like services
     in = H.323 networks in a standardized manner, and to inter-
     operate = with similar services in PSTN?

    Thanks!
    Alok

    -----------------------------------------------------------------
    Alok = Mittal    
    Technical = Leader,       Hughes Software = Systems
    Prestige = Opal, 146 Infantry Road, Bangalore - 560001
    Tel: = +91-80-2286390,91,92       Fax: = +91-80-2286393
    -----------------------------------------------------------------


    ---------
    This message = came from the IETF IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE4A0D.E2B67F16-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 14:37:09 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03837 for ; Wed, 27 Jan 1999 14:37:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EF0437FE1; Wed, 27 Jan 1999 09:13:17 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6031A7FE2; Wed, 27 Jan 1999 09:13:16 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36AF2CAB.67436AD0@Globalone.net> Date: Wed, 27 Jan 1999 15:11:40 +0000 From: Sebastien Ducarne Organization: Global One X-Sender: "Sebastien Ducarne" X-Mailer: Mozilla 4.05 [en]C-G1.V2 (Win95; I) MIME-Version: 1.0 To: IP Telephony Subject: VOIP question ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hello, I am from Global One Operator and work in the engineering team as responsible of new access modes to Voice Services. I am familiar with the Voice over ATM solutions but less for Voice over IP. I have a specific question and I hope that someone could find time to help me on it To be clear, I would like to know if it is possible to connect Customers PBX to a VOIP-Gateway and to transport all the traffic to another VOIP-Gateway connected to our large voice switch, and this without Gatekeeper. Is it possible? What is the impact on service ? On bandwidth management ? Thanks in advance for any help on this issue. Sebastien DUCARNE Global One - Voice Engineering PARIS +33 1 40 79 80 66 sebastien.ducarne@globalone.net --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 14:49:32 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA04244 for ; Wed, 27 Jan 1999 14:49:32 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C58D17FE0; Wed, 27 Jan 1999 08:47:35 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8E5997FE1; Wed, 27 Jan 1999 08:47:34 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <017d01be49fa$e14b1b40$840110ac@notebook.int.transnexus.com> From: "Stephen Thomas" To: "Henry Sinnreich" , "pcalhoun@eng.sun.com" , "Ping Pan" , , Cc: "Jonathan Rosenberg" , "Dean Willis" , "Hoefelmeyer, Ralph (MCI)" , Subject: Re: IP Telphony Gateway metering Date: Wed, 27 Jan 1999 08:42:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk A couple of observations below. -----Original Message----- From: Henry Sinnreich To: pcalhoun@eng.sun.com ; Ping Pan ; ietf-aaa@external.cisco.com ; aaa-wg@merit.edu Cc: Jonathan Rosenberg ; Dean Willis ; Hoefelmeyer, Ralph (MCI) ; iptel@lists.research.bell-labs.com Date: Tuesday, 26 January 1999 7:18 PM Subject: RE: IP Telphony Gateway metering |Pat wrote: |>Is it really necessary for the router to spew out XML |> (pages?), as |> opposed to a much simpler (and easier to parse) protocol, and have the AAA |> server simply record the information in an XML format? It seems like "simpler" protocols tend to work best when the information to be parsed has a fairly simple structure. That is certainly true today for dialup Internet access where the accounting information is essentially just duration. I'm not certain that new applications (such as multimedia over IP, to generalize the starting point of this thread) will meet that same criteria. Considering the multitude of variables that may be a part of accounting information (e.g. layered media streams, various QoS attributes, network paths, measured performance, ...) a way to encode a structure as part the information might be essential. I suppose I'm suggesting that, in the future, accounting information might be much more multi-dimensional than it is today. XML is certainly one way to encode structure, others exists as well (e.g. ASN.1). I have no credible opinion on whether the dimensionality is handled by a "router" or an "AAA server," partly because I'm not sure the distinction between the two is necessarily that clear. [...] |Next generation embedded devices could possibly use a common parser for |HTML, SIP and XML over a very thin operating system. |Would need to involve embedded device and protocol designers to explore the |best web-like approach. There is a fair body of work already on embedded device and protocol support for both ASN.1 and XML (to cite the two examples mentioned above). Although not necessarily in the IETF (other than SNMP). ISO and ITU-T have certainly spent a lot of time with ASN.1, and the Wireless Application Forum (www.wapforum.org) has developed a considerable body of work on embedded XML support. Stephen ____________________________________________________________________ Stephen Thomas +1 404 872 4745 TransNexus, Chief Technical Officer stephen.thomas@transnexus.com ____________________________________________________________________ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 18:37:27 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA09010 for ; Wed, 27 Jan 1999 18:37:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ADE197FE2; Wed, 27 Jan 1999 18:25:22 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0243C7FE4; Wed, 27 Jan 1999 18:25:21 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.3.32.19990128102533.00fbb398@mail.ozemail.com.au> X-Sender: dclowes@mail.ozemail.com.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 28 Jan 1999 10:25:33 +1100 To: "Hoefelmeyer, Ralph (MCI)" , "'Alok Mittal'" From: Douglas Clowes Subject: RE: Intelligent Services in H.323 Networks Cc: "'iptel@lists.research.bell-labs.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Indeed, a request to look at "Back End Services" - what they are and how to standardise them - including IN/AIN type services, was submitted to TIPHON recently. The request was opposed, and consequently not accepted. Douglas At 08:58 1999-01-27 -0700, Hoefelmeyer, Ralph (MCI) wrote: >>>> Arial0000,0000,ffffAlok, Arial0000,0000,ffffYes, there are efforts to provide IN/AIN services in H.323 networks and to interoperate with PSTN services, but I do not believe there is any "standard" approach yet. Erricsson has set up an H.323 network in Norway, you might check with them and see what they are doing. Arial0000,0000,ffffRalph Arial-----Original Message----- ArialFrom: ArialAlok Mittal [SMTP:amittal@hss.hns.com] ArialSent: ArialWednesday, January 27, 1999 4:53 AM ArialTo: Arial'iptel@lists.research.bell-labs.com' ArialSubject: ArialIntelligent Services in H.323 Networks Hi I have a query that hopefully belongs to this list -- Is there any effort underway to provide IN/AIN like services in H.323 networks in a standardized manner, and to inter- operate with similar services in PSTN? Thanks! Alok ----------------------------------------------------------------- Alok Mittal Technical Leader, Hughes Software Systems Prestige Opal, 146 Infantry Road, Bangalore - 560001 Tel: +91-80-2286390,91,92 Fax: +91-80-2286393 ----------------------------------------------------------------- --------- This message came from the IETF IPTEL Working Group Mailing List. <<<<<<<< --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 19:43:36 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09807 for ; Wed, 27 Jan 1999 19:43:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D209C7FE5; Wed, 27 Jan 1999 19:31:27 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1CD947FE4; Wed, 27 Jan 1999 19:31:24 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Authentication-Warning: igw1.ericsson.com.au: mail set sender to using -f Message-ID: <36AFADDB.DAA6FB0A@epa.ericsson.se> Date: Thu, 28 Jan 1999 11:22:51 +1100 From: Bjarne Munch Reply-To: epabhm@epa.ericsson.se Organization: Ericsson Australia X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: Sebastien Ducarne Cc: IP Telephony Subject: Re: VOIP question ?? References: <36AF2CAB.67436AD0@Globalone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Sebastian, I'm new to this list, and thought that I migth introduce my existence by picking up this one. In short; Yes that is possible ! But a few questions migth be in order; why do you state that you dont want a Gatekeeper ? It may be of interest to have the Gatekeeper for any future enhancement of the service offering, eg. more PBX's in the network or IP 'supplementary service' offerings. In the initial phase the Gatekeeper could be used to just set up the routing and nothing more, ie. it would be transparent to the user. Even in a 'simple', case such as yours, you would for most vendor products need to set up some routing information even without a Gatekeeper in the network. Another question to ask is what services you would utilise on your PBX to PBX link ? Is it just pure transmission PBX to PBX, or would you require support of existing PBX services such as call back or call transfer from one PBX to the other ? In the latter case you would probably need some level of QSIG capability in the VoIP network, ie. Gatekeeper signalling seems to be needed. Bandwidth management can be done, to a certain extend, via the Gatekeeper but real QoS handling would need to be handled on a network level. The issue is very much related to the size of the pipe between the two gateways and the amount of traffic. If the pipe has a reasonable spare capacity you should be able to provide an acceptable level of quality on your VoIP. Regards Bjarne Munch Product Management, IP Services Ericsson Australia Sebastien Ducarne wrote: > Hello, > > I am from Global One Operator and work in the engineering team as responsible > of new access modes to Voice Services. I am familiar with the Voice over ATM > solutions but less for Voice over IP. > > I have a specific question and I hope that someone could find time to help me > on it > To be clear, I would like to know if it is possible to connect Customers PBX > to > a VOIP-Gateway and to transport all the traffic to another VOIP-Gateway > connected > to our large voice switch, and this without Gatekeeper. > > Is it possible? What is the impact on service ? On bandwidth management ? > > Thanks in advance for any help on this issue. > > Sebastien DUCARNE > Global One - Voice Engineering PARIS > +33 1 40 79 80 66 > sebastien.ducarne@globalone.net > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 20:11:28 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA10003 for ; Wed, 27 Jan 1999 20:11:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E83EA7FE4; Wed, 27 Jan 1999 20:01:20 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 267077FE6; Wed, 27 Jan 1999 20:01:19 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <4.1.19990127161146.009d4100@gric.com> X-Sender: rbrennan@gric.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 27 Jan 1999 16:59:39 -0800 To: iptel@lists.research.bell-labs.com From: Richard Brennan Subject: RE: Intelligent Services in H.323 Networks In-Reply-To: <3.0.3.32.19990128102533.00fbb398@mail.ozemail.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Actually... the work item proposed by Telekom Austria... http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/05-9901-Sophia/11TD11 9.doc was not added to the WG-2 work program due to concern regarding the scope of the work item. The issue of interfaces to "Back End Services" will be considered at a second BOF session at the ETSI-TIPHON 12 meeting in Philadelphia, PA. (Tentatively scheduled for... Monday, 1st March 1999 18:00-20:00) ETSI-TIPHON has already approved a Technical Specification in this area: TS 101 321 (12/98) "Inter-domain pricing, authorization, and usage exchange", based on HTTP 1.1 and XML. (commonly referred to as: Open Settlement Protocol - OSP) http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg3/DTS0300 4/V1.4.2 ==================================================== Richard Brennan - Product Manager Internet Telephony GRIC Communications, Inc. 1421 McCarthy Blvd.,Milpitas, CA 95035 USA tel: +1.408.965.1193 fax: +1.408.955.1967 mailto:rbrennan@gric.com http://www.gric.com ==================================================== At 10:25 AM 1/28/99 +1100, Douglas Clowes wrote: > > Indeed, a request to look at "Back End Services" - what they are and how to > standardise them - including IN/AIN type services, was submitted to TIPHON > recently. > > The request was opposed, and consequently not accepted. > > Douglas > > At 08:58 1999-01-27 -0700, Hoefelmeyer, Ralph (MCI) wrote: > >>>> > >> >> Alok, >> >> Yes, there are efforts to provide IN/AIN services in H.323 networks and to >> interoperate with PSTN services, but I do not believe there is any >> "standard" approach yet. Erricsson has set up an H.323 network in Norway, >> you might check with them and see what they are doing. >> >> Ralph >> >> -----Original Message----- >> From: Alok Mittal [SMTP:amittal@hss.hns.com] >> Sent: Wednesday, January 27, 1999 4:53 AM >> To: 'iptel@lists.research.bell-labs.com' >> Subject: Intelligent Services in H.323 Networks >> >> Hi >> >> I have a query that hopefully belongs to this list -- >> >> Is there any effort underway to provide IN/AIN like services >> in H.323 networks in a standardized manner, and to inter- >> operate with similar services in PSTN? >> >> Thanks! >> Alok >> >> ----------------------------------------------------------------- >> Alok Mittal >> Technical Leader, Hughes Software Systems >> Prestige Opal, 146 Infantry Road, Bangalore - 560001 >> Tel: +91-80-2286390,91,92 Fax: +91-80-2286393 >> ----------------------------------------------------------------- >> >> >> --------- >> This message came from the IETF IPTEL Working Group Mailing List. > > <<<< > > > > > > --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jan 27 22:35:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA12810 for ; Wed, 27 Jan 1999 22:35:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 70A677FE6; Wed, 27 Jan 1999 21:37:19 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BE8357FE7; Wed, 27 Jan 1999 21:37:18 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36AFCCCF.5C41F215@globalone.net> Date: Wed, 27 Jan 1999 20:34:56 -0600 From: ming.lu@globalone.net (Ming Lu) Organization: Global One X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,zh,zh-CN,zh-TW,ja MIME-Version: 1.0 To: epabhm@epa.ericsson.se Cc: Sebastien Ducarne , IP Telephony Subject: Re: VOIP question ?? References: <36AF2CAB.67436AD0@Globalone.net> <36AFADDB.DAA6FB0A@epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Sebastian: gatway serves a function as "translator" between traditional PSTN/PBX network and IP network, you have no problem to connect a gateway to PBX. Also According H.3232, gatekeeper is optional. You don't have to have gatekeeper to operate a gateway. Best _ming Bjarne Munch wrote: > Hi Sebastian, > > I'm new to this list, and thought that I migth introduce my existence by picking > up this one. In short; Yes that is possible ! > > But a few questions migth be in order; why do you state that you dont want a > Gatekeeper ? > > It may be of interest to have the Gatekeeper for any future enhancement of the > service offering, eg. more PBX's in the network or IP 'supplementary service' > offerings. > In the initial phase the Gatekeeper could be used to just set up the routing and > nothing > more, ie. it would be transparent to the user. Even in a 'simple', case such as > yours, you > would for most vendor products need to set up some routing information even > without > a Gatekeeper in the network. > > Another question to ask is what services you would utilise on your PBX to > PBX link ? > > Is it just pure transmission PBX to PBX, or would you require support of > existing PBX services such as call back or call transfer from one PBX to > the other ? In the latter case you would probably need some level of QSIG > capability in the VoIP network, ie. Gatekeeper signalling seems to be > needed. > > Bandwidth management can be done, to a certain extend, via the Gatekeeper > but real QoS handling would need to be handled on a network level. The > issue is very much related to the size of the pipe between the two gateways > and the amount of traffic. If the pipe has a reasonable spare capacity you > should be able to provide an acceptable level of quality on your VoIP. > > Regards > Bjarne Munch > Product Management, IP Services > Ericsson Australia > > Sebastien Ducarne wrote: > > > Hello, > > > > I am from Global One Operator and work in the engineering team as responsible > > of new access modes to Voice Services. I am familiar with the Voice over ATM > > solutions but less for Voice over IP. > > > > I have a specific question and I hope that someone could find time to help me > > on it > > To be clear, I would like to know if it is possible to connect Customers PBX > > to > > a VOIP-Gateway and to transport all the traffic to another VOIP-Gateway > > connected > > to our large voice switch, and this without Gatekeeper. > > > > Is it possible? What is the impact on service ? On bandwidth management ? > > > > Thanks in advance for any help on this issue. > > > > Sebastien DUCARNE > > Global One - Voice Engineering PARIS > > +33 1 40 79 80 66 > > sebastien.ducarne@globalone.net > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 09:58:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA25845 for ; Thu, 28 Jan 1999 09:58:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 730917FE7; Thu, 28 Jan 1999 05:53:22 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CABEB7FE8; Thu, 28 Jan 1999 05:53:21 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <99Jan28.124759ist.113795@firewall.radvision.rad.co.il> From: Ami Amir To: ming.lu@globalone.net, epabhm@epa.ericsson.se Cc: Sebastien Ducarne , IP Telephony Subject: RE: VOIP question ?? Date: Thu, 28 Jan 1999 12:41:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi All Once you walk through and analyze the situation, you will find out that a Gatekeeper is really needed. An example of one issue -dialing schemes: If you are willing to support multiple stage dialing or assign a rigid dialing scheme (e.g. prefix 6 for PBX A, prefix 7 for PBX B etc) then you can make do w/o gatekeepers - and sacrifice functionality, mobility and flexibility. Another issue is economical: If you have more than 3 PBX's - you have two options; either create a mesh, and let each PBX support as many trunks as there are PBX's (= lots of hardware) - or support a flexible scheme, where a single PBX to GW trunk can support connections to multiple GWs. This, less expensive, functionality requires a GK. Ami -----Original Message----- From: ming.lu@globalone.net [SMTP:ming.lu@globalone.net] Sent: Thursday, January 28, 1999 4:35 AM To: epabhm@epa.ericsson.se Cc: Sebastien Ducarne; IP Telephony Subject: Re: VOIP question ?? Sebastian: gatway serves a function as "translator" between traditional PSTN/PBX network and IP network, you have no problem to connect a gateway to PBX. Also According H.3232, gatekeeper is optional. You don't have to have gatekeeper to operate a gateway. Best _ming Bjarne Munch wrote: > Hi Sebastian, > > I'm new to this list, and thought that I migth introduce my existence by picking > up this one. In short; Yes that is possible ! > > But a few questions migth be in order; why do you state that you dont want a > Gatekeeper ? > > It may be of interest to have the Gatekeeper for any future enhancement of the > service offering, eg. more PBX's in the network or IP 'supplementary service' > offerings. > In the initial phase the Gatekeeper could be used to just set up the routing and > nothing > more, ie. it would be transparent to the user. Even in a 'simple', case such as > yours, you > would for most vendor products need to set up some routing information even > without > a Gatekeeper in the network. > > Another question to ask is what services you would utilise on your PBX to > PBX link ? > > Is it just pure transmission PBX to PBX, or would you require support of > existing PBX services such as call back or call transfer from one PBX to > the other ? In the latter case you would probably need some level of QSIG > capability in the VoIP network, ie. Gatekeeper signalling seems to be > needed. > > Bandwidth management can be done, to a certain extend, via the Gatekeeper > but real QoS handling would need to be handled on a network level. The > issue is very much related to the size of the pipe between the two gateways > and the amount of traffic. If the pipe has a reasonable spare capacity you > should be able to provide an acceptable level of quality on your VoIP. > > Regards > Bjarne Munch > Product Management, IP Services > Ericsson Australia > > Sebastien Ducarne wrote: > > > Hello, > > > > I am from Global One Operator and work in the engineering team as responsible > > of new access modes to Voice Services. I am familiar with the Voice over ATM > > solutions but less for Voice over IP. > > > > I have a specific question and I hope that someone could find time to help me > > on it > > To be clear, I would like to know if it is possible to connect Customers PBX > > to > > a VOIP-Gateway and to transport all the traffic to another VOIP-Gateway > > connected > > to our large voice switch, and this without Gatekeeper. > > > > Is it possible? What is the impact on service ? On bandwidth management ? > > > > Thanks in advance for any help on this issue. > > > > Sebastien DUCARNE > > Global One - Voice Engineering PARIS > > +33 1 40 79 80 66 > > sebastien.ducarne@globalone.net > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 13:36:46 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA05310 for ; Thu, 28 Jan 1999 13:36:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7A13A7FE9; Thu, 28 Jan 1999 13:25:25 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BD6C67FEB; Thu, 28 Jan 1999 13:25:24 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <99Jan28.202021ist.113798@firewall.radvision.rad.co.il> From: Ami Amir To: "ronald h. davis" , Ami Amir Cc: ming.lu@globalone.net, epabhm@epa.ericsson.se, Sebastien Ducarne , IP Telephony Subject: RE: VOIP question ?? Date: Thu, 28 Jan 1999 20:14:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Ronald, Since I was present on the H.323 scene from its early days, I beg to differ: 1. The Gatekeeper's function from day one was ADDRESS RESOLUTION (even the name was driven by the function of Gateway Keeper). 2. As to the specific problem - any of the currently commercially available gatekeepers provide support for PBX to PBX connections. There will be problems when the connection spans very large networks that are multi-zonal and inter-company. The original spec did not attempt to resolve these issues, and hence additional work is required (be it intergatekeeper work in the ITU or the iptel work in the IETF). Regards Ami -----Original Message----- From: ronald h. davis [SMTP:ronaldd@lucent.com] Sent: Thursday, January 28, 1999 7:23 PM To: Ami Amir Cc: ming.lu@globalone.net; epabhm@epa.ericsson.se; Sebastien Ducarne; IP Telephony Subject: Re: VOIP question ?? Ami Amir wrote: > > Hi All > > Once you walk through and analyze the situation, you will find out that a > Gatekeeper is really needed. > h.323 was defined for non-qos lans, so as far as i am able to tell, the gatekeeper function arose from the need to manage bandwidth on a lan. this was accomplished through the use of a ras channel and registration and admission procedures as defined in h.323. when connecting gateways/endpoints on a wide area network, this role of the gatekeeper becomes a bit harder to define... from what i can tell, you're suggesting the role of the gatekeeper is a sort of application-level router. this is certainly a valid role but it can be achieved by h.225 call signalling, and h.245 control channels only - there is no need for a ras channel. at the network level there is a need for these application-level routers to be able to exchange information, both within an administrative domain, and between administrative domains. this creates a role for ospf and bgp equivalent protocols that allow for the exchange of information. the inter-domain problem is currently being addressed by both itu study group 16, h.225 annex g, and by the ietf iptel wg, gateway location protocol). there is also a proposal before iptel (which has been tabled for now while they work on glp) to address the intra-domain problem, peer gatekeeper routing protocol (which is horribly misnamed because it really isn't limited to h.323 gatekeepers anyway). there's also an i.now! proposal which is based upon a clearinghouse model. but the objectives of these protocols is different from the objectives of the h.323 gatekeeper ras channel. so while i see there is a role for an application-level router, which you may call a gatekeeper is you wish, to me, the term gatekeeper comes with loading of ras channel functionality that must be supported (at least according to h.323). this functionality seems largely unnecessary in the scenarios that you described. -- __ ______ __ / __/ | lucent technologies, naperville il, usa _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com "if you ain't the lead dog, the scenery never changes" -- edmund wilson --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 13:53:10 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA06068 for ; Thu, 28 Jan 1999 13:53:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BE25B7FE8; Thu, 28 Jan 1999 12:35:27 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DC86B7FE9; Thu, 28 Jan 1999 12:35:26 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Ying, Wen-Ping" To: "'Hoefelmeyer, Ralph (MCI)'" , "'Alok Mittal'" Cc: "'iptel@lists.research.bell-labs.com'" , "'Taylor, Tom-PT [SKY:B318-I:EXCH]'" , "'Christian Huitema'" Subject: RE: Intelligent Services in H.323 Networks Date: Thu, 28 Jan 1999 09:34:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA06068 Can the current view of MG/MGC from MEGACO working group be expanded to cover this function? As long as MGCP includes enough flexibilty to allow proper call disposition, as far as protocol goes, this should be feasible. The specific implementation of MGC functions could actually be integrated into the existing SCP/NCP provided the interface be changed to IP based. Wen-Ping Ying AT&T Wireless Services Voice 425-702-2725 wying@att.com > -----Original Message----- > From: Hoefelmeyer, Ralph (MCI) [SMTP:Ralph.Hoefelmeyer@mci.com] > Sent: Wednesday, January 27, 1999 7:59 AM > To: 'Alok Mittal' > Cc: 'iptel@lists.research.bell-labs.com' > Subject: RE: Intelligent Services in H.323 Networks > > Alok, > > Yes, there are efforts to provide IN/AIN services in H.323 networks and to > interoperate with PSTN services, but I do not believe there is any > "standard" approach yet.  Erricsson has set up an H.323 network in Norway, > you might check with them and see what they are doing. > > Ralph > > -----Original Message----- > From:   Alok Mittal [SMTP:amittal@hss.hns.com] > Sent:   Wednesday, January 27, 1999 4:53 AM > To:     'iptel@lists.research.bell-labs.com' > Subject:        Intelligent Services in H.323 Networks > > Hi >   >  I have a query that hopefully belongs to this list -- > >  Is there any effort underway to provide IN/AIN like services >  in H.323 networks in a standardized manner, and to inter- >  operate with similar services in PSTN? > > Thanks! > Alok > > ----------------------------------------------------------------- > Alok Mittal     > Technical Leader,       Hughes Software Systems > Prestige Opal, 146 Infantry Road, Bangalore - 560001 > Tel: +91-80-2286390,91,92       Fax: +91-80-2286393 > ----------------------------------------------------------------- > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 14:08:33 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA06565 for ; Thu, 28 Jan 1999 14:08:33 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 59DFB7FDE; Thu, 28 Jan 1999 12:26:02 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B1E7A7FE8; Thu, 28 Jan 1999 12:26:01 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Cc: ming.lu@globalone.net, epabhm@epa.ericsson.se, Sebastien Ducarne , IP Telephony Message-ID: <36B09CED.2C030CED@lucent.com> Date: Thu, 28 Jan 1999 11:22:53 -0600 From: "ronald h. davis" Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: Ami Amir Original-CC: ming.lu@globalone.net, epabhm@epa.ericsson.se, Sebastien Ducarne , IP Telephony Subject: Re: VOIP question ?? References: <99Jan28.124759ist.113795@firewall.radvision.rad.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Ami Amir wrote: > > Hi All > > Once you walk through and analyze the situation, you will find out that a > Gatekeeper is really needed. > h.323 was defined for non-qos lans, so as far as i am able to tell, the gatekeeper function arose from the need to manage bandwidth on a lan. this was accomplished through the use of a ras channel and registration and admission procedures as defined in h.323. when connecting gateways/endpoints on a wide area network, this role of the gatekeeper becomes a bit harder to define... from what i can tell, you're suggesting the role of the gatekeeper is a sort of application-level router. this is certainly a valid role but it can be achieved by h.225 call signalling, and h.245 control channels only - there is no need for a ras channel. at the network level there is a need for these application-level routers to be able to exchange information, both within an administrative domain, and between administrative domains. this creates a role for ospf and bgp equivalent protocols that allow for the exchange of information. the inter-domain problem is currently being addressed by both itu study group 16, h.225 annex g, and by the ietf iptel wg, gateway location protocol). there is also a proposal before iptel (which has been tabled for now while they work on glp) to address the intra-domain problem, peer gatekeeper routing protocol (which is horribly misnamed because it really isn't limited to h.323 gatekeepers anyway). there's also an i.now! proposal which is based upon a clearinghouse model. but the objectives of these protocols is different from the objectives of the h.323 gatekeeper ras channel. so while i see there is a role for an application-level router, which you may call a gatekeeper is you wish, to me, the term gatekeeper comes with loading of ras channel functionality that must be supported (at least according to h.323). this functionality seems largely unnecessary in the scenarios that you described. -- __ ______ __ / __/ | lucent technologies, naperville il, usa _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com "if you ain't the lead dog, the scenery never changes" -- edmund wilson --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 14:29:39 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07072 for ; Thu, 28 Jan 1999 14:29:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 682F57FEB; Thu, 28 Jan 1999 14:18:39 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B517D7FED; Thu, 28 Jan 1999 14:18:38 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Cc: ming.lu@globalone.net, epabhm@epa.ericsson.se, Sebastien Ducarne , IP Telephony Message-ID: <36B0B757.98889131@lucent.com> Date: Thu, 28 Jan 1999 13:15:35 -0600 From: "ronald h. davis" Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: Ami Amir Original-CC: ming.lu@globalone.net, epabhm@epa.ericsson.se, Sebastien Ducarne , IP Telephony Subject: Re: VOIP question ?? References: <99Jan28.202021ist.113798@firewall.radvision.rad.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Ami Amir wrote: > > Ronald, > > Since I was present on the H.323 scene from its early days, I beg to differ: > > 1. The Gatekeeper's function from day one was ADDRESS RESOLUTION (even > the name was driven by the function of Gateway Keeper). > could you explain why bandwidth was made a mandatory element in an admission request (arq) (along with other bandwidth management gatekeeper procedures)? in fact, was arq necessary at all? address resolution could be accomplished by a location request (lrq) and no arq. but it was not until a later version of h.323 that i saw the capability added that allowed zone members to register with pre-approved arq. i'm not denying the address resolution role of the gatekeeper, i'm just questioning the need for the ras channel, which every h.323 gatekeeper must support. -- __ ______ __ / __/ | lucent technologies, naperville il, usa _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com "if you ain't the lead dog, the scenery never changes" -- edmund wilson --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 14:42:53 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA07467 for ; Thu, 28 Jan 1999 14:42:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D1EBC7FEF; Thu, 28 Jan 1999 14:31:24 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 87D207FED; Thu, 28 Jan 1999 14:31:23 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <99Jan28.212713ist.113800@firewall.radvision.rad.co.il> From: Ami Amir To: "ronald h. davis" , Ami Amir Cc: ming.lu@globalone.net, epabhm@epa.ericsson.se, Sebastien Ducarne , IP Telephony Subject: RE: VOIP question ?? Date: Thu, 28 Jan 1999 21:21:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Ronald Like many other protocols, H.323 is a compromise (to quote from myself - a camel is a horse designed by a committee :->). I can relate to history and explain - but this unimportant. At the end, to the specific issue - the easiest way to solve the problem raised by Sebastien - have a GK out there, let it resolve the called phone number, translate it to IP and be done with it. Cheers Ami -----Original Message----- From: ronald h. davis [SMTP:ronaldd@lucent.com] Sent: Thursday, January 28, 1999 9:16 PM To: Ami Amir Cc: ming.lu@globalone.net; epabhm@epa.ericsson.se; Sebastien Ducarne; IP Telephony Subject: Re: VOIP question ?? Ami Amir wrote: > > Ronald, > > Since I was present on the H.323 scene from its early days, I beg to differ: > > 1. The Gatekeeper's function from day one was ADDRESS RESOLUTION (even > the name was driven by the function of Gateway Keeper). > could you explain why bandwidth was made a mandatory element in an admission request (arq) (along with other bandwidth management gatekeeper procedures)? in fact, was arq necessary at all? address resolution could be accomplished by a location request (lrq) and no arq. but it was not until a later version of h.323 that i saw the capability added that allowed zone members to register with pre-approved arq. i'm not denying the address resolution role of the gatekeeper, i'm just questioning the need for the ras channel, which every h.323 gatekeeper must support. -- __ ______ __ / __/ | lucent technologies, naperville il, usa _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com "if you ain't the lead dog, the scenery never changes" -- edmund wilson --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 17:46:42 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA10381 for ; Thu, 28 Jan 1999 17:46:42 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C85B87FF1; Thu, 28 Jan 1999 17:33:37 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F31D97FF0; Thu, 28 Jan 1999 17:33:36 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Authentication-Warning: igw1.ericsson.com.au: mail set sender to using -f Message-ID: <36B0E36D.86E9BD24@epa.ericsson.se> Date: Fri, 29 Jan 1999 09:23:42 +1100 From: Bjarne Munch Reply-To: epabhm@epa.ericsson.se Organization: Ericsson Australia X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: Ami Amir Cc: "ronald h. davis" , ming.lu@globalone.net, Sebastien Ducarne , IP Telephony Subject: Re: VOIP question ?? References: <99Jan28.202021ist.113798@firewall.radvision.rad.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, This is interesting, even though it's morning and I'm half asleep. I am thinking about Ronalds remark about application level routing and the need for protocols similar to OSPF and BGS, or even the emerging Gateway Location Protocol. I see a strong need for address resolution from E.164 number plans, and I can also see the need to structure an IP Telephony network in some hierarchy. This is partly to provide a scalable E.164 routing, but just as much to allow an operator to implement certain business rules. Such business rules would be related to a per minute cost for terminating a call towards specific destinations, receiving calls from other destinations, inter-operator domain operability etc. The question that occur to me is how much control will the operator wish to have over this IPT network ? And how much self discovery and routing adaptability will an operator wish to have? Call me a 'bell-head' but as an example; implementing an automatic gateway discovery may limit the possibility for operators to control the cost structure for terminating and originating calls to/from these gateways. I dont see this as a part of H.323, but rather the routing applicating utilising H.323. And this routing application does not nessecarily require an 'adaptive' routing protocol. Cheers Bjarne Munch Ami Amir wrote: > Ronald, > > Since I was present on the H.323 scene from its early days, I beg to differ: > > 1. The Gatekeeper's function from day one was ADDRESS RESOLUTION (even > the name was driven by the function of Gateway Keeper). > 2. As to the specific problem - any of the currently commercially > available gatekeepers provide support for PBX to PBX connections. There will > be problems when the connection spans very large networks that are > multi-zonal and inter-company. The original spec did not attempt to resolve > these issues, and hence additional work is required (be it intergatekeeper > work in the ITU or the iptel work in the IETF). > > Regards > > Ami > > -----Original Message----- > From: ronald h. davis [SMTP:ronaldd@lucent.com] > Sent: Thursday, January 28, 1999 7:23 PM > To: Ami Amir > Cc: ming.lu@globalone.net; epabhm@epa.ericsson.se; Sebastien > Ducarne; IP Telephony > Subject: Re: VOIP question ?? > > Ami Amir wrote: > > > > Hi All > > > > Once you walk through and analyze the situation, you will find out > that a > > Gatekeeper is really needed. > > > > h.323 was defined for non-qos lans, so as far as i am able to tell, > the > gatekeeper function arose from the need to manage bandwidth on a > lan. > this was accomplished through the use of a ras channel and > registration > and admission procedures as defined in h.323. > > when connecting gateways/endpoints on a wide area network, this role > of > the gatekeeper becomes a bit harder to define... > > from what i can tell, you're suggesting the role of the gatekeeper > is > a sort of application-level router. this is certainly a valid role > but it can be achieved by h.225 call signalling, and h.245 control > channels only - there is no need for a ras channel. > > at the network level there is a need for these application-level > routers to be able to exchange information, both within an > administrative domain, and between administrative domains. this > creates a role for ospf and bgp equivalent protocols that allow > for the exchange of information. the inter-domain problem is > currently > being addressed by both itu study group 16, h.225 annex g, and by > the ietf iptel wg, gateway location protocol). there is also a > proposal > before iptel (which has been tabled for now while they work on glp) > to > address the intra-domain problem, peer gatekeeper routing protocol > (which is horribly misnamed because it really isn't limited to h.323 > gatekeepers anyway). there's also an i.now! proposal which is based > upon a clearinghouse model. but the objectives of these protocols > is > different from the objectives of the h.323 gatekeeper ras channel. > > so while i see there is a role for an application-level router, > which > you may call a gatekeeper is you wish, to me, the term gatekeeper > comes with loading of ras channel functionality that must be > supported > (at least according to h.323). this functionality seems largely > unnecessary in the scenarios that you described. > > -- > __ ______ __ / __/ | lucent technologies, naperville il, > usa > _/ (_(_) / (_(_/_/_(_/ . ronald.h.davis@lucent.com > "if you ain't the lead dog, the scenery never changes" -- edmund > wilson > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 19:26:39 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA11380 for ; Thu, 28 Jan 1999 19:26:37 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EEF637FED; Thu, 28 Jan 1999 17:32:00 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 292E97FF0; Thu, 28 Jan 1999 17:31:58 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <98388C05D464D111B61800805F1504167D2AF7@p-ibis.issy.cnet.fr> From: CHATRAS Bruno CNET/DAC/ISS To: "'Hoefelmeyer, Ralph (MCI)'" , "'Alok Mittal'" Cc: "'iptel@lists.research.bell-labs.com'" Subject: RE: Intelligent Services in H.323 Networks Date: Thu, 28 Jan 1999 15:47:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE4ACD.1B0B3CE8" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE4ACD.1B0B3CE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Both ETSI and ITU are starting to discuss this issue.=20 At the next ITU SG11 WP4 (IN) meeting in March '99 there will be some contributions on this topic. You can check the T1S1 FTP server to have a look to the North-American = draft contribution. FYI, I also attach to this mail a contribution which was discussed this = week in ETSI (IN Working Group). <>=20 > -----Message d'origine----- > De: Hoefelmeyer, Ralph (MCI) [SMTP:Ralph.Hoefelmeyer@mci.com] > Date: mercredi 27 janvier 1999 16:59 > =C0: 'Alok Mittal' > Cc: 'iptel@lists.research.bell-labs.com' > Objet: RE: Intelligent Services in H.323 Networks >=20 > Alok,=20 >=20 > Yes, there are efforts to provide IN/AIN services in H.323 networks = and to > interoperate with PSTN services, but I do not believe there is any > "standard" approach yet.=A0 Erricsson has set up an H.323 network in = Norway, > you might check with them and see what they are doing. >=20 > Ralph=20 >=20 > -----Original Message-----=20 > From:=A0=A0 Alok Mittal [SMTP:amittal@hss.hns.com]=20 > Sent:=A0=A0 Wednesday, January 27, 1999 4:53 AM=20 > To:=A0=A0=A0=A0 'iptel@lists.research.bell-labs.com'=20 > Subject:=A0=A0=A0=A0=A0=A0=A0 Intelligent Services in H.323 Networks=20 >=20 > Hi=20 > =A0=20 > =A0I have a query that hopefully belongs to this list --=20 >=20 > =A0Is there any effort underway to provide IN/AIN like services=20 > =A0in H.323 networks in a standardized manner, and to inter-=20 > =A0operate with similar services in PSTN?=20 >=20 > Thanks!=20 > Alok=20 >=20 > -----------------------------------------------------------------=20 > Alok Mittal=A0=A0=A0=A0=20 > Technical Leader,=A0=A0=A0=A0=A0=A0 Hughes Software Systems=20 > Prestige Opal, 146 Infantry Road, Bangalore - 560001=20 > Tel: +91-80-2286390,91,92=A0=A0=A0=A0=A0=A0 Fax: +91-80-2286393=20 > -----------------------------------------------------------------=20 >=20 >=20 > ---------=20 > This message came from the IETF IPTEL Working Group Mailing List.=20 >=20 ------_=_NextPart_000_01BE4ACD.1B0B3CE8 Content-Type: application/msword; name="h323-IN.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="h323-IN.doc" Content-Location: ATT-0-A741A4CEBBB6D211B30F00805F19DA30-H 323-IN.DOC 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAEgAAAAAAAAAA EAAAFQAAAAIAAAD+////AAAAABMAAABqAQAAGwAAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9S AG8AbwB0ACAARQBuAHQAcgB5AAAAAACXAQAADwAAAClcDwBEAAAAEAgAAAAAAAAAAAAAagEAAIsA AABAAAAAFgAFAf//////////AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBq0KTZGvgHgW7UxNka+ ARYAAABALgAAlhQAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAQwBjAAAAQTpcAAAAAAAAAACp 8gAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAWgEAAHlJAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQH//////////wUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAOAYgio2Rr4B4BiCKjZGvgEAAAAAAAAAAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAWPHkfwAAAADMHEkAAAAAAAAAAAD+////KAACAf////8E AAAA/////wAAAABJAACgLABAACAARADqOmkQAAAAAAAAAAAAAAAAAAAAAAQAAADMAQAAAAAAABQA AAD9////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAVAEAAP//////////GAAAADEBAAAXAAAANgAAACkAAAD///////////////////// ////////////////////////////////////////////////////////////////KgAAACsAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA/v///0UAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAA/v///1YAAABHAAAASAAA AEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAAD+//// VwAAAHUAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABl AAAA/v///2cAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMA AAB0AAAA/v///3YAAACTAAAA/////3kAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAnhYA AJ8WAACgFgAAoRYAAKIWAADDFgAA7hYAAA8XAABaFwAAWxcAAFwXAABdFwAAXhcAAF8XAABgFwAA YRcAAIIXAADHFwAAGxgAACsYAABYGAAAWRgAAFoYAABbGAAAXBgAAP4AAXAj5gD+AAFwI+YA/gAB cCPmAP4AAXAj5gD7AAFwI9oR+QABcCPwAPsAAXAj2hH5AAFwI/AA/gABcCPmAP4AAXAj5gD+AAFw I+YA/gABcCPmAP4AAXAj5gD+AAFwI+YA/gABcCPmAPsAAXAj2hH5AAFwI/AA9wAAAAAAAPQAAnAj JQH+AAFwIyUB8gABcCPmAP4AAAAAAAD+AAAAAAAA+QABcCPwAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVAAACFwAFAAABFwAAARQAAAIAAAUBAAEAABgOABgA CAABAEsADwAAAAAAHgAAQPH/AgAeAAZOb3JtYWwABAAAAAUDBgBdAgBhDARYAAFAAQACAFgAB1Rp dHJlIDEAAEAAAQANARXgARbwAAw0AAABBAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAVYFcAAJAAQDyAFwAB1RpdHJlIDIAAEAAAgANAhXwABZ4AAw0AAAA BAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAVYFjFgAA XAADQAEAEgFcAAdUaXRyZSAzAABAAAMADQMVeAAWeAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAF4BYxYAAF4ABEABAAIAXgAHVGl0cmUgNAAA QgAEAAgBDQQV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAFAFWBXQIAAFwABUABAAIAXAAHVGl0cmUgNQAAQAAFAA0FFfAAFjwADDQAAQAE AAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBdAgBjFgBc AAZAAQACAFwAB1RpdHJlIDYAAEAABgANBhXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAVoFjFgAAXAAHQAEAAgBcAAdUaXRyZSA3AABA AAcADQcV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAF0CAGMUAF4ACEABAAIAXgAHVGl0cmUgOAAAQAAIAA0IFfAAFjwADDQAAQAEAAAB gAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACABWgV0CAGMUAGAA CUABAAIAYAAHVGl0cmUgOQAAQAAJAA0JFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBVgVaBXQIAYxIAHgBBQPL/oQAeABFQb2xpY2Ug cGFyIGTpZmF1dAAAAAAAAAAAAAAAACIA/k8BAfIAIgAOUmV0cmFpdE5vcm1hbDIABQAPABFuBAAA ACIAHEABAAIBIgAOUmV0cmFpdCBub3JtYWwABQAQABHEAgAAACIA/k/xABIBIgAOUmV0cmFpdE5v cm1hbDMABQARABEYBgAAACYAIEABACIBJgAMUGllZCBkZSBwYWdlAAwAEgAPCAAC0xJvIwECAAAk AP5PAQAyASQAAkhFAAcAEwAFAxbwAAALAFWBXQIAYQkIYxQAACIAIkABAAIAIgAHTOlnZW5kZQAA CgAUAAUBFXgAFngAAgBVgSIAH0ABAFIBIgAHRW4tdOp0ZQAADAAVAA8IAAK4EXAjAQIAACYACkAB AAIAJgAHSW5kZXggMQAADwAWABHIABM4/w8FAAFvIwoAAAAwACFgAQByATAAC1RpdHJlIGluZGV4 AAAJABcABwEIARXwAAALAFWBXQMAYQkIYxgAAAAAAABcFQAABQBcGAAABAD/////BQAGIf//AQAA IP//AgAEIP//AwAAIf//BAAEIP//BQAAAAAApgQAAEUOAABZEwAA7hMAAFwVAAAAAHEAAAABABUD AAACACEAAAADACEAAAAEAAAAAAAAAAAAFwAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAy AAAAPwAAAOcAAAD6AAAA6AEAAOkBAABQAgAAUQIAAEsDAADrAwAAFwUAABgFAAA5BQAAmwUAALoF AACUBgAAlQYAAP0JAAAYCgAAuAoAALkKAAC6CwAAuwsAALIMAABaEQAAWxEAANwSAADdEgAA/hIA AFkTAAB6EwAAmxMAAJwTAACdEwAAnhMAAJ8TAACgEwAAoRMAAKITAADDEwAA7hMAAA8UAABaFAAA WxQAAFwUAABdFAAAXhQAAF8UAABgFAAAYRQAAIIUAADHFAAAyBQAAFwVAACYABMAmAATAJwAAACc AAAAnAAAAJwAAACcAAAAnAAAAJwAAAAEAAEAnAAAAAQAAQCcAAAAnAAAAJwAFACcAAAAnAAAAJwA AACcAAAAnAAAAJwAAACcABQABAABAJwAAACcAAAAnAAAAAQAAQCcAAAAnAAAAJwAAACcAAAAnAAA AJwAAACcAAAAnAAAAJwAAACcAAAAnAAUAJwAAACcABQAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAA nAAAAJwAAACcABQAnAAAAJwAFACcAAAAnAAAAJwAAACcAAAAnAAAAJwAAACcAAAAnAAAAJwAFACc AAAAnAAAAAAAAACTAAAAlgAAAAADAAALFwAAmRgAAA0ADgAAAwAAnhYAAFwYAAAPABAA6QEAAAYC AAAIAgAAEQIAACcCAAApAgAAGAUAADUFAAA3BQAAQAUAAFYFAABYBQAA3RIAAPoSAAD8EgAABRMA ABsTAAAdEwAAWRMAAHYTAAB4EwAAgRMAAJcTAACZEwAAohMAAL8TAADBEwAAyhMAAOATAADiEwAA 7hMAAAsUAAANFAAAFhQAACwUAAAuFAAAYRQAAH4UAACAFAAAiRQAAJ8UAAChFAAAXBUAABM6lP+V hBMMlP+VgBM6lP+VgBMMlP+VgBM6lP+VgBMMlP+VgBM6lP+VgBMMlP+VgBM6lP+VgBMMlP+VgBM6 lP+VgBMMlP+VgBM6lP+VgBMMlP+VgAAAAABEAAAATAAAAFoAAABcAAAAXQAAAGAAAABhAAAAaQAA AGoAAABuAAAAdAAAAHsAAAB8AAAAfwAAAIAAAACHAAAAjgAAAJQAAACZAAAAogAAAKMAAAClAAAA rAAAALUAAAC3AAAAuwAAAMUAAADMAAAAzQAAANcAAADbAAAA3wAAAOAAAADlAAAA7QAAAPEAAADy AAAA+QAAAPoAAAAIAQAADwEAABUBAAAWAQAAIAEAADYBAAA+AQAAQwEAAEYBAABcAQAAZgEAAGcB AABpAQAAbgEAAHYBAAB4AQAAfgEAAH8BAACEAQAAhQEAAI0BAACUAQAAnQEAAKMBAACoAQAAuAEA AMEBAADCAQAAxQEAAMYBAADOAQAAzwEAANUBAADaAQAA3gEAAN8BAADmAQAAMwIAADcCAAA4AgAA PwIAAEACAABIAgAASQIAAE8CAABZAgAAYgIAAGMCAABmAgAAZwIAAGsCAABsAgAAcwIAAHQCAAB8 AgAAfQIAAIICAACDAgAAhQIAAIYCAACLAgAAmQIAAJwCAAC5AgAAvwIAAMECAADJAgAAygIAAM8C AADQAgAA0gIAANMCAADXAgAA2AIAAN8CAAD4AgAAAgMAAB8DAAAoAwAANgMAAD0DAABRAwAAWgMA AFsDAABeAwAAZQMAAGwDAABtAwAAdAMAAHUDAAB9AwAAfgMAAIIDAACDAwAAigMAAIsDAACUAwAA mQMAAJwDAACdAwAAqAMAAKwDAAC4AwAAuQMAAMUDAADKAwAAzQMAAM4DAADVAwAA2QMAAOADAADh AwAA6QMAAPEDAAD3AwAA/AMAAP8DAAAABAAACQQAACcEAAApBAAAKgQAACwEAAAtBAAANAQAADUE AAA3BAAAOAQAADsEAAA8BAAARgQAAEcEAABOBAAAUgQAAFcEAABdBAAAYQQAAGIEAABlBAAAZgQA AG4EAABvBAAAcQQAAHIEAAB1BAAAdgQAAHsEAAB9BAAAhwQAAIgEAACOBAAAjwQAAJMEAACUBAAA nQQAAKYEAACtBAAArgQAALUEAAC6BAAAvQQAAL4EAADEBAAAxQQAAMwEAADNBAAA0AQAANEEAADb BAAA5AQAAO8EAADwBAAA+AQAAPkEAAAABQAAAQUAAAoFAABcBQAAZQUAAHAFAAB1BQAAegUAAIQF AACFBQAAiwUAAIwFAACQBQAAkQUAAJoFAACqBQAAswUAALQFAAC5BQAAvQUAAMAFAADBBQAAxQUA AMkFAADNBQAA1wUAANkFAADaBQAA4gUAAOMFAADmBQAA7wUAAPgFAAD5BQAA/gUAAAMGAAAHBgAA CAYAAAsGAAAMBgAAFgYAABcGAAAbBgAAHAYAACYGAAAnBgAALQYAAC4GAAAyBgAAMwYAADwGAAA9 BgAAPwYAAEAGAABEBgAARQYAAEcGAABIBgAATAYAAE0GAABQBgAAUQYAAFsGAABcBgAAXwYAAGgG AABxBgAAewYAAIIGAACJBgAAkgYAAJUGAACYBgAAqgYAAK4GAACvBgAAuAYAALkGAADBBgAAwgYA AMYGAADJBgAA0wYAANQGAADZBgAA2gYAAN8GAADrBgAA8gYAAPMGAAD2BgAA9wYAAAQHAAAiBwAA JQcAAC4HAAAzBwAAOwcAAEMHAABKBwAATwcAAFAHAABUBwAAVgcAAF8HAABgBwAAZQcAAHEHAAB1 BwAAdgcAAHgHAAB5BwAAgQcAAIIHAACLBwAAjAcAAJUHAACiBwAAqgcAAK4HAACzBwAAxwcAANIH AADYBwAA2gcAANsHAADkBwAA6AcAAOsHAADsBwAA8QcAAPUHAAD4BwAAAQgAAAgIAAAOCAAAGQgA AB8IAAAkCAAAJQgAACcIAAAoCAAALwgAADQIAAA4CAAAOQgAAEAIAABBCAAAQwgAAEkIAABPCAAA ZwgAAGkIAACDCAAAhggAAJ4IAAClCAAAqAgAALEIAACyCAAAtggAALcIAAC6CAAAuwgAAMIIAADQ CAAA2ggAAOoIAADuCAAA7wgAAPYIAAD3CAAA/ggAAAgJAAAKCQAADQkAABIJAAATCQAAGAkAABoJ AAAeCQAAHwkAACUJAAAmCQAAKAkAACkJAAAtCQAAMQkAADQJAAA1CQAAPAkAAEAJAABDCQAARAkA AEgJAABMCQAATwkAAFAJAABaCQAAXgkAAGIJAABnCQAAcQkAAH8JAACCCQAAgwkAAI0JAACXCQAA nAkAALkJAAC/CQAAwAkAAMgJAADJCQAAzQkAAM4JAADVCQAA1gkAAN0JAADuCQAA8AkAAPEJAAD0 CQAA/QkAAAQKAAANCgAAFwoAAB0KAAAnCgAAKAoAACoKAAArCgAALQoAAC4KAAA3CgAAPwoAAEwK AABNCgAATwoAAFAKAABUCgAAVQoAAFcKAABYCgAAWwoAAFwKAABeCgAAXwoAAGkKAABqCgAAbAoA AIEKAACLCgAAjAoAAJAKAACRCgAAkwoAAJQKAACWCgAAlwoAAKEKAACiCgAApAoAAKUKAACoCgAA rwoAALYKAAC9CgAAwgoAAMMKAADKCgAAywoAANUKAADaCgAA5AoAAOUKAADqCgAA7goAAPEKAADy CgAA+AoAAPkKAAD8CgAA/QoAAAULAAARCwAAFQsAABcLAAAgCwAALAsAADcLAAA+CwAAQQsAAEIL AABJCwAATQsAAFYLAABeCwAAYwsAAGQLAABmCwAAZwsAAG0LAABzCwAAdgsAAH8LAACBCwAAggsA AIQLAACFCwAAjQsAAI4LAACQCwAAkQsAAJQLAACVCwAAnwsAAKALAAClCwAApgsAAKgLAACpCwAA uAsAALsLAADFCwAAxgsAAMsLAADMCwAA0gsAANMLAADWCwAA1wsAAOELAADiCwAA5gsAAOcLAADr CwAA7wsAAPcLAAD7CwAADAwAABEMAAAUDAAAFQwAABcMAAAYDAAAHgwAAB8MAAApDAAANQwAADwM AAA+DAAAQgwAAEMMAABFDAAARgwAAE0MAABODAAAUQwAAFgMAABfDAAAZAwAAG8MAABwDAAAeAwA AHkMAACADAAAgQwAAIoMAACTDAAAlgwAAJcMAACeDAAAnwwAAKEMAACiDAAApQwAAKYMAACwDAAA vQwAAMAMAADBDAAAwwwAAMQMAADJDAAAygwAAM4MAADPDAAA1gwAANcMAADZDAAA2gwAANwMAADj DAAA5gwAAO0MAAD0DAAA9QwAAPcMAAD7DAAAAg0AAAYNAAAODQAADw0AABUNAAAWDQAAGw0AABwN AAAhDQAAIg0AACQNAAAlDQAALw0AADANAAAyDQAAMw0AADYNAAA3DQAAQQ0AAEMNAABHDQAAWA0A AF0NAABeDQAAYA0AAGENAABoDQAAbA0AAG8NAABwDQAAdA0AAHUNAAB3DQAAeA0AAIMNAACEDQAA iA0AAJENAACYDQAAmQ0AAJsNAACcDQAAnw0AAKANAACnDQAAqA0AAK0NAAC0DQAAuQ0AALoNAAC8 DQAAvQ0AAMENAADCDQAAxA0AAMUNAADLDQAAzA0AANMNAADUDQAA2w0AANwNAADgDQAA4Q0AAOgN AADqDQAA7A0AAO0NAADyDQAA8w0AAPcNAAD4DQAA+g0AAAcOAAAKDgAAEw4AABgOAAAZDgAAJA4A ACUOAAAsDgAAUQ4AAFQOAABdDgAAYg4AAGMOAABoDgAAbg4AAHAOAABxDgAAdw4AAHgOAAB/DgAA gg4AAIkOAACLDgAAjg4AAI8OAACWDgAApA4AAK0OAACuDgAAtQ4AALYOAAC4DgAAuQ4AALwOAADJ DgAA0A4AANEOAADYDgAA2Q4AAOEOAADiDgAA6Q4AAOoOAADtDgAA9A4AAPsOAAAADwAAAw8AAAQP AAAPDwAAEA8AABYPAAAYDwAAHA8AAB0PAAAiDwAAIw8AACUPAAApDwAALA8AAC0PAAA3DwAAOA8A AD0PAAA+DwAAQw8AAEQPAABIDwAASQ8AAEwPAABbDwAAYg8AAGMPAABtDwAAeg8AAIMPAACMDwAA kw8AALIPAAC1DwAAtg8AAL8PAADADwAAyA8AAMkPAADRDwAA1g8AANsPAADcDwAA3g8AAN8PAADm DwAA8w8AAP0PAAD+DwAAAxAAAAkQAAALEAAADBAAAA4QAAAPEAAAGRAAABoQAAAcEAAAHRAAACAQ AAAhEAAAKxAAAC8QAAA0EAAAOBAAADsQAAA8EAAAQxAAAEQQAABLEAAATBAAAFQQAABZEAAAXBAA AF0QAABmEAAAZxAAAG8QAABzEAAAdhAAAHwQAACAEAAAkxAAAJYQAACXEAAAmxAAAJwQAACjEAAA qRAAALIQAACzEAAAuBAAALkQAAC7EAAAvBAAAMYQAADHEAAAyxAAAMwQAADPEAAA0BAAANkQAADa EAAA4xAAAPkQAAD8EAAA/RAAAAERAAACEQAAChEAABsRAAAdEQAAHhEAACURAAAmEQAALREAADQR AAA7EQAARhEAAE0RAABOEQAAWBEAAFsRAABeEQAAXxEAAGkRAAB1EQAAeBEAAH8RAACGEQAAhxEA AIkRAACKEQAAjBEAAI0RAACUEQAAlREAAJsRAACfEQAAqxEAALIRAAC1EQAAthEAALkRAAC6EQAA vBEAAL0RAADHEQAAzBEAAM8RAADQEQAA1REAANYRAADcEQAA3REAAOARAADnEQAA7hEAAPARAAD3 EQAA+BEAAAMSAAAEEgAACRIAAAoSAAAMEgAADRIAAA8SAAAQEgAAFxIAACkSAAAyEgAANhIAAEMS AABNEgAAURIAAFUSAABZEgAAWhIAAF4SAABjEgAAZxIAAGgSAABwEgAAchIAAHcSAACBEgAAhhIA AKQSAACnEgAAqBIAALISAACzEgAAvxIAAMASAADDEgAAxBIAAM4SAADPEgAA0xIAANQSAADaEgAA LxMAADQTAAA5EwAARRMAAOYTAADtEwAAMhQAAEUUAABGFAAAThQAAE8UAABRFAAAUhQAAFkUAACl FAAAshQAALMUAAC7FAAAvBQAAL4UAAC/FAAAxhQAAMcUAAAyFQAAOxUAAEsVAABSFQAAXRUAAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHABSAG8AbwB0ACAARQBuAHQAcgB5 AAAAAACXAQAADwAAAClcDwBEAAAAEAgAAAAAAAAAAAAAagEAAIsAAABAAAAAFgAFAf////////// AQAAAAAJAgAAAAAAwAAAAAAAAEYAAAAAgBq0KTZGvgGge+MyNka+ARYAAADALgAAlhQAAFcAbwBy AGQARABvAGMAdQBtAGUAbgB0AAAAQwBjAAAAQTpcAAAAAAAAAACp8gAAAAAAAAAAAAAAAAAAAAAA AAAaAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWgEA AHlJAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABYAAQE9AAAA/////wUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAYgio2 Rr4B4BiCKjZGvgEAAAAAAAAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAWPHkfwAAAADMHEkAAAAAAAAAAAD+////KAACAf////8EAAAA/////wAAAABJAACgLABA ACAARADqOmkQAAAAAAAAAAAAAAAAAAAAAAQAAADMAQAAAAAAAP//////////AwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAVAEAABQAAAD9 ////GAAAABoAAAAXAAAANgAAACkAAAD+/////v////3////+//////////////////////////// ////////////////////////////////////////KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAA ADEAAAAyAAAAMwAAADQAAAAZAAAA/////0UAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAA PwAAAEAAAABBAAAAQgAAAEMAAABEAAAA/v///1YAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABN AAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAAD+////VwAAAHUAAABZAAAAWgAAAFsA AABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAA/v///2cAAABoAAAAaQAA AGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAA/v///3YAAACTAAAA /////3kAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAAAAAABfADkANwA4 ADMAMwA0ADkAMwA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgABAQcAAAAIAAAANwAAAAEJAgAAAAAAwAAAAAAAAEYAAAAA4BiCKjZGvgHgGIIqNka+AQAAAAAA AAAAAAAAAF8AOQA3ADgAMwAzADgAMgA2ADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAWAAEB//////////8wAAAAAQkCAAAAAADAAAAAAAAARgAAAADgGIIqNka+ AQC6iSo2Rr4BAAAAAAAAAAAAAAAAXwA5ADcANwA4ADQAMQAwADYAOAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQH//////////ykAAAABCQIAAAAAAMAAAAAA AABGAAAAAAC6iSo2Rr4BALqJKjZGvgEAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAD+////BQAAAAYA AAAHAAAACAAAAAkAAAAKAAAACwAAAP7///8NAAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAA ABUAAAAWAAAAFwAAAP7////+////GgAAAP7///8cAAAA/v///x4AAAAfAAAAIAAAAP7///8iAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAA/v////7///8rAAAA/v///y0AAAD+////LwAAADAAAAAx AAAA/v///zMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAD+/////v///zwAAAD+////PgAAAP7/ //9AAAAAQQAAAEIAAAD+////RAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAP7////+////TQAA AP7///9PAAAA/v///1EAAABSAAAAUwAAAP7///9VAAAAVgAAAFcAAABYAAAAWQAAAFoAAAD+//// /v///10AAAD+////XwAAAP7///9hAAAAYgAAAGMAAAD+////ZQAAAGYAAABnAAAAaAAAAGkAAABq AAAAawAAAP7////+////bgAAAP7///9wAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgA AAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAA AAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAKgAAAAIAAAAAQAAAEgAAAAPAAAAUAAAAAQAAABcAAAA BQAAAGQAAAAGAAAAbAAAAAsAAAB0AAAAEAAAAHwAAAAMAAAAhAAAAAIAAADkBAAAHgAAAAEAAAAA AAAAAwAAAADYAgADAAAAJAAAAAMAAAAIAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAAAsA AABSYXBwZWwgOiBIAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACcAQAA EgAAAAEAAACYAAAAAgAAAKAAAAADAAAAtAAAAAQAAADAAAAABQAAANwAAAAGAAAA6AAAAAcAAAD0 AAAACAAAAAgBAAAJAAAAGAEAABIAAAAkAQAACgAAAEwBAAALAAAAWAEAAAwAAABkAQAADQAAAHAB AAAOAAAAfAEAAA8AAACEAQAAEAAAAIwBAAATAAAAlAEAAAIAAADkBAAAHgAAAAsAAABSYXBwZWwg OiBIAP8eAAAAAQAAAAAUAAAeAAAAEQAAAEplYW4tQ2xhdWRlIERhbmcABQBhHgAAAAEAAAAAAAAA HgAAAAEAAAAAABQAHgAAAAsAAABOb3JtYWwuZG90AAAeAAAACAAAAENIQVRSQVMAHgAAAAIAAAAy AAAAHgAAAB4AAABNaWNyb3NvZnQgV29yZCBmb3IgV2luZG93cyA5NQAAAEAAAAAAAAAAAAAAAEAA AAAAItXqNUa+AUAAAAAAaJgONka+AUAAAAAAaJgONka+AQMAAAAFAAAAAwAAAAEDAAADAAAAIhEA AAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAKAAAAAI AAAAAQAAAEgAAAAPAAAAUAAAAAQAAABcAAAABQAAAGQAAAAGAAAAbAAAAAsAAAB0AAAAEAAAAHwA AAAMAAAAhAAAAAIAAADkBAAAHgAAAAEAAAAAAAAAAwAAAABMAAADAAAAAQAAAAMAAAABAAAACwAA AAAAAAALAAAAAAAAAAwQAAACAAAAHgAAAAEAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfADkANwA4ADUAMwAxADcAMAA4AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAAYAAAAKAAAAIgAAAAEJ AgAAAAAAwAAAAAAAAEYAAAAAALqJKjZGvgEAuokqNka+AQAAAAAAAAAAAAAAAF8AOQA3ADgANQAz ADMAMgA2ADkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA //////////8bAAAAAQkCAAAAAADAAAAAAAAARgAAAAAAuokqNka+AcDhkio2Rr4BAAAAAAAAAAAA AAAAXwA5ADcAOAA1ADMANAAxADQAOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYAAQEJAAAACwAAABQAAAABCQIAAAAAAMAAAAAAAABGAAAAAMDhkio2Rr4BwOGS KjZGvgEAAAAAAAAAAAAAAABfADkANwA4ADUAMwA0ADgAMwA4AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP//////////DQAAAAEJAgAAAAAAwAAAAAAAAEYA AAAAwOGSKjZGvgHA4ZIqNka+AQAAAAAAAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAAANAAAAAAAAAAAQBDAG8AbQBwAE8A YgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5AAAAagAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAA AIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAA lgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACk AAAApQAAAP7///+nAAAA/v///6kAAACqAAAAqwAAAP7///+tAAAArgAAAK8AAACwAAAAsQAAALIA AACzAAAA/v////7///+2AAAA/v///7gAAAD+////ugAAAP7///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////8BAQAAAgEAAAMBAAAEAQAABQEAAAYBAAAHAQAA CAEAAAkBAAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAAEQEAABIBAAATAQAAFAEAABUBAAAW AQAAFwEAABgBAAAZAQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAAIAEAACEBAAAiAQAA/v///yQB AAAyAQAAJgEAACcBAAAoAQAAKQEAACoBAAArAQAALAEAAC0BAAAuAQAALwEAADABAAD+//////// /zMBAAA0AQAANQEAADYBAAA3AQAAOAEAADkBAAA6AQAAHAAAADwBAAA9AQAAPgEAAD8BAABAAQAA QQEAAEIBAABDAQAARAEAAEUBAABGAQAARwEAAP7///9JAQAASgEAAEsBAABMAQAATQEAAE4BAABP AQAAUAEAAFEBAABSAQAA/v////////9WAQAA/////1cBAABYAQAAWQEAAP7///9bAQAAXAEAAF0B AABeAQAAXwEAAGABAABhAQAAYgEAAGMBAABkAQAAZQEAAGYBAABnAQAAaAEAAGkBAAACAAAA/f// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8ACQIAAAAAAMAA AAAAAABGGAAAAERvY3VtZW50IE1pY3Jvc29mdCBXb3JkAAoAAABNU1dvcmREb2MAEAAAAFdvcmQu RG9jdW1lbnQuNgD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIGVuZHBvaW50cyAoRmlndXJlIDIpLg0NEyBJTkNP UlBPUkVSIFdvcmQuUGljdHVyZS42ICAUARUNRmlndXJlIBMgU0VRIEZpZ3VyZSBcKiBBUkFCRSAU MhUgLSBTaWduYWxpbmcgYW5kIG1lZGlhIHBhdGhzIGZvciBHYXRla2VlcGVyIFJvdXRlZCBDYWxs IFNpZ25hbGluZw1CQ1NNIGZvciBILjMyMyB0ZWxlcGhvbnkgY2FsbHMNSW4gdGhlIHJlc3Qgb2Yg dGhpcyBkb2N1bWVudCB3ZSBjb25zaWRlciB0aGUgY2FzZSBvZiB0ZWxlcGhvbnkgY2FsbHMgYW5k IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCBHYXRla2VlcGVyIFJvdXRlZCBDYWxsIFNpZ25hbGlu ZyBpcyB1c2VkIHNvIHRoYXQgdGhlIEdhdGVrZWVwZXIgY2FuIG1vbml0b3Igc2lnbmFsaW5nIG1l c3NhZ2VzIGJldHdlZW4gSC4zMjMgZW5kcG9pbnRzLg0NVGhlIHVzZSBvZiBRLjkzMSBmb3IgY2Fs bCBzaWduYWxpbmcgc3VnZ2VzdHMgdGhhdCBhIEdhdGVrZWVwZXIgY291bGQgbW9kZWwgYSBCQ1NN IGFuZCBwcm92aWRlIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGEgU1NGL0NDRi4gRmlndXJlIDMgc2hv d3MgdGhlIG1lc3NhZ2UgZmxvd3MgZm9yIGFuIG9yZGluYXJ5IEguMzIzIHZvaWNlIGNhbGwuIERp ZmZlcmVudCBhcnJvdyBzdHlsZXMgYXJlIHVzZWQgdG8gaW5kaWNhdGUgZGlmZmVyZW50IHByb3Rv Y29scy4gQSBwb3NzaWJsZSBzZXF1ZW5jZSBvZiBzdGF0ZSB0cmFuc2l0aW9ucyBmb3IgYW4gT3Jp Z2luYXRpbmcgQkNTTSBpcyBpbmRpY2F0ZWQgb24gdGhlIHJpZ2h0IG9mIHRoZSBmaWd1cmUuIE1h cHBpbmcgb2YgYSBUZXJtaW5hdGluZyBCQ1NNIHdvdWxkIGJlIHNpbWlsYXIuIEluIHRoaXMgZXhh bXBsZSB3ZSBoYXZlIG1hcHBlZCBILjIyNS4wL1EuOTMxIG1lc3NhZ2VzIHRvIEJDU00gdHJhbnNp dGlvbnMuIE5vIHVzZSB3YXMgbWFkZSBvZiBILjI0NSBtZXNzYWdlcyBiZWNhdXNlIGEgdGVsZXBo b255IGNhbGwgd2FzIGFzc3VtZWQuIFN1cHBvcnQgZm9yIG11bHRpbWVkaWEgY29tbXVuaWNhdGlv bnMgd2lsbCByZXF1aXJlIG1hcHBpbmcgb2YgSC4yNDUgdG8gYSBzdGF0ZSBtb2RlbC4gVGhpcyBz aG91bGQgYmUgZG9uZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgd29yayBvbiB0aGUgc2VwYXJhdGlv biBvZiBjYWxsIGFuZCBjb25uZWN0aW9uLiBTdXBwb3J0IGZvciB0aGUgdHJpZ2dlcmluZyBvZiB2 YWx1ZSBhZGRlZCBzZXJ2aWNlcyBvbiByZWdpc3RyYXRpb24gb3IgYWNjZXNzIHJlcXVlc3RzIHdp bGwgcmVxdWlyZSBtYXBwaW5nIG9mIFJBUyBtZXNzYWdlcyB0byB0aGUgQlVDU00uIA1NYXBwaW5n IG9mIElOQVAgb3BlcmF0aW9ucw1JZiBhIEdhdGVrZWVwZXIgaXMgdG8gaW1wbGVtZW50IGFuIFNT RiBmdW5jdGlvbmFsaXR5IHNvIHRoYXQgaXQgY2FuIGJlIGNvbnRyb2xsZWQgYnkgYSBTQ0YsIElO QVAgU1NGLVNDRiBvcGVyYXRpb25zIG5lZWQgdG8gYmUgdHJhbnNwb3NlZCB0byB0aGUgSC4zMjMg Y29udGV4dC4NDUZvciBldmVudCByZWxhdGVkIG9wZXJhdGlvbnMgYW5kIG9wZXJhdGlvbnMgd2hp Y2ggZG8gbm90IG1vZGlmeSB0aGUgc2VxdWVuY2Ugb2YgYSBiYXNpYyBjYWxsIChJbml0aWFsRFAs IENvbnRpbnVlLCBSZWxlYXNlQ2FsbCwuLi4pLCB0aGUgbWFwcGluZyBvZiBwYXJhbWV0ZXIgdmFs dWVzIHdvdWxkIGJlIG5lZWRlZCwgYnV0IHRoZSBhY3Rpb25zIHRvIGJlIGV4ZWN1dGVkIGJ5IHRo ZSBHYXRla2VlcGVyIHdvdWxkIGJlIHN0cmFpZ2h0Zm9yd2FyZC4NDU9wZXJhdGlvbnMgd2hpY2gg bW9kaWZ5IHRoZSBjb25uZWN0aW9uIHZpZXcgc3VjaCBhcyBTcGxpdExlZyBvciBNZXJnZUNhbGxT ZWdtZW50cyBhcmUgbm90IHNvIGVhc2lseSB0cmFuc3Bvc2VkIGluIGEgSC4zMjMgY29udGV4dC4g VGhpcyBpcyBiZWNhdXNlIHRoZSBtZWRpYSBzdHJlYW1zIGFyZSBlc3RhYmxpc2hlZCBkaXJlY3Rs eSBiZXR3ZWVuIGVuZHBvaW50cyBhbmQgYXJlIG5vdCByZWxheWVkIGJ5IHRoZSBHYXRla2VlcGVy Lg1BIHBvc3NpYmxlIHdheSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gaXMgdG8gZm9yY2UgdGhlIG1l ZGlhIHN0cmVhbXMgdG8gZ28gdGhyb3VnaCBhbiByZWxheWluZyBlbnRpdHkgd2hpY2ggY291bGQg YmUgY29udHJvbGxlZCBieSB0aGUgR2F0ZWtlZXBlci4gU3VjaCBhIGNvbmZpZ3VyYXRpb24gY291 bGQgYmUgbmF0dXJhbCBpZiB0aGUgY2FsbCBpcyBlc3RhYmxpc2hlZCBmcm9tIGEgbG9jYWwgbmV0 d29yayB0byB0aGUgb3V0c2lkZSB3b3JsZCBhbmQgYSBwcm94eSBpcyB1c2VkIHRvIGZpbHRlciB0 cmFmZmljIGxlYXZpbmcgdGhpcyBuZXR3b3JrLiBJdCB3b3VsZCBhbHNvIGJlIHJlbGV2YW50IGlu IHRoZSBjYXNlIG9mIGNhbGxzIGVzdGFibGlzaGVkIGJldHdlZW4gYW4gSC4zMjMgdGVybWluYWwg YW5kIGEgdGVybWluYWwgb24gdGhlIFBTVE4gYXMgdGhlc2UgY2FsbHMgbXVzdCBiZSByb3V0ZWQg dGhyb3VnaCBhIGdhdGV3YXkuIFRoZSBnYXRld2F5IGFyY2hpdGVjdHVyZSBjdXJyZW50bHkgZmF2 b3JlZCBieSB0aGUgSUVURiB1c2VzIGEgZ2F0ZXdheSBjb250cm9sIHByb3RvY29sIGJldHdlZW4g dGhlIG1lZGlhIGdhdGV3YXkgYW5kIHRoZSBjb250cm9sbGluZyBlbnRpdHkgKHRoaXMgd291bGQg YmUgaW4gdGhlIEdhdGVrZWVwZXIgd2hpY2ggd291bGQgcGxheSB0aGUgcvRsZSBvZiBNZWRpYSBH YXRld2F5IENvbnRyb2xsZXIpLiBDYW5kaWRhdGUgcHJvdG9jb2xzIGFyZSBmb3IgZXhhbXBsZSBN R0NQIGFuZCBNRENQLiBGaWd1cmUgNCBzaG93cyB0aGUgZGlmZmVyZW50IGVudGl0aWVzIGludm9s dmVkLiBJbiBvcmRlciB0byBlbXVsYXRlIGEgU1NGLCBJTkFQIG9wZXJhdGlvbnMgd291bGQgaGF2 ZSB0byBiZSB0cmFuc2xhdGVkIGJ5IHRoZSBHYXRla2VlcGVyIGluIHRlcm1zIG9mIHRoZSBnYXRl d2F5IGNvbnRyb2wgcHJvdG9jb2wgYW5kIHRoZSBzaWduYWxpbmcgcHJvdG9jb2wgb24gdGhlIFBT VE4gc2lkZS4gRmlndXJlcyA1LTcgc2hvdyBob3cgc29tZSB0eXBpY2FsIElOQVAgc2VxdWVuY2Vz IGNvdWxkIGJlIHRyYW5zbGF0ZWQgaW50byB0aGUgZGlmZmVyZW50IHByb3RvY29scy4gSC4zMjMg bWVzc2FnZXMgaGF2ZSBub3QgYmVlbiBkZXRhaWxlZCBhbmQgdXNlIG9mIE1HQ1AgaXMgYXNzdW1l ZCBiZXR3ZWVuIE1lZGlhIEdhdGV3YXkgYW5kIE1lZGlhIEdhdGV3YXkgQ29udHJvbGxlci4NDVRo ZSBjb25zdHJhaW50IG9mIGZvcmNpbmcgdGhlIG1lZGlhIHN0cmVhbXMgdG8gYmUgcmVsYXllZCB0 aG91Z2ggYW4gaW50ZXJtZWRpYXRlIHBvaW50IG1heSBub3QgYmUgY29udmVuaWVudCBmb3IgYWxs IGNhbGxzIGluc2lkZSB0aGUgbG9jYWwgbmV0d29yay4gQW5vdGhlciBwb3NzaWJpbGl0eSBjb3Vs ZCBiZSB0byByZXF1aXJlIHN1cHBvcnQgaW4gSC4zMjMgdGVybWluYWxzIG9mIHN1cHBsZW1lbnRh cnkgc2VydmljZXMgc3VjaCBhcyBDYWxsIEhvbGQgYW5kIENhbGwgVHJhbnNmZXIuIFRoZXNlIHNl cnZpY2VzIHdvdWxkIHNlcnZlIGFzIGJ1aWxkaW5nIGJsb2NrcyBmb3IgdGhlIG9wZXJhdGlvbnMg bWFuaXB1bGF0aW5nIHRoZSBjb25uZWN0aW9uIHZpZXcgc3RhdGVzLg0NEyBJTkNPUlBPUkVSIFdv cmQuUGljdHVyZS42ICAUARUNRmlndXJlIBMgU0VRIEZpZ3VyZSBcKiBBUkFCRSAUMxUgLSBILjMy MyBtZXNzYWdlIGZsb3dzIGFuZCBjb3JyZXNwb25kaWcgT19CQ1NNIHRyYW5zaXRpb25zDRMgSU5D T1JQT1JFUiBXb3JkLlBpY3R1cmUuNiAgFAEVDUZpZ3VyZSATIFNFUSBGaWd1cmUgXCogQVJBQkUg FDQVDQ0NDQ0NDQ0TIElOQ09SUE9SRVIgV29yZC5QaWN0dXJlLjYgIBQBFQ1GaWd1cmUgEyBTRVEg RmlndXJlIFwqIEFSQUJFIBQ1FSAtIENvbm5lY3QNEyBJTkNPUlBPUkVSIFdvcmQuUGljdHVyZS42 ICAUARUNRmlndXJlIBMgU0VRIEZpZ3VyZSBcKiBBUkFCRSAUNhUgLSBJbml0aWF0ZUNhbGxBdHRl bXB0IGZvbGxvd2VkIGJ5IENvbm5lY3QNDQ0NDQ0NDRMgSU5DT1JQT1JFUiBXb3JkLlBpY3R1cmUu NiAgFAEVDUZpZ3VyZSATIFNFUSBGaWd1cmUgXCogQVJBQkUgFDcVIC0gRGlzY29ubmVjdExlZyBm b2xsb3dlZCBieSBDb25uZWN0DUV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFuZGFyZCBJ bnN0aXR1dGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRELTAwDUVUU0kgU1RDIFNQ UzMLIA1Tb3BoaWEgQW50aXBvbGlzLCBGcmFuY2UsIDI1LTI5IEphbnVhcnkgMTk5OQ0NDQ0NHwCP AaEBAJkQpIMupchBpooFp4oFqIoFqYoFqgAAqwkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADl18HQxVv916P91FP91EP918OhyBAAAi9iF230ZVlZW aKICAABWamJT/3UI6EOW+v/pJAEAADP2OXX0dDJqAf916P91FP91EP919Og5BAAAi9iF230ZVlZW aKECAABWamFT/3UI6AqW+v/p6wAAADPSi0UIOVB8dE05VfB0FIlVrLoBAAAAi0XUiUWwi03wiU20 M8A5RfR0GIvKQmvJDIlEDayLRfiJRA2wi130iVwNtIXSdBFSjUWsUItNCP9xZFHokLcAAP915ItV CP916P+yiAAAAOghBAAAi9iF23QCM9uDfQwBdXKNvfz+//8zwLkTAAAA86uLdQiNvfz+//+Dxmyl paWlOUX4dA2NvQz///+LdfilpaWljYX8/v//jU2oUY2VSP///8eFSP///wAAAEDHhVD///8AEAAA x4VU////TAAAAFKJhVj///9qAWhANsFt6LIX+/8z9jl17HQ5i0Xs/0gMi0XsOXAMdSuNTfiJdfiL RexRi3gQV4sH/1AMV+j7e/r/i0XsO8Z0C1BW/3XI/xXMGbht/3Xw6OF7+v//dfTo2Xv6//91zP8V 5Bm4bYvD6wW4VwAHgF9eW4vlXcIQAFWL7IPsPFNWVzP2/3UI/3UkiXX86LVy+v+FwA+FCAIAAItF CIsIgXlQztO9bQ+F9gEAAwBQAEkAQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAbAAAATAAAAAAAAAADAE0ARQBUAEEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAACAQwAAAAPAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYAAAAUHgAAAAAAAAEAQwBvAG0AcABPAGIA agAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQAAAGYAAAAAAAAA AwBPAGIAagBJAG4AZgBvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABIAAgAOAAAAEQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAYAAAABAAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADcAAABDGwAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBEAAAABIAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAANABAAAAAAAABQBEAG8AYwB1AG0AZQBu AHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAA0AAAAAAAAAAD AFAASQBDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACwAAABMAAAAAAAAAAMATQBFAFQAQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAMAAIBEwAAABYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAZgAAACQcAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAAAZgAAAAAAAAADAE8AYgBqAEkAbgBmAG8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACABUAAAAY AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACkAAAAEAAAAAAAAAFcA bwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WAAAACsbAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgEXAAAAGQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAhAAAA0AEAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5 AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0AAADQAAAAAAAAAAMAUABJAEMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPQAAAEwAAAAAAAAAAwBN AEUAVABBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAwAAgEaAAAAHQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACF AAAASBoAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADsAAABmAAAAAAAAAAMATwBiAGoASQBuAGYAbwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIAHAAAAB8AAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOgAAAAQAAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgD///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4AAAAFxkAAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKAACAR4AAAAgAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIA AADQAQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAALgAAANAAAAAAAAAAAwBQAEkAQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOAAAATAAAAAAAAAADAE0ARQBUAEEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAACASEAAAAkAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKIAAACQHAAAAAAAAAEAQwBv AG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAASAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAA AGYAAAAAAAAAAwBPAGIAagBJAG4AZgBvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAgAjAAAAJgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABLAAAABAAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJUAAAANGQAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBJQAAACcAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwAAANABAAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAA ADgAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAA 0AAAAAAAAAADAFAASQBDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAF4AAABMAAAAAAAAAAMATQBFAFQAQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAIBKAAAACsAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzgAAAICoAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAAAZgAAAAAAAAADAE8AYgBq AEkAbgBmAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EgACACoAAAAtAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFsAAAAE AAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAswAAAA8yAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8A bgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEsAAAALgAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUAAAAwAEAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAADQAAAAAAAAAAMAUABJAEMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAEwA AAAAAAAAAwBNAEUAVABBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAwAAgEvAAAAMgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABvAAAAvA0AAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAG0AAABmAAAAAAAAAAMATwBiAGoASQBuAGYAbwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIAMQAAADQAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAAAQAAAAAAAAAVwBvAHIAZABE AG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAQAAzxYA AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACATMAAAA1AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGQAAADQAQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAANAAAAAAAAAAAwBQAEkAQwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3AAAATAAAAAAAAAADAE0ARQBUAEEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAC ATYAAAA5AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgBAAB4FAAA AAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAtQAAAGYAAAAAAAAAAwBPAGIAagBJAG4AZgBvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgA4AAAAOwAAAP////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC0AAAABAAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADsBAADtGAAAAAAAAAUAUwB1AG0AbQBh AHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB OgAAADwAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAAANABAAAA AAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAADgAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACoAAAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACgAQAAEgAA AAEAAACYAAAAAgAAAKAAAAADAAAArAAAAAQAAAC4AAAABQAAANQAAAAGAAAA4AAAAAcAAADsAAAA CAAAAAABAAAJAAAAHAEAABIAAAAoAQAACgAAAFABAAALAAAAXAEAAAwAAABoAQAADQAAAHQBAAAO AAAAgAEAAA8AAACIAQAAEAAAAJABAAATAAAAmAEAAAIAAADkBAAAHgAAAAEAAAAAD0cAHgAAAAEA AAAAfUQAHgAAABEAAABKZWFuLUNsYXVkZSBEYW5nAA5HAB4AAAABAAAAAAcAAB4AAAABAAAAAAAA AB4AAAALAAAAbm9ybWFsLmRvdAAAHgAAABEAAABKZWFuLUNsYXVkZSBEYW5nAAARAB4AAAACAAAA MgAAAB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFdpbmRvd3MgOTUAAABAAAAAAAAAAAAAAABA AAAAAPqF8mPXuQFAAAAAAOA2+CZGvgFAAAAAAEj7WS9GvgEDAAAAAQAAAAMAAAACAAAAAwAAABEA AAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANylaABX4AwEAAAAAGUAAAAAAAAAAAAAAAADAADQAwAAQxsAAAAAAAAAAAAAAAAAAAAAAAAVAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAADgAAPAQAAAAOAAA8BAAAPBIAAAAAAAA8 EgAAAAAAAHQSAAAAAAAAdBIAAAAAAAB0EgAAFAAAAJ4SAAAUAAAAnhIAAAAAAACyEgAAAAAAALIS AAAAAAAAshIAAAAAAACyEgAACgAAALwSAAAQAAAAnhIAAAAAAACGGgAAMQAAAMwSAAAAAAAAzBIA AAAAAADMEgAAAAAAAMwSAAAAAAAAzBIAAAAAAACYEwAAAAAAAJgTAAAAAAAAmBMAAAAAAACYEwAA AgAAAJoTAAAAAAAAmhMAAAAAAACaEwAANgAAANATAABMAwAAHBcAAEwDAABoGgAAHgAAALcaAABY AAAADxsAADQAAACGGgAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0EgAAAAAAAJgTAAAAAAAAAAAEAAUA AQACAMwSAADMAAAAmBMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmBMAAAAAAACYEwAAAAAAAIYaAAAA AAAAmBMAAAAAAAA8EgAAAAAAADwSAAAAAAAAzBIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzBIAAAAA AACYEwAAAAAAAJgTAAAAAAAAmBMAAAAAAACYEwAAAAAAADwSAAA4AAAAzBIAAAAAAAB0EgAAAAAA AMwSAAAAAAAAmBMAAAAAAAAAAAAAAAAAACBZZ2IvRr4BiBIAAAgAAACQEgAADgAAADwSAAAAAAAA PBIAAAAAAAA8EgAAAAAAADwSAAAAAAAAmBMAAAAAAACYEwAAAAAAAJgTAAAAAAAAmBMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgICAgICAgICAgICAgICAgICAgIDURpc2Nvbm5l Y3RMZWcNQ29ubmVjdChASVApDQ0NNSkNDTIpDQ1Nb2RpZnlDb25uZWN0aW9uDQ1Nb2RpZnlDb25u ZWN0aW9uDQ1NZWRpYSBHYXRld2F5DQ1ILjMyMyB0ZXJtaW5hbA0NUkFTC1EuOTMxC0guMjQ1DQ1I LjMyMyB0ZXJtaW5hbA0NR0sNDU1lZGlhIEdhdGV3YXkgQ29udHJvbGxlcg0NUFNUTg0NSVAgbmV0 d29yaw0NDQ0bAKEBAKTATqXATqYHGqfPG6iQH6lZHaoAAKsJAAAAMgABAQAwAAACBCgAOx/fIM0G pAIAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAwAAEBCzAAAAEAJgBXIa0lswJECLICAAAA AEMIAAAAAA8AAAAaABoAAAAAAAAAAAAyAAEBDDAAAAIEKAALIkApPAEeAQAAAAAFAAUA////AP// /wABAAAAAAAAAAAAFAAAADIAAQEKMAAAAgQoAFchYCc8AR4BAAAAAAUABQD///8A////AAEAAAAA AAAAAAAUAAAAMgABAQkwAAACBCgAGCQTKQgIaAIAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQA AAAwAAEBCDAAAAEAJgBIIYYu6QgBAAAAAADoCAAAAAAAACgAAAAYABoAAAAAAAAAAAAwAAEBBDAA AAEAJgBIIdUqFgmjAwAAAAAVCaIDAAAAACgAAAAYABoAAAAAAAAAAAAwAAEBBTAAAAEAJgCkLoYu OQQQAAAADwA4BAAAAAAAACgAAAAYABoAAAAAAAAAAAAwAAEBBjAAAAEAJgCMKFAolAPtBAAAAACT A+wEAAAAAA8AAAAaABgAAAAAAAAAAAAyAAEB+y8AAAIEKABOKjwtGwSkAgAAAAAFAAAA////AP// /wABAAAAAAAAAAAAFAAAADIAAQH4LwAAAgQoAB8dDy0bBKQCAAAAAAUAAAD///8AAAAhUQAAAAAA AAAAAAAUAAAAMAABAQIwAAABACYAOSFEJf4C7QT9AgAAAADsBAAAAAAPAAAAGgAaAAAAAAAAAAAA MgABAQMwAAACBCgAOx+BJCsD0QIAAAAAKAAFAP///wAAACFRAAAAAAAAAAAAABQAAAAyAAEB+S8A AAIEKAAfHTEpGwSkAgAAAAAFAAAA////AAAAIVEAAAAAAAAAAAAAFAAAADAAAQEHMAAAAQAmADQm hh8BAIQEAAAAAAAAgwQAAAAADwAAABoAGAAAAAAAAAAAADAAAQH6LwAAAQAmAHksViIBAB8PAAAA AAAAHg8AAAAABQACABgAGAAAAAAAAAAAADIAAQH3LwAAAgQoADYkGCQbBHcCAAAAAAUAAAD///8A AAAhUQAAAAAAAAAAAAAUAAAAMgABAfwvAAACBCgAYSbLJRsEdwIAAAAABQAAAP///wD///8AAQAA AAAAAAAAABQAAAAyAAEB/S8AAAIEKABpLVYiSARpAQAAAAAFAAUA////AP///wABAAAAAAAAAAAA FAAAADIAAQEBMAAAAgQoAGAnViJIBGkBAAAAAAUABQD///8A////AAEAAAAAAAAAAAAUAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMA ABQDAAAVAwAAMQMAADIDAAA1AwAANgMAADkDAAA6AwAASwMAAEwDAABdAwAAXgMAAGsDAABtAwAA ewMAAH0DAACNAwAAjgMAAJwDAACeAwAAoAMAAKIDAAC6AwAAuwMAALwDAADBAwAAwgMAAM0DAADP AwAA0AMAAMUHAAD5APUA9QD1APXx9QD1APUA9QD1APUA7esA9QD1AADpAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAJ1AQADYxAABl0CAGMQAAAGXQIAYwIAAAZdAgBjFAAAC3UBRAQAAAAAYQAEAB8AAwAA FQMAACMDAAAwAwAAMQMAADIDAAA1AwAANgMAADkDAAA6AwAASwMAAEwDAABdAwAAXgMAAGwDAAD+ AAHrGBsB3QABqAbkALwAAagG5ACcAAGoBuQA/gAAAAAAAJkAARkB5AD+AAAAAAAAmQABGQHkAP4A AAAAAAB4AAHiB+QA/gAB4gcYAFcAAeIH5AD+AAAAAAAAUgAC7gPkAAAAAAAAAAQAAAUBFVAAAAAg AAANChEbARPl/gw0AAABCAAAAYAAAAYAGwEAAAAAAAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAgAAANChEbARPl/gw0AAABCAAAAYAAAAMAGwEAAAAAAAApAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAFAQAfAAARqgETVv4MNAAAAjgCAAIAFAABABsBAAAAAAAAKSAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADQoRVwET5f4MNAAAAQgAAAGAAAAEABsB AAAAAAAAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADQoRVwET5f4MNAAAAjgC AAIAFAABABsBAAAAAAAAKSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAADmwDAABt AwAAfAMAAH0DAACNAwAAjgMAAJ0DAACeAwAAoQMAAKIDAAC7AwAAvAMAAMEDAADCAwAAzQMAAM4D AADPAwAA0AMAAP4AAAAAAAD5AALwA+QA/gAAAAAAAPYAAwcD5AD+AAAAAAAA+QAC8APkAP4AAAAA AAD5AAHuA+QA/gAAAAAAAPYAA+4DuQD+AAAAAAAA/gABIgTkAP4AAAAAAAD+AAEiBOQA/gAAAAAA AP4AAAAAAAD+AAHrGBsBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAUBAAQAAAUBFVAAAAABAAARDgATAAgA AQBLAA8AAAAAABwAAEDx/wIAHAAGTm9ybWFsAAIAAAAGAGEMBGMYAFgAAUABAAIAWAAHVGl0cmUg MQAAQAABAA0BFeABFvAADDQAAAEEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgBVgVwAAkABAPIAXAAHVGl0cmUgMgAAQAACAA0CFfAAFngADDQAAAAEAAAB gAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBVgWMWAABcAANA AQASAVwAB1RpdHJlIDMAAEAAAwANAxV4ABZ4AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAXgFjFgAAXgAEQAEAAgBeAAdUaXRyZSA0AABCAAQA CAENBBXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAUAVYFdAgAAXAAFQAEAAgBcAAdUaXRyZSA1AABAAAUADQUV8AAWPAAMNAABAAQAAAGA AAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAF0CAGMWAFwABkAB AAIAXAAHVGl0cmUgNgAAQAAGAA0GFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBWgWMWAABcAAdAAQACAFwAB1RpdHJlIDcAAEAABwAN BxXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAYAXQIAYxQAXgAIQAEAAgBeAAdUaXRyZSA4AABAAAgADQgV8AAWPAAMNAABAAQAAAGAAAAB AAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAFaBXQIAYxQAYAAJQAEA AgBgAAdUaXRyZSA5AABAAAkADQkV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAFWBVoFdAgBjEgAeAEFA8v+hAB4AEVBvbGljZSBwYXIg ZOlmYXV0AAAAAAAAAAAAAAAAIgD+TwEB8gAiAA5SZXRyYWl0Tm9ybWFsMgAFAA8AEW4EAAAAIgAc QAEAAgEiAA5SZXRyYWl0IG5vcm1hbAAFABAAEcQCAAAAIgD+T/EAEgEiAA5SZXRyYWl0Tm9ybWFs MwAFABEAERgGAAAAJgAgQAEAIgEmAAxQaWVkIGRlIHBhZ2UADAASAA8IAALTEm8jAQIAAAAAAAAd AAAAIQAAACUAAABJAAAAWAAAAGgAAAB5AAAAiQAAAI0AAACnAAAArQAAALkAAAC8AAAAAAAAANAA AAAJANADAAAAAP////8BAAQg//8BAAAAAADQAAAAAAAAAAAAAAAAABYAAADQAAAABgAAAAYAAAAA AwAAxQcAAAQAAAMAAGwDAADQAwAABQAGAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA0AAAAO0DAAAB AB8EAAAAAE8EAAABAIEEAAABALMEAAABAOUEAAAAABUFAAAAAEUFAAAAAHUFAAAAAKUFAAABANcF AAABAAkGAAAAADkGAAABAGsGAAABAJ0GAAAAAM0GAAAAAP0GAAABAC8HAAABAGEHAAABAJMHAAAB AP9ASFAgTGFzZXJKZXQgNDAwMCBQUwBMUFQxOgBQU0NSSVBUAEhQIExhc2VySmV0IDQwMDAgUFMA SFAgTGFzZXJKZXQgNDAwMCBQUwAAAAAAAAAAAAAAAAAABAMElAC4Ah93AAABAAkAmgszCGQAAQAH AFgCAQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAwBIAAMgZ AAABAAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAILka71nOmts/LYFAAIAAQAAAAAAAQAA AAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP//AwD//wEA//8AAP//AQD//wAA//8AAP// AAD//wEA//8BAP//AAD//wEA//8BAP//AAD//wAA//8AAP//AAD//wEA//8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9QYWdlIHBlcnNvbm5hbGlz6WUgMQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdl IHBlcnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAAAAAAAAAAAAAEhQIExhc2VySmV0 IDQwMDAgUFMAAAAAAAAAAAAAAAAAAAQDBJQAuAIfdwAAAQAJAJoLMwhkAAEABwBYAgEAAgBYAgMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAMASAADIGQAAAQAAAAAAAAAB AAAAAgAAAAAAAAAAAAAAAAAAAAAAAACC5Gu9ZzprbPy2BQACAAEAAAAAAAEAAAAAAAIAAgABAFID AADCAQAAAAAAAAAAZAAAAAAAAwD//wMA//8BAP//AAD//wEA//8AAP//AAD//wAA//8BAP//AQD/ /wAA//8BAP//AQD//wAA//8AAP//AAD//wAA//8BAP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP//UGFnZSBwZXJzb25uYWxpc+llIDEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAUGFnZSBwZXJzb25uYWxp c+llIDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRD AAAAAAAAUGFnZSBwZXJzb25uYWxpc+llIDMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAAAAAAAAAAAADgAEAAAAAAAAAAAALAAEAAQAAAAAA AAAfAAAAAAAxABUWkAEAAFRpbWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAAQXJpYWwA IgAEAAMDjBhWDMQCAACpAQAAAABwtDEGsLQxpgAAAAACAAAAAAACAAAAEQAAAAEAAQAAAAQAgwAB AAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDVgwAADQAAAAAAAAAEEplYW4tQ2xhdWRlIERhbmcQ SmVhbi1DbGF1ZGUgRGFuZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMK AAD/////AQkCAAAAAADAAAAAAAAARhUAAABJbWFnZSBNaWNyb3NvZnQgV29yZAAKAAAATVNXb3Jk RG9jAA8AAABXb3JkLlBpY3R1cmUuNgD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABMAAAAAAAAAAAACAD4KwAAfB8AAO0YAADZEQAAAAAAAAAAAAAAAAAAAAAAAOgDAADo AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4b EJOXCAArLPmuMAAAAKAAAAAIAAAAAQAAAEgAAAAPAAAAUAAAAAQAAABcAAAABQAAAGQAAAAGAAAA bAAAAAsAAAB0AAAAEAAAAHwAAAAMAAAAhAAAAAIAAADkBAAAHgAAAAEAAAAAcwAAAwAAAAA4AAAD AAAAAQAAAAMAAAABAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAAAgA+Ct8HwAAAQAJAAAD BQ8AAAwAIwAAAAAAFAAAACYGDwAeAP////8EABQAAABXb3JkDgBNaWNyb3NvZnQgV29yZAUAAAAL AgAAAAAFAAAADAJwB2MKDQAAAPsCAAAAAAAAAAAAAAAAAAAAAAABAAwEAAAALQEAAAQAAAACAQEA FQAAAPsCnP8AAAAAAACQAQAAAAAEAAASVGltZXMgTmV3IFJvbWFuAGsBBAAAAC0BAQAFAAAACQIA AAAABAAAAAIBAQAEAAAAAgEBAAcAAAD8AgEAAAAAAAAABAAAAC0BAgAJAAAA+gIAAAIAAAAAAAAA IgAEAAAALQEDAAcAAAAbBOoC9QXjAT8ECQAAAPoCAAAAAAAAAAAAACIABAAAAC0BBAAEAAAA8AED AAcAAAD8AgAA////AAAABAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBOEC6wXsAUgEBAAAAAIB AQAQAAAA+wKt/wAAAAAAAJABAAAAAAQAACJBcmlhbAAqAAQAAAAtAQUADgAAADIKEALdBAIABAAA AAAAYwpwB0dLQQA3AAQAAAAtAQEABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BAgAJAAAA +gIAAAIAAAAAAAAAIgAEAAAALQEGAAcAAAAbBLkGAQOfBUoBBAAAAC0BBAAEAAAA8AEGAAQAAAAt AQMABAAAAAIBAQADAAAAHgAHAAAAFgSwBvcCqAVTAQQAAAACAQEABAAAAC0BBQATAAAAMgrMBbYB BQAEAAAAAABjCnAHSC4zMjMAPAAXAC4ALgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABcAAAAy CisGkAEIAAQAAAAAAGMKcAd0ZXJtaW5hbBcALgAcAEcAEgAuAC4AEgAEAAAALQEBAAQAAAACAQEA BAAAACcB//8EAAAAAgEBAAQAAAAtAQIACQAAAPoCAAACAAAAAAAAACIABAAAAC0BBgAHAAAAGwQd BQEDAwRKAQQAAAAtAQQABAAAAPABBgAEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEEwX3AgwE UwEEAAAAAgEBAAQAAAAtAQUAEwAAADIKMAS2AQUABAAAAAAAYwpwB0guMzIzADwAFwAuAC4ALgAE AAAAAgEBAAQAAAACAQEABAAAAC0BBQAXAAAAMgqPBJABCAAEAAAAAABjCnAHdGVybWluYWwXAC4A HABHABIALgAuABIABAAAAC0BAQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAHAAAA/AIAAAAAAAAA AAQAAAAtAQYACQAAAPoCBQAAAAAA////ACIABAAAAC0BBwAMAAAAJAMEAK8HJwGxBycBsQcrAa8H KwEMAAAAJAMEAK8HMwGxBzMBsQc3Aa8HNwEMAAAAJAMEAK8HPwGxBz8BsQdDAa8HQwEMAAAAJAME AK8HSwGxB0sBsQdPAa8HTwEMAAAAJAMEAK8HVwGxB1cBsQdbAa8HWwEMAAAAJAMEAK8HYwGxB2MB sQdnAa8HZwEMAAAAJAMEAK8HbwGxB28BsQdzAa8HcwEMAAAAJAMEAK8HewGxB3sBsQd/Aa8HfwEM AAAAJAMEAK8HhwGxB4cBsQeLAa8HiwEMAAAAJAMEAK8HkwGxB5MBsQeXAa8HlwEMAAAAJAMEAK8H nwGxB58BsQejAa8HowEMAAAAJAMEAK8HqwGxB6sBsQevAa8HrwEMAAAAJAMEAK8HtwGxB7cBsQe7 Aa8HuwEMAAAAJAMEAK8HwwGxB8MBsQfHAa8HxwEMAAAAJAMEAK8HzwGxB88BsQfTAa8H0wEMAAAA JAMEAK8H2wGxB9sBsQffAa8H3wEMAAAAJAMEAK8H5wGxB+cBsQfrAa8H6wEMAAAAJAMEAK8H8wGx B/MBsQf3Aa8H9wEMAAAAJAMEAK8H/wGxB/8BsQcDAq8HAwIMAAAAJAMEAK8HCwKxBwsCsQcPAq8H DwIMAAAAJAMEAK8HFwKxBxcCsQcbAq8HGwIMAAAAJAMEAK8HIwKxByMCsQcnAq8HJwIMAAAAJAME AK8HLwKxBy8CsQczAq8HMwIMAAAAJAMEAK8HOwKxBzsCsQc/Aq8HPwIMAAAAJAMEAK8HRwKxB0cC sQdLAq8HSwIMAAAAJAMEAK8HUwKxB1MCsQdXAq8HVwIMAAAAJAMEAK8HXwKxB18CsQdjAq8HYwIM AAAAJAMEAK8HawKxB2sCsQdvAq8HbwIMAAAAJAMEAK8HdwKxB3cCsQd7Aq8HewIMAAAAJAMEAK8H gwKxB4MCsQeHAq8HhwIMAAAAJAMEAK8HjwKxB48CsQeTAq8HkwIMAAAAJAMEAK8HmwKxB5sCsQef Aq8HnwIMAAAAJAMEAK8HpwKxB6cCsQerAq8HqwIMAAAAJAMEAK8HswKxB7MCsQe3Aq8HtwIMAAAA JAMEAK8HvwKxB78CsQfDAq8HwwIMAAAAJAMEAK8HywKxB8sCsQfPAq8HzwIMAAAAJAMEAK8H1wKx B9cCsQfbAq8H2wIMAAAAJAMEAK8H4wKxB+MCsQfnAq8H5wIMAAAAJAMEAK8H7wKxB+8CsQfzAq8H 8wIMAAAAJAMEAK8H+wKxB/sCsQf/Aq8H/wIMAAAAJAMEAK8HBwOxBwcDsQcLA68HCwMMAAAAJAME AK8HEwOxBxMDsQcXA68HFwMMAAAAJAMEAK8HHwOxBx8DsQcjA68HIwMMAAAAJAMEAK8HKwOxBysD sQcvA68HLwMMAAAAJAMEAK8HNwOxBzcDsQc7A68HOwMMAAAAJAMEAK8HQwOxB0MDsQdHA68HRwMM AAAAJAMEAK8HTwOxB08DsQdTA68HUwMMAAAAJAMEAK8HWwOxB1sDsQdfA68HXwMMAAAAJAMEAK8H ZwOxB2cDsQdrA68HawMMAAAAJAMEAK8HcwOxB3MDsQd3A68HdwMMAAAAJAMEAK8HfwOxB38DsQeD A68HgwMMAAAAJAMEAK8HiwOxB4sDsQePA68HjwMMAAAAJAMEAK8HlwOxB5cDsQebA68HmwMMAAAA JAMEAK8HowOxB6MDsQenA68HpwMMAAAAJAMEAK8HrwOxB68DsQezA68HswMMAAAAJAMEAK8HuwOx B7sDsQe/A68HvwMMAAAAJAMEAK8HxwOxB8cDsQfLA68HywMMAAAAJAMEAK8H0wOxB9MDsQfXA68H 1wMMAAAAJAMEAK8H3wOxB98DsQfjA68H4wMMAAAAJAMEAK8H6wOxB+sDsQfvA68H7wMMAAAAJAME AK8H9wOxB/cDsQf7A68H+wMMAAAAJAMEAK8HAwSxBwMEsQcHBK8HBwQMAAAAJAMEAK8HDwSxBw8E sQcTBK8HEwQMAAAAJAMEAK8HGwSxBxsEsQcfBK8HHwQMAAAAJAMEAK8HJwSxBycEsQcrBK8HKwQM AAAAJAMEAK8HMwSxBzMEsQc3BK8HNwQMAAAAJAMEAK8HPwSxBz8EsQdDBK8HQwQMAAAAJAMEAK8H SwSxB0sEsQdQBK8HUAQMAAAAJAMEAK8HWASxB1gEsQdcBK8HXAQMAAAAJAMEAK8HZASxB2QEsQdo BK8HaAQMAAAAJAMEAK8HcASxB3AEsQd0BK8HdAQMAAAAJAMEAK8HfASxB3wEsQeABK8HgAQMAAAA JAMEAK8HiASxB4gEsQeMBK8HjAQMAAAAJAMEAK8HlASxB5QEsQeYBK8HmAQMAAAAJAMEAK8HoASx B6AEsQekBK8HpAQMAAAAJAMEAK8HrASxB6wEsQewBK8HsAQMAAAAJAMEAK8HuASxB7gEsQe8BK8H vAQMAAAAJAMEAK8HxASxB8QEsQfIBK8HyAQMAAAAJAMEAK8H0ASxB9AEsQfUBK8H1AQMAAAAJAME AK8H3ASxB9wEsQfgBK8H4AQMAAAAJAMEAK8H6ASxB+gEsQfsBK8H7AQMAAAAJAMEAK8H9ASxB/QE sQf4BK8H+AQMAAAAJAMEAK8HAAWxBwAFsQcEBa8HBAUMAAAAJAMEAK8HDAWxBwwFsQcQBa8HEAUM AAAAJAMEAK8HGAWxBxgFsQccBa8HHAUMAAAAJAMEAK8HJAWxByQFsQcoBa8HKAUMAAAAJAMEAK8H MAWxBzAFsQc0Ba8HNAUMAAAAJAMEAK8HPAWxBzwFsQdABa8HQAUMAAAAJAMEAK8HSAWxB0gFsQdM Ba8HTAUMAAAAJAMEAK8HVAWxB1QFsQdYBa8HWAUMAAAAJAMEAK8HYAWxB2AFsQdkBa8HZAUMAAAA JAMEAK8HbAWxB2wFsQdwBa8HcAUMAAAAJAMEAK8HeAWxB3gFsQd8Ba8HfAUMAAAAJAMEAK8HhAWx B4QFsQeIBa8HiAUMAAAAJAMEAK8HkAWxB5AFsQeUBa8HlAUMAAAAJAMEAK8HnAWxB5wFsQegBa8H oAUMAAAAJAMEAK8HqAWxB6gFsQesBa8HrAUMAAAAJAMEAK8HtAWxB7QFsQe4Ba8HuAUMAAAAJAME AK8HwAWxB8AFsQfEBa8HxAUMAAAAJAMEAK8HzAWxB8wFsQfQBa8H0AUMAAAAJAMEAK8H2AWxB9gF sQfcBa8H3AUMAAAAJAMEAK8H5AWxB+QFsQfoBa8H6AUMAAAAJAMEAK8H8AWxB/AFsQf0Ba8H9AUM AAAAJAMEAK8H/AWxB/wFsQcABq8HAAYMAAAAJAMEAK8HCAaxBwgGsQcMBq8HDAYMAAAAJAMEAK8H FAaxBxQGsQcYBq8HGAYMAAAAJAMEAK8HIAaxByAGsQckBq8HJAYMAAAAJAMEAK8HLAaxBywGsQcw Bq8HMAYMAAAAJAMEAK8HOAaxBzgGsQc8Bq8HPAYMAAAAJAMEAK8HRAaxB0QGsQdIBq8HSAYMAAAA JAMEAK8HUAaxB1AGsQdUBq8HVAYMAAAAJAMEAK8HXAaxB1wGsQdgBq8HYAYMAAAAJAMEAK8HaAax B2gGsQdsBq8HbAYMAAAAJAMEAK8HdAaxB3QGsQd4Bq8HeAYMAAAAJAMEAK8HgAaxB4AGsQeEBq8H hAYMAAAAJAMEAK8HjAaxB4wGsQeQBq8HkAYMAAAAJAMEAK8HmAaxB5gGsQecBq8HnAYMAAAAJAME AK8HpAaxB6QGsQeoBq8HqAYMAAAAJAMEAK8HsAaxB7AGsQe0Bq8HtAYMAAAAJAMEAK8HvAaxB7wG sQfABq8HwAYMAAAAJAMEAK8HyAaxB8gGsQfMBq8HzAYMAAAAJAMEAK8H1AaxB9QGsQfYBq8H2AYM AAAAJAMEAK8H4AaxB+AGsQfkBq8H5AYMAAAAJAMEAK8H7AaxB+wGsQfwBq8H8AYMAAAAJAMEAK8H +AaxB/gGsQf8Bq8H/AYMAAAAJAMEAK8HBAexBwQHsQcIB68HCAcMAAAAJAMEAK8HEAexBxAHsQcU B68HFAcMAAAAJAMEAK8HHAexBxwHsQcgB68HIAcMAAAAJAMEAK8HKAexBygHsQcsB68HLAcMAAAA JAMEAK8HNAexBzQHsQc4B68HOAcMAAAAJAMEAK8HQAexB0AHsQdEB68HRAcMAAAAJAMEAK8HTAex B0wHsQdQB68HUAcMAAAAJAMEAK8HWAexB1gHsQdcB68HXAcMAAAAJAMEAK8HZAexB2QHsQdoB68H aAcMAAAAJAMEAK8HcAexB3AHsQd0B68HdAcEAAAALQEDAAQAAAAtAQQABAAAAAIBAQAEAAAAAgEB AAQAAAAtAQMACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAHAAAAGwTMBn8IsgXJBgQAAAAtAQQA BAAAAPABCAAEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEwgZ1CLsF0gYEAAAAAgEBAAQAAAAt AQUAEwAAADIK3wUzBwUABAAAAAAAYwpwB01lZGlhAEUALgAuABIALgAEAAAAAgEBAAQAAAACAQEA BAAAAC0BBQAWAAAAMgo+BgEHBwAEAAAAAABjCnAHR2F0ZXdheQBBAC4AFwAuADsALgAnAAQAAAAt AQEABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BAwAJAAAA+gIAAAIAAAAAAAAAIgAEAAAA LQEIAAcAAAAbBKAD3AaYAiYFBAAAAC0BBAAEAAAA8AEIAAQAAAAtAQMABAAAAAIBAQADAAAAHgAH AAAAFgSWA9IGoQIvBQQAAAACAQEAEAAAAPsCvf8AAAAAAACQAQAAAAAEAAAiQXJpYWwAAAEEAAAA LQEIABMAAAAyCqMCpgUFAAQAAAAAAGMKcAdNZWRpYQA3ACUAJQAPACUABAAAAAIBAQAEAAAAAgEB AAQAAAAtAQgAFgAAADIK8AJ9BQcABAAAAAAAYwpwB0dhdGV3YXkANAAlABMAJQAvACUAIQAEAAAA AgEBAAQAAAACAQEABAAAAC0BCAAaAAAAMgo9A3AFCgAEAAAAAABjCnAHQ29udHJvbGxlcjAAJQAl ABMAFgAlAA8ADwAlABYAFQAAAPsCvf8AAAAAAACQAQAAAAAEAAASVGltZXMgTmV3IFJvbWFuADQA BAAAAC0BCQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEDAAkAAAAdBiEA8ACXAMkBJwEU CAQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgS3AdUJMAEcCAQAAAACAQEABAAAAC0BBQARAAAA MgozARwIBAAEAAAAAABjCnAHUFNUTjcANwA0ADwABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAA AC0BAwAJAAAAHQYhAPAAGgHWAosAKwIEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEngH5BJMA MwIEAAAAAgEBAAQAAAAtAQUAEQAAADIKlgBMAgQABAAAAAAAYwpwBzEpICAuABwAFwAVAB8AAAAy CpYAwgINAAQAAAAAAGMKcAdEaXNjb25uZWN0TGVnADwAEgAqACoALgAuAC4ALgAqABcALgAuAC4A BAAAAAIBAQAEAAAAAgEBAAQAAAAtAQUAEAAAADIK9QBMAgMABAAAAAAAYwpwBzQpIAAuABwALAAd AAAAMgr1AMICDAAEAAAAAABjCnAHQ29ubmVjdChASVApPAAuAC4ALgAuACoAFwAcAFQAFwA3ABwA BAAAAAIBAQAEAAAAAgEBAAQAAAAtAQUABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BAwAJ AAAAHQYhAPAAlwDJAScBkAUEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEtwFRBzABmAUEAAAA AgEBAAQAAAAtAQUAGgAAADIKMwGYBQoABAAAAAAAYwpwB0lQIG5ldHdvcmsXADcAFwAuAC4AFwA7 AC4AHAArAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQoA BQAAABQCcwI0BAUAAAATAloECwMEAAAALQEEAAQAAADwAQoABAAAAC0BBgAJAAAA+gIAAAEAAAAA AAAAIgAEAAAALQEKAAoAAAAkAwMAIwNgBPsCSAQAA20EBAAAAC0BAwAEAAAALQEEAAQAAADwAQoA BAAAAC0BBgAJAAAA+gIAAAEAAAAAAAAAIgAEAAAALQEKAAoAAAAkAwMAHARtAkMEhQI/BGACBAAA AC0BAwAEAAAALQEEAAQAAADwAQoABAAAAAIBAQAEAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYE NAN2AxcCMwIEAAAAAgEBAAQAAAAtAQUAEAAAADIKGgJ+AgMABAAAAAAAYwpwB1JBUwA8ADcANwAE AAAAAgEBAAQAAAACAQEABAAAAC0BBQATAAAAMgp5AmICBQAEAAAAAABjCnAHUS45MzEAQQAXAC4A LgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABMAAAAyCtgCZQIFAAQAAAAAAGMKcAdILjI0NQA8 ABcALgAuAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0B CgAFAAAAFAK/BCkDBQAAABMCNQbPBgQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAA AAAAAAAiAAQAAAAtAQoACgAAACQDAwAoA+MEQQOlBAYDsgQEAAAALQEDAAQAAAAtAQQABAAAAPAB CgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCgAFAAAAFAJBBr0IBQAA ABMCOwZZCgQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoA CgAAACQDAwDJCGIGyQgfBpcIQgYEAAAALQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAAC AQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCgAFAAAAFAKlAw0GBQAAABMCoQV+BwQAAAAtAQQA BAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwCMB40FZgeo BYoHsgUEAAAALQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAA AAAAACIABAAAAC0BCgAFAAAAFAL7/xMFBQAAABMCxwETBQQAAAAtAQQABAAAAPABCgAEAAAALQEG AAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwAqBcAB/ATAARMF3QEEAAAALQEDAAQA AAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCgAF AAAAFAI7BiwDBQAAABMCOwa8BgQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAA AAAiAAQAAAAtAQoACgAAACQDAwA4A10GOAMaBgYDOwYEAAAALQEDAAQAAAAtAQQABAAAAPABCgAE AAAAAgEBAAQAAAACAQEABAAAAC0BAwAJAAAAHQYhAPAAAQFZA/YDMgQEAAAALQEDAAQAAAACAQEA AwAAAB4ABwAAABYE8ASDB/4DOgQEAAAAAgEBAAQAAAAtAQUAEAAAADIKAQQ6BAMABAAAAAAAYwpw BzMpIAAuABwALAAjAAAAMgoBBLAEEAAEAAAAAABjCnAHTW9kaWZ5Q29ubmVjdGlvbkUALgAuABIA GAAnADwALgAuAC4ALgAqABcAEgAuAC4ABAAAAAIBAQAEAAAAAgEBABAAAAD7Avj/AAAAAAAAkAEA AAAABAAAIkFyaWFsAAAEBAAAAC0BCgAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQAQAAAAMgpqBDoE AwAEAAAAAABjCnAHNikgAC4AHAAsACMAAAAyCmoEsAQQAAQAAAAAAGMKcAdNb2RpZnlDb25uZWN0 aW9uRQAuAC4AEgAYACcAPAAuAC4ALgAuACoAFwASAC4ALgAEAAAAAgEBAAQAAAAnAf//BAAAAAIB AQAEAAAALQEDAAkAAAAdBiEA8AB4AIUAQQMMAwQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgSx A4kDSQMUAwQAAAACAQEABAAAAC0BBQAOAAAAMgpMAygDAgAEAAAAAABjCnAHMikuABwABAAAAAIB AQAEAAAAJwH//wQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCwAFAAAAFAKgAiUEBQAA ABMC6AUTAwQAAAAtAQQABAAAAPABCwAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQsA CgAAACQDAwArA+gFAAPaBQwD/QUEAAAALQEDAAQAAAAtAQQABAAAAPABCwAEAAAALQEGAAkAAAD6 AgAAAQAAAAAAAAAiAAQAAAAtAQsACgAAACQDAwANBKACOASvAiwEjAIEAAAALQEDAAQAAAAtAQQA BAAAAPABCwAEAAAAAgEBAAQAAAACAQEABAAAAC0BAwAJAAAAHQYhAPAAeACFAAkEVwMEAAAALQED AAQAAAACAQEAAwAAAB4ABwAAABYEeQTUAxEEXwMEAAAAAgEBAAQAAAAtAQUADgAAADIKFARzAwIA BAAAAAAAYwpwBzUpLgAcAAQAAAACAQEABAAAACcB//8EAAAALQEAAAMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAA AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAKABAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAACsAAAA BAAAALgAAAAFAAAA1AAAAAYAAADgAAAABwAAAOwAAAAIAAAAAAEAAAkAAAAcAQAAEgAAACgBAAAK AAAAUAEAAAsAAABcAQAADAAAAGgBAAANAAAAdAEAAA4AAACAAQAADwAAAIgBAAAQAAAAkAEAABMA AACYAQAAAgAAAOQEAAAeAAAAAQAAAAB0RwAeAAAAAQAAAAB4RAAeAAAAEQAAAEplYW4tQ2xhdWRl IERhbmcA4EYAHgAAAAEAAAAA+kYAHgAAAAEAAAAAg0EAHgAAAAsAAABub3JtYWwuZG90AAAeAAAA EQAAAEplYW4tQ2xhdWRlIERhbmcAAEAAHgAAAAIAAAAyAAAAHgAAAB4AAABNaWNyb3NvZnQgV29y ZCBmb3IgV2luZG93cyA5NQBHAEAAAAAAAAAAAAAAAEAAAAAA+oXyY9e5AUAAAAAACiV6I0a+AUAA AAAAivZqLEa+AQMAAAABAAAAAwAAAAIAAAADAAAADwAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wEJAgAA AAAAwAAAAAAAAEYVAAAASW1hZ2UgTWljcm9zb2Z0IFdvcmQACgAAAE1TV29yZERvYwAPAAAAV29y ZC5QaWN0dXJlLjYA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAA AAAAAAAAAAgA+CsAAHwfAADtGAAA2REAAAAAAAAAAAAAAAAAAAAAAADoAwAA6AMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAA AACgAAAACAAAAAEAAABIAAAADwAAAFAAAAAEAAAAXAAAAAUAAABkAAAABgAAAGwAAAALAAAAdAAA ABAAAAB8AAAADAAAAIQAAAACAAAA5AQAANylaABX4AwEAAAAAGUAAAAAAAAAAAAAAAADAADOAwAA KxsAAAAAAAAAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAA DgAAPAQAAAAOAAA8BAAAPBIAAAAAAAA8EgAAAAAAAHASAAAAAAAAcBIAAAAAAABwEgAAFAAAAJoS AAAUAAAAmhIAAAAAAACuEgAAAAAAAK4SAAAAAAAArhIAAAAAAACuEgAACgAAALgSAAAQAAAAmhIA AAAAAABuGgAAMQAAAMgSAAAAAAAAyBIAAAAAAADIEgAAAAAAAMgSAAAAAAAAyBIAAAAAAACAEwAA AAAAAIATAAAAAAAAgBMAAAAAAACAEwAAAgAAAIITAAAAAAAAghMAAAAAAACCEwAANgAAALgTAABM AwAABBcAAEwDAABQGgAAHgAAAJ8aAABYAAAA9xoAADQAAABuGgAAAAAAAAAAAAAAAAAAAAAAAAAA AABwEgAAAAAAAIATAAAAAAAAAAAEAAUAAQACAMgSAAC4AAAAgBMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgBMAAAAAAACAEwAAAAAAAG4aAAAAAAAAgBMAAAAAAAA8EgAAAAAAADwSAAAAAAAAyBIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAyBIAAAAAAACAEwAAAAAAAIATAAAAAAAAgBMAAAAAAACAEwAAAAAA ADwSAAA0AAAAyBIAAAAAAABwEgAAAAAAAMgSAAAAAAAAgBMAAAAAAAAAAAAAAAAAAOBMJXssRr4B hBIAAAgAAACMEgAADgAAADwSAAAAAAAAPBIAAAAAAAA8EgAAAAAAADwSAAAAAAAAgBMAAAAAAACA EwAAAAAAAIATAAAAAAAAgBMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgICAgI CAgICAgICAgICAgICA1DcmVhdGVDb25uZWN0aW9uDU1vZGlmeUNvbm5lY3Rpb24NDTUpDQ1SQVML US45MzELSC4yNDUNDUluaXRpYXRlQ2FsbEF0dGVtcHQoQFBTVE4pDUNvbm5lY3QoQElQKQ0NDTIp IElBTQ0NR0sNDU1lZGlhIEdhdGV3YXkgQ29udHJvbGxlcg0NUFNUTg0NSVAgbmV0d29yaw0NTWVk aWEgR2F0ZXdheQ0NSC4zMjMgdGVybWluYWwNDQ0NGwChAQCkwE6lwE6mBxqnzxuokB+pWR2qAACr CQAAADIAAQEAMAAAAgQoABoixymeCGgCAAAAAAUABQD///8A////AAEAAAAAAAAAAAAUAAAAMgAB AQAwAAACBCgAEB2cJ+EBLQEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAyAAEBAjAAAAIE KAAdH8omKwPRAgAAAAAoAAUA////AAAAIVEAAAAAAAAAAAAAFAAAADIAAQEAMAAAAgQoABMa3yAT DKQCAAAAAAUABQD///8A////AAEAAAAAAAAAAAAUAAAAMgABAQAwAAACBCgALS2eJe8CLQEAAAAA BQAFAP///wD///8AAQAAAAAAAAAAABQAAAAwAAEBCjAAAAEAJgB7Kvcm+gYBAAAAAAD5BgAAAAAA AA8AAAAaABgAAAAAAAAAAAAwAAEBCTAAAAEAJgA0JoYfAQCEBAAAAAAAAIMEAAAAAA8AAAAaABgA AAAAAAAAAAAwAAEB/C8AAAEAJgB5LFYiAQAfDwAAAAAAAB4PAAAAAAUAAgAYABgAAAAAAAAAAAAw AAEBBjAAAAEAJgCMKFAo4ALQAwAAAADfAs8DAAAAAA8AAAAaABgAAAAAAAAAAAAwAAEBATAAAAEA JgBnIEQl0APrBs8DAAAAAOoGAAAAAA8AAAAaABoAAAAAAAAAAAAyAAEB+i8AAAIEKAA2JBgkGwR3 AgAAAAAFAAAA////AAAAIVEAAAAAAAAAAAAAFAAAADIAAQH+LwAAAgQoAGEmyyUbBHcCAAAAAAUA AAD///8A////AAEAAAAAAAAAAAAUAAAAMAABAQUwAAABACYAlS5pLTkEEAAAAA8AOAQAAAAAAAAo AAAAGgAYAAAAAAAAAAAAMAABAQMwAAABACYAdCKHLdsHAQAAAAAA2gcAAAAAAAAoAAAAGAAaAAAA AAAAAAAAMgABAf8vAAACBCgAaS1WIkgEaQEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAy AAEBADAAAAIEKABgJ1YiSARpAQAAAAAFAAUA////AP///wABAAAAAAAAAAAAFAAAADIAAQH9LwAA AgQoAE4qLiwbBKQCAAAAAAUAAAD///8A////AAEAAAAAAAAAAAAUAAAAMgABAfsvAAACBCgASx4u LBsEpAIAAAAABQAAAP///wAAACFRAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAABIDAAATAwAANQMAADYDAAA5AwAAOgMAAEoDAABLAwAA dAMAAHUDAAB8AwAAfQMAAH8DAACBAwAAmQMAAJoDAACbAwAAoAMAAKEDAACsAwAArQMAALoDAAC8 AwAAygMAAM0DAADOAwAAYQcAAPkA9QD1APUA9QD1APUA8e8A9QD1APUA9QAA7QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnUBAANjEAAGXQIAYxAAAAZd AgBjFAAAC3UBRAQAAAAAYQAEABsAAwAAEwMAACQDAAA1AwAANgMAADkDAAA6AwAASgMAAEsDAABm AwAAcwMAAHQDAAB1AwAAfAMAAH0DAAD+AAHrGBsB3QABdwjkALwAAXcI5AD+AAAAAAAAuQABvAHk AP4AAAAAAAC5AAMFA+QA/gAAAAAAAJgAAe8L5AB3AAHvC+QAVwAB7wvkAP4AAAAAAAC5AAHJAuQA /gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAAARqgETVv4MNAAAAjgCAAIAFAABABsBAAAAAAAAKSAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADQoRVwET5f4MNAAAAQgAAAGAAAADABsB AAAAAAAAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADQoRVwET5f4MNAAAAjgC AAIAFAABABsBAAAAAAAAKSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAABQEAIAAA DQoRGwET5f4MNAAAAQgAAAGAAAAGABsBAAAAAAAAKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAIAAADQoRGwET5f4MNAAAAjgCAAIAFAAEABsBAAAAAAAAKSAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAADn0DAACAAwAAgQMAAJoDAACbAwAAoAMAAKEDAACsAwAArQMAALsD AAC8AwAAywMAAMwDAADNAwAAzgMAAPsAAe4D5AD5AAAAAAAA9gAD7gO5APkAAAAAAAD5AAEiBOQA +QAAAAAAAPkAASIE5AD5AAAAAAAA+wAC7gPkAPkAAAAAAAD7AALwA+QA+QAAAAAAAPkAAAAAAAD5 AAHrGBsBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AAUBAAEAAAAEAAAFARVQAAAODgATAAgAAQBLAA8AAAAAABwAAEDx/wIAHAAGTm9ybWFsAAIAAAAG AGEMBGMYAFgAAUABAAIAWAAHVGl0cmUgMQAAQAABAA0BFeABFvAADDQAAAEEAAABgAAAAQAAAJAA AAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBVgVwAAkABAPIAXAAHVGl0cmUg MgAAQAACAA0CFfAAFngADDQAAAAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABQBVgWMWAABcAANAAQASAVwAB1RpdHJlIDMAAEAAAwANAxV4ABZ4AAw0AAEA BAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAXgFjFgAA XgAEQAEAAgBeAAdUaXRyZSA0AABCAAQACAENBBXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAu AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAVYFdAgAAXAAFQAEAAgBcAAdUaXRyZSA1 AABAAAUADQUV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAGAF0CAGMWAFwABkABAAIAXAAHVGl0cmUgNgAAQAAGAA0GFfAAFjwADDQAAQAE AAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBWgWMWAABc AAdAAQACAFwAB1RpdHJlIDcAAEAABwANBxXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAXQIAYxQAXgAIQAEAAgBeAAdUaXRyZSA4AABA AAgADQgV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAIAFaBXQIAYxQAYAAJQAEAAgBgAAdUaXRyZSA5AABAAAkADQkV8AAWPAAMNAABAAQA AAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAFWBVoFdAgBj EgAeAEFA8v+hAB4AEVBvbGljZSBwYXIgZOlmYXV0AAAAAAAAAAAAAAAAIgD+TwEB8gAiAA5SZXRy YWl0Tm9ybWFsMgAFAA8AEW4EAAAAIgAcQAEAAgEiAA5SZXRyYWl0IG5vcm1hbAAFABAAEcQCAAAA IgD+T/EAEgEiAA5SZXRyYWl0Tm9ybWFsMwAFABEAERgGAAAAJgAgQAEAIgEmAAxQaWVkIGRlIHBh Z2UADAASAA8IAALTEm8jAQIAAAAAAAAjAAAAJwAAADgAAABiAAAAagAAAG4AAACIAAAAjgAAAJoA AACpAAAAuQAAALwAAAAAAAAAzgAAAAkAzgMAAAcA/////wEABCD//wEAAAAAAM4AAAAAAAAAAAAA AAAAFAAAAM4AAAAGAAAABgAAAAADAABhBwAABAAAAwAAfQMAAM4DAAAFAAYAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAAR AAAAzgAAAOsDAAABAB0EAAABAE8EAAABAIEEAAABALMEAAABAOUEAAAAABUFAAAAAEUFAAAAAHUF AAAAAKUFAAAAANUFAAABAAcGAAABADkGAAAAAGkGAAAAAJkGAAABAMsGAAABAP0GAAABAC8HAAAB AP9ASFAgTGFzZXJKZXQgNDAwMCBQUwBMUFQxOgBQU0NSSVBUAEhQIExhc2VySmV0IDQwMDAgUFMA SFAgTGFzZXJKZXQgNDAwMCBQUwAAAAAAAAAAAAAAAAAABAMElAC4Ah93AAABAAkAmgszCGQAAQAH AFgCAQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAwBIAAMgZ AAABAAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAILka71nOmts/LYFAAIAAQAAAAAAAQAA AAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP//AwD//wEA//8AAP//AQD//wAA//8AAP// AAD//wEA//8BAP//AAD//wEA//8BAP//AAD//wAA//8AAP//AAD//wEA//8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9QYWdlIHBlcnNvbm5hbGlz6WUgMQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdl IHBlcnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAAAAAAAAAAAAAEhQIExhc2VySmV0 IDQwMDAgUFMAAAAAAAAAAAAAAAAAAAQDBJQAuAIfdwAAAQAJAJoLMwhkAAEABwBYAgEAAgBYAgMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAMASAADIGQAAAQAAAAAAAAAB AAAAAgAAAAAAAAAAAAAAAAAAAAAAAACC5Gu9ZzprbPy2BQACAAEAAAAAAAEAAAAAAAIAAgABAFID AADCAQAAAAAAAAAAZAAAAAAAAwD//wMA//8BAP//AAD//wEA//8AAP//AAD//wAA//8BAP//AQD/ /wAA//8BAP//AQD//wAA//8AAP//AAD//wAA//8BAP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP//UGFnZSBwZXJzb25uYWxpc+llIDEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAUGFnZSBwZXJzb25uYWxp c+llIDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRD AAAAAAAAUGFnZSBwZXJzb25uYWxpc+llIDMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAAAAAAAAAAAADgAEAAAAAAAAAAAAHAAEAAQAAAAAA AAAfAAAAAAAxABUWkAEAAFRpbWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAAQXJpYWwA IgAEAAMDjBhWDMQCAACpAQAAAABXtDEGm7QxpgAAAAACAAAAAAACAAAADwAAAAEAAQAAAAQAgwAB AAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDVgwAADQAAAAAAAAAEEplYW4tQ2xhdWRlIERhbmcQ SmVhbi1DbGF1ZGUgRGFuZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAIAPgrfB8AAAEACQAAAw4OAAALADIAAAAAABQAAAAmBg8AHgD/////BAAUAAAA V29yZA4ATWljcm9zb2Z0IFdvcmQFAAAACwIAAAAABQAAAAwCcAdjCg0AAAD7AgAAAAAAAAAAAAAA AAAAAAAAAQAMBAAAAC0BAAAEAAAAAgEBABUAAAD7Apz/AAAAAAAAkAEAAAAABAAAElRpbWVzIE5l dyBSb21hbgBrAQQAAAAtAQEABQAAAAkCAAAAAAQAAAACAQEABAAAAAIBAQAHAAAA/AIBAAAAAAAA AAQAAAAtAQIACQAAAPoCAAACAAAAAAAAACIABAAAAC0BAwAHAAAAGwTqAvUF4wE/BAkAAAD6AgAA AAAAAAAAAAAiAAQAAAAtAQQABAAAAPABAwAHAAAA/AIAAP///wAAAAQAAAAtAQMABAAAAAIBAQAD AAAAHgAHAAAAFgThAusF7AFIBAQAAAACAQEAEAAAAPsCrf8AAAAAAACQAQAAAAAEAAAiQXJpYWwA KgAEAAAALQEFAA4AAAAyChAC3QQCAAQAAAAAAGMKcAdHS0EANwAEAAAALQEBAAQAAAACAQEABAAA ACcB//8EAAAAAgEBAAQAAAAtAQIACQAAAPoCAAACAAAAAAAAACIABAAAAC0BBgAHAAAAGwRcBn4D QQXHAQQAAAAtAQQABAAAAPABBgAEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEUgZ0A0sF0AEE AAAAAgEBAAQAAAAtAQUAEwAAADIKbwUzAgUABAAAAAAAYwpwB0guMzIzADwAFwAuAC4ALgAEAAAA AgEBAAQAAAACAQEABAAAAC0BBQAXAAAAMgrOBQ0CCAAEAAAAAABjCnAHdGVybWluYWwXAC4AHABH ABIALgAuABIABAAAAC0BAQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAHAAAA/AIAAAAAAAAAAAQA AAAtAQYACQAAAPoCBQAAAAAA////ACIABAAAAC0BBwAMAAAAJAMEAK8HJwGxBycBsQcrAa8HKwEM AAAAJAMEAK8HMwGxBzMBsQc3Aa8HNwEMAAAAJAMEAK8HPwGxBz8BsQdDAa8HQwEMAAAAJAMEAK8H SwGxB0sBsQdPAa8HTwEMAAAAJAMEAK8HVwGxB1cBsQdbAa8HWwEMAAAAJAMEAK8HYwGxB2MBsQdn Aa8HZwEMAAAAJAMEAK8HbwGxB28BsQdzAa8HcwEMAAAAJAMEAK8HewGxB3sBsQd/Aa8HfwEMAAAA JAMEAK8HhwGxB4cBsQeLAa8HiwEMAAAAJAMEAK8HkwGxB5MBsQeXAa8HlwEMAAAAJAMEAK8HnwGx B58BsQejAa8HowEMAAAAJAMEAK8HqwGxB6sBsQevAa8HrwEMAAAAJAMEAK8HtwGxB7cBsQe7Aa8H uwEMAAAAJAMEAK8HwwGxB8MBsQfHAa8HxwEMAAAAJAMEAK8HzwGxB88BsQfTAa8H0wEMAAAAJAME AK8H2wGxB9sBsQffAa8H3wEMAAAAJAMEAK8H5wGxB+cBsQfrAa8H6wEMAAAAJAMEAK8H8wGxB/MB sQf3Aa8H9wEMAAAAJAMEAK8H/wGxB/8BsQcDAq8HAwIMAAAAJAMEAK8HCwKxBwsCsQcPAq8HDwIM AAAAJAMEAK8HFwKxBxcCsQcbAq8HGwIMAAAAJAMEAK8HIwKxByMCsQcnAq8HJwIMAAAAJAMEAK8H LwKxBy8CsQczAq8HMwIMAAAAJAMEAK8HOwKxBzsCsQc/Aq8HPwIMAAAAJAMEAK8HRwKxB0cCsQdL Aq8HSwIMAAAAJAMEAK8HUwKxB1MCsQdXAq8HVwIMAAAAJAMEAK8HXwKxB18CsQdjAq8HYwIMAAAA JAMEAK8HawKxB2sCsQdvAq8HbwIMAAAAJAMEAK8HdwKxB3cCsQd7Aq8HewIMAAAAJAMEAK8HgwKx B4MCsQeHAq8HhwIMAAAAJAMEAK8HjwKxB48CsQeTAq8HkwIMAAAAJAMEAK8HmwKxB5sCsQefAq8H nwIMAAAAJAMEAK8HpwKxB6cCsQerAq8HqwIMAAAAJAMEAK8HswKxB7MCsQe3Aq8HtwIMAAAAJAME AK8HvwKxB78CsQfDAq8HwwIMAAAAJAMEAK8HywKxB8sCsQfPAq8HzwIMAAAAJAMEAK8H1wKxB9cC sQfbAq8H2wIMAAAAJAMEAK8H4wKxB+MCsQfnAq8H5wIMAAAAJAMEAK8H7wKxB+8CsQfzAq8H8wIM AAAAJAMEAK8H+wKxB/sCsQf/Aq8H/wIMAAAAJAMEAK8HBwOxBwcDsQcLA68HCwMMAAAAJAMEAK8H EwOxBxMDsQcXA68HFwMMAAAAJAMEAK8HHwOxBx8DsQcjA68HIwMMAAAAJAMEAK8HKwOxBysDsQcv A68HLwMMAAAAJAMEAK8HNwOxBzcDsQc7A68HOwMMAAAAJAMEAK8HQwOxB0MDsQdHA68HRwMMAAAA JAMEAK8HTwOxB08DsQdTA68HUwMMAAAAJAMEAK8HWwOxB1sDsQdfA68HXwMMAAAAJAMEAK8HZwOx B2cDsQdrA68HawMMAAAAJAMEAK8HcwOxB3MDsQd3A68HdwMMAAAAJAMEAK8HfwOxB38DsQeDA68H gwMMAAAAJAMEAK8HiwOxB4sDsQePA68HjwMMAAAAJAMEAK8HlwOxB5cDsQebA68HmwMMAAAAJAME AK8HowOxB6MDsQenA68HpwMMAAAAJAMEAK8HrwOxB68DsQezA68HswMMAAAAJAMEAK8HuwOxB7sD sQe/A68HvwMMAAAAJAMEAK8HxwOxB8cDsQfLA68HywMMAAAAJAMEAK8H0wOxB9MDsQfXA68H1wMM AAAAJAMEAK8H3wOxB98DsQfjA68H4wMMAAAAJAMEAK8H6wOxB+sDsQfvA68H7wMMAAAAJAMEAK8H 9wOxB/cDsQf7A68H+wMMAAAAJAMEAK8HAwSxBwMEsQcHBK8HBwQMAAAAJAMEAK8HDwSxBw8EsQcT BK8HEwQMAAAAJAMEAK8HGwSxBxsEsQcfBK8HHwQMAAAAJAMEAK8HJwSxBycEsQcrBK8HKwQMAAAA JAMEAK8HMwSxBzMEsQc3BK8HNwQMAAAAJAMEAK8HPwSxBz8EsQdDBK8HQwQMAAAAJAMEAK8HSwSx B0sEsQdQBK8HUAQMAAAAJAMEAK8HWASxB1gEsQdcBK8HXAQMAAAAJAMEAK8HZASxB2QEsQdoBK8H aAQMAAAAJAMEAK8HcASxB3AEsQd0BK8HdAQMAAAAJAMEAK8HfASxB3wEsQeABK8HgAQMAAAAJAME AK8HiASxB4gEsQeMBK8HjAQMAAAAJAMEAK8HlASxB5QEsQeYBK8HmAQMAAAAJAMEAK8HoASxB6AE sQekBK8HpAQMAAAAJAMEAK8HrASxB6wEsQewBK8HsAQMAAAAJAMEAK8HuASxB7gEsQe8BK8HvAQM AAAAJAMEAK8HxASxB8QEsQfIBK8HyAQMAAAAJAMEAK8H0ASxB9AEsQfUBK8H1AQMAAAAJAMEAK8H 3ASxB9wEsQfgBK8H4AQMAAAAJAMEAK8H6ASxB+gEsQfsBK8H7AQMAAAAJAMEAK8H9ASxB/QEsQf4 BK8H+AQMAAAAJAMEAK8HAAWxBwAFsQcEBa8HBAUMAAAAJAMEAK8HDAWxBwwFsQcQBa8HEAUMAAAA JAMEAK8HGAWxBxgFsQccBa8HHAUMAAAAJAMEAK8HJAWxByQFsQcoBa8HKAUMAAAAJAMEAK8HMAWx BzAFsQc0Ba8HNAUMAAAAJAMEAK8HPAWxBzwFsQdABa8HQAUMAAAAJAMEAK8HSAWxB0gFsQdMBa8H TAUMAAAAJAMEAK8HVAWxB1QFsQdYBa8HWAUMAAAAJAMEAK8HYAWxB2AFsQdkBa8HZAUMAAAAJAME AK8HbAWxB2wFsQdwBa8HcAUMAAAAJAMEAK8HeAWxB3gFsQd8Ba8HfAUMAAAAJAMEAK8HhAWxB4QF sQeIBa8HiAUMAAAAJAMEAK8HkAWxB5AFsQeUBa8HlAUMAAAAJAMEAK8HnAWxB5wFsQegBa8HoAUM AAAAJAMEAK8HqAWxB6gFsQesBa8HrAUMAAAAJAMEAK8HtAWxB7QFsQe4Ba8HuAUMAAAAJAMEAK8H wAWxB8AFsQfEBa8HxAUMAAAAJAMEAK8HzAWxB8wFsQfQBa8H0AUMAAAAJAMEAK8H2AWxB9gFsQfc Ba8H3AUMAAAAJAMEAK8H5AWxB+QFsQfoBa8H6AUMAAAAJAMEAK8H8AWxB/AFsQf0Ba8H9AUMAAAA JAMEAK8H/AWxB/wFsQcABq8HAAYMAAAAJAMEAK8HCAaxBwgGsQcMBq8HDAYMAAAAJAMEAK8HFAax BxQGsQcYBq8HGAYMAAAAJAMEAK8HIAaxByAGsQckBq8HJAYMAAAAJAMEAK8HLAaxBywGsQcwBq8H MAYMAAAAJAMEAK8HOAaxBzgGsQc8Bq8HPAYMAAAAJAMEAK8HRAaxB0QGsQdIBq8HSAYMAAAAJAME AK8HUAaxB1AGsQdUBq8HVAYMAAAAJAMEAK8HXAaxB1wGsQdgBq8HYAYMAAAAJAMEAK8HaAaxB2gG sQdsBq8HbAYMAAAAJAMEAK8HdAaxB3QGsQd4Bq8HeAYMAAAAJAMEAK8HgAaxB4AGsQeEBq8HhAYM AAAAJAMEAK8HjAaxB4wGsQeQBq8HkAYMAAAAJAMEAK8HmAaxB5gGsQecBq8HnAYMAAAAJAMEAK8H pAaxB6QGsQeoBq8HqAYMAAAAJAMEAK8HsAaxB7AGsQe0Bq8HtAYMAAAAJAMEAK8HvAaxB7wGsQfA Bq8HwAYMAAAAJAMEAK8HyAaxB8gGsQfMBq8HzAYMAAAAJAMEAK8H1AaxB9QGsQfYBq8H2AYMAAAA JAMEAK8H4AaxB+AGsQfkBq8H5AYMAAAAJAMEAK8H7AaxB+wGsQfwBq8H8AYMAAAAJAMEAK8H+Aax B/gGsQf8Bq8H/AYMAAAAJAMEAK8HBAexBwQHsQcIB68HCAcMAAAAJAMEAK8HEAexBxAHsQcUB68H FAcMAAAAJAMEAK8HHAexBxwHsQcgB68HIAcMAAAAJAMEAK8HKAexBygHsQcsB68HLAcMAAAAJAME AK8HNAexBzQHsQc4B68HOAcMAAAAJAMEAK8HQAexB0AHsQdEB68HRAcMAAAAJAMEAK8HTAexB0wH sQdQB68HUAcMAAAAJAMEAK8HWAexB1gHsQdcB68HXAcMAAAAJAMEAK8HZAexB2QHsQdoB68HaAcM AAAAJAMEAK8HcAexB3AHsQd0B68HdAcEAAAALQEDAAQAAAAtAQQABAAAAAIBAQAEAAAAAgEBAAQA AAAtAQMACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAHAAAAGwRcBn8IQQXJBgQAAAAtAQQABAAA APABCAAEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEUgZ1CEsF0gYEAAAAAgEBAAQAAAAtAQUA EwAAADIKbwUzBwUABAAAAAAAYwpwB01lZGlhAEUALgAuABIALgAEAAAAAgEBAAQAAAACAQEABAAA AC0BBQAWAAAAMgrOBQEHBwAEAAAAAABjCnAHR2F0ZXdheQBBAC4AFwAuADsALgAnAAQAAAAtAQEA BAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BAwAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEI AAcAAAAbBKAD3AaYAiYFBAAAAC0BBAAEAAAA8AEIAAQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAA FgSWA9IGoQIvBQQAAAACAQEAEAAAAPsCvf8AAAAAAACQAQAAAAAEAAAiQXJpYWwAAAEEAAAALQEI ABMAAAAyCqMCpgUFAAQAAAAAAGMKcAdNZWRpYQA3ACUAJQAPACUABAAAAAIBAQAEAAAAAgEBAAQA AAAtAQgAFgAAADIK8AJ9BQcABAAAAAAAYwpwB0dhdGV3YXkANAAlABMAJQAvACUAIQAEAAAAAgEB AAQAAAACAQEABAAAAC0BCAAaAAAAMgo9A3AFCgAEAAAAAABjCnAHQ29udHJvbGxlcjAAJQAlABMA FgAlAA8ADwAlABYAFQAAAPsCvf8AAAAAAACQAQAAAAAEAAASVGltZXMgTmV3IFJvbWFuADQABAAA AC0BCQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEDAAkAAAAdBiEA8ACXAMkBJwEUCAQA AAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgS3AdUJMAEcCAQAAAACAQEABAAAAC0BBQARAAAAMgoz ARwIBAAEAAAAAABjCnAHUFNUTjcANwA0ADwABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0B AwAJAAAAHQYhAPAAAQGXA0EEXgMEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEOwXtBkkEZgME AAAAAgEBAAQAAAAtAQUAEQAAADIKTARmAwQABAAAAAAAYwpwBzQpICAuABwAFwAVACMAAAAyCkwE 3AMQAAQAAAAAAGMKcAdDcmVhdGVDb25uZWN0aW9uPAAcAC4ALgAXAC4APAAuAC4ALgAuACoAFwAS AC4ALgAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQAQAAAAMgqrBGYDAwAEAAAAAABjCnAHNikgAC4A HAAsACMAAAAyCqsE3AMQAAQAAAAAAGMKcAdNb2RpZnlDb25uZWN0aW9uRQAuAC4AEgAYACcAPAAu AC4ALgAuACoAFwASAC4ALgAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEDAAkAAAAdBiEA 8AB+AMkAWgNEAQQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgTQAwUCYgNMAQQAAAACAQEABAAA AC0BBQAOAAAAMgplA4MBAgAEAAAAAABjCnAHNSkuABwABAAAAAIBAQAEAAAAJwH//wQAAAACAQEA BAAAAC0BAwAJAAAAHQYhAPAAGgEJBYsABQAEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYEngEG BZMADQAEAAAAAgEBAAQAAAAtAQUAEQAAADIKlgAmAAQABAAAAAAAYwpwBzEpICAuABwAFwAVADIA AAAyCpYAnAAaAAQAAAAAAGMKcAdJbml0aWF0ZUNhbGxBdHRlbXB0KEBQU1ROKRcALgASABcAEgAu ABcALgA8AC4AEgASADcAFwAXAC4ARwAuABcAHABUADcANwA0ADwAHAAEAAAAAgEBAAQAAAACAQEA BAAAAC0BBQAQAAAAMgr1ACYAAwAEAAAAAABjCnAHMykgAC4AHAAsAB0AAAAyCvUAnAAMAAQAAAAA AGMKcAdDb25uZWN0KEBJUCk8AC4ALgAuAC4AKgAXABwAVAAXADcAHAAEAAAAAgEBAAQAAAACAQEA BAAAAC0BBQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEDAAkAAAAdBiEA8AB+ADkBhQL7 BwQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgT8AiwJjgIDCAQAAAACAQEABAAAAC0BBQAUAAAA MgqRAh0IBgAEAAAAAABjCnAHMikgSUFNLgAcABcAFwA3AEUABAAAAAIBAQAEAAAAJwH//wQAAAAC AQEABAAAAC0BAwAJAAAAHQYhAPAAlwDJAScBkAUEAAAALQEDAAQAAAACAQEAAwAAAB4ABwAAABYE twFRBzABmAUEAAAAAgEBAAQAAAAtAQUAGgAAADIKMwGYBQoABAAAAAAAYwpwB0lQIG5ldHdvcmsX ADcAFwAuAC4AFwA7AC4AHAArAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAkAAAD6AgAABgAAAAAA AAAiAAQAAAAtAQoABQAAABQCcwI0BAUAAAATAi8FswIEAAAALQEEAAQAAADwAQoABAAAAC0BBgAJ AAAA+gIAAAEAAAAAAAAAIgAEAAAALQEKAAoAAAAkAwMAywIzBaMCHQWoAkIFBAAAAC0BAwAEAAAA LQEEAAQAAADwAQoABAAAAC0BBgAJAAAA+gIAAAEAAAAAAAAAIgAEAAAALQEKAAoAAAAkAwMAHQRu AkUEhQI/BGACBAAAAC0BAwAEAAAALQEEAAQAAADwAQoABAAAAAIBAQAEAAAAAgEBAAQAAAACAQEA AwAAAB4ABwAAABYEKARpAwsDJwIEAAAAAgEBAAQAAAAtAQUAEAAAADIKDgNyAgMABAAAAAAAYwpw B1JBUwA8ADcANwAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQATAAAAMgptA1YCBQAEAAAAAABjCnAH US45MzEAQQAXAC4ALgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABMAAAAyCswDWQIFAAQAAAAA AGMKcAdILjI0NQA8ABcALgAuAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEACQAAAPoCAAARAAAA AAAAACIABAAAAC0BCgAFAAAAFALRBakDBQAAABMC0QXJBgQAAAAtAQQABAAAAPABCgAEAAAALQEG AAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwC1A/IFtQOwBYMD0QUEAAAALQEDAAQA AAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCgAF AAAAFALLBZEIBQAAABMCxQUuCgQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAA AAAiAAQAAAAtAQoACgAAACQDAwAhCqQFIQrnBVMKxQUEAAAALQEDAAQAAAAtAQQABAAAAPABCgAE AAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCgAFAAAAFAKlAw0GBQAAABMC KgUyBwQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAA ACQDAwBABxYFGwcyBT8HOwUEAAAALQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCgAFAAAAFAL7/xMFBQAAABMCxwETBQQAAAAtAQQABAAA APABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwAqBcAB/ATAARMF 3QEEAAAALQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAAAAAA ACIABAAAAC0BCgAFAAAAFAIVA9sGBQAAABMCFQOuCQQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkA AAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwCmCf4CpgksA8MJFQMEAAAALQEDAAQAAAAt AQQABAAAAPABCgAEAAAAAgEBAAQAAAAtAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAA AQAAAAAAAAADAAAAAEYAAAMAAAABAAAAAwAAAAEAAAALAAAAAAAAAAsAAAAAAAAADBAAAAIAAAAe AAAAAQAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA AKABAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAACsAAAABAAAALgAAAAFAAAA1AAAAAYAAADgAAAA BwAAAOwAAAAIAAAAAAEAAAkAAAAcAQAAEgAAACgBAAAKAAAAUAEAAAsAAABcAQAADAAAAGgBAAAN AAAAdAEAAA4AAACAAQAADwAAAIgBAAAQAAAAkAEAABMAAACYAQAAAgAAAOQEAAAeAAAAAQAAAAD/ AQAeAAAAAQAAAAAAAAAeAAAAEQAAAEplYW4tQ2xhdWRlIERhbmcAhkgAHgAAAAEAAAAAAAAAHgAA AAEAAAAAAAAAHgAAAAsAAABub3JtYWwuZG90AAAeAAAAEQAAAEplYW4tQ2xhdWRlIERhbmcA7UwA HgAAAAIAAAAyAAAAHgAAAB4AAABNaWNyb3NvZnQgV29yZCBmb3IgV2luZG93cyA5NQAAAEAAAAAA RsMjAAAAAEAAAAAA+oXyY9e5AUAAAAAACMHwIUa+AUAAAAAAtkh2Kka+AQMAAAABAAAAAwAAAAIA AAADAAAADwAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wEJAgAAAAAAwAAAAAAAAEYVAAAASW1hZ2UgTWlj cm9zb2Z0IFdvcmQACgAAAE1TV29yZERvYwAPAAAAV29yZC5QaWN0dXJlLjYA9DmycQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAAAAAAAAAAAAgAGSYAAHwfAACZFQAA2REA AAAAAAAAAAAAAAAAAAAAAADoAwAA6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAA AAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAACgAAAACAAAAAEAAABIAAAAgQAAAIIA AACDAAAAhAAAAP7///+GAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAA AJEAAACSAAAA/v///5QAAACxAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAA nwAAAKAAAAChAAAA/v///6MAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACt AAAArgAAAK8AAACwAAAA/v///7IAAAAjAQAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsA AAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAA AMoAAADLAAAAzAAAAP7////9////zwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA 2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADm AAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQA AAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAADcpWgAV+AM BAAAAABlAAAAAAAAAAAAAAAAAwAApQMAABcZAAAAAAAAAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAkgAAAAAAAAAAAAAAAAwAADwEAAAADAAAPAQAADwQAAAAAAAAPBAAAAAAAABs EAAAAAAAAGwQAAAAAAAAbBAAABQAAACWEAAAFAAAAJYQAAAAAAAAqhAAAAAAAACqEAAAAAAAAKoQ AAAAAAAAqhAAAAoAAAC0EAAACgAAAJYQAAAAAAAAWhgAADEAAAC+EAAAAAAAAL4QAAAAAAAAvhAA AAAAAAC+EAAAAAAAAL4QAAAAAAAAbBEAAAAAAABsEQAAAAAAAGwRAAAAAAAAbBEAAAIAAABuEQAA AAAAAG4RAAAAAAAAbhEAADYAAACkEQAATAMAAPAUAABMAwAAPBgAAB4AAACLGAAAWAAAAOMYAAA0 AAAAWhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbBAAAAAAAABsEQAAAAAAAAAABAAFAAEAAQC+EAAA rgAAAGwRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGwRAAAAAAAAbBEAAAAAAABaGAAAAAAAAGwRAAAA AAAAPBAAAAAAAAA8EAAAAAAAAL4QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL4QAAAAAAAAbBEAAAAA AABsEQAAAAAAAGwRAAAAAAAAbBEAAAAAAAA8EAAAMAAAAL4QAAAAAAAAbBAAAAAAAAC+EAAAAAAA AGwRAAAAAAAAAAAAAAAAAABA9AR9Kka+AYAQAAAIAAAAiBAAAA4AAAA8EAAAAAAAADwQAAAAAAAA PBAAAAAAAAA8EAAAAAAAAGwRAAAAAAAAbBEAAAAAAABsEQAAAAAAAGwRAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICA0yKSBDcmVhdGVDb25uZWN0aW9u DQ0zKSBJQU0NDSAxKSBDb25uZWN0KEBQU1ROKQ0NR0sNDU1lZGlhIEdhdGV3YXkgQ29udHJvbGxl cg0NUkFTC1EuOTMxC0guMjQ1DQ1QU1RODQ1JUCBuZXR3b3JrDQ1NZWRpYSBHYXRld2F5DQ1ILjMy MyB0ZXJtaW5hbA0NDQ0bAKEBAKTATqXATqZZHafPG6iQH6lZHaoAAKsJAAAAMgABAQAwAAACBCgA gyIwKvkHaQEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAyAAEBADAAAAIEKAAtLZ4l7wIt AQAAAAAFAAUA////AP///wABAAAAAAAAAAAAFAAAADIAAQEAMAAAAgQoANMd3yBTCGkBAAAAAAUA BQD///8A////AAEAAAAAAAAAAAAUAAAAMAABAQowAAABACYAeyr3JvoGAQAAAAAA+QYAAAAAAAAP AAAAGgAYAAAAAAAAAAAAMAABAQkwAAABACYANCaGHwEAhAQAAAAAAACDBAAAAAAPAAAAGgAYAAAA AAAAAAAAMAABAfwvAAABACYAeSxWIgEAHw8AAAAAAAAeDwAAAAAFAAIAGAAYAAAAAAAAAAAAMAAB AQYwAAABACYAjChQKOAC0AMAAAAA3wLPAwAAAAAPAAAAGgAYAAAAAAAAAAAAMAABAQEwAAABACYA ZyBEJdAD6wbPAwAAAADqBgAAAAAPAAAAGgAaAAAAAAAAAAAAMgABAfovAAACBCgANiQYJBsEdwIA AAAABQAAAP///wAAACFRAAAAAAAAAAAAABQAAAAyAAEB/i8AAAIEKABhJsslGwR3AgAAAAAFAAAA ////AP///wABAAAAAAAAAAAAFAAAADAAAQEFMAAAAQAmAJUuaS05BBAAAAAPADgEAAAAAAAAKAAA ABoAGAAAAAAAAAAAADAAAQEDMAAAAQAmAHQihy3bBwEAAAAAANoHAAAAAAAAKAAAABoAGAAAAAAA AAAAADIAAQECMAAAAgQoAHcfyibCAtECAAAAACgABQD///8AAAAhUQAAAAAAAAAAAAAUAAAAMgAB Af8vAAACBCgAaS1WIkgEaQEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAyAAEBADAAAAIE KABgJ1YiSARpAQAAAAAFAAUA////AP///wABAAAAAAAAAAAAFAAAADIAAQH9LwAAAgQoAE4qLiwb BKQCAAAAAAUAAAD///8A////AAEAAAAAAAAAAAAUAAAAMgABAfsvAAACBCgASx4uLBsEpAIAAAAA BQAAAP///wAAACFRAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAARAwAAEgMA ACYDAAAnAwAALgMAAC8DAABCAwAAQwMAAEUDAABHAwAAXwMAAGADAABhAwAAcQMAAHIDAAB3AwAA eAMAAIMDAACEAwAAkQMAAJMDAAChAwAApAMAAKUDAAAGBwAA+QD1APUA9QD1APHvAPUA9QD1APUA 9QAA7QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAJ1AQADYxAABl0CAGMQAAAGXQIAYxQAAAt1AUQEAAAAAGEABAAZAAMAABIDAAAmAwAA JwMAAC4DAAAvAwAAQgMAAEMDAABGAwAARwMAAGADAABhAwAAcQMAAHIDAAB3AwAAeAMAAIMDAACE AwAAkgMAAJMDAACiAwAAowMAAKQDAAClAwAA/gABlxUbAf4AAdQH5AD+AAAAAAAA+wAByQLkAP4A AAAAAAD+AAEvCOQA/gAAAAAAAPYAAe4D5AD+AAAAAAAA+wAD7gO5AP4AAAAAAAD7AAOeAuQA/gAA AAAAAP4AASIE5AD+AAAAAAAA/gABIgTkAP4AAAAAAAD2AALuA+QA/gAAAAAAAPYAAvAD5AD+AAAA AAAA/gAAAAAAAP4AAZcVGwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAABQEVUAAAAAIAAAUBAAEAABcOABMACAABAEsADwAA AAAAHAAAQPH/AgAcAAZOb3JtYWwAAgAAAAYAYQwEYxgAWAABQAEAAgBYAAdUaXRyZSAxAABAAAEA DQEV4AEW8AAMNAAAAQQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAFWBXAACQAEA8gBcAAdUaXRyZSAyAABAAAIADQIV8AAWeAAMNAAAAAQAAAGAAAABAAAA kAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAFWBYxYAAFwAA0ABABIBXAAH VGl0cmUgMwAAQAADAA0DFXgAFngADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABQBeAWMWAABeAARAAQACAF4AB1RpdHJlIDQAAEIABAAIAQ0EFfAA FjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BQBVgV0CAABcAAVAAQACAFwAB1RpdHJlIDUAAEAABQANBRXwABY8AAw0AAEABAAAAYAAAAEAAACQ AAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAXQIAYxYAXAAGQAEAAgBcAAdU aXRyZSA2AABAAAYADQYV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAFAFaBYxYAAFwAB0ABAAIAXAAHVGl0cmUgNwAAQAAHAA0HFfAAFjwA DDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBd AgBjFABeAAhAAQACAF4AB1RpdHJlIDgAAEAACAANCBXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAA AAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAVoFdAgBjFABgAAlAAQACAGAAB1Rp dHJlIDkAAEAACQANCRXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAoAVYFWgV0CAGMSAB4AQUDy/6EAHgARUG9saWNlIHBhciBk6WZhdXQA AAAAAAAAAAAAAAAiAP5PAQHyACIADlJldHJhaXROb3JtYWwyAAUADwARbgQAAAAiABxAAQACASIA DlJldHJhaXQgbm9ybWFsAAUAEAARxAIAAAAiAP5P8QASASIADlJldHJhaXROb3JtYWwzAAUAEQAR GAYAAAAmACBAAQAiASYADFBpZWQgZGUgcGFnZQAMABIADwgAAtMSbyMBAgAAAAAAABUAAAAdAAAA MQAAADUAAABPAAAAYAAAAGYAAAByAAAAgQAAAJEAAACUAAAAAAAAAKUAAAALAKUDAAAAAP////8B AAQg//8BAAAAAAClAAAAAAAAAAAAAAAAABMAAAClAAAABgAAAAYAAAAAAwAABgcAAAQAAAMAAKUD AAAFAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN AAAADgAAAA8AAAAQAAAApQAAAMIDAAABAPQDAAABACYEAAABAFgEAAAAAIgEAAAAALgEAAAAAOgE AAAAABgFAAAAAEgFAAABAHoFAAABAKwFAAAAANwFAAAAAAwGAAABAD4GAAABAHAGAAABAKIGAAAB ANQGAAABAP9ASFAgTGFzZXJKZXQgNDAwMCBQUwBMUFQxOgBQU0NSSVBUAEhQIExhc2VySmV0IDQw MDAgUFMASFAgTGFzZXJKZXQgNDAwMCBQUwAAAAAAAAAAAAAAAAAABAMElAC4Ah93AAABAAkAmgsz CGQAAQAHAFgCAQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAA wBIAAMgZAAABAAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAILka71nOmts/LYFAAIAAQAA AAAAAQAAAAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP//AwD//wEA//8AAP//AQD//wAA //8AAP//AAD//wEA//8BAP//AAD//wEA//8BAP//AAD//wAA//8AAP//AAD//wEA//8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9QYWdlIHBlcnNvbm5hbGlz6WUg MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAA AABQYWdlIHBlcnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAAAAAAAAAAAAAEhQIExh c2VySmV0IDQwMDAgUFMAAAAAAAAAAAAAAAAAAAQDBJQAuAIfdwAAAQAJAJoLMwhkAAEABwBYAgEA AgBYAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAMASAADIGQAAAQAA AAAAAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAAAACC5Gu9ZzprbPy2BQACAAEAAAAAAAEAAAAAAAIA AgABAFIDAADCAQAAAAAAAAAAZAAAAAAAAwD//wMA//8BAP//AAD//wEA//8AAP//AAD//wAA//8B AP//AQD//wAA//8BAP//AQD//wAA//8AAP//AAD//wAA//8BAP//AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//UGFnZSBwZXJzb25uYWxpc+llIDEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAUGFnZSBwZXJz b25uYWxpc+llIDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WEMAALRDAAAAAAAAUGFnZSBwZXJzb25uYWxpc+llIDMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAAAAAAAAAAAAAgAAABQAAAAUAAAALAAEA AQAFAAAAAAAfAAUAAAAxABUWkAEAAFRpbWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAA QXJpYWwAIgAEAAMDjBhWDMQCAACpAQAAAABMtDEGjbQxpgAAAAACAAEAAAACAAAADwAAAAEAAQAA AAQAgwABAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDVgwAADQAAAAAAAAAEEplYW4tQ2xhdWRl IERhbmcQSmVhbi1DbGF1ZGUgRGFuZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAGSZ8HwAAAQAJAAADIA0AAAsA KAAAAAAAFAAAACYGDwAeAP////8EABQAAABXb3JkDgBNaWNyb3NvZnQgV29yZAUAAAALAgAAAAAF AAAADAJwBwAJDQAAAPsCAAAAAAAAAAAAAAAAAAAAAAABAAwEAAAALQEAAAQAAAACAQEAFQAAAPsC nP8AAAAAAACQAQAAAAAEAAASVGltZXMgTmV3IFJvbWFuAGsBBAAAAC0BAQAFAAAACQIAAAAABAAA AAIBAQAEAAAAAgEBAAcAAAD8AgEAAAAAAAAABAAAAC0BAgAJAAAA+gIAAAIAAAAAAAAAIgAEAAAA LQEDAAcAAAAbBOoCkwTjAd0CCQAAAPoCAAAAAAAAAAAAACIABAAAAC0BBAAEAAAA8AEDAAcAAAD8 AgAA////AAAABAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBOECiQTsAeYCBAAAAAIBAQAQAAAA +wKt/wAAAAAAAJABAAAAAAQAACJBcmlhbAAqAAQAAAAtAQUADgAAADIKEAJ7AwIABAAAAAAAAAlw B0dLQQA3AAQAAAAtAQEABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BAgAJAAAA+gIAAAIA AAAAAAAAIgAEAAAALQEGAAcAAAAbBFwGHAJBBWUABAAAAC0BBAAEAAAA8AEGAAQAAAAtAQMABAAA AAIBAQADAAAAHgAHAAAAFgRSBhICSwVuAAQAAAACAQEABAAAAC0BBQATAAAAMgpvBdEABQAEAAAA AAAACXAHSC4zMjMAPAAXAC4ALgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABcAAAAyCs4FqwAI AAQAAAAAAAAJcAd0ZXJtaW5hbBcALgAcAEcAEgAuAC4AEgAEAAAALQEBAAQAAAACAQEABAAAACcB //8EAAAAAgEBAAcAAAD8AgAAAAAAAAAABAAAAC0BBgAJAAAA+gIFAAAAAAD///8AIgAEAAAALQEH AAwAAAAkAwQATQYnAU8GJwFPBisBTQYrAQwAAAAkAwQATQYzAU8GMwFPBjcBTQY3AQwAAAAkAwQA TQY/AU8GPwFPBkMBTQZDAQwAAAAkAwQATQZLAU8GSwFPBk8BTQZPAQwAAAAkAwQATQZXAU8GVwFP BlsBTQZbAQwAAAAkAwQATQZjAU8GYwFPBmcBTQZnAQwAAAAkAwQATQZvAU8GbwFPBnMBTQZzAQwA AAAkAwQATQZ7AU8GewFPBn8BTQZ/AQwAAAAkAwQATQaHAU8GhwFPBosBTQaLAQwAAAAkAwQATQaT AU8GkwFPBpcBTQaXAQwAAAAkAwQATQafAU8GnwFPBqMBTQajAQwAAAAkAwQATQarAU8GqwFPBq8B TQavAQwAAAAkAwQATQa3AU8GtwFPBrsBTQa7AQwAAAAkAwQATQbDAU8GwwFPBscBTQbHAQwAAAAk AwQATQbPAU8GzwFPBtMBTQbTAQwAAAAkAwQATQbbAU8G2wFPBt8BTQbfAQwAAAAkAwQATQbnAU8G 5wFPBusBTQbrAQwAAAAkAwQATQbzAU8G8wFPBvcBTQb3AQwAAAAkAwQATQb/AU8G/wFPBgMCTQYD AgwAAAAkAwQATQYLAk8GCwJPBg8CTQYPAgwAAAAkAwQATQYXAk8GFwJPBhsCTQYbAgwAAAAkAwQA TQYjAk8GIwJPBicCTQYnAgwAAAAkAwQATQYvAk8GLwJPBjMCTQYzAgwAAAAkAwQATQY7Ak8GOwJP Bj8CTQY/AgwAAAAkAwQATQZHAk8GRwJPBksCTQZLAgwAAAAkAwQATQZTAk8GUwJPBlcCTQZXAgwA AAAkAwQATQZfAk8GXwJPBmMCTQZjAgwAAAAkAwQATQZrAk8GawJPBm8CTQZvAgwAAAAkAwQATQZ3 Ak8GdwJPBnsCTQZ7AgwAAAAkAwQATQaDAk8GgwJPBocCTQaHAgwAAAAkAwQATQaPAk8GjwJPBpMC TQaTAgwAAAAkAwQATQabAk8GmwJPBp8CTQafAgwAAAAkAwQATQanAk8GpwJPBqsCTQarAgwAAAAk AwQATQazAk8GswJPBrcCTQa3AgwAAAAkAwQATQa/Ak8GvwJPBsMCTQbDAgwAAAAkAwQATQbLAk8G ywJPBs8CTQbPAgwAAAAkAwQATQbXAk8G1wJPBtsCTQbbAgwAAAAkAwQATQbjAk8G4wJPBucCTQbn AgwAAAAkAwQATQbvAk8G7wJPBvMCTQbzAgwAAAAkAwQATQb7Ak8G+wJPBv8CTQb/AgwAAAAkAwQA TQYHA08GBwNPBgsDTQYLAwwAAAAkAwQATQYTA08GEwNPBhcDTQYXAwwAAAAkAwQATQYfA08GHwNP BiMDTQYjAwwAAAAkAwQATQYrA08GKwNPBi8DTQYvAwwAAAAkAwQATQY3A08GNwNPBjsDTQY7AwwA AAAkAwQATQZDA08GQwNPBkcDTQZHAwwAAAAkAwQATQZPA08GTwNPBlMDTQZTAwwAAAAkAwQATQZb A08GWwNPBl8DTQZfAwwAAAAkAwQATQZnA08GZwNPBmsDTQZrAwwAAAAkAwQATQZzA08GcwNPBncD TQZ3AwwAAAAkAwQATQZ/A08GfwNPBoMDTQaDAwwAAAAkAwQATQaLA08GiwNPBo8DTQaPAwwAAAAk AwQATQaXA08GlwNPBpsDTQabAwwAAAAkAwQATQajA08GowNPBqcDTQanAwwAAAAkAwQATQavA08G rwNPBrMDTQazAwwAAAAkAwQATQa7A08GuwNPBr8DTQa/AwwAAAAkAwQATQbHA08GxwNPBssDTQbL AwwAAAAkAwQATQbTA08G0wNPBtcDTQbXAwwAAAAkAwQATQbfA08G3wNPBuMDTQbjAwwAAAAkAwQA TQbrA08G6wNPBu8DTQbvAwwAAAAkAwQATQb3A08G9wNPBvsDTQb7AwwAAAAkAwQATQYDBE8GAwRP BgcETQYHBAwAAAAkAwQATQYPBE8GDwRPBhMETQYTBAwAAAAkAwQATQYbBE8GGwRPBh8ETQYfBAwA AAAkAwQATQYnBE8GJwRPBisETQYrBAwAAAAkAwQATQYzBE8GMwRPBjcETQY3BAwAAAAkAwQATQY/ BE8GPwRPBkMETQZDBAwAAAAkAwQATQZLBE8GSwRPBlAETQZQBAwAAAAkAwQATQZYBE8GWARPBlwE TQZcBAwAAAAkAwQATQZkBE8GZARPBmgETQZoBAwAAAAkAwQATQZwBE8GcARPBnQETQZ0BAwAAAAk AwQATQZ8BE8GfARPBoAETQaABAwAAAAkAwQATQaIBE8GiARPBowETQaMBAwAAAAkAwQATQaUBE8G lARPBpgETQaYBAwAAAAkAwQATQagBE8GoARPBqQETQakBAwAAAAkAwQATQasBE8GrARPBrAETQaw BAwAAAAkAwQATQa4BE8GuARPBrwETQa8BAwAAAAkAwQATQbEBE8GxARPBsgETQbIBAwAAAAkAwQA TQbQBE8G0ARPBtQETQbUBAwAAAAkAwQATQbcBE8G3ARPBuAETQbgBAwAAAAkAwQATQboBE8G6ARP BuwETQbsBAwAAAAkAwQATQb0BE8G9ARPBvgETQb4BAwAAAAkAwQATQYABU8GAAVPBgQFTQYEBQwA AAAkAwQATQYMBU8GDAVPBhAFTQYQBQwAAAAkAwQATQYYBU8GGAVPBhwFTQYcBQwAAAAkAwQATQYk BU8GJAVPBigFTQYoBQwAAAAkAwQATQYwBU8GMAVPBjQFTQY0BQwAAAAkAwQATQY8BU8GPAVPBkAF TQZABQwAAAAkAwQATQZIBU8GSAVPBkwFTQZMBQwAAAAkAwQATQZUBU8GVAVPBlgFTQZYBQwAAAAk AwQATQZgBU8GYAVPBmQFTQZkBQwAAAAkAwQATQZsBU8GbAVPBnAFTQZwBQwAAAAkAwQATQZ4BU8G eAVPBnwFTQZ8BQwAAAAkAwQATQaEBU8GhAVPBogFTQaIBQwAAAAkAwQATQaQBU8GkAVPBpQFTQaU BQwAAAAkAwQATQacBU8GnAVPBqAFTQagBQwAAAAkAwQATQaoBU8GqAVPBqwFTQasBQwAAAAkAwQA TQa0BU8GtAVPBrgFTQa4BQwAAAAkAwQATQbABU8GwAVPBsQFTQbEBQwAAAAkAwQATQbMBU8GzAVP BtAFTQbQBQwAAAAkAwQATQbYBU8G2AVPBtwFTQbcBQwAAAAkAwQATQbkBU8G5AVPBugFTQboBQwA AAAkAwQATQbwBU8G8AVPBvQFTQb0BQwAAAAkAwQATQb8BU8G/AVPBgAGTQYABgwAAAAkAwQATQYI Bk8GCAZPBgwGTQYMBgwAAAAkAwQATQYUBk8GFAZPBhgGTQYYBgwAAAAkAwQATQYgBk8GIAZPBiQG TQYkBgwAAAAkAwQATQYsBk8GLAZPBjAGTQYwBgwAAAAkAwQATQY4Bk8GOAZPBjwGTQY8BgwAAAAk AwQATQZEBk8GRAZPBkgGTQZIBgwAAAAkAwQATQZQBk8GUAZPBlQGTQZUBgwAAAAkAwQATQZcBk8G XAZPBmAGTQZgBgwAAAAkAwQATQZoBk8GaAZPBmwGTQZsBgwAAAAkAwQATQZ0Bk8GdAZPBngGTQZ4 BgwAAAAkAwQATQaABk8GgAZPBoQGTQaEBgwAAAAkAwQATQaMBk8GjAZPBpAGTQaQBgwAAAAkAwQA TQaYBk8GmAZPBpwGTQacBgwAAAAkAwQATQakBk8GpAZPBqgGTQaoBgwAAAAkAwQATQawBk8GsAZP BrQGTQa0BgwAAAAkAwQATQa8Bk8GvAZPBsAGTQbABgwAAAAkAwQATQbIBk8GyAZPBswGTQbMBgwA AAAkAwQATQbUBk8G1AZPBtgGTQbYBgwAAAAkAwQATQbgBk8G4AZPBuQGTQbkBgwAAAAkAwQATQbs Bk8G7AZPBvAGTQbwBgwAAAAkAwQATQb4Bk8G+AZPBvwGTQb8BgwAAAAkAwQATQYEB08GBAdPBggH TQYIBwwAAAAkAwQATQYQB08GEAdPBhQHTQYUBwwAAAAkAwQATQYcB08GHAdPBiAHTQYgBwwAAAAk AwQATQYoB08GKAdPBiwHTQYsBwwAAAAkAwQATQY0B08GNAdPBjgHTQY4BwwAAAAkAwQATQZAB08G QAdPBkQHTQZEBwwAAAAkAwQATQZMB08GTAdPBlAHTQZQBwwAAAAkAwQATQZYB08GWAdPBlwHTQZc BwwAAAAkAwQATQZkB08GZAdPBmgHTQZoBwwAAAAkAwQATQZwB08GcAdPBnQHTQZ0BwQAAAAtAQMA BAAAAC0BBAAEAAAAAgEBAAQAAAACAQEABAAAAC0BAwAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEI AAcAAAAbBFwGHQdBBWcFBAAAAC0BBAAEAAAA8AEIAAQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAA FgRSBhMHSwVwBQQAAAACAQEABAAAAC0BBQATAAAAMgpvBdEFBQAEAAAAAAAACXAHTWVkaWEARQAu AC4AEgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABYAAAAyCs4FnwUHAAQAAAAAAAAJcAdHYXRl d2F5AEEALgAXAC4AOwAuACcABAAAAC0BAQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQED AAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQgABwAAABsEoAN6BZgCxAMEAAAALQEEAAQAAADwAQgA BAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBJYDcAWhAs0DBAAAAAIBAQAQAAAA+wK9/wAAAAAA AJABAAAAAAQAACJBcmlhbAAAAQQAAAAtAQgAEwAAADIKowJEBAUABAAAAAAAAAlwB01lZGlhADcA JQAlAA8AJQAEAAAAAgEBAAQAAAACAQEABAAAAC0BCAAWAAAAMgrwAhsEBwAEAAAAAAAACXAHR2F0 ZXdheQA0ACUAEwAlAC8AJQAhAAQAAAACAQEABAAAAAIBAQAEAAAALQEIABoAAAAyCj0DDgQKAAQA AAAAAAAJcAdDb250cm9sbGVyMAAlACUAEwAWACUADwAPACUAFgAVAAAA+wK9/wAAAAAAAJABAAAA AAQAABJUaW1lcyBOZXcgUm9tYW4ANAAEAAAALQEJAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQA AAAtAQMACQAAAB0GIQDwAJcAyQEnAbIGBAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBLcBcwgw AboGBAAAAAIBAQAEAAAALQEFABEAAAAyCjMBugYEAAQAAAAAAAAJcAdQU1RONwA3ADQAPAAEAAAA AgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEDAAkAAAAdBiEA8ACXAFMDbQQnAgQAAAAtAQMABAAA AAIBAQADAAAAHgAHAAAAFgT8BHIFdQQvAgQAAAACAQEABAAAAC0BBQAoAAAAMgp4BC8CEwAEAAAA AAAACXAHMikgQ3JlYXRlQ29ubmVjdGlvbgAuABwAFwA8ABwALgAuABcALgA8AC4ALgAuAC4AKgAX ABIALgAuAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAAtAQMACQAAAB0GIQDwAH4AOQGFApkG BAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBPwCygeOAqEGBAAAAAIBAQAEAAAALQEFABQAAAAy CpECuwYGAAQAAAAAAAAJcAczKSBJQU0uABwAFwAXADcARQAEAAAAAgEBAAQAAAAnAf//BAAAAAIB AQAEAAAALQEDAAkAAAAdBiEA8ACXAHkDiwAzAAQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgQa AaQDkwA7AAQAAAACAQEABAAAAC0BBQAmAAAAMgqWADsAEgAEAAAAAAAACXAHIDEpIENvbm5lY3Qo QFBTVE4pFwAuABwAFwA8AC4ALgAuAC4AKgAXABwAVAA3ADcANAA8ABwABAAAAAIBAQAEAAAAJwH/ /wQAAAACAQEABAAAAC0BAwAJAAAAHQYhAPAAlwDJAScBLgQEAAAALQEDAAQAAAACAQEAAwAAAB4A BwAAABYEtwHvBTABNgQEAAAAAgEBAAQAAAAtAQUAGgAAADIKMwE2BAoABAAAAAAAAAlwB0lQIG5l dHdvcmsXADcAFwAuAC4AFwA7AC4AHAArAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAkAAAD6AgAA BgAAAAAAAAAiAAQAAAAtAQoABQAAABQCcwLSAgUAAAATAi8FUQEEAAAALQEEAAQAAADwAQoABAAA AC0BBgAJAAAA+gIAAAEAAAAAAAAAIgAEAAAALQEKAAoAAAAkAwMAaQEzBUEBHQVGAUIFBAAAAC0B AwAEAAAALQEEAAQAAADwAQoABAAAAC0BBgAJAAAA+gIAAAEAAAAAAAAAIgAEAAAALQEKAAoAAAAk AwMAuwJuAuMChQLdAmACBAAAAC0BAwAEAAAALQEEAAQAAADwAQoABAAAAAIBAQAEAAAAAgEBAAQA AAACAQEAAwAAAB4ABwAAABYEKAQBAgsD6gAEAAAAAgEBAAQAAAAtAQUAEAAAADIKDgMgAQMABAAA AAAAAAlwB1JBUwA8ADcANwAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQATAAAAMgptAwQBBQAEAAAA AAAACXAHUS45MzEAQQAXAC4ALgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABMAAAAyCswDBgEF AAQAAAAAAAAJcAdILjI0NQA8ABcALgAuAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEACQAAAPoC AAARAAAAAAAAACIABAAAAC0BCgAFAAAAFALRBSECBQAAABMC0QVBBQQAAAAtAQQABAAAAPABCgAE AAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwA1BbAFNQXyBWcF0QUEAAAA LQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAA AC0BCgAFAAAAFALLBS8HBQAAABMCxQXLCAQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAA AQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwC+CKQFvwjnBfEIxQUEAAAALQEDAAQAAAAtAQQABAAA APABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCgAFAAAAFAKlA6sE BQAAABMCKgXQBQQAAAAtAQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAt AQoACgAAACQDAwDeBRYFuQUyBd0FOwUEAAAALQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQA AAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCgAFAAAAFAL7/7EDBQAAABMCxwGxAwQAAAAt AQQABAAAAPABCgAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwDIA8AB mgPAAbED3QEEAAAALQEDAAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAG AAAAAAAAACIABAAAAC0BCgAFAAAAFAIVA3kFBQAAABMCFQNMCAQAAAAtAQQABAAAAPABCgAEAAAA LQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQoACgAAACQDAwBECP4CRAgsA2EIFQMEAAAALQED AAQAAAAtAQQABAAAAPABCgAEAAAAAgEBAAQAAAAtAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAUAAAAAQAAABcAAAABQAAAGQAAAAGAAAAbAAAAAsA AAB0AAAAEAAAAHwAAAAMAAAAhAAAAAIAAADkBAAAHgAAAAEAAAAAAPAAAwAAAAA2AAADAAAAAQAA AAMAAAABAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAAAEAAAAAAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAA AAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACgAQAAEgAAAAEAAACYAAAAAgAAAKAA AAADAAAArAAAAAQAAAC4AAAABQAAANQAAAAGAAAA4AAAAAcAAADsAAAACAAAAAABAAAJAAAAHAEA ABIAAAAoAQAACgAAAFABAAALAAAAXAEAAAwAAABoAQAADQAAAHQBAAAOAAAAgAEAAA8AAACIAQAA EAAAAJABAAATAAAAmAEAAAIAAADkBAAAHgAAAAEAAAAAAAAAHgAAAAEAAAAAAACgHgAAABEAAABK ZWFuLUNsYXVkZSBEYW5nAA5HAB4AAAABAAAAAAAAAB4AAAABAAAAAAAAAB4AAAALAAAAbm9ybWFs LmRvdAB3HgAAABEAAABKZWFuLUNsYXVkZSBEYW5nAD9EAB4AAAACAAAAMgAAAB4AAAAeAAAATWlj cm9zb2Z0IFdvcmQgZm9yIFdpbmRvd3MgOTUAAABAAAAAAAAAAAAAAABAAAAAAPqF8mPXuQFAAAAA AL41uh5GvgFAAAAAACb6GydGvgEDAAAAAQAAAAMAAAACAAAAAwAAAA4AAAADAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoA AP////8BCQIAAAAAAMAAAAAAAABGFQAAAEltYWdlIE1pY3Jvc29mdCBXb3JkAAoAAABNU1dvcmRE b2MADwAAAFdvcmQuUGljdHVyZS42APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEwAAAAAAAAAAAAIABkmAAB8HwAAmRUAANkRAAAAAAAAAAAAAAAAAAAAAAAA6AMAAOgD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA3KVoAFfgDAQAAAAAZQAAAAAAAAAAAAAAAAMAAJADAAANGQAA AAAAAAAAAAAAAAAAAAAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH4AAAAAAAAAAAAAAAAMAAA8 BAAAAAwAADwEAAA8EAAAAAAAADwQAAAAAAAAbBAAAAAAAABsEAAAAAAAAGwQAAAUAAAAlhAAABQA AACWEAAAAAAAAKoQAAAAAAAAqhAAAAAAAACqEAAAAAAAAKoQAAAKAAAAtBAAAAoAAACWEAAAAAAA AFAYAAAxAAAAvhAAAAAAAAC+EAAAAAAAAL4QAAAAAAAAvhAAAAAAAAC+EAAAAAAAAGIRAAAAAAAA YhEAAAAAAABiEQAAAAAAAGIRAAACAAAAZBEAAAAAAABkEQAAAAAAAGQRAAA2AAAAmhEAAEwDAADm FAAATAMAADIYAAAeAAAAgRgAAFgAAADZGAAANAAAAFAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGwQ AAAAAAAAYhEAAAAAAAAAAAQABQABAAEAvhAAAKQAAABiEQAAAAAAAAAAAAAAAAAAAAAAAAAAAABi EQAAAAAAAGIRAAAAAAAAUBgAAAAAAABiEQAAAAAAADwQAAAAAAAAPBAAAAAAAAC+EAAAAAAAAAAA AAAAAAAAAAAAAAAAAAC+EAAAAAAAAGIRAAAAAAAAYhEAAAAAAABiEQAAAAAAAGIRAAAAAAAAPBAA ADAAAAC+EAAAAAAAAGwQAAAAAAAAvhAAAAAAAABiEQAAAAAAAAAAAAAAAAAAgA+xLSdGvgGAEAAA CAAAAIgQAAAOAAAAPBAAAAAAAAA8EAAAAAAAADwQAAAAAAAAPBAAAAAAAABiEQAAAAAAAGIRAAAA AAAAYhEAAAAAAABiEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgICAgICAgI CAgICAgICA1JTkFQDQ1NR0NQoD8NDUdLDQ1NZWRpYSBHYXRld2F5IENvbnRyb2xsZXINDU1lZGlh IHN0cmVhbXMNDVJBUwtRLjkzMQtILjI0NQ0NUFNUTg0NSVAgbmV0d29yaw0NTWVkaWEgR2F0ZXdh eQ0NSC4zMjMgdGVybWluYWwNDQ0NGwChAQCkwE6lwE6mWR2nzxuokB+pWR2qAACrCQAAADAAAQH8 LwAAAQAmAHksViIBAB8PAAAAAAAAHg8AAAAABQACABgAGAAAAAAAAAAAADIAAQEHMAAAAgQoAIIj 7iCkAg8BAAAAACgABQD///8AAAAhUQAAAAAAAAAAAAAUAAAAMAABAQgwAAABACYAUibgHwEADAQA AAsEAAAAAAAAAAAFAAIAGQAZAAAAAAAAAAAAMgABAf8vAAACBCgAQyaaKToDaQEAAAAABQAFAP// /wD///8AAQAAAAAAAAAAABQAAAAwAAEBBjAAAAEAJgCMKFAo4ALQAwAAAADfAs8DAAAAAA8AAAAY ABgAAAAAAAAAAAAwAAEBATAAAAEAJgBnIEQl0APrBs8DAAAAAOoGAAAAAA8AAAAYABgAAAAAAAAA AAAyAAEB+i8AAAIEKAA2JBgkGwR3AgAAAAAFAAAA////AAAAIVEAAAAAAAAAAAAAFAAAADIAAQH+ LwAAAgQoAGEmyyUbBHcCAAAAAAUAAAD///8A////AAEAAAAAAAAAAAAUAAAAMAABAQUwAAABACYA lS5pLTkEEAAAAA8AOAQAAAAAAAAoAAAAGAAaAAAAAAAAAAAAMgABAQQwAAACBCgANyM9LEYGWgEA AAAAKAAFAP///wAAACFRAAAAAAAAAAAAABQAAAAwAAEBAzAAAAEAJgB0Ioct2wcBAAAAAADaBwAA AAAAACgAAAAaABoAAAAAAAAAAAAyAAEBAjAAAAIEKAB3H8omwgLRAgAAAAAoAAUA////AAAAIVEA AAAAAAAAAAAAFAAAADIAAQH/LwAAAgQoAGktViJIBGkBAAAAAAUABQD///8A////AAEAAAAAAAAA AAAUAAAAMgABAQAwAAACBCgAYCdWIkgEaQEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAy AAEB/S8AAAIEKABOKi4sGwSkAgAAAAAFAAAA////AP///wABAAAAAAAAAAAAFAAAADIAAQH7LwAA AgQoAEseLiwbBKQCAAAAAAUAAAD///8AAAAhUQAAAAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAEAMAABEDAAAVAwAAFwMAAB4DAAAfAwAAIQMAACMDAAA7AwAA PAMAAD0DAABLAwAATAMAAFwDAABdAwAAYgMAAGMDAABuAwAAbwMAAHwDAAB+AwAAjAMAAI8DAACQ AwAAwQYAAPkA9QD1APUA8e8A9QD1APUA9QD1APUAAO0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACdQEAA2MQAAZdAgBjEAAABl0CAGMU AAALdQFEBAAAAABhAAQAGQADAAARAwAAFgMAABcDAAAeAwAAHwMAACIDAAAjAwAAPAMAAD0DAABL AwAATAMAAFwDAABdAwAAYgMAAGMDAABuAwAAbwMAAH0DAAB+AwAAjQMAAI4DAACPAwAAkAMAAP4A AZcVGwH7AAF+AuQA/gAAAAAAAP4AARYD5AD+AAAAAAAA9gAB7gPkAP4AAAAAAAD7AAPuA7kA/gAA AAAAAPsAASIG5AD+AAAAAAAA+wADngLkAP4AAAAAAAD+AAEiBOQA/gAAAAAAAP4AASIE5AD+AAAA AAAA9gAC7gPkAP4AAAAAAAD2AALwA+QA/gAAAAAAAP4AAAAAAAD+AAGXFRsBAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAUB FVAAAAACAAAFAQABAAAXDgATAAgAAQBLAA8AAAAAABwAAEDx/wIAHAAGTm9ybWFsAAIAAAAGAGEM BGMYAFgAAUABAAIAWAAHVGl0cmUgMQAAQAABAA0BFeABFvAADDQAAAEEAAABgAAAAQAAAJAAAAAA AC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBVgVwAAkABAPIAXAAHVGl0cmUgMgAA QAACAA0CFfAAFngADDQAAAAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABQBVgWMWAABcAANAAQASAVwAB1RpdHJlIDMAAEAAAwANAxV4ABZ4AAw0AAEABAAA AYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAXgFjFgAAXgAE QAEAAgBeAAdUaXRyZSA0AABCAAQACAENBBXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAVYFdAgAAXAAFQAEAAgBcAAdUaXRyZSA1AABA AAUADQUV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAF0CAGMWAFwABkABAAIAXAAHVGl0cmUgNgAAQAAGAA0GFfAAFjwADDQAAQAEAAAB gAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBWgWMWAABcAAdA AQACAFwAB1RpdHJlIDcAAEAABwANBxXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAXQIAYxQAXgAIQAEAAgBeAAdUaXRyZSA4AABAAAgA DQgV8AAWPAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIAFaBXQIAYxQAYAAJQAEAAgBgAAdUaXRyZSA5AABAAAkADQkV8AAWPAAMNAABAAQAAAGA AAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAFWBVoFdAgBjEgAe AEFA8v+hAB4AEVBvbGljZSBwYXIgZOlmYXV0AAAAAAAAAAAAAAAAIgD+TwEB8gAiAA5SZXRyYWl0 Tm9ybWFsMgAFAA8AEW4EAAAAIgAcQAEAAgEiAA5SZXRyYWl0IG5vcm1hbAAFABAAEcQCAAAAIgD+ T/EAEgEiAA5SZXRyYWl0Tm9ybWFsMwAFABEAERgGAAAAJgAgQAEAIgEmAAxQaWVkIGRlIHBhZ2UA DAASAA8IAALTEm8jAQIAAAAAAAAGAAAADgAAABIAAAAsAAAAOwAAAEwAAABSAAAAXgAAAG0AAAB9 AAAAgAAAAAAAAACQAAAADACQAwAACwD/////AQAEIP//AQAAAAAAkAAAAAAAAAAAAAAAAAASAAAA kAAAAAYAAAAGAAAAAAMAAMEGAAAEAAADAACQAwAABQAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAkAAAAK0DAAAAAN0DAAABAA8E AAAAAD8EAAABAHEEAAAAAKEEAAAAANEEAAABAAMFAAABADUFAAAAAGUFAAABAJcFAAAAAMcFAAAB APkFAAABACsGAAABAF0GAAABAI8GAAABAP9ASFAgTGFzZXJKZXQgNDAwMCBQUwBMUFQxOgBQU0NS SVBUAEhQIExhc2VySmV0IDQwMDAgUFMASFAgTGFzZXJKZXQgNDAwMCBQUwAAAAAAAAAAAAAAAAAA BAMElAC4Ah93AAABAAkAmgszCGQAAQAHAFgCAQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAAAAwBIAAMgZAAABAAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAA AILka71nOmts/LYFAAIAAQAAAAAAAQAAAAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP// AwD//wEA//8AAP//AQD//wAA//8AAP//AAD//wEA//8BAP//AAD//wEA//8BAP//AAD//wAA//8A AP//AAD//wEA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9Q YWdlIHBlcnNvbm5hbGlz6WUgMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz 6WUgMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMA AAAAAAAAAAAAAAAAAEhQIExhc2VySmV0IDQwMDAgUFMAAAAAAAAAAAAAAAAAAAQDBJQAuAIfdwAA AQAJAJoLMwhkAAEABwBYAgEAAgBYAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACAAAAMASAADIGQAAAQAAAAAAAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAAAACC5Gu9ZzprbPy2 BQACAAEAAAAAAAEAAAAAAAIAAgABAFIDAADCAQAAAAAAAAAAZAAAAAAAAwD//wMA//8BAP//AAD/ /wEA//8AAP//AAD//wAA//8BAP//AQD//wAA//8BAP//AQD//wAA//8AAP//AAD//wAA//8BAP// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//UGFnZSBwZXJzb25u YWxpc+llIDEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMA ALRDAAAAAAAAUGFnZSBwZXJzb25uYWxpc+llIDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAUGFnZSBwZXJzb25uYWxpc+llIDMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAAAAAAAAA AAADgAEAAAAAAAAAAAAHAAEAAQAAAAAAAAAAAAAAAAAxABUWkAEAAFRpbWVzIE5ldyBSb21hbgAM FpABAgBTeW1ib2wACyaQAQAAQXJpYWwAIgAEAAMDjBhWDMQCAACpAQAAAAAxtDEGcbQxpgAAAAAC AAAAAAACAAAADgAAAAEAAQAAAAQAgwABAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDVgwAADQA AAAAAAAAEEplYW4tQ2xhdWRlIERhbmcQSmVhbi1DbGF1ZGUgRGFuZwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAIABkmfB8AAAEACQAAA0QOAAALAB8AAAAAABQAAAAmBg8AHgD/////BAAUAAAAV29y ZA4ATWljcm9zb2Z0IFdvcmQFAAAACwIAAAAABQAAAAwCcAcACQ0AAAD7AgAAAAAAAAAAAAAAAAAA AAAAAQAMBAAAAC0BAAAEAAAAAgEBABUAAAD7Apz/AAAAAAAAkAEAAAAABAAAElRpbWVzIE5ldyBS b21hbgBrAQQAAAAtAQEABAAAAAIBAQAEAAAAAgEBAAcAAAD8AgEAAAAAAAAABAAAAC0BAgAJAAAA +gIAAAIAAAAAAAAAIgAEAAAALQEDAAcAAAAbBOoCkwTjAd0CCQAAAPoCAAAAAAAAAAAAACIABAAA AC0BBAAEAAAA8AEDAAcAAAD8AgAA////AAAABAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBOEC iQTsAeYCBAAAAAIBAQAQAAAA+wKt/wAAAAAAAJABAAAAAAQAACJBcmlhbAAqAAQAAAAtAQUADgAA ADIKEAJ7AwIABAAAAAAAAAlwB0dLQQA3AAQAAAAtAQEABAAAAAIBAQAEAAAAJwH//wQAAAACAQEA BAAAAC0BAgAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEGAAcAAAAbBFwGHAJBBWUABAAAAC0BBAAE AAAA8AEGAAQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgRSBhICSwVuAAQAAAACAQEABAAAAC0B BQATAAAAMgpvBdEABQAEAAAAAAAACXAHSC4zMjMAPAAXAC4ALgAuAAQAAAACAQEABAAAAAIBAQAE AAAALQEFABcAAAAyCs4FqwAIAAQAAAAAAAAJcAd0ZXJtaW5hbBcALgAcAEcAEgAuAC4AEgAEAAAA LQEBAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAcAAAD8AgAAAAAAAAAABAAAAC0BBgAJAAAA+gIF AAAAAAD///8AIgAEAAAALQEHAAwAAAAkAwQATQYnAU8GJwFPBisBTQYrAQwAAAAkAwQATQYzAU8G MwFPBjcBTQY3AQwAAAAkAwQATQY/AU8GPwFPBkMBTQZDAQwAAAAkAwQATQZLAU8GSwFPBk8BTQZP AQwAAAAkAwQATQZXAU8GVwFPBlsBTQZbAQwAAAAkAwQATQZjAU8GYwFPBmcBTQZnAQwAAAAkAwQA TQZvAU8GbwFPBnMBTQZzAQwAAAAkAwQATQZ7AU8GewFPBn8BTQZ/AQwAAAAkAwQATQaHAU8GhwFP BosBTQaLAQwAAAAkAwQATQaTAU8GkwFPBpcBTQaXAQwAAAAkAwQATQafAU8GnwFPBqMBTQajAQwA AAAkAwQATQarAU8GqwFPBq8BTQavAQwAAAAkAwQATQa3AU8GtwFPBrsBTQa7AQwAAAAkAwQATQbD AU8GwwFPBscBTQbHAQwAAAAkAwQATQbPAU8GzwFPBtMBTQbTAQwAAAAkAwQATQbbAU8G2wFPBt8B TQbfAQwAAAAkAwQATQbnAU8G5wFPBusBTQbrAQwAAAAkAwQATQbzAU8G8wFPBvcBTQb3AQwAAAAk AwQATQb/AU8G/wFPBgMCTQYDAgwAAAAkAwQATQYLAk8GCwJPBg8CTQYPAgwAAAAkAwQATQYXAk8G FwJPBhsCTQYbAgwAAAAkAwQATQYjAk8GIwJPBicCTQYnAgwAAAAkAwQATQYvAk8GLwJPBjMCTQYz AgwAAAAkAwQATQY7Ak8GOwJPBj8CTQY/AgwAAAAkAwQATQZHAk8GRwJPBksCTQZLAgwAAAAkAwQA TQZTAk8GUwJPBlcCTQZXAgwAAAAkAwQATQZfAk8GXwJPBmMCTQZjAgwAAAAkAwQATQZrAk8GawJP Bm8CTQZvAgwAAAAkAwQATQZ3Ak8GdwJPBnsCTQZ7AgwAAAAkAwQATQaDAk8GgwJPBocCTQaHAgwA AAAkAwQATQaPAk8GjwJPBpMCTQaTAgwAAAAkAwQATQabAk8GmwJPBp8CTQafAgwAAAAkAwQATQan Ak8GpwJPBqsCTQarAgwAAAAkAwQATQazAk8GswJPBrcCTQa3AgwAAAAkAwQATQa/Ak8GvwJPBsMC TQbDAgwAAAAkAwQATQbLAk8GywJPBs8CTQbPAgwAAAAkAwQATQbXAk8G1wJPBtsCTQbbAgwAAAAk AwQATQbjAk8G4wJPBucCTQbnAgwAAAAkAwQATQbvAk8G7wJPBvMCTQbzAgwAAAAkAwQATQb7Ak8G +wJPBv8CTQb/AgwAAAAkAwQATQYHA08GBwNPBgsDTQYLAwwAAAAkAwQATQYTA08GEwNPBhcDTQYX AwwAAAAkAwQATQYfA08GHwNPBiMDTQYjAwwAAAAkAwQATQYrA08GKwNPBi8DTQYvAwwAAAAkAwQA TQY3A08GNwNPBjsDTQY7AwwAAAAkAwQATQZDA08GQwNPBkcDTQZHAwwAAAAkAwQATQZPA08GTwNP BlMDTQZTAwwAAAAkAwQATQZbA08GWwNPBl8DTQZfAwwAAAAkAwQATQZnA08GZwNPBmsDTQZrAwwA AAAkAwQATQZzA08GcwNPBncDTQZ3AwwAAAAkAwQATQZ/A08GfwNPBoMDTQaDAwwAAAAkAwQATQaL A08GiwNPBo8DTQaPAwwAAAAkAwQATQaXA08GlwNPBpsDTQabAwwAAAAkAwQATQajA08GowNPBqcD TQanAwwAAAAkAwQATQavA08GrwNPBrMDTQazAwwAAAAkAwQATQa7A08GuwNPBr8DTQa/AwwAAAAk AwQATQbHA08GxwNPBssDTQbLAwwAAAAkAwQATQbTA08G0wNPBtcDTQbXAwwAAAAkAwQATQbfA08G 3wNPBuMDTQbjAwwAAAAkAwQATQbrA08G6wNPBu8DTQbvAwwAAAAkAwQATQb3A08G9wNPBvsDTQb7 AwwAAAAkAwQATQYDBE8GAwRPBgcETQYHBAwAAAAkAwQATQYPBE8GDwRPBhMETQYTBAwAAAAkAwQA TQYbBE8GGwRPBh8ETQYfBAwAAAAkAwQATQYnBE8GJwRPBisETQYrBAwAAAAkAwQATQYzBE8GMwRP BjcETQY3BAwAAAAkAwQATQY/BE8GPwRPBkMETQZDBAwAAAAkAwQATQZLBE8GSwRPBlAETQZQBAwA AAAkAwQATQZYBE8GWARPBlwETQZcBAwAAAAkAwQATQZkBE8GZARPBmgETQZoBAwAAAAkAwQATQZw BE8GcARPBnQETQZ0BAwAAAAkAwQATQZ8BE8GfARPBoAETQaABAwAAAAkAwQATQaIBE8GiARPBowE TQaMBAwAAAAkAwQATQaUBE8GlARPBpgETQaYBAwAAAAkAwQATQagBE8GoARPBqQETQakBAwAAAAk AwQATQasBE8GrARPBrAETQawBAwAAAAkAwQATQa4BE8GuARPBrwETQa8BAwAAAAkAwQATQbEBE8G xARPBsgETQbIBAwAAAAkAwQATQbQBE8G0ARPBtQETQbUBAwAAAAkAwQATQbcBE8G3ARPBuAETQbg BAwAAAAkAwQATQboBE8G6ARPBuwETQbsBAwAAAAkAwQATQb0BE8G9ARPBvgETQb4BAwAAAAkAwQA TQYABU8GAAVPBgQFTQYEBQwAAAAkAwQATQYMBU8GDAVPBhAFTQYQBQwAAAAkAwQATQYYBU8GGAVP BhwFTQYcBQwAAAAkAwQATQYkBU8GJAVPBigFTQYoBQwAAAAkAwQATQYwBU8GMAVPBjQFTQY0BQwA AAAkAwQATQY8BU8GPAVPBkAFTQZABQwAAAAkAwQATQZIBU8GSAVPBkwFTQZMBQwAAAAkAwQATQZU BU8GVAVPBlgFTQZYBQwAAAAkAwQATQZgBU8GYAVPBmQFTQZkBQwAAAAkAwQATQZsBU8GbAVPBnAF TQZwBQwAAAAkAwQATQZ4BU8GeAVPBnwFTQZ8BQwAAAAkAwQATQaEBU8GhAVPBogFTQaIBQwAAAAk AwQATQaQBU8GkAVPBpQFTQaUBQwAAAAkAwQATQacBU8GnAVPBqAFTQagBQwAAAAkAwQATQaoBU8G qAVPBqwFTQasBQwAAAAkAwQATQa0BU8GtAVPBrgFTQa4BQwAAAAkAwQATQbABU8GwAVPBsQFTQbE BQwAAAAkAwQATQbMBU8GzAVPBtAFTQbQBQwAAAAkAwQATQbYBU8G2AVPBtwFTQbcBQwAAAAkAwQA TQbkBU8G5AVPBugFTQboBQwAAAAkAwQATQbwBU8G8AVPBvQFTQb0BQwAAAAkAwQATQb8BU8G/AVP BgAGTQYABgwAAAAkAwQATQYIBk8GCAZPBgwGTQYMBgwAAAAkAwQATQYUBk8GFAZPBhgGTQYYBgwA AAAkAwQATQYgBk8GIAZPBiQGTQYkBgwAAAAkAwQATQYsBk8GLAZPBjAGTQYwBgwAAAAkAwQATQY4 Bk8GOAZPBjwGTQY8BgwAAAAkAwQATQZEBk8GRAZPBkgGTQZIBgwAAAAkAwQATQZQBk8GUAZPBlQG TQZUBgwAAAAkAwQATQZcBk8GXAZPBmAGTQZgBgwAAAAkAwQATQZoBk8GaAZPBmwGTQZsBgwAAAAk AwQATQZ0Bk8GdAZPBngGTQZ4BgwAAAAkAwQATQaABk8GgAZPBoQGTQaEBgwAAAAkAwQATQaMBk8G jAZPBpAGTQaQBgwAAAAkAwQATQaYBk8GmAZPBpwGTQacBgwAAAAkAwQATQakBk8GpAZPBqgGTQao BgwAAAAkAwQATQawBk8GsAZPBrQGTQa0BgwAAAAkAwQATQa8Bk8GvAZPBsAGTQbABgwAAAAkAwQA TQbIBk8GyAZPBswGTQbMBgwAAAAkAwQATQbUBk8G1AZPBtgGTQbYBgwAAAAkAwQATQbgBk8G4AZP BuQGTQbkBgwAAAAkAwQATQbsBk8G7AZPBvAGTQbwBgwAAAAkAwQATQb4Bk8G+AZPBvwGTQb8BgwA AAAkAwQATQYEB08GBAdPBggHTQYIBwwAAAAkAwQATQYQB08GEAdPBhQHTQYUBwwAAAAkAwQATQYc B08GHAdPBiAHTQYgBwwAAAAkAwQATQYoB08GKAdPBiwHTQYsBwwAAAAkAwQATQY0B08GNAdPBjgH TQY4BwwAAAAkAwQATQZAB08GQAdPBkQHTQZEBwwAAAAkAwQATQZMB08GTAdPBlAHTQZQBwwAAAAk AwQATQZYB08GWAdPBlwHTQZcBwwAAAAkAwQATQZkB08GZAdPBmgHTQZoBwwAAAAkAwQATQZwB08G cAdPBnQHTQZ0BwQAAAAtAQMABAAAAC0BBAAEAAAAAgEBAAQAAAACAQEABAAAAC0BAwAJAAAA+gIA AAIAAAAAAAAAIgAEAAAALQEIAAcAAAAbBFwGHQdBBWcFBAAAAC0BBAAEAAAA8AEIAAQAAAAtAQMA BAAAAAIBAQADAAAAHgAHAAAAFgRSBhMHSwVwBQQAAAACAQEABAAAAC0BBQATAAAAMgpvBdEFBQAE AAAAAAAACXAHTWVkaWEARQAuAC4AEgAuAAQAAAACAQEABAAAAAIBAQAEAAAALQEFABYAAAAyCs4F nwUHAAQAAAAAAAAJcAdHYXRld2F5AEEALgAXAC4AOwAuACcABAAAAC0BAQAEAAAAAgEBAAQAAAAn Af//BAAAAAIBAQAEAAAALQEDAAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQgABwAAABsEoAN6BZgC xAMEAAAALQEEAAQAAADwAQgABAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBJYDcAWhAs0DBAAA AAIBAQAQAAAA+wK9/wAAAAAAAJABAAAAAAQAACJBcmlhbAAAAQQAAAAtAQgAEwAAADIKowJEBAUA BAAAAAAAAAlwB01lZGlhADcAJQAlAA8AJQAEAAAAAgEBAAQAAAACAQEABAAAAC0BCAAWAAAAMgrw AhsEBwAEAAAAAAAACXAHR2F0ZXdheQA0ACUAEwAlAC8AJQAhAAQAAAACAQEABAAAAAIBAQAEAAAA LQEIABoAAAAyCj0DDgQKAAQAAAAAAAAJcAdDb250cm9sbGVyMAAlACUAEwAWACUADwAPACUAFgAV AAAA+wK9/wAAAAAAAJABAAAAAAQAABJUaW1lcyBOZXcgUm9tYW4ANAAEAAAALQEJAAQAAAACAQEA BAAAACcB//8EAAAAAgEBAAQAAAAtAQMACQAAAB0GIQDwAJcAWQEuBLcDBAAAAC0BAwAEAAAAAgEB AAMAAAAeAAcAAAAWBL4ECAU3BL8DBAAAAAIBAQAEAAAALQEFABEAAAAyCjoEvwMEAAQAAAAAAAAJ cAdNR0NQRQBBADwANwAOAAAAMgo6BLgEAgAEAAAAAAAACXAHID8XAC4ABAAAAAIBAQAEAAAAJwH/ /wQAAAACAQEABAAAAC0BAwAJAAAAHQYhAPAAlwDJAScBsgYEAAAALQEDAAQAAAACAQEAAwAAAB4A BwAAABYEtwFzCDABugYEAAAAAgEBAAQAAAAtAQUAEQAAADIKMwG6BgQABAAAAAAAAAlwB1BTVE43 ADcANAA8AAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAAtAQMACQAAAB0GIQDwAJcAyQEnAS4E BAAAAC0BAwAEAAAAAgEBAAMAAAAeAAcAAAAWBLcB7wUwATYEBAAAAAIBAQAEAAAALQEFABoAAAAy CjMBNgQKAAQAAAAAAAAJcAdJUCBuZXR3b3JrFwA3ABcALgAuABcAOwAuABwAKwAEAAAAAgEBAAQA AAAnAf//BAAAAAIBAQAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEKAAUAAAAUAmAC3QIFAAAAEwJC BUYBBAAAAC0BBAAEAAAA8AEKAAQAAAACAQEABAAAAAIBAQAEAAAAAgEBAAMAAAAeAAcAAAAWBCgE AQILA+oABAAAAAIBAQAEAAAALQEFABAAAAAyCg4DIAEDAAQAAAAAAAAJcAdSQVMAPAA3ADcABAAA AAIBAQAEAAAAAgEBAAQAAAAtAQUAEwAAADIKbQMEAQUABAAAAAAAAAlwB1EuOTMxAEEAFwAuAC4A LgAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQATAAAAMgrMAwYBBQAEAAAAAAAACXAHSC4yNDUAPAAX AC4ALgAuAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAkAAAD6AgAAEQAAAAAAAAAiAAQAAAAtAQoA BQAAABQC0QVHAgUAAAATAtEFQQUEAAAALQEEAAQAAADwAQoABAAAAC0BBgAJAAAA+gIAAAEAAAAA AAAAIgAEAAAALQEKAAoAAAAkAwMANQWwBTUF8gVnBdEFBAAAAC0BAwAEAAAALQEEAAQAAADwAQoA BAAAAC0BBgAJAAAA+gIAAAEAAAAAAAAAIgAEAAAALQEKAAoAAAAkAwMAUwLyBVMCsAUhAtEFBAAA AC0BAwAEAAAALQEEAAQAAADwAQoABAAAAAIBAQAEAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYE 0QUIBVAFegIEAAAAAgEBAAQAAAAtAQUAHwAAADIKUwWvAg0ABAAAAAAAAAlwB01lZGlhIHN0cmVh bXMARQAuAC4AEgAuABcAKgAXABwALgAuAEcAKgAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAJAAAA +gIAABEAAAAAAAAAIgAEAAAALQEKAAUAAAAUAsoFVAcFAAAAEwLFBfEIBAAAAC0BBAAEAAAA8AEK AAQAAAAtAQYACQAAAPoCAAABAAAAAAAAACIABAAAAC0BCgAKAAAAJAMDAGEH6wVgB6kFLwfLBQQA AAAtAQMABAAAAC0BBAAEAAAA8AEKAAQAAAACAQEABAAAAAIBAQAJAAAA+gIAAAYAAAAAAAAAIgAE AAAALQEKAAUAAAAUAqUDqwQFAAAAEwI7Bd0FBAAAAC0BBAAEAAAA8AEKAAQAAAACAQEABAAAAAIB AQAEAAAAAgEBAAMAAAAeAAcAAAAWBPsApAOaAJoCBAAAAAIBAQAEAAAALQEFABEAAAAyCp0AvgIE AAQAAAAAAAAJcAdJTkFQFwA8ADcANwAEAAAALQEBAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQA AAAtAQYABAAAAC0BBwAMAAAAJAMEAL0D0AG/A9ABvwPMAb0DzAEMAAAAJAMEAL0DxAG/A8QBvwPA Ab0DwAEMAAAAJAMEAL0DuAG/A7gBvwO0Ab0DtAEMAAAAJAMEAL0DrAG/A6wBvwOoAb0DqAEMAAAA JAMEAL0DoAG/A6ABvwOcAb0DnAEMAAAAJAMEAL0DlAG/A5QBvwOQAb0DkAEMAAAAJAMEAL0DiAG/ A4gBvwOEAb0DhAEMAAAAJAMEAL0DfAG/A3wBvwN4Ab0DeAEMAAAAJAMEAL0DcAG/A3ABvwNsAb0D bAEMAAAAJAMEAL0DZAG/A2QBvwNgAb0DYAEMAAAAJAMEAL0DWAG/A1gBvwNUAb0DVAEMAAAAJAME AL0DTAG/A0wBvwNIAb0DSAEMAAAAJAMEAL0DQAG/A0ABvwM8Ab0DPAEMAAAAJAMEAL0DNAG/AzQB vwMwAb0DMAEMAAAAJAMEAL0DKAG/AygBvwMkAb0DJAEMAAAAJAMEAL0DHAG/AxwBvwMYAb0DGAEM AAAAJAMEAL0DEAG/AxABvwMMAb0DDAEMAAAAJAMEAL0DBAG/AwQBvwMAAb0DAAEMAAAAJAMEAL0D 9wC/A/cAvwPzAL0D8wAMAAAAJAMEAL0D6wC/A+sAvwPnAL0D5wAMAAAAJAMEAL0D3wC/A98AvwPb AL0D2wAMAAAAJAMEAL0D0wC/A9MAvwPPAL0DzwAMAAAAJAMEAL0DxwC/A8cAvwPDAL0DwwAMAAAA JAMEAL0DuwC/A7sAvwO3AL0DtwAMAAAAJAMEAL0DrwC/A68AvwOrAL0DqwAMAAAAJAMEAL0DowC/ A6MAvwOfAL0DnwAMAAAAJAMEAL0DlwC/A5cAvwOTAL0DkwAMAAAAJAMEAL0DiwC/A4sAvwOHAL0D hwAMAAAAJAMEAL0DfwC/A38AvwN7AL0DewAMAAAAJAMEAL0DcwC/A3MAvwNvAL0DbwAMAAAAJAME AL0DZwC/A2cAvwNjAL0DYwAMAAAAJAMEAL0DWwC/A1sAvwNXAL0DVwAMAAAAJAMEAL0DTwC/A08A vwNLAL0DSwAMAAAAJAMEAL0DQwC/A0MAvwM/AL0DPwAMAAAAJAMEAL0DNwC/AzcAvwMzAL0DMwAM AAAAJAMEAL0DKwC/AysAvwMnAL0DJwAEAAAALQEDAAQAAAAtAQQACQAAAPoCAAACAAAAAAAAACIA BAAAAC0BCgAFAAAAFAIhAL4DBQAAABMCPgCnAwQAAAAtAQQABAAAAPABCgAJAAAA+gIAAAIAAAAA AAAAIgAEAAAALQEKAAUAAAAUAiEAvgMFAAAAEwI+ANUDBAAAAC0BBAAEAAAA8AEKAAkAAAD6AgAA AgAAAAAAAAAiAAQAAAAtAQoABQAAABQC0AG+AwUAAAATArMB1QMEAAAALQEEAAQAAADwAQoACQAA APoCAAACAAAAAAAAACIABAAAAC0BCgAFAAAAFALQAb4DBQAAABMCswGnAwQAAAAtAQQABAAAAPAB CgAEAAAAAgEBAAQAAAAtAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAAC AAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAACgAAAACAAAAAEAAABIAAAA DwAAAFAAAAAEAAAAXAAAAAUAAABkAAAABgAAAGwAAAALAAAAdAAAABAAAAB8AAAADAAAAIQAAAAC AAAA5AQAAB4AAAABAAAAAAABAAMAAAAAUAAAAwAAAAEAAAADAAAAAQAAAAsAAAAAAAAACwAAAAAA AAAMEAAAAgAAAB4AAAABAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAAkAEAABIAAAABAAAAmAAAAAIAAACgAAAAAwAAAKwAAAAEAAAAuAAAAAUAAADE AAAABgAAANAAAAAHAAAA3AAAAAgAAADwAAAACQAAAAwBAAASAAAAGAEAAAoAAABAAQAACwAAAEwB AAAMAAAAWAEAAA0AAABkAQAADgAAAHABAAAPAAAAeAEAABAAAACAAQAAEwAAAIgBAAACAAAA5AQA AB4AAAABAAAAAPRBAB4AAAABAAAAAEBIAB4AAAADAAAAbW0AAB4AAAABAAAAAABkAB4AAAABAAAA AAAAAB4AAAALAAAAbm9ybWFsLmRvdACgHgAAABEAAABKZWFuLUNsYXVkZSBEYW5nAAAAAB4AAAAC AAAAMwBpdB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFdpbmRvd3MgOTUASABAAAAAAEgnrQEA AABAAAAAAJLBkFvXuQFAAAAAALgIbFVFvgFAAAAAAPBWQzNGvgEDAAAAAQAAAAMAAAAOAAAAAwAA AFUAAAADAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8BCQIAAAAAAMAAAAAAAABGFQAAAEltYWdl IE1pY3Jvc29mdCBXb3JkAAoAAABNU1dvcmREb2MADwAAAFdvcmQuUGljdHVyZS42APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAAAAAAAAAAAAIAFpFAABEUgAAUScA AKQuAAAAAAAAAAAAAAAAAAAAAAAAIAMAACADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3KVoAFfgDAQA AAAAZQAAAAAAAAAAAAAAAAMAAOcFAAAPMgAAAAAAAAAAAAAAAAAAAAAAAGcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAH8CAAAAAAAAAAAAAAAkAABsAQAAACQAAGwBAABsJQAAAAAAAGwlAAAAAAAALCYA AAAAAAAsJgAAAAAAACwmAAAUAAAAViYAAAAAAABWJgAAAAAAAFYmAAAAAAAAViYAAAAAAABWJgAA AAAAAFYmAAAQAAAAZiYAABYAAABWJgAAAAAAAGAxAAAxAAAAfCYAAAAAAAB8JgAAAAAAAHwmAAAA AAAAfCYAAAAAAAB8JgAAAAAAAHIqAAAAAAAAcioAAAAAAAByKgAAAAAAAHIqAAACAAAAdCoAAAAA AAB0KgAAAAAAAHQqAAA2AAAAqioAAEwDAAD2LQAATAMAAEIxAAAeAAAAkTEAAFgAAADpMQAAJgAA AGAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwmAAAAAAAAcioAAAAAAAAAAA0ADwACAAMAfCYAAPYD AAByKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAByKgAAAAAAAHIqAAAAAAAAYDEAAAAAAAByKgAAAAAA AGwlAAAAAAAAbCUAAAAAAAB8JgAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8JgAAAAAAAHIqAAAAAAAA cioAAAAAAAByKgAAAAAAAHIqAAAAAAAAbCUAAMAAAAB8JgAAAAAAACwmAAAAAAAAfCYAAAAAAABy KgAAAAAAAAAAAAAAAAAAYJpEuDRGvgFAJgAACAAAAEgmAAAOAAAAbCUAAAAAAABsJQAAAAAAAGwl AAAAAAAAbCUAAAAAAAByKgAAAAAAAHIqAAAAAAAAcioAAAAAAAByKgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgIDVNlbmRfQ2FsbA0NQXV0aF9DYWxsX1NldHVwDQ1DYWxsIFByb2NlZWRpbmcNDVNlbGVj dCBSb3V0ZQ0NQW5hbHlzZSBJbmZvDQ1Db2xsZWN0IEluZm8NDUF1dGhfT3JpZ19BdHQNDUNhbGwg UHJvY2VlZGluZw0NU2V0dXANDUFSUQ0NQUNGDQ1TZXR1cA0NRFJRL0RDRiBEaXNlbmdhZ2UgUmVx dWVzdC9Db25maXJtDQ1BUlEvQUNGIEFkbWlzc2lvbiBSZXF1ZXN0L0NvbmZpcm0NDVJBUyBtZXNz YWdlcw0NSC4yMjUuMC9RLjkzMSBtZXNzYWdlcw0NSC4yNDUgbWVzc2FnZXMNDU9fTnVsbA0NT19B Y3RpdmUNDVRlcm0gQ2FwIFNldCBBY2sNDVRlcm0gQ2FwIFNldA0NUmVsZWFzZSBDb21wbGV0ZQ0N RW5kIFNlc3Npb24gQ29tbWFuZA0NRW5kIFNlc3Npb24gQ29tbWFuZA0NTWVkaWEgQ2hhbm5lbA0N T3BlbiBMb2dpY2FsIENoYW5uZWwgQWNrDQ1PcGVuIExvZ2ljYWwgQ2hhbm5lbA0NQ29ubmVjdA0N RENGDQ1EQ0YNDURSUQ0NRFJRDQ1Db252ZXJzYXRpb24NDVRlcm0gQ2FwIFNldCBBY2sNDVRlcm0g Q2FwIFNldA0NTWVkaWEgQ2hhbm5lbA0NT3BlbiBMb2dpY2FsIENoYW5uZWwgQWNrDQ1PcGVuIExv Z2ljYWwgQ2hhbm5lbA0NQWxlcnRpbmcNDU9fQWxlcnRpbmcNDU9fTlVMTA0NVGVybSBCDQ1UZXJt IEENDUdLDQ1BQ0YNDUFSUQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGwChAQCkwE6lwE6m QhenLhCokB+pjgCqAACrCQAAADAAAQEyMAAAAQAmAA0vzDP5BwEAAAAAAPgHAAAAAAAABQACABgA GAAAAAAAAAAAADAAAQEnMAAAAQAmAA0vhS/5BwEAAAAAAPgHAAAAAAAABQACABgAGAAAAAAAAAAA ADAAAQHOLwAAAQAmAC86gCUBAGEJAAAAAAAAYAkAAAAABQAAABoAGAAAAAAAAAAAADAAAQExMAAA AQAmAD46DDABAEkDAAAAAAAASAMAAAAADwAAABoAGAAAAAAAAAAAADAAAQHPLwAAAQAmAE062zMC ACIMAQAAAAAAIQwAAAAABQAAABoAGAAAAAAAAAAAADIAAQEbMAAAAgQoAPY27y6gBi0BAAAAAAUA AAD///8A////AAEAAAAAAAAAAAAUAAAAMgABARwwAAACBCgA9jYPLaAGLQEAAAAABQAAAP///wD/ //8AAQAAAAAAAAAAABQAAAAyAAEB2S8AAAIEKAB9HPYkKQTFAAAAAAAPAAUA////AAAAAAAAAAAA AAAAAAAAFAAAADIAAQEdMAAAAgQoAPY2TSugBi0BAAAAAAUAAAD///8A////AAEAAAAAAAAAAAAU AAAAMgABAR4wAAACBCgA9jZtKaAGLQEAAAAABQAAAP///wD///8AAQAAAAAAAAAAABQAAAAyAAEB ITAAAAIEKAD2No0noAYtAQAAAAAFAAAA////AP///wABAAAAAAAAAAAAFAAAADIAAQEgMAAAAgQo APY22iWgBi0BAAAAAAUAAAD///8A////AAEAAAAAAAAAAAAUAAAAMAABAQUwAAABACYA6yPYMhQL AQATCwAAAAAAAAAAAAAPAAAAFQAUAAAAAAAAAAAAMgABAdovAAACBCgAYyfpMSkExQAAAAAADwAF AP///wAAAAAAAAAAAAAAAAAAABQAAAAyAAEB1S8AAAIEKADtJpkueQXFAAAAAAAPAAUA////AAAA AAAAAAAAAAAAAAAAFAAAADIAAQHTLwAAAgQoAL8ooi+JAcUAAAAAAA8ABQD///8AAAAAAAAAAAAA AAAAAAAUAAAAMgABAdQvAAACBCgAvyieMIkBxQAAAAAADwAFAP///wAAAAAAAAAAAAAAAAAAABQA AAAwAAEB3S8AAAEAJgD6I3cwFAsBABMLAAAAAAAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEB3i8A AAEAJgD6I48xIwsBAAAAAAAiCwAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEB3y8AAAEAJgDrI3sv MgsBAAAAAAAxCwAAAAAAAA8AAAAVABQAAAAAAAAAAAAyAAEB1i8AAAIEKADpG8IjeQXFAAAAAAAP AAUA////AAAAAAAAAAAAAAAAAAAAFAAAADAAAQEAMAAAAQAmABQZ1iXaCgEA2QoAAAAAAAAAAAAA DwAAABUAFAAAAAAAAAAAADAAAQEkMAAAAQAmAOsjriQbEwEAAAAAABoTAAAAAAAABQACABgAGAAA AAAAAAAAADIAAQEpMAAAAgQoABIqw0vGDTwBAAAAAAUABQD///8A////AAEAAAAAAAAAAAAUAAAA MgABASowAAACBCgABRnDS8YNPAEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAwAAEB/C8A AAEAJgARL+wgAQBxKAAAAAAAAHAoAAAAAAUAAAAYABgAAAAAAAAAAAAwAAEB+y8AAAEAJgDtIwgh AQBkKAAAAAAAAGMoAAAAAAUAAAAYABgAAAAAAAAAAAAwAAEB+i8AAAEAJgAXGdAgAQCrKAAAAAAA AKooAAAAAAUAAAAYABgAAAAAAAAAAAAwAAEBKDAAAAEAJgAjGbBKaAIBAAAAAABnAgAAAAAAACgA AAAWABQAAAAAAAAAAAAyAAEBKzAAAAIEKABrHAFKZAY8AQAAAAAFAAUA////AP///wABAAAAAAAA AAAAFAAAADAAAQEsMAAAAQAmANwjsEpoAgEAAAAAAGcCAAAAAAAABQAAABUAFAAAAAAAAAAAADIA AQEtMAAAAgQoACQnAUpwCTwBAAAAAAUABQD///8A////AAEAAAAAAAAAAAAUAAAAMAABAS4wAAAB ACYA7DGwSmgCAQAAAAAAZwIAAAAAAAAFAAIAFQAUAAAAAAAAAAAAMgABAS8wAAACBCgANDUBSnAJ PAEAAAAABQAFAP///wD///8AAQAAAAAAAAAAABQAAAAwAAEBIzAAAAEAJgBNOhlBAQB1BAAAAAAA AHQEAAAAAAUAAAAaABgAAAAAAAAAAAAyAAEBHzAAAAIEKAD2NpxFoAYtAQAAAAAFAAAA////AP// /wABAAAAAAAAAAAAFAAAADAAAQElMAAAAQAmAA0vMkb5BwEAAAAAAPgHAAAAAAAABQACABgAGAAA AAAAAAAAADIAAQEwMAAAAgQoAPY2GkCgBi0BAAAAAAUAAAD///8A////AAEAAAAAAAAAAAAUAAAA MAABASYwAAABACYADS+wQPkHAQAAAAAA+AcAAAAAAAAFAAIAGAAYAAAAAAAAAAAAMgABAeAvAAAC BCgAbBwEO3kFxQAAAAAADwAFAP///wAAAAAAAAAAAAAAAAAAABQAAAAyAAEB4i8AAAIEKADYJQg6 eQXFAAAAAAAPAAUA////AAAAAAAAAAAAAAAAAAAAFAAAADIAAQHmLwAAAgQoALwlTkWxBcUAAAAA AA8ABQD///8AAAAAAAAAAAAAAAAAAAAUAAAAMgABAecvAAACBCgAyRs2RJEGxQAAAAAADwAFAP// /wAAAAAAAAAAAAAAAAAAABQAAAAyAAEB6C8AAAIEKADcJAJDkQbFAAAAAAAPAAUA////AAAAAAAA AAAAAAAAAAAAFAAAADIAAQHpLwAAAgQoAO8jij4BB8UAAAAAAA8ABQD///8AAAAAAAAAAAAAAAAA AAAUAAAAMgABAesvAAACBCgAnBs0PQEHxQAAAAAADwAFAP///wAAAAAAAAAAAAAAAAAAABQAAAAy AAEB7S8AAAIEKAAwJTg8PQbFAAAAAAAPAAUA////AAAAAAAAAAAAAAAAAAAAFAAAADIAAQHvLwAA AgQoADAl6T8pBMUAAAAAAA8ABQD///8AAAAAAAAAAAAAAAAAAAAUAAAAMgABAfAvAAACBCgAeChi R4kBxQAAAAAADwAFAP///wAAAAAAAAAAAAAAAAAAABQAAAAyAAEB8S8AAAIEKAAVIWJHiQHFAAAA AAAPAAUA////AAAAAAAAAAAAAAAAAAAAFAAAADIAAQHyLwAAAgQoAHgoSkaJAcUAAAAAAA8ABQD/ //8AAAAAAAAAAAAAAAAAAAAUAAAAMgABAfMvAAACBCgAFSFKRokBxQAAAAAADwAFAP///wAAAAAA AAAAAAAAAAAAABQAAAAwAAEB9S8AAAEAJgAjGV0/6xUBAAAAAADqFQAAAAAAACgAAAAVABQAAAAA AAAAAAAwAAEB9i8AAAEAJgAUGf9G2goBAAAAAADZCgAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEB 9y8AAAEAJgAyGSZI5woBAOYKAAAAAAAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEB+C8AAAEAJgDr Iw5HFAsBABMLAAAAAAAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEB+S8AAAEAJgDrIyZIBQsBAAAA AAAECwAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEBCDAAAAEAJgAUGcw62goBAAAAAADZCgAAAAAA AA8AAgAVABQAAAAAAAAAAAAwAAEBCTAAAAEAJgDrI8w6IwsBAAAAAAAiCwAAAAAAAA8AAgAVABQA AAAAAAAAAAAwAAEBCjAAAAEAJgAjGcg7ywoBAMoKAAAAAAAAAAAAAA8AAgAVABQAAAAAAAAAAAAw AAEBCzAAAAEAJgDrI8g7FAsBABMLAAAAAAAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBDDAAAAEA JgAjGfw8ywoBAAAAAADKCgAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBDTAAAAEAJgDcI/w8MgsB AAAAAAAxCwAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBDjAAAAEAJgAjGfg9ywoBAMoKAAAAAAAA AAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBDzAAAAEAJgDrI/g9IwsBACILAAAAAAAAAAAAAA8AAgAV ABQAAAAAAAAAAAAwAAEBEDAAAAEAJgAUGa1A2goBANkKAAAAAAAAAAAAAA8AAAAVABQAAAAAAAAA AAAwAAEBETAAAAEAJgDrI61AFAsBABMLAAAAAAAAAAAAAA8AAAAVABQAAAAAAAAAAAAwAAEBEjAA AAEAJgAUGcZD2goBAAAAAADZCgAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBEzAAAAEAJgDrI8ZD IwsBAAAAAAAiCwAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBFDAAAAEAJgDrIy5GFAsBAAAAAAAT CwAAAAAAAA8AAAAVABQAAAAAAAAAAAAwAAEBFTAAAAEAJgAUGS5G2goBAAAAAADZCgAAAAAAAA8A AAAVABQAAAAAAAAAAAAwAAEBFjAAAAEAJgAUGfpE2goBANkKAAAAAAAAAAAAAA8AAgAVABQAAAAA AAAAAAAwAAEBFzAAAAEAJgDcI/pEMgsBADELAAAAAAAAAAAAAA8AAgAVABQAAAAAAAAAAAAyAAEB GTAAAAIEKACrIGtB5QZRAQAAAAAPAAAA////AP///wABAAAAAAAAAAAAFAAAADAAAQEEMAAAAQAm ACMZaznrFQEA6hUAAAAAAAAAAAAAKAAAABUAFAAAAAAAAAAAADIAAQHhLwAAAgQoAOclXzV5BcUA AAAAAA8ABQD///8AAAAAAAAAAAAAAAAAAAAUAAAAMgABAeMvAAACBCgALxwrNHkFxQAAAAAADwAF AP///wAAAAAAAAAAAAAAAAAAABQAAAAwAAEB5C8AAAEAJgAjGQs12goBANkKAAAAAAAAAAAAAA8A AgAVABQAAAAAAAAAAAAwAAEB5S8AAAEAJgAjGSM22goBAAAAAADZCgAAAAAAAA8AAgAVABQAAAAA AAAAAAAyAAEB6i8AAAIEKADPJac4AQfFAAAAAAAPAAUA////AAAAAAAAAAAAAAAAAAAAFAAAADIA AQHsLwAAAgQoAMclczcBB8UAAAAAAA8ABQD///8AAAAAAAAAAAAAAAAAAAAUAAAAMgABAe4vAAAC BCgAOBxbNj0GxQAAAAAADwAFAP///wAAAAAAAAAAAAAAAAAAABQAAAAwAAEB/i8AAAEAJgD6Iws1 FAsBABMLAAAAAAAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEB/y8AAAEAJgD6IyM2IwsBAAAAAAAi CwAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEBATAAAAEAJgD6Izs3FAsBABMLAAAAAAAAAAAAAA8A AgAVABQAAAAAAAAAAAAwAAEBAjAAAAEAJgAjGVM42goBAAAAAADZCgAAAAAAAA8AAgAVABQAAAAA AAAAAAAwAAEBAzAAAAEAJgD6I1M4IwsBAAAAAAAiCwAAAAAAAA8AAgAVABQAAAAAAAAAAAAwAAEB GDAAAAEAJgAjGTs32goBANkKAAAAAAAAAAAAAA8AAgAVABQAAAAAAAAAAAAyAAEB9C8AAAIEKADI HAEzKQTFAAAAAAAPAAUA////AAAAAAAAAAAAAAAAAAAAFAAAADIAAQEaMAAAAgQoAPY2RTOgBi0B AAAAAAUAAAD///8A////AAEAAAAAAAAAAAAUAAAAMAABAQYwAAABACYAFBnFM9oKAQDZCgAAAAAA AAAAAAAPAAAAFQAUAAAAAAAAAAAAMAABAQcwAAABACYA6yPFMyMLAQAiCwAAAAAAAAAAAAAPAAAA FQAUAAAAAAAAAAAAMgABASIwAAACBCgA9jZFJKAGLQEAAAAABQAAAP///wD///8AAAAAAAAAAAAA ABQAAAAyAAEB0C8AAAIEKAAoLeEfgQMZAQAAAAAPAAUA////AAAAAAAAAAAAAAAAAAAAFAAAADIA AQHSLwAAAgQoAIIX0h9lAxkBAAAAAA8ABQD///8AAAAAAAAAAAAAAAAAAAAUAAAAMgABAdEvAAAC BCgA4iLwH/kBGQEAAAAADwAFAP///wAAAAAAAAAAAAAAAAAAABQAAAAwAAEB/S8AAAEAJgAUGaQk 2goBAAAAAADZCgAAAAAAAA8AAAAVABQAAAAAAAAAAAAwAAEB3C8AAAEAJgAUGYwj2goBANkKAAAA AAAAAAAAACgAAAAWABQAAAAAAAAAAAAwAAEB2y8AAAEAJgAUGXQi3AoBAAAAAADbCgAAAAAAACgA AAAWABQAAAAAAAAAAAAyAAEB1y8AAAIEKAAVIcgiiQHFAAAAAAAPAAUA////AAAAAAAAAAAAAAAA AAAAFAAAADIAAQHYLwAAAgQoABUhlCGJAcUAAAAAAA8ABQD///8AAAAAAAAAAAAAAAAAAAAUAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAQMAAGYDAABnAwAAcQMAAHID AACCAwAAgwMAAJMDAACUAwAAoQMAAKIDAACvAwAAsAMAAL0DAAC+AwAAzAMAAM0DAADdAwAA3gMA AOQDAADlAwAA6QMAAOoDAADuAwAA7wMAAPUDAAD2AwAAGAQAABkEAAA7BAAAPAQAAEkEAABKBAAA YQQAAGIEAABxBAAAcgQAAHkEAAB6BAAAgwQAAIQEAACVBAAAlgQAAKMEAACkBAAAtQQAALYEAADK BAAAywQAAN8EAADgBAAA7gQAAO8EAAAIBQAACQUAAB4FAAAfBQAAJwUAACgFAAAsBQAALQUAADEF AAAyBQAANgUAADcFAAA7BQAAPAUAAEkFAABKBQAAWwUAAFwFAABpBQAAagUAAHgFAAB5BQAAkgUA AJMFAACoBQAAqQUAALIFAACzBQAAvgUAAL8FAADGBQAAxwUAAM0FAADPBQAA1gUAANcFAADZBQAA 2wUAAN8FAADgBQAA5AUAAOYFAAAA+QD1APUA8QD1APUA9QD1APEA8QDxAPEA8QD1APUA9QD1APUA 9QD1APEA8QDxAPEA8QDxAPEA8QDxAPEA8QDxAPEA9QDxAPEA8QDxAPEA8QD1APUA9QD1APUA8QDx AAAAAAZdAgBjDgAABl0CAGMUAAALdQFEBAAAAABhAAQAX+YFAADnBQAAaRkAAAD+AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACdQECAAMAAAEDAABnAwAAcQMAAHIDAACCAwAA gwMAAJMDAACUAwAAoQMAAKIDAACvAwAAsAMAAL0DAAC+AwAAzAMAAM0DAADdAwAA3gMAAOQDAADl AwAA6QMAAOoDAADuAwAA7wMAAPUDAAD2AwAAGAQAABkEAAA7BAAAPAQAAEkEAABKBAAAYQQAAGIE AABxBAAAcgQAAHkEAAB6BAAAgwQAAIQEAACVBAAAlgQAAKMEAACkBAAA+wABTycbAfsAAU8nGwH4 AAFzBuQA9gAAAAAAAPgAAXMG5AD2AAAAAAAA+AABAwSjAPYAAAAAAAD4AAFzBuQA9gAAAAAAAPgA AXMG5AD2AAAAAAAA+AABcwbkAPYAAAAAAAD4AAFzBuQA9gAAAAAAAPgAAQYEowD2AAAAAAAA+AAB UwWjAPYAAAAAAAD2AAFmAaMA9gAAAAAAAPYAAWYBowD2AAAAAAAA+AABUwWjAPYAAAAAAAD2AAGf DeQA9gAAAAAAAPYAAaIN5AD2AAAAAAAA9gABQQbkAPYAAAAAAAD2AAFKCeQA9gAAAAAAAPYAAUoJ 5AD2AAAAAAAA+AABcwbkAPYAAAAAAAD4AAFzBuQA9gAAAAAAAPgAAVMFowD2AAAAAAAA+AABUwWj APYAAAAAAAAAAAAAAQAAAAIAAAUBAAQAABTwAAAAACykBAAAtQQAALYEAADKBAAAywQAAN8EAADg BAAA7gQAAO8EAAAIBQAACQUAAB4FAAAfBQAAJwUAACgFAAAsBQAALQUAADEFAAAyBQAANgUAADcF AAA7BQAAPAUAAEkFAABKBQAAWwUAAFwFAABpBQAAagUAAHgFAAB5BQAAkgUAAJMFAACoBQAAqQUA ALIFAACzBQAAvgUAAL8FAADGBQAAxwUAAM4FAADPBQAA1gUAANcFAADaBQAA/QABjQWjAPsAAAAA AAD9AAFsBqMA+wAAAAAAAP0AAWwGowD7AAAAAAAA/QAB3QajAPsAAAAAAAD9AAHdBqMA+wAAAAAA AP0AARgGowD7AAAAAAAA/QABAwSjAPsAAAAAAAD9AAFjAaMA+wAAAAAAAP0AAWMBowD7AAAAAAAA /QABYwGjAPsAAAAAAAD9AAFjAaMA+wAAAAAAAP0AAa8G5AD7AAAAAAAA/QABUwWjAPsAAAAAAAD9 AAFWBaMA+wAAAAAAAP0AAd0GowD7AAAAAAAA/QAB2gajAPsAAAAAAAD9AAEYBqMA+wAAAAAAAP0A AQMEowD7AAAAAAAA/QABcwbkAPsAAAAAAAD9AAFzBuQA+wAAAAAAAP0AAVsD5AD7AAAAAAAA/QAB PgPkAPsAAAAAAAD9AAHUAeQAAAAAAQAAAAIAAAUBLdoFAADbBQAA3wUAAOAFAADkBQAA5QUAAOYF AADnBQAA/gAAAAAAAPsAAWMBowD+AAAAAAAA+wABYwGjAP4AAAAAAAD+AAAAAAAA9gABTycbAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAQAABTwAAAAAAACAAAFAQABAAAHDgATAAgAAQBLAA8AAAAAABwAAEDx/wIAHAAG Tm9ybWFsAAIAAAAGAGEMBGMYACAAAUABAAIAIAAHVGl0cmUgMQAACAABABXgARbwAAIAVYEoAAJA AQDyACgAB1RpdHJlIDIAAAsAAgARbgQV8AAWeAAABQBVgWMWAAAoAANAAQASASgAB1RpdHJlIDMA AAsAAwARzQUVeAAWeAAABQBeAWMWAAAAAAAAAAAAAAAAAAAeAEFA8v+hAB4AEVBvbGljZSBwYXIg ZOlmYXV0AAAAAAAAAAAAAAAAIgD+TwEB8gAiAA5SZXRyYWl0Tm9ybWFsMgAFAA8AEW4EAAAAIgAc QAEAAgEiAA5SZXRyYWl0IG5vcm1hbAAFABAAEcQCAAAAIgD+T/EAEgEiAA5SZXRyYWl0Tm9ybWFs MwAFABEAERgGAAAAJgAgQAEAIgEmAAxQaWVkIGRlIHBhZ2UADAASAA8IAALTEm8jAQIAAAAAAAAL AAAAHAAAAC0AAAA7AAAASQAAAFcAAABmAAAAdwAAAH4AAACDAAAAiAAAAI8AAACyAAAA1QAAAOMA AAD7AAAACwEAABMBAAAdAQAALwEAAD0BAABPAQAAZAEAAHkBAACIAQAAogEAALgBAADBAQAAxgEA AMsBAADQAQAA1QEAAOMBAAD1AQAAAwIAABICAAAsAgAAQgIAAEwCAABYAgAAYAIAAGgCAABwAgAA dAIAAHkCAAB+AgAAgQIAAAAAAADnAgAADgAABgAADAD/////AQAEIP//AQAAAAAA5wIAAAAAAAAA AAADAADmBQAAaRkAAA0ADgAAAwAApAQAANoFAADnBQAADwAQABEAAQAAAAIAAAADAAAABAAAAAUA AAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAA ABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA IgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAw AAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAA AE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAA WwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAADnAgAAHQYAAAAATQYA AAAAfQYAAAAArQYAAAAA3QYAAAAADQcAAAEAPwcAAAEAcQcAAAEAowcAAAEA1QcAAAEABwgAAAEA OQgAAAEAawgAAAAAmwgAAAEAzQgAAAEA/wgAAAEAMQkAAAEAYwkAAAAAkwkAAAAAwwkAAAAA8wkA AAEAJQoAAAAAVQoAAAAAhQoAAAEAtwoAAAEA6QoAAAAAGQsAAAAASQsAAAAAeQsAAAAAqQsAAAEA 2wsAAAAACwwAAAEAPQwAAAAAbQwAAAEAnwwAAAAAzwwAAAEAAQ0AAAAAMQ0AAAEAYw0AAAAAkw0A AAEAxQ0AAAEA9w0AAAEAKQ4AAAEAWw4AAAEAjQ4AAAEAvw4AAAEA8Q4AAAEAIw8AAAEAVQ8AAAEA hw8AAAEAuQ8AAAEA6w8AAAEAHRAAAAAATRAAAAAAfRAAAAAArRAAAAAA3RAAAAAADREAAAAAPREA AAAAbREAAAAAnREAAAAAzREAAAAA/REAAAAALRIAAAAAXRIAAAAAjRIAAAAAvRIAAAAA7RIAAAAA HRMAAAAATRMAAAAAfRMAAAAArRMAAAAA3RMAAAAADRQAAAEAPxQAAAAAbxQAAAEAoRQAAAEA0xQA AAAAAxUAAAAAMxUAAAEAZRUAAAEAlxUAAAEAyRUAAAAA+RUAAAAAKRYAAAAAWRYAAAAAiRYAAAAA uRYAAAAA6RYAAAEAGxcAAAEATRcAAAAAfRcAAAAArRcAAAEA3xcAAAEAERgAAAEAQxgAAAEAdRgA AAAApRgAAAAA1RgAAAAABRkAAAEANxkAAAEA/0BIUCBMYXNlckpldCA0MDAwIFBTAExQVDE6AFBT Q1JJUFQASFAgTGFzZXJKZXQgNDAwMCBQUwBIUCBMYXNlckpldCA0MDAwIFBTAAAAAAAAAAAAAAAA AAAEAwSUALgCH3cAAAEACQCaCzMIZAABAAcAWAIBAAIAWAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAgAAADAEgAAyBkAAAEAAAAAAAAAAQAAAAIAAAAAAAAAAAAAAAAAAAAA AAAAguRrvWc6a2z8tgUAAgABAAAAAAABAAAAAAACAAIAAQBSAwAAwgEAAAAAAAAAAGQAAAAAAAMA //8DAP//AQD//wAA//8BAP//AAD//wAA//8AAP//AQD//wEA//8AAP//AQD//wEA//8AAP//AAD/ /wAA//8AAP//AQD//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ /1BhZ2UgcGVyc29ubmFsaXPpZSAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFhDAAC0QwAAAAAAAFBhZ2UgcGVyc29ubmFsaXPpZSAyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhDAAC0QwAAAAAAAFBhZ2UgcGVyc29ubmFs aXPpZSAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhDAAC0 QwAAAAAAAAAAAAAAAAAASFAgTGFzZXJKZXQgNDAwMCBQUwAAAAAAAAAAAAAAAAAABAMElAC4Ah93 AAABAAkAmgszCGQAAQAHAFgCAQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIAAAAwBIAAMgZAAABAAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAILka71nOmts /LYFAAIAAQAAAAAAAQAAAAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP//AwD//wEA//8A AP//AQD//wAA//8AAP//AAD//wEA//8BAP//AAD//wEA//8BAP//AAD//wAA//8AAP//AAD//wEA //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9QYWdlIHBlcnNv bm5hbGlz6WUgMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABY QwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAAAAAAAA AAAAAAOAAQABAAAAAQAAAAsAAQABAAEAAAAAAB8AAQAAADEAFRaQAQAAVGltZXMgTmV3IFJvbWFu AAwWkAECAFN5bWJvbAALJpABAABBcmlhbAAiAAQAAwOMGFYMxAIAAKkBAAAAADCsMQbQtDGmAAAA AAMADAAAAA4AAABVAAAAAQABAAAABACDAAEAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAIQNWDAAA JgAAAAAAAAACbW0QSmVhbi1DbGF1ZGUgRGFuZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcBAAAIAQAACQEA AAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAA GAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAD+////JAEAADIBAAAm AQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAAP7////+////MwEAADQB AAA1AQAANgEAADcBAAA4AQAAOQEAADoBAABTAQAAPAEAAD0BAAA+AQAAPwEAAEABAABBAQAAQgEA AEMBAABEAQAARQEAAEYBAABHAQAA/v///0kBAABKAQAASwEAAEwBAABNAQAATgEAAE8BAABQAQAA UQEAAFIBAAD+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////CABaRURSAAABAAkAAAM7VAAACgA9AAAAAAAUAAAAJgYPAB4A /////wQAFAAAAFdvcmQOAE1pY3Jvc29mdCBXb3JkBQAAAAsCAAAAAAUAAAAMAm8TYhANAAAA+wIA AAAAAAAAAAAAAAAAAAAAAAEADAQAAAAtAQAABAAAAAIBAQAVAAAA+wKc/wAAAAAAAJABAAAAAAQA ABJUaW1lcyBOZXcgUm9tYW4AawEEAAAALQEBAAUAAAAJAgAAAAAEAAAAAgEBAAQAAAACAQEABAAA AC0BAQAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAACAAAAAAAAACIABAAAAC0BAgAFAAAAFAJ5Ao0O BQAAABMCSwaNDgkAAAD6AgAAAAAAAAAAAAAiAAQAAAAtAQMABAAAAPABAgAHAAAA/AIAAAAAAAAA AAQAAAAtAQIACQAAAPoCAAABAAAAAAAAACIABAAAAC0BBAAKAAAAJAMDAKQORAZ2DkQGjQ5hBgcA AAD8AgAA////AAAABAAAAC0BBQAEAAAALQEDAAQAAADwAQQABAAAAAIBAQAEAAAAAgEBAAkAAAD6 AgAAAgAAAAAAAAAiAAQAAAAtAQQABQAAABQCdAiaDgUAAAATAmwNmg4EAAAALQEDAAQAAADwAQQA BAAAAC0BAgAJAAAA+gIAAAEAAAAAAAAAIgAEAAAALQEEAAoAAAAkAwMAsQ5lDYMOZQ2aDoINBAAA AC0BBQAEAAAALQEDAAQAAADwAQQABAAAAAIBAQAEAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYE jwCOCikAKAkEAAAAAgEBABAAAAD7Aq3/AAAAAAAAkAEAAAAABAAAIkFyaWFsACoABAAAAC0BBAAU AAAAMgosAFEJBgAEAAAAAABiEG8TVGVybSBCNAAuABwARwAXADcABAAAAC0BAQAEAAAAAgEBAAQA AAAnAf//BAAAAAIBAQAEAAAAAgEBAAMAAAAeAAcAAAAWBJUAowUwAOAEBAAAAAIBAQAEAAAALQEE AA4AAAAyCjMABQUCAAQAAAAAAGIQbxNHS0EANwAEAAAALQEBAAQAAAACAQEABAAAACcB//8EAAAA AgEBAAQAAAACAQEAAwAAAB4ABwAAABYEiQB9ASMAIwAEAAAAAgEBAAQAAAAtAQQAFAAAADIKJgBG AAYABAAAAAAAYhBvE1Rlcm0gQTQALgAcAEcAFwA3AAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQA AAACAQEAAwAAAB4ABwAAABYE/QbmB7oGUQcEAAAAAgEBABAAAAD7Asb/AAAAAAAAkAEAAAAABAAA IkFyaWFsAK+BBAAAAC0BBgAQAAAAMgq8BlEHAwAEAAAAAABiEG8TQVJRACcAKgAtAAQAAAACAQEA BAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEZgfmByMHUQcEAAAAAgEBAAQAAAAt AQYAEAAAADIKJQdRBwMABAAAAAAAYhBvE0FDRgAnACoAIwAEAAAAAgEBAAQAAAAnAf//BAAAAAIB AQAEAAAAAgEBAAMAAAAeAAcAAAAWBI4GxwhLBo8GBAAAAAIBAQAEAAAALQEGABMAAAAyCk0GXwcF AAQAAAAAAGIQbxNTZXR1cAAnACAAEAAgACAABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIB AQADAAAAHgAHAAAAFgQKAjAExwH4AQQAAAACAQEABAAAAC0BBgATAAAAMgrJAcgCBQAEAAAAAABi EG8TU2V0dXAAJwAgABAAIAAgAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4A BwAAABYEogG0BF8BIAQEAAAAAgEBAAQAAAAtAQYAEAAAADIKYQEvBAMABAAAAAAAYhBvE0FDRgAn ACoAIwAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEBAAMAAAAeAAcAAAAWBCEBtATfACAE BAAAAAIBAQAEAAAALQEGABAAAAAyCuEAKgQDAAQAAAAAAGIQbxNBUlEAJwAqAC0ABAAAAAIBAQAE AAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgSKAuIDSAI2AgQAAAACAQEABAAAAC0B BgAiAAAAMgpKAj8CDwAEAAAAAABiEG8TQ2FsbCBQcm9jZWVkaW5nACoAIAANAA0AEAAnABMAIAAd ACAAIAAgAA0AIAAgAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYE 7wdtCK0HwAYEAAAAAgEBAAQAAAAtAQYAIgAAADIKrwfJBg8ABAAAAAAAYhBvE0NhbGwgUHJvY2Vl ZGluZwAqACAADQANABAAJwATACAAHQAgACAAIAANACAAIAAEAAAAAgEBAAQAAAAnAf//BAAAAAIB AQAJAAAA+gIAABEAAAAAAAAAIgAEAAAALQEHAAUAAAAUAjQBwgAFAAAAEwI0ASIFBAAAAC0BAwAE AAAA8AEHAAQAAAAtAQIACQAAAPoCAAABAAAAAAAAACIABAAAAC0BBwAKAAAAJAMDABYFGwEWBU0B SAU0AQQAAAAtAQUABAAAAC0BAwAEAAAA8AEHAAQAAAACAQEABAAAAAIBAQAJAAAA+gIAABEAAAAA AAAAIgAEAAAALQEHAAUAAAAUAqkBRwUFAAAAEwKpAegABAAAAC0BAwAEAAAA8AEHAAQAAAAtAQIA CQAAAPoCAAABAAAAAAAAACIABAAAAC0BBwAKAAAAJAMDAPQAwgH0AJABwgCpAQQAAAAtAQUABAAA AC0BAwAEAAAA8AEHAAQAAAACAQEABAAAAAIBAQAJAAAA+gIAABEAAAAAAAAAIgAEAAAALQEHAAUA AAAUAgsH6gkFAAAAEwILB3IFBAAAAC0BAwAEAAAA8AEHAAQAAAAtAQIACQAAAPoCAAABAAAAAAAA ACIABAAAAC0BBwAKAAAAJAMDAH8FJAd/BfIGTQULBwQAAAAtAQUABAAAAC0BAwAEAAAA8AEHAAQA AAACAQEABAAAAAIBAQAJAAAA+gIAABEAAAAAAAAAIgAEAAAALQEHAAUAAAAUAn8HTQUFAAAAEwJ/ B8sJBAAAAC0BAwAEAAAA8AEHAAQAAAAtAQIACQAAAPoCAAABAAAAAAAAACIABAAAAC0BBwAKAAAA JAMDAL4JZge+CZgH8Al/BwQAAAAtAQUABAAAAC0BAwAEAAAA8AEHAAQAAAACAQEABAAAAAIBAQAJ AAAA+gIAAAYAAAAAAAAAIgAEAAAALQEHAAUAAAAUAqIGRgUFAAAAEwKiBvAJBAAAAC0BAwAEAAAA 8AEHAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQcABQAAABQCogbwCQUAAAATAo4G0wkEAAAALQED AAQAAADwAQcACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BBwAFAAAAFAKiBvAJBQAAABMCtQbTCQQA AAAtAQMABAAAAPABBwAEAAAAAgEBAAQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgS7C2cEeAsv AgQAAAACAQEABAAAAC0BBgAjAAAAMgp6C10CEAAEAAAAAABiEG8TVGVybSBDYXAgU2V0IEFjayQA IAATADEAEAAqACAAIAAQACcAIAAQABAAJwAdAB4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAA AAIBAQADAAAAHgAHAAAAFgRhCVoIHgkiBgQAAAACAQEABAAAAC0BBgAjAAAAMgogCVAGEAAEAAAA AABiEG8TVGVybSBDYXAgU2V0IEFjayQAIAATADEAEAAqACAAIAAQACcAIAAQABAAJwAdAB4ABAAA AAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgRSC1QIDwscBgQAAAACAQEA BAAAAC0BBgAdAAAAMgoRC4MGDAAEAAAAAABiEG8TVGVybSBDYXAgU2V0JAAgABMAMQAQACoAIAAg ABAAJwAgABAABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgTgCE4E nggVAgQAAAACAQEABAAAAC0BBgAdAAAAMgqgCHwCDAAEAAAAAABiEG8TVGVybSBDYXAgU2V0JAAg ABMAMQAQACoAIAAgABAAJwAgABAABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BAgAJAAAA +gIFAAAAAAD///8AIgAEAAAALQEHAAwAAAAkAwQATgXwCE4F9ghCBfYIQgXwCAwAAAAkAwQAKgXw CCoF9ggeBfYIHgXwCAwAAAAkAwQABgXwCAYF9gj6BPYI+gTwCAwAAAAkAwQA4gTwCOIE9gjWBPYI 1gTwCAwAAAAkAwQAvgTwCL4E9giyBPYIsgTwCAwAAAAkAwQAmgTwCJoE9giOBPYIjgTwCAwAAAAk AwQAdgTwCHYE9ghqBPYIagTwCAwAAAAkAwQAUgTwCFIE9ghGBPYIRgTwCAwAAAAkAwQALgTwCC4E 9ggiBPYIIgTwCAwAAAAkAwQACgTwCAoE9gj+A/YI/gPwCAwAAAAkAwQA5gPwCOYD9gjaA/YI2gPw CAwAAAAkAwQAwgPwCMID9gi2A/YItgPwCAwAAAAkAwQAngPwCJ4D9giSA/YIkgPwCAwAAAAkAwQA egPwCHoD9ghuA/YIbgPwCAwAAAAkAwQAVgPwCFYD9ghKA/YISgPwCAwAAAAkAwQAMgPwCDID9ggm A/YIJgPwCAwAAAAkAwQADgPwCA4D9ggCA/YIAgPwCAwAAAAkAwQA6gLwCOoC9gjeAvYI3gLwCAwA AAAkAwQAxgLwCMYC9gi6AvYIugLwCAwAAAAkAwQAogLwCKIC9giWAvYIlgLwCAwAAAAkAwQAfgLw CH4C9ghyAvYIcgLwCAwAAAAkAwQAWgLwCFoC9ghOAvYITgLwCAwAAAAkAwQANgLwCDYC9ggqAvYI KgLwCAwAAAAkAwQAEgLwCBIC9ggGAvYIBgLwCAwAAAAkAwQA7gHwCO4B9gjiAfYI4gHwCAwAAAAk AwQAygHwCMoB9gi+AfYIvgHwCAwAAAAkAwQApgHwCKYB9giaAfYImgHwCAwAAAAkAwQAggHwCIIB 9gh2AfYIdgHwCAwAAAAkAwQAXgHwCF4B9ghSAfYIUgHwCAwAAAAkAwQAOgHwCDoB9gguAfYILgHw CAwAAAAkAwQAFgHwCBYB9ggKAfYICgHwCAwAAAAkAwQA8gDwCPIA9gjmAPYI5gDwCAwAAAAkAwQA zgDwCM4A9gjIAPYIyADwCAQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEI AAUAAAAUAvMIyAAFAAAAEwIHCeYABAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQA AAAtAQgABQAAABQC8wjIAAUAAAATAt8I5gAEAAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAAAgEB AAQAAAAtAQIABAAAAC0BBwAMAAAAJAMEAMgAZQnIAGsJ1ABrCdQAZQkMAAAAJAMEAOwAZQnsAGsJ +ABrCfgAZQkMAAAAJAMEABABZQkQAWsJHAFrCRwBZQkMAAAAJAMEADQBZQk0AWsJQAFrCUABZQkM AAAAJAMEAFgBZQlYAWsJZAFrCWQBZQkMAAAAJAMEAHwBZQl8AWsJiAFrCYgBZQkMAAAAJAMEAKAB ZQmgAWsJrAFrCawBZQkMAAAAJAMEAMQBZQnEAWsJ0AFrCdABZQkMAAAAJAMEAOgBZQnoAWsJ9AFr CfQBZQkMAAAAJAMEAAwCZQkMAmsJGAJrCRgCZQkMAAAAJAMEADACZQkwAmsJPAJrCTwCZQkMAAAA JAMEAFQCZQlUAmsJYAJrCWACZQkMAAAAJAMEAHgCZQl4AmsJhAJrCYQCZQkMAAAAJAMEAJwCZQmc AmsJqAJrCagCZQkMAAAAJAMEAMACZQnAAmsJzAJrCcwCZQkMAAAAJAMEAOQCZQnkAmsJ8AJrCfAC ZQkMAAAAJAMEAAgDZQkIA2sJFANrCRQDZQkMAAAAJAMEACwDZQksA2sJOANrCTgDZQkMAAAAJAME AFADZQlQA2sJXANrCVwDZQkMAAAAJAMEAHQDZQl0A2sJgANrCYADZQkMAAAAJAMEAJgDZQmYA2sJ pANrCaQDZQkMAAAAJAMEALwDZQm8A2sJyANrCcgDZQkMAAAAJAMEAOADZQngA2sJ7ANrCewDZQkM AAAAJAMEAAQEZQkEBGsJEARrCRAEZQkMAAAAJAMEACgEZQkoBGsJNARrCTQEZQkMAAAAJAMEAEwE ZQlMBGsJWARrCVgEZQkMAAAAJAMEAHAEZQlwBGsJfARrCXwEZQkMAAAAJAMEAJQEZQmUBGsJoARr CaAEZQkMAAAAJAMEALgEZQm4BGsJxARrCcQEZQkMAAAAJAMEANwEZQncBGsJ6ARrCegEZQkMAAAA JAMEAAAFZQkABWsJDAVrCQwFZQkMAAAAJAMEACQFZQkkBWsJMAVrCTAFZQkMAAAAJAMEAEgFZQlI BWsJTgVrCU4FZQkEAAAALQEFAAQAAAAtAQMACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAA FAJoCU4FBQAAABMCVAkwBQQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEI AAUAAAAUAmgJTgUFAAAAEwJ7CTAFBAAAAC0BAwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAEAAAA AgEBAAMAAAAeAAcAAAAWBAQQYAjCDxAGBAAAAAIBAQAEAAAALQEGACMAAAAyCsQPSQYQAAQAAAAA AGIQbxNSZWxlYXNlIENvbXBsZXRlKgAgAA0AIAAgAB0AIAAQACoAIAAxACAADQAgABAAIAAEAAAA AgEBAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEBAAMAAAAeAAcAAAAWBJAPmARND+sBBAAAAAIBAQAE AAAALQEGACgAAAAyCk8PEAITAAQAAAAAAGIQbxNFbmQgU2Vzc2lvbiBDb21tYW5kACcAIAAgABAA JwAgAB0AHQANACAAIAAQACoAIAAxADEAIAAgACAABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAA AAIBAQADAAAAHgAHAAAAFgQPD2AIzQ6zBQQAAAACAQEABAAAAC0BBgAoAAAAMgrPDtgFEwAEAAAA AABiEG8TRW5kIFNlc3Npb24gQ29tbWFuZAAnACAAIAAQACcAIAAdAB0ADQAgACAAEAAqACAAMQAx ACAAIAAgAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEMw0sCPAM UAUEAAAAAgEBAAQAAAAtAQYAHwAAADIK8gz7BQ0ABAAAAAAAYhBvE01lZGlhIENoYW5uZWwALwAg ACAADQAgABAAKgAgACAAIAAgACAADQAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEBAAMA AAAeAAcAAAAWBL8K9Ah8ChgGBAAAAAIBAQAEAAAALQEGAB8AAAAyCn4KwwYNAAQAAAAAAGIQbxNN ZWRpYSBDaGFubmVsAC8AIAAgAA0AIAAQACoAIAAgACAAIAAgAA0ABAAAAAIBAQAEAAAAJwH//wQA AAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgSkDLQEYQzYAQQAAAACAQEABAAAAC0BBgAvAAAAMgpj DO4BGAAEAAAAAABiEG8TT3BlbiBMb2dpY2FsIENoYW5uZWwgQWNrLQAgACAAIAAQACAAIAAgAA0A HQAgAA0AEAAqACAAIAAgACAAIAANABAAJwAdAB4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAA AAIBAQADAAAAHgAHAAAAFgQ+CvAI/AkVBgQAAAACAQEABAAAAC0BBgAvAAAAMgr+CSsGGAAEAAAA AABiEG8TT3BlbiBMb2dpY2FsIENoYW5uZWwgQWNrLQAgACAAIAAQACAAIAAgAA0AHQAgAA0AEAAq ACAAIAAgACAAIAANABAAJwAdAB4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAA HgAHAAAAFgQ7DGAI+AvWBQQAAAACAQEABAAAAC0BBgApAAAAMgr6C/0FFAAEAAAAAABiEG8TT3Bl biBMb2dpY2FsIENoYW5uZWwtACAAIAAgABAAIAAgACAADQAdACAADQAQACoAIAAgACAAIAAgAA0A BAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgTKCaMEhwkZAgQAAAAC AQEABAAAAC0BBgApAAAAMgqJCUACFAAEAAAAAABiEG8TT3BlbiBMb2dpY2FsIENoYW5uZWwtACAA IAAgABAAIAAgACAADQAdACAADQAQACoAIAAgACAAIAAgAA0ABAAAAAIBAQAEAAAAJwH//wQAAAAC AQEABAAAAAIBAQADAAAAHgAHAAAAFgTFDYIHgg3WBQQAAAACAQEABAAAAC0BBgAWAAAAMgqEDUAG BwAEAAAAAABiEG8TQ29ubmVjdAAqACAAIAAgACAAHQAQAAQAAAACAQEABAAAACcB//8EAAAAAgEB AAQAAAACAQEAAwAAAB4ABwAAABYE4hDIB58QNAcEAAAAAgEBAAQAAAAtAQYAEAAAADIKoRBCBwMA BAAAAAAAYhBvE0RDRgAqACoAIwAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEBAAMAAAAe AAcAAAAWBOIQtASfECAEBAAAAAIBAQAEAAAALQEGABAAAAAyCqEQLgQDAAQAAAAAAGIQbxNEQ0YA KgAqACMABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgRtEMgHKxA0 BwQAAAACAQEABAAAAC0BBgAQAAAAMgotED0HAwAEAAAAAABiEG8TRFJRACoAKgAtAAQAAAACAQEA BAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEbRC0BCsQIAQEAAAAAgEBAAQAAAAt AQYAEAAAADIKLRApBAMABAAAAAAAYhBvE0RSUQAqACoALQAEAAAAAgEBAAQAAAAnAf//BAAAAAIB AQAEAAAAAgEBAAMAAAAeAAcAAAAWBGQIAQQhCFUCBAAAAAIBAQAEAAAALQEGABcAAAAyCiMIyAII AAQAAAAAAGIQbxNBbGVydGluZycADQAgABMAEAANACAAIAAEAAAAAgEBAAQAAAAnAf//BAAAAAIB AQAJAAAA+gIAABEAAAAAAAAAIgAEAAAALQEIAAUAAAAUAkANyAAFAAAAEwJADeoJBAAAAC0BAwAE AAAA8AEIAAkAAAD6AgAAEQAAAAAAAAAiAAQAAAAtAQgABQAAABQCQA3qCQUAAAATAicNuAkEAAAA LQEDAAQAAADwAQgACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCAAFAAAAFAJADeoJBQAAABMCWQ24 CQQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0B CAAFAAAAFAJuEMIABQAAABMCbhAiBQQAAAAtAQMABAAAAPABCAAEAAAALQECAAkAAAD6AgAAAQAA AAAAAAAiAAQAAAAtAQgACgAAACQDAwAVBVUQFQWHEEcFbhAEAAAALQEFAAQAAAAtAQMABAAAAPAB CAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCAAFAAAAFALpEFkFBQAA ABMC6RD0AAQAAAAtAQMABAAAAPABCAAEAAAALQECAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQgA CgAAACQDAwABAQIRAQHQEM8A6RAEAAAALQEFAAQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAAC AQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCAAFAAAAFAJ0EOQJBQAAABMCdBBsBQQAAAAtAQMA BAAAAPABCAAEAAAALQECAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQgACgAAACQDAwB4BY0QeAVb EEYFdBAEAAAALQEFAAQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAA AAAAACIABAAAAC0BCAAFAAAAFALpEEYFBQAAABMC6RC4CQQAAAAtAQMABAAAAPABCAAEAAAALQEC AAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQgACgAAACQDAwCrCdAQqwkCEd0J6RAEAAAALQEFAAQA AAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAF AAAAFAKFAMMABQAAABMCdxHDAAQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoC AAACAAAAAAAAACIABAAAAC0BCAAFAAAAFAKcAEcFBQAAABMCcBFHBQQAAAAtAQMABAAAAPABCAAE AAAAAgEBAAQAAAACAQEACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAFAAAAFAKRAOwJBQAAABMC ahHsCQQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAA AC0BCAAFAAAAFAIdAsIABQAAABMCHQJHBQQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAA IgAEAAAALQEIAAUAAAAUAh0CRwUFAAAAEwIKAioFBAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAA AAAAAAAiAAQAAAAtAQgABQAAABQCHQJHBQUAAAATAjECKgUEAAAALQEDAAQAAADwAQgABAAAAAIB AQAEAAAAAgEBAAQAAAAtAQIABAAAAC0BBwAMAAAAJAMEAOoJ8AjqCfYI3gn2CN4J8AgMAAAAJAME AMYJ8AjGCfYIugn2CLoJ8AgMAAAAJAMEAKIJ8AiiCfYIlgn2CJYJ8AgMAAAAJAMEAH4J8Ah+CfYI cgn2CHIJ8AgMAAAAJAMEAFoJ8AhaCfYITgn2CE4J8AgMAAAAJAMEADYJ8Ag2CfYIKgn2CCoJ8AgM AAAAJAMEABIJ8AgSCfYIBgn2CAYJ8AgMAAAAJAMEAO4I8AjuCPYI4gj2COII8AgMAAAAJAMEAMoI 8AjKCPYIvgj2CL4I8AgMAAAAJAMEAKYI8AimCPYImgj2CJoI8AgMAAAAJAMEAIII8AiCCPYIdgj2 CHYI8AgMAAAAJAMEAF4I8AheCPYIUgj2CFII8AgMAAAAJAMEADoI8Ag6CPYILgj2CC4I8AgMAAAA JAMEABYI8AgWCPYICgj2CAoI8AgMAAAAJAMEAPIH8AjyB/YI5gf2COYH8AgMAAAAJAMEAM4H8AjO B/YIwgf2CMIH8AgMAAAAJAMEAKoH8AiqB/YIngf2CJ4H8AgMAAAAJAMEAIUH8AiFB/YIeQf2CHkH 8AgMAAAAJAMEAGEH8AhhB/YIVQf2CFUH8AgMAAAAJAMEAD0H8Ag9B/YIMQf2CDEH8AgMAAAAJAME ABkH8AgZB/YIDQf2CA0H8AgMAAAAJAMEAPUG8Aj1BvYI6Qb2COkG8AgMAAAAJAMEANEG8AjRBvYI xQb2CMUG8AgMAAAAJAMEAK0G8AitBvYIoQb2CKEG8AgMAAAAJAMEAIkG8AiJBvYIfQb2CH0G8AgM AAAAJAMEAGUG8AhlBvYIWQb2CFkG8AgMAAAAJAMEAEEG8AhBBvYINQb2CDUG8AgMAAAAJAMEAB0G 8AgdBvYIEQb2CBEG8AgMAAAAJAMEAPkF8Aj5BfYI7QX2CO0F8AgMAAAAJAMEANUF8AjVBfYIyQX2 CMkF8AgMAAAAJAMEALEF8AixBfYIpQX2CKUF8AgMAAAAJAMEAI0F8AiNBfYIgQX2CIEF8AgMAAAA JAMEAGkF8AhpBfYIXQX2CF0F8AgEAAAALQEFAAQAAAAtAQMACQAAAPoCAAAGAAAAAAAAACIABAAA AC0BCAAFAAAAFALzCE0FBQAAABMCBwlqBQQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAA IgAEAAAALQEIAAUAAAAUAvMITQUFAAAAEwLfCGoFBAAAAC0BAwAEAAAA8AEIAAQAAAACAQEABAAA AAIBAQAEAAAALQECAAQAAAAtAQcADAAAACQDBABNBWUJTQVrCVkFawlZBWUJDAAAACQDBABxBWUJ cQVrCX0Fawl9BWUJDAAAACQDBACVBWUJlQVrCaEFawmhBWUJDAAAACQDBAC5BWUJuQVrCcUFawnF BWUJDAAAACQDBADdBWUJ3QVrCekFawnpBWUJDAAAACQDBAABBmUJAQZrCQ0GawkNBmUJDAAAACQD BAAlBmUJJQZrCTEGawkxBmUJDAAAACQDBABJBmUJSQZrCVUGawlVBmUJDAAAACQDBABtBmUJbQZr CXkGawl5BmUJDAAAACQDBACRBmUJkQZrCZ0GawmdBmUJDAAAACQDBAC1BmUJtQZrCcEGawnBBmUJ DAAAACQDBADZBmUJ2QZrCeUGawnlBmUJDAAAACQDBAD9BmUJ/QZrCQkHawkJB2UJDAAAACQDBAAh B2UJIQdrCS0HawktB2UJDAAAACQDBABFB2UJRQdrCVEHawlRB2UJDAAAACQDBABpB2UJaQdrCXUH awl1B2UJDAAAACQDBACNB2UJjQdrCZkHawmZB2UJDAAAACQDBACyB2UJsgdrCb4Hawm+B2UJDAAA ACQDBADWB2UJ1gdrCeIHawniB2UJDAAAACQDBAD6B2UJ+gdrCQYIawkGCGUJDAAAACQDBAAeCGUJ HghrCSoIawkqCGUJDAAAACQDBABCCGUJQghrCU4IawlOCGUJDAAAACQDBABmCGUJZghrCXIIawly CGUJDAAAACQDBACKCGUJighrCZYIawmWCGUJDAAAACQDBACuCGUJrghrCboIawm6CGUJDAAAACQD BADSCGUJ0ghrCd4IawneCGUJDAAAACQDBAD2CGUJ9ghrCQIJawkCCWUJDAAAACQDBAAaCWUJGglr CSYJawkmCWUJDAAAACQDBAA+CWUJPglrCUoJawlKCWUJDAAAACQDBABiCWUJYglrCW4JawluCWUJ DAAAACQDBACGCWUJhglrCZIJawmSCWUJDAAAACQDBACqCWUJqglrCbYJawm2CWUJDAAAACQDBADO CWUJzglrCdoJawnaCWUJBAAAAC0BBQAEAAAALQEDAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCaAnwCQUAAAATAlQJ0wkEAAAALQEDAAQAAADwAQgACQAAAPoCAAAGAAAAAAAAACIABAAA AC0BCAAFAAAAFAJoCfAJBQAAABMCewnTCQQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAKdAkcFBQAAABMCnQLCAAQAAAAtAQMABAAA APABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAUAp0CwgAFAAAAEwKwAt8ABAAAAC0B AwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCnQLCAAUAAAATAokC3wAE AAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAAAgEBAAQAAAAtAQIABAAAAC0BBwAMAAAAJAMEAOoJ 2QnqCd8J3gnfCd4J2QkMAAAAJAMEAMYJ2QnGCd8JugnfCboJ2QkMAAAAJAMEAKIJ2QmiCd8Jlgnf CZYJ2QkMAAAAJAMEAH4J2Ql+Cd8JcgnfCXIJ2QkMAAAAJAMEAFoJ2QlaCd8JTgnfCU4J2QkMAAAA JAMEADYJ2Qk2Cd8JKgnfCSoJ2QkMAAAAJAMEABIJ2QkSCd8JBgnfCQYJ2QkMAAAAJAMEAO4I2Qnu CN8J4gjfCeII2QkMAAAAJAMEAMoI2QnKCN8JvgjfCb4I2QkMAAAAJAMEAKYI2QmmCN8JmgjfCZoI 2QkMAAAAJAMEAIII2QmCCN8JdgjfCXYI2QkMAAAAJAMEAF4I2QleCN8JUgjfCVII2QkMAAAAJAME ADoI2Qk6CN8JLgjfCS4I2QkMAAAAJAMEABYI2QkWCN8JCgjfCQoI2QkMAAAAJAMEAPIH2QnyB98J 5gffCeYH2QkMAAAAJAMEAM4H2QnOB98JwgffCcIH2QkMAAAAJAMEAKoH2QmqB98JngffCZ4H2QkM AAAAJAMEAIUH2QmFB98JeQffCXkH2QkMAAAAJAMEAGEH2QlhB98JVQffCVUH2QkMAAAAJAMEAD0H 2Qk9B98JMQffCTEH2QkMAAAAJAMEABkH2QkZB98JDQffCQ0H2QkMAAAAJAMEAPUG2Qn1Bt8J6Qbf CekG2QkMAAAAJAMEANEG2QnRBt8JxQbfCcUG2QkMAAAAJAMEAK0G2QmtBt8JoQbfCaEG2QkMAAAA JAMEAIkG2QmJBt8JfQbfCX0G2QkMAAAAJAMEAGUG2QllBt8JWQbfCVkG2QkMAAAAJAMEAEEG2QlB Bt8JNQbfCTUG2QkMAAAAJAMEAB0G2QkdBt8JEQbfCREG2QkMAAAAJAMEAPkF2Qn5Bd8J7QXfCe0F 2QkMAAAAJAMEANUF2QnVBd8JyQXfCckF2QkMAAAAJAMEALEF2QmxBd8JpQXfCaUF2QkMAAAAJAME AI0F2QmNBd8JgQXfCYEF2QkMAAAAJAMEAGkF2QlpBd8JXQXfCV0F2QkEAAAALQEFAAQAAAAtAQMA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFALcCU0FBQAAABMC8AlqBQQAAAAtAQMABAAA APABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAUAtwJTQUFAAAAEwLICWoFBAAAAC0B AwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAEAAAALQECAAQAAAAtAQcADAAAACQDBADIAE4KyABU CtQAVArUAE4KDAAAACQDBADsAE4K7ABUCvgAVAr4AE4KDAAAACQDBAAQAU4KEAFUChwBVAocAU4K DAAAACQDBAA0AU4KNAFUCkABVApAAU4KDAAAACQDBABYAU4KWAFUCmQBVApkAU4KDAAAACQDBAB8 AU4KfAFUCogBVAqIAU4KDAAAACQDBACgAU4KoAFUCqwBVAqsAU4KDAAAACQDBADEAU4KxAFUCtAB VArQAU4KDAAAACQDBADoAU4K6AFUCvQBVAr0AU4KDAAAACQDBAAMAk4KDAJUChgCVAoYAk4KDAAA ACQDBAAwAk4KMAJUCjwCVAo8Ak4KDAAAACQDBABUAk4KVAJUCmACVApgAk4KDAAAACQDBAB4Ak4K eAJUCoQCVAqEAk4KDAAAACQDBACcAk4KnAJUCqgCVAqoAk4KDAAAACQDBADAAk4KwAJUCswCVArM Ak4KDAAAACQDBADkAk4K5AJUCvACVArwAk4KDAAAACQDBAAIA04KCANUChQDVAoUA04KDAAAACQD BAAsA04KLANUCjgDVAo4A04KDAAAACQDBABQA04KUANUClwDVApcA04KDAAAACQDBAB0A04KdANU CoADVAqAA04KDAAAACQDBACYA04KmANUCqQDVAqkA04KDAAAACQDBAC8A04KvANUCsgDVArIA04K DAAAACQDBADgA04K4ANUCuwDVArsA04KDAAAACQDBAAEBE4KBARUChAEVAoQBE4KDAAAACQDBAAo BE4KKARUCjQEVAo0BE4KDAAAACQDBABMBE4KTARUClgEVApYBE4KDAAAACQDBABwBE4KcARUCnwE VAp8BE4KDAAAACQDBACUBE4KlARUCqAEVAqgBE4KDAAAACQDBAC4BE4KuARUCsQEVArEBE4KDAAA ACQDBADcBE4K3ARUCugEVAroBE4KDAAAACQDBAAABU4KAAVUCgwFVAoMBU4KDAAAACQDBAAkBU4K JAVUCjAFVAowBU4KDAAAACQDBABIBU4KSAVUCk4FVApOBU4KBAAAAC0BBQAEAAAALQEDAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCUQpOBQUAAAATAj0KMAUEAAAALQEDAAQAAADwAQgA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAJRCk4FBQAAABMCZQowBQQAAAAtAQMABAAA APABCAAEAAAAAgEBAAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQATQVOCk0FVApZBVQK WQVOCgwAAAAkAwQAcQVOCnEFVAp9BVQKfQVOCgwAAAAkAwQAlQVOCpUFVAqhBVQKoQVOCgwAAAAk AwQAuQVOCrkFVArFBVQKxQVOCgwAAAAkAwQA3QVOCt0FVArpBVQK6QVOCgwAAAAkAwQAAQZOCgEG VAoNBlQKDQZOCgwAAAAkAwQAJQZOCiUGVAoxBlQKMQZOCgwAAAAkAwQASQZOCkkGVApVBlQKVQZO CgwAAAAkAwQAbQZOCm0GVAp5BlQKeQZOCgwAAAAkAwQAkQZOCpEGVAqdBlQKnQZOCgwAAAAkAwQA tQZOCrUGVArBBlQKwQZOCgwAAAAkAwQA2QZOCtkGVArlBlQK5QZOCgwAAAAkAwQA/QZOCv0GVAoJ B1QKCQdOCgwAAAAkAwQAIQdOCiEHVAotB1QKLQdOCgwAAAAkAwQARQdOCkUHVApRB1QKUQdOCgwA AAAkAwQAaQdOCmkHVAp1B1QKdQdOCgwAAAAkAwQAjQdOCo0HVAqZB1QKmQdOCgwAAAAkAwQAsgdO CrIHVAq+B1QKvgdOCgwAAAAkAwQA1gdOCtYHVAriB1QK4gdOCgwAAAAkAwQA+gdOCvoHVAoGCFQK BghOCgwAAAAkAwQAHghOCh4IVAoqCFQKKghOCgwAAAAkAwQAQghOCkIIVApOCFQKTghOCgwAAAAk AwQAZghOCmYIVApyCFQKcghOCgwAAAAkAwQAighOCooIVAqWCFQKlghOCgwAAAAkAwQArghOCq4I VAq6CFQKughOCgwAAAAkAwQA0ghOCtIIVAreCFQK3ghOCgwAAAAkAwQA9ghOCvYIVAoCCVQKAglO CgwAAAAkAwQAGglOChoJVAomCVQKJglOCgwAAAAkAwQAPglOCj4JVApKCVQKSglOCgwAAAAkAwQA YglOCmIJVApuCVQKbglOCgwAAAAkAwQAhglOCoYJVAqSCVQKkglOCgwAAAAkAwQAqglOCqoJVAq2 CVQKtglOCgwAAAAkAwQAzglOCs4JVAraCVQK2glOCgQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYA AAAAAAAAIgAEAAAALQEIAAUAAAAUAlEK8AkFAAAAEwI9CtMJBAAAAC0BAwAEAAAA8AEIAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCUQrwCQUAAAATAmUK0wkEAAAALQEDAAQAAADwAQgA BAAAAAIBAQAEAAAAAgEBAAkAAAD6AgAAEQAAAAAAAAAiAAQAAAAtAQgABQAAABQCxgrqCQUAAAAT AsYKyAAEAAAALQEDAAQAAADwAQgACQAAAPoCAAARAAAAAAAAACIABAAAAC0BCAAFAAAAFALGCsgA BQAAABMC3wr6AAQAAAAtAQMABAAAAPABCAAJAAAA+gIAABEAAAAAAAAAIgAEAAAALQEIAAUAAAAU AsYKyAAFAAAAEwKtCvoABAAAAC0BAwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAJAAAA+gIAAAYA AAAAAAAAIgAEAAAALQEIAAUAAAAUAggI5AkFAAAAEwIICEYFBAAAAC0BAwAEAAAA8AEIAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCCAhGBQUAAAATAhwIZAUEAAAALQEDAAQAAADwAQgA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAIICEYFBQAAABMC9QdkBQQAAAAtAQMABAAA APABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAJrCEcF BQAAABMCawjCAAQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU AmsIwgAFAAAAEwJ/CN8ABAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCawjCAAUAAAATAlcI3wAEAAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAAAgEBAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCawjqCQUAAAATAmsIRgUEAAAALQEDAAQAAADwAQgA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAJrCEYFBQAAABMCfwhkBQQAAAAtAQMABAAA APABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAUAmsIRgUFAAAAEwJXCGQFBAAAAC0B AwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAEAAAALQECAAQAAAAtAQcADAAAACQDBADCAFYLwgBc C84AXAvOAFYLDAAAACQDBADmAFYL5gBcC/IAXAvyAFYLDAAAACQDBAAKAVYLCgFcCxYBXAsWAVYL DAAAACQDBAAuAVYLLgFcCzoBXAs6AVYLDAAAACQDBABSAVYLUgFcC14BXAteAVYLDAAAACQDBAB2 AVYLdgFcC4IBXAuCAVYLDAAAACQDBACaAVYLmgFcC6YBXAumAVYLDAAAACQDBAC+AVYLvgFcC8oB XAvKAVYLDAAAACQDBADiAVYL4gFcC+4BXAvuAVYLDAAAACQDBAAGAlYLBgJcCxICXAsSAlYLDAAA ACQDBAAqAlYLKgJcCzYCXAs2AlYLDAAAACQDBABOAlYLTgJcC1oCXAtaAlYLDAAAACQDBAByAlYL cgJcC34CXAt+AlYLDAAAACQDBACWAlYLlgJcC6ICXAuiAlYLDAAAACQDBAC6AlYLugJcC8YCXAvG AlYLDAAAACQDBADeAlYL3gJcC+oCXAvqAlYLDAAAACQDBAACA1YLAgNcCw8DXAsPA1YLDAAAACQD BAAnA1YLJwNcCzMDXAszA1YLDAAAACQDBABLA1YLSwNcC1cDXAtXA1YLDAAAACQDBABvA1YLbwNc C3sDXAt7A1YLDAAAACQDBACTA1YLkwNcC58DXAufA1YLDAAAACQDBAC3A1YLtwNcC8MDXAvDA1YL DAAAACQDBADbA1YL2wNcC+cDXAvnA1YLDAAAACQDBAD/A1YL/wNcCwsEXAsLBFYLDAAAACQDBAAj BFYLIwRcCy8EXAsvBFYLDAAAACQDBABHBFYLRwRcC1MEXAtTBFYLDAAAACQDBABrBFYLawRcC3cE XAt3BFYLDAAAACQDBACPBFYLjwRcC5sEXAubBFYLDAAAACQDBACzBFYLswRcC78EXAu/BFYLDAAA ACQDBADXBFYL1wRcC+MEXAvjBFYLDAAAACQDBAD7BFYL+wRcCwcFXAsHBVYLDAAAACQDBAAfBVYL HwVcCysFXAsrBVYLDAAAACQDBABDBVYLQwVcC0cFXAtHBVYLBAAAAC0BBQAEAAAALQEDAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCWQtHBQUAAAATAkULKgUEAAAALQEDAAQAAADwAQgA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAJZC0cFBQAAABMCbAsqBQQAAAAtAQMABAAA APABCAAEAAAAAgEBAAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQARgVWC0YFXAtSBVwL UgVWCwwAAAAkAwQAagVWC2oFXAt2BVwLdgVWCwwAAAAkAwQAjgVWC44FXAuaBVwLmgVWCwwAAAAk AwQAsgVWC7IFXAu+BVwLvgVWCwwAAAAkAwQA1gVWC9YFXAviBVwL4gVWCwwAAAAkAwQA+gVWC/oF XAsGBlwLBgZWCwwAAAAkAwQAHgZWCx4GXAsqBlwLKgZWCwwAAAAkAwQAQgZWC0IGXAtOBlwLTgZW CwwAAAAkAwQAZgZWC2YGXAtyBlwLcgZWCwwAAAAkAwQAigZWC4oGXAuWBlwLlgZWCwwAAAAkAwQA rgZWC64GXAu6BlwLugZWCwwAAAAkAwQA0gZWC9IGXAveBlwL3gZWCwwAAAAkAwQA9gZWC/YGXAsC B1wLAgdWCwwAAAAkAwQAGgdWCxoHXAsmB1wLJgdWCwwAAAAkAwQAPgdWCz4HXAtKB1wLSgdWCwwA AAAkAwQAYgdWC2IHXAtuB1wLbgdWCwwAAAAkAwQAhgdWC4YHXAuSB1wLkgdWCwwAAAAkAwQAqgdW C6oHXAu2B1wLtgdWCwwAAAAkAwQAzgdWC84HXAvaB1wL2gdWCwwAAAAkAwQA8gdWC/IHXAv+B1wL /gdWCwwAAAAkAwQAFghWCxYIXAsiCFwLIghWCwwAAAAkAwQAOghWCzoIXAtGCFwLRghWCwwAAAAk AwQAXghWC14IXAtqCFwLaghWCwwAAAAkAwQAgghWC4IIXAuOCFwLjghWCwwAAAAkAwQApghWC6YI XAuyCFwLsghWCwwAAAAkAwQAyghWC8oIXAvWCFwL1ghWCwwAAAAkAwQA7ghWC+4IXAv6CFwL+ghW CwwAAAAkAwQAEglWCxIJXAseCVwLHglWCwwAAAAkAwQANglWCzYJXAtCCVwLQglWCwwAAAAkAwQA WglWC1oJXAtmCVwLZglWCwwAAAAkAwQAfglWC34JXAuKCVwLiglWCwwAAAAkAwQAoglWC6IJXAuu CVwLrglWCwwAAAAkAwQAxglWC8YJXAvSCVwL0glWCwQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYA AAAAAAAAIgAEAAAALQEIAAUAAAAUAlkL6gkFAAAAEwJFC80JBAAAAC0BAwAEAAAA8AEIAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCWQvqCQUAAAATAmwLzQkEAAAALQEDAAQAAADwAQgA BAAAAAIBAQAEAAAAAgEBAAQAAAAtAQIABAAAAC0BBwAMAAAAJAMEAEcFvwtHBcULOwXFCzsFvwsM AAAAJAMEACMFvwsjBcULFwXFCxcFvwsMAAAAJAMEAP8Evwv/BMUL8wTFC/MEvwsMAAAAJAMEANsE vwvbBMULzwTFC88EvwsMAAAAJAMEALcEvwu3BMULqwTFC6sEvwsMAAAAJAMEAJMEvwuTBMULhwTF C4cEvwsMAAAAJAMEAG8EvwtvBMULYwTFC2MEvwsMAAAAJAMEAEsEvwtLBMULPwTFCz8EvwsMAAAA JAMEACcEvwsnBMULGwTFCxsEvwsMAAAAJAMEAAMEvwsDBMUL9wPFC/cDvwsMAAAAJAMEAN8Dvwvf A8UL0wPFC9MDvwsMAAAAJAMEALsDvwu7A8ULrwPFC68DvwsMAAAAJAMEAJcDvwuXA8ULiwPFC4sD vwsMAAAAJAMEAHMDvwtzA8ULZwPFC2cDvwsMAAAAJAMEAE8DvwtPA8ULQwPFC0MDvwsMAAAAJAME ACsDvwsrA8ULHwPFCx8DvwsMAAAAJAMEAAYDvwsGA8UL+gLFC/oCvwsMAAAAJAMEAOICvwviAsUL 1gLFC9YCvwsMAAAAJAMEAL4Cvwu+AsULsgLFC7ICvwsMAAAAJAMEAJoCvwuaAsULjgLFC44CvwsM AAAAJAMEAHYCvwt2AsULagLFC2oCvwsMAAAAJAMEAFICvwtSAsULRgLFC0YCvwsMAAAAJAMEAC4C vwsuAsULIgLFCyICvwsMAAAAJAMEAAoCvwsKAsUL/gHFC/4BvwsMAAAAJAMEAOYBvwvmAcUL2gHF C9oBvwsMAAAAJAMEAMIBvwvCAcULtgHFC7YBvwsMAAAAJAMEAJ4BvwueAcULkgHFC5IBvwsMAAAA JAMEAHoBvwt6AcULbgHFC24BvwsMAAAAJAMEAFYBvwtWAcULSgHFC0oBvwsMAAAAJAMEADIBvwsy AcULJgHFCyYBvwsMAAAAJAMEAA4BvwsOAcULAgHFCwIBvwsMAAAAJAMEAOoAvwvqAMUL3gDFC94A vwsEAAAALQEFAAQAAAAtAQMACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFALCC8gABQAA ABMC1QvmAAQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAUAsIL yAAFAAAAEwKuC+YABAAAAC0BAwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAEAAAALQECAAQAAAAt AQcADAAAACQDBADkCb8L5AnFC9gJxQvYCb8LDAAAACQDBADACb8LwAnFC7QJxQu0Cb8LDAAAACQD BACcCb8LnAnFC5AJxQuQCb8LDAAAACQDBAB4Cb8LeAnFC2wJxQtsCb8LDAAAACQDBABUCb8LVAnF C0gJxQtICb8LDAAAACQDBAAwCb8LMAnFCyQJxQskCb8LDAAAACQDBAAMCb8LDAnFCwAJxQsACb8L DAAAACQDBADoCL8L6AjFC9wIxQvcCL8LDAAAACQDBADECL8LxAjFC7gIxQu4CL8LDAAAACQDBACg CL8LoAjFC5QIxQuUCL8LDAAAACQDBAB8CL8LfAjFC3AIxQtwCL8LDAAAACQDBABYCL8LWAjFC0wI xQtMCL8LDAAAACQDBAA0CL8LNAjFCygIxQsoCL8LDAAAACQDBAAQCL8LEAjFCwQIxQsECL8LDAAA ACQDBADsB78L7AfFC+AHxQvgB78LDAAAACQDBADIB78LyAfFC7wHxQu8B78LDAAAACQDBACkB78L pAfFC5gHxQuYB78LDAAAACQDBACAB78LgAfFC3QHxQt0B78LDAAAACQDBABcB78LXAfFC1AHxQtQ B78LDAAAACQDBAA4B78LOAfFCywHxQssB78LDAAAACQDBAAUB78LFAfFCwgHxQsIB78LDAAAACQD BADwBr8L8AbFC+QGxQvkBr8LDAAAACQDBADMBr8LzAbFC8AGxQvABr8LDAAAACQDBACoBr8LqAbF C5wGxQucBr8LDAAAACQDBACEBr8LhAbFC3gGxQt4Br8LDAAAACQDBABgBr8LYAbFC1QGxQtUBr8L DAAAACQDBAA8Br8LPAbFCzAGxQswBr8LDAAAACQDBAAYBr8LGAbFCwwGxQsMBr8LDAAAACQDBAD0 Bb8L9AXFC+gFxQvoBb8LDAAAACQDBADQBb8L0AXFC8QFxQvEBb8LDAAAACQDBACsBb8LrAXFC6AF xQugBb8LDAAAACQDBACIBb8LiAXFC3wFxQt8Bb8LDAAAACQDBABkBb8LZAXFC1gFxQtYBb8LBAAA AC0BBQAEAAAALQEDAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCwgtGBQUAAAATAtUL ZAUEAAAALQEDAAQAAADwAQgACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFALCC0YFBQAA ABMCrgtkBQQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwA AAAkAwQAyAA/DMgARQzUAEUM1AA/DAwAAAAkAwQA7AA/DOwARQz4AEUM+AA/DAwAAAAkAwQAEAE/ DBABRQwcAUUMHAE/DAwAAAAkAwQANAE/DDQBRQxAAUUMQAE/DAwAAAAkAwQAWAE/DFgBRQxkAUUM ZAE/DAwAAAAkAwQAfAE/DHwBRQyIAUUMiAE/DAwAAAAkAwQAoAE/DKABRQysAUUMrAE/DAwAAAAk AwQAxAE/DMQBRQzQAUUM0AE/DAwAAAAkAwQA6AE/DOgBRQz0AUUM9AE/DAwAAAAkAwQADAI/DAwC RQwYAkUMGAI/DAwAAAAkAwQAMAI/DDACRQw8AkUMPAI/DAwAAAAkAwQAVAI/DFQCRQxgAkUMYAI/ DAwAAAAkAwQAeAI/DHgCRQyEAkUMhAI/DAwAAAAkAwQAnAI/DJwCRQyoAkUMqAI/DAwAAAAkAwQA wAI/DMACRQzMAkUMzAI/DAwAAAAkAwQA5AI/DOQCRQzwAkUM8AI/DAwAAAAkAwQACQM/DAkDRQwV A0UMFQM/DAwAAAAkAwQALQM/DC0DRQw5A0UMOQM/DAwAAAAkAwQAUQM/DFEDRQxdA0UMXQM/DAwA AAAkAwQAdQM/DHUDRQyBA0UMgQM/DAwAAAAkAwQAmQM/DJkDRQylA0UMpQM/DAwAAAAkAwQAvQM/ DL0DRQzJA0UMyQM/DAwAAAAkAwQA4QM/DOEDRQztA0UM7QM/DAwAAAAkAwQABQQ/DAUERQwRBEUM EQQ/DAwAAAAkAwQAKQQ/DCkERQw1BEUMNQQ/DAwAAAAkAwQATQQ/DE0ERQxZBEUMWQQ/DAwAAAAk AwQAcQQ/DHEERQx9BEUMfQQ/DAwAAAAkAwQAlQQ/DJUERQyhBEUMoQQ/DAwAAAAkAwQAuQQ/DLkE RQzFBEUMxQQ/DAwAAAAkAwQA3QQ/DN0ERQzpBEUM6QQ/DAwAAAAkAwQAAQU/DAEFRQwNBUUMDQU/ DAwAAAAkAwQAJQU/DCUFRQwxBUUMMQU/DAQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYAAAAAAAAA IgAEAAAALQEIAAUAAAAUAkIMRwUFAAAAEwIuDCoFBAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAA AAAAAAAiAAQAAAAtAQgABQAAABQCQgxHBQUAAAATAlYMKgUEAAAALQEDAAQAAADwAQgABAAAAAIB AQAEAAAAAgEBAAQAAAAtAQIABAAAAC0BBwAMAAAAJAMEAEAFPwxABUUMTAVFDEwFPwwMAAAAJAME AGQFPwxkBUUMcAVFDHAFPwwMAAAAJAMEAIgFPwyIBUUMlAVFDJQFPwwMAAAAJAMEAKwFPwysBUUM uAVFDLgFPwwMAAAAJAMEANAFPwzQBUUM3AVFDNwFPwwMAAAAJAMEAPQFPwz0BUUMAAZFDAAGPwwM AAAAJAMEABgGPwwYBkUMJAZFDCQGPwwMAAAAJAMEADwGPww8BkUMSAZFDEgGPwwMAAAAJAMEAGAG PwxgBkUMbAZFDGwGPwwMAAAAJAMEAIQGPwyEBkUMkAZFDJAGPwwMAAAAJAMEAKgGPwyoBkUMtAZF DLQGPwwMAAAAJAMEAMwGPwzMBkUM2AZFDNgGPwwMAAAAJAMEAPAGPwzwBkUM/AZFDPwGPwwMAAAA JAMEABQHPwwUB0UMIAdFDCAHPwwMAAAAJAMEADgHPww4B0UMRAdFDEQHPwwMAAAAJAMEAFwHPwxc B0UMaAdFDGgHPwwMAAAAJAMEAIAHPwyAB0UMjAdFDIwHPwwMAAAAJAMEAKQHPwykB0UMsAdFDLAH PwwMAAAAJAMEAMgHPwzIB0UM1AdFDNQHPwwMAAAAJAMEAOwHPwzsB0UM+AdFDPgHPwwMAAAAJAME ABAIPwwQCEUMHAhFDBwIPwwMAAAAJAMEADQIPww0CEUMQAhFDEAIPwwMAAAAJAMEAFgIPwxYCEUM ZAhFDGQIPwwMAAAAJAMEAHwIPwx8CEUMiAhFDIgIPwwMAAAAJAMEAKAIPwygCEUMrAhFDKwIPwwM AAAAJAMEAMQIPwzECEUM0AhFDNAIPwwMAAAAJAMEAOgIPwzoCEUM9AhFDPQIPwwMAAAAJAMEAAwJ PwwMCUUMGAlFDBgJPwwMAAAAJAMEADAJPwwwCUUMPAlFDDwJPwwMAAAAJAMEAFQJPwxUCUUMYAlF DGAJPwwMAAAAJAMEAHgJPwx4CUUMhAlFDIQJPwwMAAAAJAMEAJwJPwycCUUMqAlFDKgJPwwMAAAA JAMEAMAJPwzACUUMzAlFDMwJPwwMAAAAJAMEAOQJPwzkCUUM6glFDOoJPwwEAAAALQEFAAQAAAAt AQMACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAJCDOoJBQAAABMCLgzNCQQAAAAtAQMA BAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAUAkIM6gkFAAAAEwJWDM0JBAAA AC0BAwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAEAAAALQECAAQAAAAtAQcADAAAACQDBABHBagM RwWuDDsFrgw7BagMDAAAACQDBAAjBagMIwWuDBcFrgwXBagMDAAAACQDBAD/BKgM/wSuDPMErgzz BKgMDAAAACQDBADbBKgM2wSuDM8ErgzPBKgMDAAAACQDBAC3BKgMtwSuDKsErgyrBKgMDAAAACQD BACTBKgMkwSuDIcErgyHBKgMDAAAACQDBABvBKgMbwSuDGMErgxjBKgMDAAAACQDBABLBKgMSwSu DD8Ergw/BKgMDAAAACQDBAAnBKgMJwSuDBsErgwbBKgMDAAAACQDBAADBKgMAwSuDPcDrgz3A6gM DAAAACQDBADfA6gM3wOuDNMDrgzTA6gMDAAAACQDBAC7A6gMuwOuDK8DrgyvA6gMDAAAACQDBACX A6gMlwOuDIsDrgyLA6gMDAAAACQDBABzA6gMcwOuDGcDrgxnA6gMDAAAACQDBABPA6gMTwOuDEMD rgxDA6gMDAAAACQDBAArA6gMKwOuDB8DrgwfA6gMDAAAACQDBAAGA6gMBgOuDPoCrgz6AqgMDAAA ACQDBADiAqgM4gKuDNYCrgzWAqgMDAAAACQDBAC+AqgMvgKuDLICrgyyAqgMDAAAACQDBACaAqgM mgKuDI4CrgyOAqgMDAAAACQDBAB2AqgMdgKuDGoCrgxqAqgMDAAAACQDBABSAqgMUgKuDEYCrgxG AqgMDAAAACQDBAAuAqgMLgKuDCICrgwiAqgMDAAAACQDBAAKAqgMCgKuDP4Brgz+AagMDAAAACQD BADmAagM5gGuDNoBrgzaAagMDAAAACQDBADCAagMwgGuDLYBrgy2AagMDAAAACQDBACeAagMngGu DJIBrgySAagMDAAAACQDBAB6AagMegGuDG4BrgxuAagMDAAAACQDBABWAagMVgGuDEoBrgxKAagM DAAAACQDBAAyAagMMgGuDCYBrgwmAagMDAAAACQDBAAOAagMDgGuDAIBrgwCAagMDAAAACQDBADq AKgM6gCuDN4ArgzeAKgMBAAAAC0BBQAEAAAALQEDAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCqwzIAAUAAAATAr8M5gAEAAAALQEDAAQAAADwAQgACQAAAPoCAAAGAAAAAAAAACIABAAA AC0BCAAFAAAAFAKrDMgABQAAABMClwzmAAQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEA BAAAAC0BAgAEAAAALQEHAAwAAAAkAwQA6gmoDOoJrgzeCa4M3gmoDAwAAAAkAwQAxgmoDMYJrgy6 Ca4MugmoDAwAAAAkAwQAogmoDKIJrgyWCa4MlgmoDAwAAAAkAwQAfgmoDH4JrgxyCa4McgmoDAwA AAAkAwQAWgmoDFoJrgxOCa4MTgmoDAwAAAAkAwQANgmoDDYJrgwqCa4MKgmoDAwAAAAkAwQAEgmo DBIJrgwGCa4MBgmoDAwAAAAkAwQA7gioDO4IrgziCK4M4gioDAwAAAAkAwQAygioDMoIrgy+CK4M vgioDAwAAAAkAwQApgioDKYIrgyaCK4MmgioDAwAAAAkAwQAggioDIIIrgx2CK4MdgioDAwAAAAk AwQAXgioDF4IrgxSCK4MUgioDAwAAAAkAwQAOgioDDoIrgwuCK4MLgioDAwAAAAkAwQAFgioDBYI rgwKCK4MCgioDAwAAAAkAwQA8geoDPIHrgzmB64M5geoDAwAAAAkAwQAzgeoDM4HrgzCB64Mwgeo DAwAAAAkAwQAqgeoDKoHrgyeB64MngeoDAwAAAAkAwQAhgeoDIYHrgx6B64MegeoDAwAAAAkAwQA YgeoDGIHrgxWB64MVgeoDAwAAAAkAwQAPgeoDD4HrgwyB64MMgeoDAwAAAAkAwQAGgeoDBoHrgwO B64MDgeoDAwAAAAkAwQA9gaoDPYGrgzqBq4M6gaoDAwAAAAkAwQA0gaoDNIGrgzGBq4MxgaoDAwA AAAkAwQArgaoDK4GrgyiBq4MogaoDAwAAAAkAwQAigaoDIoGrgx+Bq4MfgaoDAwAAAAkAwQAZgao DGYGrgxaBq4MWgaoDAwAAAAkAwQAQgaoDEIGrgw2Bq4MNgaoDAwAAAAkAwQAHgaoDB4GrgwSBq4M EgaoDAwAAAAkAwQA+gWoDPoFrgzuBa4M7gWoDAwAAAAkAwQA1gWoDNYFrgzKBa4MygWoDAwAAAAk AwQAsgWoDLIFrgymBa4MpgWoDAwAAAAkAwQAjgWoDI4FrgyCBa4MggWoDAwAAAAkAwQAagWoDGoF rgxeBa4MXgWoDAQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU AqsMRgUFAAAAEwK/DGQFBAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCqwxGBQUAAAATApcMZAUEAAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAAAgEBAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCzA1HBQUAAAATAswNwgAEAAAALQEDAAQAAADwAQgA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFALMDcIABQAAABMC3w3fAAQAAAAtAQMABAAA APABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAUAswNwgAFAAAAEwK4Dd8ABAAAAC0B AwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU AswN5AkFAAAAEwLMDUYFBAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCzA1GBQUAAAATAt8NZAUEAAAALQEDAAQAAADwAQgACQAAAPoCAAAGAAAAAAAAACIABAAA AC0BCAAFAAAAFALMDUYFBQAAABMCuA1kBQQAAAAtAQMABAAAAPABCAAEAAAAAgEBAAQAAAACAQEA BAAAAC0BAgAEAAAALQEHAAwAAAAkAwQAwgATD8IAGQ/OABkPzgATDwwAAAAkAwQA5gATD+YAGQ/y ABkP8gATDwwAAAAkAwQACgETDwoBGQ8WARkPFgETDwwAAAAkAwQALgETDy4BGQ86ARkPOgETDwwA AAAkAwQAUgETD1IBGQ9eARkPXgETDwwAAAAkAwQAdgETD3YBGQ+CARkPggETDwwAAAAkAwQAmgET D5oBGQ+mARkPpgETDwwAAAAkAwQAvgETD74BGQ/KARkPygETDwwAAAAkAwQA4gETD+IBGQ/uARkP 7gETDwwAAAAkAwQABgITDwYCGQ8SAhkPEgITDwwAAAAkAwQAKgITDyoCGQ82AhkPNgITDwwAAAAk AwQATgITD04CGQ9aAhkPWgITDwwAAAAkAwQAcgITD3ICGQ9+AhkPfgITDwwAAAAkAwQAlgITD5YC GQ+iAhkPogITDwwAAAAkAwQAugITD7oCGQ/GAhkPxgITDwwAAAAkAwQA3gITD94CGQ/qAhkP6gIT DwwAAAAkAwQAAgMTDwIDGQ8PAxkPDwMTDwwAAAAkAwQAJwMTDycDGQ8zAxkPMwMTDwwAAAAkAwQA SwMTD0sDGQ9XAxkPVwMTDwwAAAAkAwQAbwMTD28DGQ97AxkPewMTDwwAAAAkAwQAkwMTD5MDGQ+f AxkPnwMTDwwAAAAkAwQAtwMTD7cDGQ/DAxkPwwMTDwwAAAAkAwQA2wMTD9sDGQ/nAxkP5wMTDwwA AAAkAwQA/wMTD/8DGQ8LBBkPCwQTDwwAAAAkAwQAIwQTDyMEGQ8vBBkPLwQTDwwAAAAkAwQARwQT D0cEGQ9TBBkPUwQTDwwAAAAkAwQAawQTD2sEGQ93BBkPdwQTDwwAAAAkAwQAjwQTD48EGQ+bBBkP mwQTDwwAAAAkAwQAswQTD7MEGQ+/BBkPvwQTDwwAAAAkAwQA1wQTD9cEGQ/jBBkP4wQTDwwAAAAk AwQA+wQTD/sEGQ8HBRkPBwUTDwwAAAAkAwQAHwUTDx8FGQ8rBRkPKwUTDwwAAAAkAwQAQwUTD0MF GQ9HBRkPRwUTDwQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU AhYPRwUFAAAAEwICDyoFBAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCFg9HBQUAAAATAioPKgUEAAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAAAgEBAAQAAAAt AQIABAAAAC0BBwAMAAAAJAMEAEYFEw9GBRkPUgUZD1IFEw8MAAAAJAMEAGoFEw9qBRkPdgUZD3YF Ew8MAAAAJAMEAI4FEw+OBRkPmgUZD5oFEw8MAAAAJAMEALIFEw+yBRkPvgUZD74FEw8MAAAAJAME ANYFEw/WBRkP4gUZD+IFEw8MAAAAJAMEAPoFEw/6BRkPBgYZDwYGEw8MAAAAJAMEAB4GEw8eBhkP KgYZDyoGEw8MAAAAJAMEAEIGEw9CBhkPTgYZD04GEw8MAAAAJAMEAGYGEw9mBhkPcgYZD3IGEw8M AAAAJAMEAIoGEw+KBhkPlgYZD5YGEw8MAAAAJAMEAK4GEw+uBhkPugYZD7oGEw8MAAAAJAMEANIG Ew/SBhkP3gYZD94GEw8MAAAAJAMEAPYGEw/2BhkPAgcZDwIHEw8MAAAAJAMEABoHEw8aBxkPJgcZ DyYHEw8MAAAAJAMEAD4HEw8+BxkPSgcZD0oHEw8MAAAAJAMEAGIHEw9iBxkPbgcZD24HEw8MAAAA JAMEAIYHEw+GBxkPkgcZD5IHEw8MAAAAJAMEAKoHEw+qBxkPtgcZD7YHEw8MAAAAJAMEAM4HEw/O BxkP2gcZD9oHEw8MAAAAJAMEAPIHEw/yBxkP/gcZD/4HEw8MAAAAJAMEABYIEw8WCBkPIggZDyII Ew8MAAAAJAMEADoIEw86CBkPRggZD0YIEw8MAAAAJAMEAF4IEw9eCBkPaggZD2oIEw8MAAAAJAME AIIIEw+CCBkPjggZD44IEw8MAAAAJAMEAKYIEw+mCBkPsggZD7IIEw8MAAAAJAMEAMoIEw/KCBkP 1ggZD9YIEw8MAAAAJAMEAO4IEw/uCBkP+ggZD/oIEw8MAAAAJAMEABIJEw8SCRkPHgkZDx4JEw8M AAAAJAMEADYJEw82CRkPQgkZD0IJEw8MAAAAJAMEAFoJEw9aCRkPZgkZD2YJEw8MAAAAJAMEAH4J Ew9+CRkPigkZD4oJEw8MAAAAJAMEAKIJEw+iCRkPrgkZD64JEw8MAAAAJAMEAMYJEw/GCRkP0gkZ D9IJEw8EAAAALQEFAAQAAAAtAQMACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAIWD+oJ BQAAABMCAg/NCQQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU AhYP6gkFAAAAEwIqD80JBAAAAC0BAwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAJAAAA+gIAAAYA AAAAAAAAIgAEAAAALQEIAAUAAAAUAhcQRgUFAAAAEwIXEOQJBAAAAC0BAwAEAAAA8AEIAAkAAAD6 AgAABgAAAAAAAAAiAAQAAAAtAQgABQAAABQCFxDkCQUAAAATAgMQxwkEAAAALQEDAAQAAADwAQgA CQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAIXEOQJBQAAABMCKhDHCQQAAAAtAQMABAAA APABCAAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAIXEMIA BQAAABMCFxBHBQQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU AhcQRwUFAAAAEwIDECoFBAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAiAAQAAAAtAQgA BQAAABQCFxBHBQUAAAATAioQKgUEAAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAAAgEBAAQAAAAt AQIABAAAAC0BBwAMAAAAJAMEAEcFkw9HBZkPOwWZDzsFkw8MAAAAJAMEACMFkw8jBZkPFwWZDxcF kw8MAAAAJAMEAP8Ekw//BJkP8wSZD/MEkw8MAAAAJAMEANsEkw/bBJkPzwSZD88Ekw8MAAAAJAME ALcEkw+3BJkPqwSZD6sEkw8MAAAAJAMEAJMEkw+TBJkPhwSZD4cEkw8MAAAAJAMEAG8Ekw9vBJkP YwSZD2MEkw8MAAAAJAMEAEsEkw9LBJkPPwSZDz8Ekw8MAAAAJAMEACcEkw8nBJkPGwSZDxsEkw8M AAAAJAMEAAMEkw8DBJkP9wOZD/cDkw8MAAAAJAMEAN8Dkw/fA5kP0wOZD9MDkw8MAAAAJAMEALsD kw+7A5kPrwOZD68Dkw8MAAAAJAMEAJcDkw+XA5kPiwOZD4sDkw8MAAAAJAMEAHMDkw9zA5kPZwOZ D2cDkw8MAAAAJAMEAE8Dkw9PA5kPQwOZD0MDkw8MAAAAJAMEACsDkw8rA5kPHwOZDx8Dkw8MAAAA JAMEAAcDkw8HA5kP+gKZD/oCkw8MAAAAJAMEAOICkw/iApkP1gKZD9YCkw8MAAAAJAMEAL4Ckw++ ApkPsgKZD7ICkw8MAAAAJAMEAJoCkw+aApkPjgKZD44Ckw8MAAAAJAMEAHYCkw92ApkPagKZD2oC kw8MAAAAJAMEAFICkw9SApkPRgKZD0YCkw8MAAAAJAMEAC4Ckw8uApkPIgKZDyICkw8MAAAAJAME AAoCkw8KApkP/gGZD/4Bkw8MAAAAJAMEAOYBkw/mAZkP2gGZD9oBkw8MAAAAJAMEAMIBkw/CAZkP tgGZD7YBkw8MAAAAJAMEAJ4Bkw+eAZkPkgGZD5IBkw8MAAAAJAMEAHoBkw96AZkPbgGZD24Bkw8M AAAAJAMEAFYBkw9WAZkPSgGZD0oBkw8MAAAAJAMEADIBkw8yAZkPJgGZDyYBkw8MAAAAJAMEAA4B kw8OAZkPAgGZDwIBkw8MAAAAJAMEAOoAkw/qAJkP3gCZD94Akw8MAAAAJAMEAMYAkw/GAJkPwgCZ D8IAkw8EAAAALQEFAAQAAAAtAQMACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAFAAAAFAKWD8IA BQAAABMCqg/fAAQAAAAtAQMABAAAAPABCAAJAAAA+gIAAAYAAAAAAAAAIgAEAAAALQEIAAUAAAAU ApYPwgAFAAAAEwKDD98ABAAAAC0BAwAEAAAA8AEIAAQAAAACAQEABAAAAAIBAQAEAAAALQECAAQA AAAtAQcADAAAACQDBADqCZMP6gmZD94JmQ/eCZMPDAAAACQDBADGCZMPxgmZD7oJmQ+6CZMPDAAA ACQDBACiCZMPogmZD5YJmQ+WCZMPDAAAACQDBAB+CZMPfgmZD3IJmQ9yCZMPDAAAACQDBABaCZMP WgmZD04JmQ9OCZMPDAAAACQDBAA2CZMPNgmZDyoJmQ8qCZMPDAAAACQDBAASCZMPEgmZDwYJmQ8G CZMPDAAAACQDBADuCJMP7giZD+IImQ/iCJMPDAAAACQDBADKCJMPygiZD74ImQ++CJMPDAAAACQD BACmCJMPpgiZD5oImQ+aCJMPDAAAACQDBACCCJMPggiZD3YImQ92CJMPDAAAACQDBABeCJMPXgiZ D1IImQ9SCJMPDAAAACQDBAA6CJMPOgiZDy4ImQ8uCJMPDAAAACQDBAAWCJMPFgiZDwoImQ8KCJMP DAAAACQDBADyB5MP8geZD+YHmQ/mB5MPDAAAACQDBADOB5MPzgeZD8IHmQ/CB5MPDAAAACQDBACq B5MPqgeZD54HmQ+eB5MPDAAAACQDBACGB5MPhgeZD3oHmQ96B5MPDAAAACQDBABiB5MPYgeZD1YH mQ9WB5MPDAAAACQDBAA+B5MPPgeZDzIHmQ8yB5MPDAAAACQDBAAaB5MPGgeZDw4HmQ8OB5MPDAAA ACQDBAD2BpMP9gaZD+oGmQ/qBpMPDAAAACQDBADSBpMP0gaZD8YGmQ/GBpMPDAAAACQDBACuBpMP rgaZD6IGmQ+iBpMPDAAAACQDBACKBpMPigaZD34GmQ9+BpMPDAAAACQDBABmBpMPZgaZD1oGmQ9a BpMPDAAAACQDBABCBpMPQgaZDzYGmQ82BpMPDAAAACQDBAAeBpMPHgaZDxIGmQ8SBpMPDAAAACQD BAD6BZMP+gWZD+4FmQ/uBZMPDAAAACQDBADWBZMP1gWZD8oFmQ/KBZMPDAAAACQDBACyBZMPsgWZ D6YFmQ+mBZMPDAAAACQDBACOBZMPjgWZD4IFmQ+CBZMPDAAAACQDBABqBZMPagWZD14FmQ9eBZMP DAAAACQDBABGBZMPRgWZD0AFmQ9ABZMPBAAAAC0BBQAEAAAALQEDAAkAAAD6AgAABgAAAAAAAAAi AAQAAAAtAQgABQAAABQClg9ABQUAAAATAqoPXQUEAAAALQEDAAQAAADwAQgACQAAAPoCAAAGAAAA AAAAACIABAAAAC0BCAAFAAAAFAKWD0AFBQAAABMCgw9dBQQAAAAtAQMABAAAAPABCAAEAAAAAgEB AAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQATgXZCU4F3wlCBd8JQgXZCQwAAAAkAwQA KgXZCSoF3wkeBd8JHgXZCQwAAAAkAwQABgXZCQYF3wn6BN8J+gTZCQwAAAAkAwQA4gTZCeIE3wnW BN8J1gTZCQwAAAAkAwQAvgTZCb4E3wmyBN8JsgTZCQwAAAAkAwQAmgTZCZoE3wmOBN8JjgTZCQwA AAAkAwQAdgTZCXYE3wlqBN8JagTZCQwAAAAkAwQAUgTZCVIE3wlGBN8JRgTZCQwAAAAkAwQALgTZ CS4E3wkiBN8JIgTZCQwAAAAkAwQACgTZCQoE3wn+A98J/gPZCQwAAAAkAwQA5gPZCeYD3wnaA98J 2gPZCQwAAAAkAwQAwgPZCcID3wm2A98JtgPZCQwAAAAkAwQAngPZCZ4D3wmSA98JkgPZCQwAAAAk AwQAegPZCXoD3wluA98JbgPZCQwAAAAkAwQAVgPZCVYD3wlKA98JSgPZCQwAAAAkAwQAMgPZCTID 3wkmA98JJgPZCQwAAAAkAwQADgPZCQ4D3wkCA98JAgPZCQwAAAAkAwQA6gLZCeoC3wneAt8J3gLZ CQwAAAAkAwQAxgLZCcYC3wm6At8JugLZCQwAAAAkAwQAogLZCaIC3wmWAt8JlgLZCQwAAAAkAwQA fgLZCX4C3wlyAt8JcgLZCQwAAAAkAwQAWgLZCVoC3wlOAt8JTgLZCQwAAAAkAwQANgLZCTYC3wkq At8JKgLZCQwAAAAkAwQAEgLZCRIC3wkGAt8JBgLZCQwAAAAkAwQA7gHZCe4B3wniAd8J4gHZCQwA AAAkAwQAygHZCcoB3wm+Ad8JvgHZCQwAAAAkAwQApgHZCaYB3wmaAd8JmgHZCQwAAAAkAwQAggHZ CYIB3wl2Ad8JdgHZCQwAAAAkAwQAXgHZCV4B3wlSAd8JUgHZCQwAAAAkAwQAOgHZCToB3wkuAd8J LgHZCQwAAAAkAwQAFgHZCRYB3wkKAd8JCgHZCQwAAAAkAwQA8gDZCfIA3wnmAN8J5gDZCQwAAAAk AwQAzgDZCc4A3wnIAN8JyADZCQQAAAAtAQUABAAAAC0BAwAJAAAA+gIAAAYAAAAAAAAAIgAEAAAA LQEIAAUAAAAUAtwJyAAFAAAAEwLwCeYABAAAAC0BAwAEAAAA8AEIAAkAAAD6AgAABgAAAAAAAAAi AAQAAAAtAQgABQAAABQC3AnIAAUAAAATAsgJ5gAEAAAALQEDAAQAAADwAQgABAAAAAIBAQAEAAAA AgEBAAQAAAAtAQUACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCAAHAAAAGwSoDswGGw7sAwQAAAAt AQMABAAAAPABCAAEAAAALQEFAAQAAAACAQEAAwAAAB4ABwAAABYEnA7ABiYO9wMEAAAAAgEBAAQA AAAtAQQAHQAAADIKKQ5nBAwABAAAAAAAYhBvE0NvbnZlcnNhdGlvbjwALgAuACkALgAcACoALgAX ABIALgAuAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAAtAQUACQAAAPoCAAACAAAAAAAAACIA BAAAAC0BCAAHAAAAGwS0CPkPNgg2DQQAAAAtAQMABAAAAPABCAAEAAAALQEFAAQAAAACAQEAAwAA AB4ABwAAABYEqgjvDz8IPw0EAAAAAgEBAAQAAAAtAQQAGgAAADIKQgjTDQoABAAAAAAAYhBvE09f QWxlcnRpbmdBAC4ANwASAC4AHAAXABIALgAuAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAAt AQUACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAHAAAAGwTlBvkPZwY2DQQAAAAtAQMABAAAAPAB CAAEAAAALQEFAAQAAAACAQEAAwAAAB4ABwAAABYE2wbvD3AGPw0EAAAAAgEBAAQAAAAtAQQAGQAA ADIKcwbYDQkABAAAAAAAYhBvE1NlbmRfQ2FsbAA3AC4ALgAuAC4APAAuABIAEgAEAAAAAgEBAAQA AAAnAf//BAAAAAIBAQAEAAAALQEFAAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQgABwAAABsEHQb5 D58FNg0EAAAALQEDAAQAAADwAQgABAAAAC0BBQAEAAAAAgEBAAMAAAAeAAcAAAAWBBMG7w+oBT8N BAAAAAIBAQAEAAAALQEEACIAAAAyCqsFYQ0PAAQAAAAAAGIQbxNBdXRoX0NhbGxfU2V0dXAANwAu ABcALgAuADwALgASABIALgA3AC4AFwAuAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0B BQAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEIAAcAAAAbBGIF+Q/kBDYNBAAAAC0BAwAEAAAA8AEI AAQAAAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgRYBe8P7QQ/DQQAAAACAQEABAAAAC0BBAAdAAAA MgrwBKoNDAAEAAAAAABiEG8TU2VsZWN0IFJvdXRlNwAuABIALgAqABcAFwA8AC4ALgAXAC4ABAAA AAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BBQAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEIAAcA AAAbBJoE+Q8cBDYNBAAAAC0BAwAEAAAA8AEIAAQAAAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgSQ BO8PJQQ/DQQAAAACAQEABAAAAC0BBAAdAAAAMgooBLQNDAAEAAAAAABiEG8TQW5hbHlzZSBJbmZv NwAuAC4AEgAnACoALgAXABcALgAYAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAC0BBQAJ AAAA+gIAAAIAAAAAAAAAIgAEAAAALQEIAAcAAAAbBFgQ+Q/aDzYNBAAAAC0BAwAEAAAA8AEIAAQA AAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgROEO8P4w8/DQQAAAACAQEABAAAAC0BBAAUAAAAMgrm DxgOBgAEAAAAAABiEG8TT19OdWxsQQAuADwALgASABIABAAAAAIBAQAEAAAAJwH//wQAAAACAQEA BAAAAC0BBQAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEIAAcAAAAbBBwD+Q+eAjYNBAAAAC0BAwAE AAAA8AEIAAQAAAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgQTA+8PqAI/DQQAAAACAQEABAAAAC0B BAAfAAAAMgqrApMNDQAEAAAAAABiEG8TQXV0aF9PcmlnX0F0dAA3AC4AFwAuAC4AQQAcABIALgAu ADcAFwAXAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAAtAQUACQAAAPoCAAACAAAAAAAAACIA BAAAAC0BCAAHAAAAGwTSA/kPVAM2DQQAAAAtAQMABAAAAPABCAAEAAAALQEFAAQAAAACAQEAAwAA AB4ABwAAABYEyAPvD10DPw0EAAAAAgEBAAQAAAAtAQQAHQAAADIKYAPHDQwABAAAAAAAYhBvE0Nv bGxlY3QgSW5mbzwALgASABIALgAqABcAFwAXAC4AGAAuAAQAAAACAQEABAAAACcB//8EAAAAAgEB AAcAAAD8AgEAAAAAAAAABAAAAC0BCAAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEJAAcAAAAbBHQC +Q/2ATYNBAAAAC0BAwAEAAAA8AEJAAQAAAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgRqAu8P/wE/ DQQAAAACAQEABAAAAC0BBAAUAAAAMgoCAvUNBgAEAAAAAABiEG8TT19OVUxMQQAuADwAPAAuAC4A BAAAAAIBAQAEAAAAJwH//wQAAAACAQEACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCQAFAAAAFAL5 DZoOBQAAABMCvg+aDgQAAAAtAQMABAAAAPABCQAEAAAALQECAAkAAAD6AgAAAQAAAAAAAAAiAAQA AAAtAQkACgAAACQDAwCxDrYPgw62D5oO1A8EAAAALQEFAAQAAAAtAQMABAAAAPABCQAEAAAAAgEB AAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQARgUgAkYFIgJKBSICSgUgAgwAAAAkAwQA UgUgAlIFIgJWBSICVgUgAgwAAAAkAwQAXgUgAl4FIgJiBSICYgUgAgwAAAAkAwQAagUgAmoFIgJu BSICbgUgAgwAAAAkAwQAdgUgAnYFIgJ6BSICegUgAgwAAAAkAwQAggUgAoIFIgKGBSIChgUgAgwA AAAkAwQAjgUgAo4FIgKSBSICkgUgAgwAAAAkAwQAmgUgApoFIgKeBSICngUgAgwAAAAkAwQApgUg AqYFIgKqBSICqgUgAgwAAAAkAwQAsgUgArIFIgK2BSICtgUgAgwAAAAkAwQAvgUgAr4FIgLCBSIC wgUgAgwAAAAkAwQAygUgAsoFIgLOBSICzgUgAgwAAAAkAwQA1gUgAtYFIgLaBSIC2gUgAgwAAAAk AwQA4gUgAuIFIgLmBSIC5gUgAgwAAAAkAwQA7gUgAu4FIgLyBSIC8gUgAgwAAAAkAwQA+gUgAvoF IgL+BSIC/gUgAgwAAAAkAwQABgYgAgYGIgIKBiICCgYgAgwAAAAkAwQAEgYgAhIGIgIWBiICFgYg AgwAAAAkAwQAHgYgAh4GIgIiBiICIgYgAgwAAAAkAwQAKgYgAioGIgIuBiICLgYgAgwAAAAkAwQA NgYgAjYGIgI6BiICOgYgAgwAAAAkAwQAQgYgAkIGIgJGBiICRgYgAgwAAAAkAwQATgYgAk4GIgJS BiICUgYgAgwAAAAkAwQAWgYgAloGIgJeBiICXgYgAgwAAAAkAwQAZgYgAmYGIgJqBiICagYgAgwA AAAkAwQAcgYgAnIGIgJ2BiICdgYgAgwAAAAkAwQAfgYgAn4GIgKCBiICggYgAgwAAAAkAwQAigYg AooGIgKOBiICjgYgAgwAAAAkAwQAlgYgApYGIgKaBiICmgYgAgwAAAAkAwQAogYgAqIGIgKmBiIC pgYgAgwAAAAkAwQArgYgAq4GIgKyBiICsgYgAgwAAAAkAwQAugYgAroGIgK+BiICvgYgAgwAAAAk AwQAxgYgAsYGIgLKBiICygYgAgwAAAAkAwQA0gYgAtIGIgLWBiIC1gYgAgwAAAAkAwQA3gYgAt4G IgLiBiIC4gYgAgwAAAAkAwQA6gYgAuoGIgLuBiIC7gYgAgwAAAAkAwQA9gYgAvYGIgL6BiIC+gYg AgwAAAAkAwQAAgcgAgIHIgIGByICBgcgAgwAAAAkAwQADgcgAg4HIgISByICEgcgAgwAAAAkAwQA GgcgAhoHIgIeByICHgcgAgwAAAAkAwQAJgcgAiYHIgIqByICKgcgAgwAAAAkAwQAMgcgAjIHIgI2 ByICNgcgAgwAAAAkAwQAPgcgAj4HIgJCByICQgcgAgwAAAAkAwQASgcgAkoHIgJOByICTgcgAgwA AAAkAwQAVgcgAlYHIgJaByICWgcgAgwAAAAkAwQAYgcgAmIHIgJmByICZgcgAgwAAAAkAwQAbgcg Am4HIgJyByICcgcgAgwAAAAkAwQAegcgAnoHIgJ+ByICfgcgAgwAAAAkAwQAhgcgAoYHIgKKByIC igcgAgwAAAAkAwQAkgcgApIHIgKWByIClgcgAgwAAAAkAwQAngcgAp4HIgKiByICogcgAgwAAAAk AwQAqgcgAqoHIgKuByICrgcgAgwAAAAkAwQAtgcgArYHIgK6ByICugcgAgwAAAAkAwQAwgcgAsIH IgLGByICxgcgAgwAAAAkAwQAzgcgAs4HIgLSByIC0gcgAgwAAAAkAwQA2gcgAtoHIgLeByIC3gcg AgwAAAAkAwQA5gcgAuYHIgLqByIC6gcgAgwAAAAkAwQA8gcgAvIHIgL2ByIC9gcgAgwAAAAkAwQA /gcgAv4HIgICCCICAgggAgwAAAAkAwQACgggAgoIIgIOCCICDgggAgwAAAAkAwQAFgggAhYIIgIa CCICGgggAgwAAAAkAwQAIgggAiIIIgImCCICJgggAgwAAAAkAwQALgggAi4IIgIyCCICMgggAgwA AAAkAwQAOgggAjoIIgI+CCICPgggAgwAAAAkAwQARgggAkYIIgJKCCICSgggAgwAAAAkAwQAUggg AlIIIgJWCCICVgggAgwAAAAkAwQAXgggAl4IIgJiCCICYgggAgwAAAAkAwQAagggAmoIIgJuCCIC bgggAgwAAAAkAwQAdgggAnYIIgJ6CCICegggAgwAAAAkAwQAggggAoIIIgKGCCIChgggAgwAAAAk AwQAjgggAo4IIgKSCCICkgggAgwAAAAkAwQAmgggApoIIgKeCCICngggAgwAAAAkAwQApgggAqYI IgKqCCICqgggAgwAAAAkAwQAsgggArIIIgK2CCICtgggAgwAAAAkAwQAvgggAr4IIgLCCCICwggg AgwAAAAkAwQAygggAsoIIgLOCCICzgggAgwAAAAkAwQA1gggAtYIIgLaCCIC2gggAgwAAAAkAwQA 4gggAuIIIgLmCCIC5gggAgwAAAAkAwQA7gggAu4IIgLyCCIC8gggAgwAAAAkAwQA+gggAvoIIgL+ CCIC/gggAgwAAAAkAwQABgkgAgYJIgIKCSICCgkgAgwAAAAkAwQAEgkgAhIJIgIWCSICFgkgAgwA AAAkAwQAHgkgAh4JIgIiCSICIgkgAgwAAAAkAwQAKgkgAioJIgIuCSICLgkgAgwAAAAkAwQANgkg AjYJIgI6CSICOgkgAgwAAAAkAwQAQgkgAkIJIgJGCSICRgkgAgwAAAAkAwQATgkgAk4JIgJSCSIC UgkgAgwAAAAkAwQAWgkgAloJIgJeCSICXgkgAgwAAAAkAwQAZgkgAmYJIgJqCSICagkgAgwAAAAk AwQAcgkgAnIJIgJ2CSICdgkgAgwAAAAkAwQAfgkgAn4JIgKCCSICggkgAgwAAAAkAwQAigkgAooJ IgKOCSICjgkgAgwAAAAkAwQAlgkgApYJIgKaCSICmgkgAgwAAAAkAwQAogkgAqIJIgKmCSICpgkg AgwAAAAkAwQArgkgAq4JIgKyCSICsgkgAgwAAAAkAwQAugkgAroJIgK+CSICvgkgAgwAAAAkAwQA xgkgAsYJIgLKCSICygkgAgwAAAAkAwQA0gkgAtIJIgLWCSIC1gkgAgwAAAAkAwQA3gkgAt4JIgLi CSIC4gkgAgwAAAAkAwQA6gkgAuoJIgLuCSIC7gkgAgwAAAAkAwQA9gkgAvYJIgL6CSIC+gkgAgwA AAAkAwQAAgogAgIKIgIGCiICBgogAgwAAAAkAwQADgogAg4KIgISCiICEgogAgwAAAAkAwQAGgog AhoKIgIeCiICHgogAgwAAAAkAwQAJgogAiYKIgIqCiICKgogAgwAAAAkAwQAMgogAjIKIgI2CiIC NgogAgwAAAAkAwQAPgogAj4KIgJCCiICQgogAgwAAAAkAwQASgogAkoKIgJOCiICTgogAgwAAAAk AwQAVgogAlYKIgJaCiICWgogAgwAAAAkAwQAYgogAmIKIgJmCiICZgogAgwAAAAkAwQAbgogAm4K IgJyCiICcgogAgwAAAAkAwQAegogAnoKIgJ+CiICfgogAgwAAAAkAwQAhgogAoYKIgKKCiICigog AgwAAAAkAwQAkgogApIKIgKWCiIClgogAgwAAAAkAwQAngogAp4KIgKiCiICogogAgwAAAAkAwQA qgogAqoKIgKuCiICrgogAgwAAAAkAwQAtgogArYKIgK6CiICugogAgwAAAAkAwQAwgogAsIKIgLG CiICxgogAgwAAAAkAwQAzgogAs4KIgLSCiIC0gogAgwAAAAkAwQA2gogAtoKIgLeCiIC3gogAgwA AAAkAwQA5gogAuYKIgLqCiIC6gogAgwAAAAkAwQA8gogAvIKIgL2CiIC9gogAgwAAAAkAwQA/gog Av4KIgICCyICAgsgAgwAAAAkAwQACgsgAgoLIgIOCyICDgsgAgwAAAAkAwQAFgsgAhYLIgIaCyIC GgsgAgwAAAAkAwQAIgsgAiILIgImCyICJgsgAgwAAAAkAwQALgsgAi4LIgIyCyICMgsgAgwAAAAk AwQAOgsgAjoLIgI+CyICPgsgAgwAAAAkAwQARgsgAkYLIgJKCyICSgsgAgwAAAAkAwQAUgsgAlIL IgJWCyICVgsgAgwAAAAkAwQAXgsgAl4LIgJiCyICYgsgAgwAAAAkAwQAagsgAmoLIgJuCyICbgsg AgwAAAAkAwQAdgsgAnYLIgJ6CyICegsgAgwAAAAkAwQAggsgAoILIgKGCyIChgsgAgwAAAAkAwQA jgsgAo4LIgKSCyICkgsgAgwAAAAkAwQAmgsgApoLIgKeCyICngsgAgwAAAAkAwQApgsgAqYLIgKq CyICqgsgAgwAAAAkAwQAsgsgArILIgK2CyICtgsgAgwAAAAkAwQAvgsgAr4LIgLCCyICwgsgAgwA AAAkAwQAygsgAsoLIgLOCyICzgsgAgwAAAAkAwQA1gsgAtYLIgLaCyIC2gsgAgwAAAAkAwQA4gsg AuILIgLmCyIC5gsgAgwAAAAkAwQA7gsgAu4LIgLyCyIC8gsgAgwAAAAkAwQA+gsgAvoLIgL+CyIC /gsgAgwAAAAkAwQABgwgAgYMIgIKDCICCgwgAgwAAAAkAwQAEgwgAhIMIgIWDCICFgwgAgwAAAAk AwQAHgwgAh4MIgIiDCICIgwgAgwAAAAkAwQAKgwgAioMIgIuDCICLgwgAgwAAAAkAwQANgwgAjYM IgI6DCICOgwgAgwAAAAkAwQAQgwgAkIMIgJGDCICRgwgAgwAAAAkAwQATgwgAk4MIgJSDCICUgwg AgwAAAAkAwQAWgwgAloMIgJeDCICXgwgAgwAAAAkAwQAZgwgAmYMIgJqDCICagwgAgwAAAAkAwQA cgwgAnIMIgJ2DCICdgwgAgwAAAAkAwQAfgwgAn4MIgKCDCICggwgAgwAAAAkAwQAigwgAooMIgKO DCICjgwgAgwAAAAkAwQAlgwgApYMIgKaDCICmgwgAgwAAAAkAwQAogwgAqIMIgKmDCICpgwgAgwA AAAkAwQArgwgAq4MIgKyDCICsgwgAgwAAAAkAwQAugwgAroMIgK+DCICvgwgAgwAAAAkAwQAxgwg AsYMIgLKDCICygwgAgwAAAAkAwQA0gwgAtIMIgLWDCIC1gwgAgwAAAAkAwQA3gwgAt4MIgLiDCIC 4gwgAgwAAAAkAwQA6gwgAuoMIgLuDCIC7gwgAgwAAAAkAwQA9gwgAvYMIgL6DCIC+gwgAgwAAAAk AwQAAg0gAgINIgIGDSICBg0gAgwAAAAkAwQADg0gAg4NIgISDSICEg0gAgwAAAAkAwQAGg0gAhoN IgIeDSICHg0gAgwAAAAkAwQAJg0gAiYNIgIqDSICKg0gAgwAAAAkAwQAMg0gAjINIgI2DSICNg0g AgQAAAAtAQUABAAAAC0BAwAEAAAAAgEBAAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQA 6gkXEOoJGRDuCRkQ7gkXEAwAAAAkAwQA9gkXEPYJGRD6CRkQ+gkXEAwAAAAkAwQAAgoXEAIKGRAG ChkQBgoXEAwAAAAkAwQADgoXEA4KGRASChkQEgoXEAwAAAAkAwQAGgoXEBoKGRAeChkQHgoXEAwA AAAkAwQAJgoXECYKGRAqChkQKgoXEAwAAAAkAwQAMgoXEDIKGRA2ChkQNgoXEAwAAAAkAwQAPgoX ED4KGRBCChkQQgoXEAwAAAAkAwQASgoXEEoKGRBOChkQTgoXEAwAAAAkAwQAVgoXEFYKGRBaChkQ WgoXEAwAAAAkAwQAYgoXEGIKGRBmChkQZgoXEAwAAAAkAwQAbgoXEG4KGRByChkQcgoXEAwAAAAk AwQAegoXEHoKGRB+ChkQfgoXEAwAAAAkAwQAhgoXEIYKGRCKChkQigoXEAwAAAAkAwQAkgoXEJIK GRCWChkQlgoXEAwAAAAkAwQAngoXEJ4KGRCiChkQogoXEAwAAAAkAwQAqgoXEKoKGRCuChkQrgoX EAwAAAAkAwQAtgoXELYKGRC6ChkQugoXEAwAAAAkAwQAwgoXEMIKGRDGChkQxgoXEAwAAAAkAwQA zgoXEM4KGRDSChkQ0goXEAwAAAAkAwQA2goXENoKGRDeChkQ3goXEAwAAAAkAwQA5goXEOYKGRDq ChkQ6goXEAwAAAAkAwQA8goXEPIKGRD2ChkQ9goXEAwAAAAkAwQA/goXEP4KGRACCxkQAgsXEAwA AAAkAwQACgsXEAoLGRAOCxkQDgsXEAwAAAAkAwQAFgsXEBYLGRAaCxkQGgsXEAwAAAAkAwQAIgsX ECILGRAmCxkQJgsXEAwAAAAkAwQALgsXEC4LGRAyCxkQMgsXEAwAAAAkAwQAOgsXEDoLGRA+CxkQ PgsXEAwAAAAkAwQARgsXEEYLGRBKCxkQSgsXEAwAAAAkAwQAUgsXEFILGRBWCxkQVgsXEAwAAAAk AwQAXgsXEF4LGRBiCxkQYgsXEAwAAAAkAwQAagsXEGoLGRBuCxkQbgsXEAwAAAAkAwQAdgsXEHYL GRB6CxkQegsXEAwAAAAkAwQAggsXEIILGRCGCxkQhgsXEAwAAAAkAwQAjgsXEI4LGRCSCxkQkgsX EAwAAAAkAwQAmgsXEJoLGRCeCxkQngsXEAwAAAAkAwQApgsXEKYLGRCqCxkQqgsXEAwAAAAkAwQA sgsXELILGRC2CxkQtgsXEAwAAAAkAwQAvgsXEL4LGRDCCxkQwgsXEAwAAAAkAwQAygsXEMoLGRDO CxkQzgsXEAwAAAAkAwQA1gsXENYLGRDaCxkQ2gsXEAwAAAAkAwQA4gsXEOILGRDmCxkQ5gsXEAwA AAAkAwQA7gsXEO4LGRDyCxkQ8gsXEAwAAAAkAwQA+gsXEPoLGRD+CxkQ/gsXEAwAAAAkAwQABgwX EAYMGRAKDBkQCgwXEAwAAAAkAwQAEgwXEBIMGRAWDBkQFgwXEAwAAAAkAwQAHgwXEB4MGRAiDBkQ IgwXEAwAAAAkAwQAKgwXECoMGRAuDBkQLgwXEAwAAAAkAwQANgwXEDYMGRA6DBkQOgwXEAwAAAAk AwQAQgwXEEIMGRBGDBkQRgwXEAwAAAAkAwQATgwXEE4MGRBSDBkQUgwXEAwAAAAkAwQAWgwXEFoM GRBeDBkQXgwXEAwAAAAkAwQAZgwXEGYMGRBqDBkQagwXEAwAAAAkAwQAcgwXEHIMGRB2DBkQdgwX EAwAAAAkAwQAfgwXEH4MGRCCDBkQggwXEAwAAAAkAwQAigwXEIoMGRCODBkQjgwXEAwAAAAkAwQA lgwXEJYMGRCaDBkQmgwXEAwAAAAkAwQAogwXEKIMGRCmDBkQpgwXEAwAAAAkAwQArgwXEK4MGRCy DBkQsgwXEAwAAAAkAwQAugwXELoMGRC+DBkQvgwXEAwAAAAkAwQAxgwXEMYMGRDKDBkQygwXEAwA AAAkAwQA0gwXENIMGRDWDBkQ1gwXEAwAAAAkAwQA3gwXEN4MGRDiDBkQ4gwXEAwAAAAkAwQA6gwX EOoMGRDuDBkQ7gwXEAwAAAAkAwQA9gwXEPYMGRD6DBkQ+gwXEAwAAAAkAwQAAg0XEAINGRAGDRkQ Bg0XEAwAAAAkAwQADg0XEA4NGRASDRkQEg0XEAwAAAAkAwQAGg0XEBoNGRAeDRkQHg0XEAwAAAAk AwQAJg0XECYNGRAqDRkQKg0XEAwAAAAkAwQAMg0XEDINGRA2DRkQNg0XEAQAAAAtAQUABAAAAC0B AwAEAAAAAgEBAAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQA6gnMDeoJzg3uCc4N7gnM DQwAAAAkAwQA9gnMDfYJzg36Cc4N+gnMDQwAAAAkAwQAAgrMDQIKzg0GCs4NBgrMDQwAAAAkAwQA DgrMDQ4Kzg0SCs4NEgrMDQwAAAAkAwQAGgrMDRoKzg0eCs4NHgrMDQwAAAAkAwQAJgrMDSYKzg0q Cs4NKgrMDQwAAAAkAwQAMgrMDTIKzg02Cs4NNgrMDQwAAAAkAwQAPgrMDT4Kzg1CCs4NQgrMDQwA AAAkAwQASgrMDUoKzg1OCs4NTgrMDQwAAAAkAwQAVgrMDVYKzg1aCs4NWgrMDQwAAAAkAwQAYgrM DWIKzg1mCs4NZgrMDQwAAAAkAwQAbgrMDW4Kzg1yCs4NcgrMDQwAAAAkAwQAegrMDXoKzg1+Cs4N fgrMDQwAAAAkAwQAhgrMDYYKzg2KCs4NigrMDQwAAAAkAwQAkgrMDZIKzg2WCs4NlgrMDQwAAAAk AwQAngrMDZ4Kzg2iCs4NogrMDQwAAAAkAwQAqgrMDaoKzg2uCs4NrgrMDQwAAAAkAwQAtgrMDbYK zg26Cs4NugrMDQwAAAAkAwQAwgrMDcIKzg3GCs4NxgrMDQwAAAAkAwQAzgrMDc4Kzg3SCs4N0grM DQwAAAAkAwQA2grMDdoKzg3eCs4N3grMDQwAAAAkAwQA5grMDeYKzg3qCs4N6grMDQwAAAAkAwQA 8grMDfIKzg32Cs4N9grMDQwAAAAkAwQA/grMDf4Kzg0CC84NAgvMDQwAAAAkAwQACgvMDQoLzg0O C84NDgvMDQwAAAAkAwQAFgvMDRYLzg0aC84NGgvMDQwAAAAkAwQAIgvMDSILzg0mC84NJgvMDQwA AAAkAwQALgvMDS4Lzg0yC84NMgvMDQwAAAAkAwQAOgvMDToLzg0+C84NPgvMDQwAAAAkAwQARgvM DUYLzg1KC84NSgvMDQwAAAAkAwQAUgvMDVILzg1WC84NVgvMDQwAAAAkAwQAXgvMDV4Lzg1iC84N YgvMDQwAAAAkAwQAagvMDWoLzg1uC84NbgvMDQwAAAAkAwQAdgvMDXYLzg16C84NegvMDQwAAAAk AwQAggvMDYILzg2GC84NhgvMDQwAAAAkAwQAjgvMDY4Lzg2SC84NkgvMDQwAAAAkAwQAmgvMDZoL zg2eC84NngvMDQwAAAAkAwQApgvMDaYLzg2qC84NqgvMDQwAAAAkAwQAsgvMDbILzg22C84NtgvM DQwAAAAkAwQAvgvMDb4Lzg3CC84NwgvMDQwAAAAkAwQAygvMDcoLzg3OC84NzgvMDQwAAAAkAwQA 1gvMDdYLzg3aC84N2gvMDQwAAAAkAwQA4gvMDeILzg3mC84N5gvMDQwAAAAkAwQA7gvMDe4Lzg3y C84N8gvMDQwAAAAkAwQA+gvMDfoLzg3+C84N/gvMDQwAAAAkAwQABgzMDQYMzg0KDM4NCgzMDQwA AAAkAwQAEgzMDRIMzg0WDM4NFgzMDQwAAAAkAwQAHgzMDR4Mzg0iDM4NIgzMDQwAAAAkAwQAKgzM DSoMzg0uDM4NLgzMDQwAAAAkAwQANgzMDTYMzg06DM4NOgzMDQwAAAAkAwQAQgzMDUIMzg1GDM4N RgzMDQwAAAAkAwQATgzMDU4Mzg1SDM4NUgzMDQwAAAAkAwQAWgzMDVoMzg1eDM4NXgzMDQwAAAAk AwQAZgzMDWYMzg1qDM4NagzMDQwAAAAkAwQAcgzMDXIMzg12DM4NdgzMDQwAAAAkAwQAfgzMDX4M zg2CDM4NggzMDQwAAAAkAwQAigzMDYoMzg2ODM4NjgzMDQwAAAAkAwQAlgzMDZYMzg2aDM4NmgzM DQwAAAAkAwQAogzMDaIMzg2mDM4NpgzMDQwAAAAkAwQArgzMDa4Mzg2yDM4NsgzMDQwAAAAkAwQA ugzMDboMzg2+DM4NvgzMDQwAAAAkAwQAxgzMDcYMzg3KDM4NygzMDQwAAAAkAwQA0gzMDdIMzg3W DM4N1gzMDQwAAAAkAwQA3gzMDd4Mzg3iDM4N4gzMDQwAAAAkAwQA6gzMDeoMzg3uDM4N7gzMDQwA AAAkAwQA9gzMDfYMzg36DM4N+gzMDQwAAAAkAwQAAg3MDQINzg0GDc4NBg3MDQwAAAAkAwQADg3M DQ4Nzg0SDc4NEg3MDQwAAAAkAwQAGg3MDRoNzg0eDc4NHg3MDQwAAAAkAwQAJg3MDSYNzg0qDc4N Kg3MDQwAAAAkAwQAMg3MDTINzg02Dc4NNg3MDQQAAAAtAQUABAAAAC0BAwAEAAAAAgEBAAQAAAAC AQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQA6gmlBuoJpwbuCacG7gmlBgwAAAAkAwQA9gmlBvYJ pwb6CacG+gmlBgwAAAAkAwQAAgqlBgIKpwYGCqcGBgqlBgwAAAAkAwQADgqlBg4KpwYSCqcGEgql BgwAAAAkAwQAGgqlBhoKpwYeCqcGHgqlBgwAAAAkAwQAJgqlBiYKpwYqCqcGKgqlBgwAAAAkAwQA MgqlBjIKpwY2CqcGNgqlBgwAAAAkAwQAPgqlBj4KpwZCCqcGQgqlBgwAAAAkAwQASgqlBkoKpwZO CqcGTgqlBgwAAAAkAwQAVgqlBlYKpwZaCqcGWgqlBgwAAAAkAwQAYgqlBmIKpwZmCqcGZgqlBgwA AAAkAwQAbgqlBm4KpwZyCqcGcgqlBgwAAAAkAwQAegqlBnoKpwZ+CqcGfgqlBgwAAAAkAwQAhgql BoYKpwaKCqcGigqlBgwAAAAkAwQAkgqlBpIKpwaWCqcGlgqlBgwAAAAkAwQAngqlBp4KpwaiCqcG ogqlBgwAAAAkAwQAqgqlBqoKpwauCqcGrgqlBgwAAAAkAwQAtgqlBrYKpwa6CqcGugqlBgwAAAAk AwQAwgqlBsIKpwbGCqcGxgqlBgwAAAAkAwQAzgqlBs4KpwbSCqcG0gqlBgwAAAAkAwQA2gqlBtoK pwbeCqcG3gqlBgwAAAAkAwQA5gqlBuYKpwbqCqcG6gqlBgwAAAAkAwQA8gqlBvIKpwb2CqcG9gql BgwAAAAkAwQA/gqlBv4KpwYCC6cGAgulBgwAAAAkAwQACgulBgoLpwYOC6cGDgulBgwAAAAkAwQA FgulBhYLpwYaC6cGGgulBgwAAAAkAwQAIgulBiILpwYmC6cGJgulBgwAAAAkAwQALgulBi4LpwYy C6cGMgulBgwAAAAkAwQAOgulBjoLpwY+C6cGPgulBgwAAAAkAwQARgulBkYLpwZKC6cGSgulBgwA AAAkAwQAUgulBlILpwZWC6cGVgulBgwAAAAkAwQAXgulBl4LpwZiC6cGYgulBgwAAAAkAwQAagul BmoLpwZuC6cGbgulBgwAAAAkAwQAdgulBnYLpwZ6C6cGegulBgwAAAAkAwQAggulBoILpwaGC6cG hgulBgwAAAAkAwQAjgulBo4LpwaSC6cGkgulBgwAAAAkAwQAmgulBpoLpwaeC6cGngulBgwAAAAk AwQApgulBqYLpwaqC6cGqgulBgwAAAAkAwQAsgulBrILpwa2C6cGtgulBgwAAAAkAwQAvgulBr4L pwbCC6cGwgulBgwAAAAkAwQAygulBsoLpwbOC6cGzgulBgwAAAAkAwQA1gulBtYLpwbaC6cG2gul BgwAAAAkAwQA4gulBuILpwbmC6cG5gulBgwAAAAkAwQA7gulBu4LpwbyC6cG8gulBgwAAAAkAwQA +gulBvoLpwb+C6cG/gulBgwAAAAkAwQABgylBgYMpwYKDKcGCgylBgwAAAAkAwQAEgylBhIMpwYW DKcGFgylBgwAAAAkAwQAHgylBh4MpwYiDKcGIgylBgwAAAAkAwQAKgylBioMpwYuDKcGLgylBgwA AAAkAwQANgylBjYMpwY6DKcGOgylBgwAAAAkAwQAQgylBkIMpwZGDKcGRgylBgwAAAAkAwQATgyl Bk4MpwZSDKcGUgylBgwAAAAkAwQAWgylBloMpwZeDKcGXgylBgwAAAAkAwQAZgylBmYMpwZqDKcG agylBgwAAAAkAwQAcgylBnIMpwZ2DKcGdgylBgwAAAAkAwQAfgylBn4MpwaCDKcGggylBgwAAAAk AwQAigylBooMpwaODKcGjgylBgwAAAAkAwQAlgylBpYMpwaaDKcGmgylBgwAAAAkAwQAogylBqIM pwamDKcGpgylBgwAAAAkAwQArgylBq4MpwayDKcGsgylBgwAAAAkAwQAugylBroMpwa+DKcGvgyl BgwAAAAkAwQAxgylBsYMpwbKDKcGygylBgwAAAAkAwQA0gylBtIMpwbWDKcG1gylBgwAAAAkAwQA 3gylBt4MpwbiDKcG4gylBgwAAAAkAwQA6gylBuoMpwbuDKcG7gylBgwAAAAkAwQA9gylBvYMpwb6 DKcG+gylBgwAAAAkAwQAAg2lBgINpwYGDacGBg2lBgwAAAAkAwQADg2lBg4NpwYSDacGEg2lBgwA AAAkAwQAGg2lBhoNpwYeDacGHg2lBgwAAAAkAwQAJg2lBiYNpwYqDacGKg2lBgwAAAAkAwQAMg2l BjINpwY2DacGNg2lBgQAAAAtAQUABAAAAC0BAwAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAA AAAAACIABAAAAC0BCQAFAAAAFAL4EcgABQAAABMC+BGjAQQAAAAtAQMABAAAAPABCQAEAAAALQEC AAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQkACgAAACQDAwCXAd8RlwEREskB+BEEAAAALQEFAAQA AAAtAQMABAAAAPABCQAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQAJAAAAHQYhAPAAhAC9BWoS1wcE AAAALQEFAAQAAAACAQEAAwAAAB4ABwAAABYE5xKMDXIS3wcEAAAAAgEBAAQAAAAtAQQAPQAAADIK dRLfByEABAAAAAAAYhBvE0RSUS9EQ0YgRGlzZW5nYWdlIFJlcXVlc3QvQ29uZmlybQA8ADwAQQAX ADwAPAAzABcAPAASACoALgAuAC4ALgAuAC4AFwA8AC4ALgAuAC4AKgAXABcAPAAuAC4AGAASABwA RwAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEFAAkAAAAdBiEA8ACEAL4FahK8AAQAAAAt AQUABAAAAAIBAQADAAAAHgAHAAAAFgTnEnIGchLEAAQAAAACAQEABAAAAC0BBAA9AAAAMgp1EsQA IQAEAAAAAABiEG8TQVJRL0FDRiBBZG1pc3Npb24gUmVxdWVzdC9Db25maXJtADcAPABBABcANwA8 ADMAFwA3AC4ARwASACoAKgASAC4ALgAXADwALgAuAC4ALgAqABcAFwA8AC4ALgAYABIAHABHAAQA AAACAQEABAAAACcB//8EAAAAAgEBAAQAAAAtAQUACQAAAB0GIQDwAIQAqwKvESYCBAAAAC0BBQAE AAAAAgEBAAMAAAAeAAcAAAAWBCsSyQS3ES4CBAAAAAIBAQAEAAAALQEEAB0AAAAyCroRLgIMAAQA AAAAAGIQbxNSQVMgbWVzc2FnZXM8ADcANwAXAEcALgAqACoALgAuAC4AKgAEAAAAAgEBAAQAAAAn Af//BAAAAAIBAQAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEJAAUAAAAUAvgRQAUFAAAAEwL4EUAG BAAAAC0BAwAEAAAA8AEJAAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQkABQAAABQC+BFABgUAAAAT AuQRIwYEAAAALQEDAAQAAADwAQkACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCQAFAAAAFAL4EUAG BQAAABMCCxIjBgQAAAAtAQMABAAAAPABCQAEAAAAAgEBAAQAAAACAQEABAAAAC0BBQAJAAAAHQYh APAAhADvA68RngYEAAAALQEFAAQAAAACAQEAAwAAAB4ABwAAABYEKxKFCrcRpgYEAAAAAgEBAAQA AAAtAQQALAAAADIKuhGmBhYABAAAAAAAYhBvE0guMjI1LjAvUS45MzEgbWVzc2FnZXM8ABcALgAu AC4AFwAuABcAQQAXAC4ALgAuABcARwAuACoAKgAuAC4ALgAqAAQAAAACAQEABAAAACcB//8EAAAA AgEBAAQAAAAtAQIABAAAAC0BBwAMAAAAJAMEABwL9xEcC/kRIAv5ESAL9xEMAAAAJAMEACgL9xEo C/kRLAv5ESwL9xEMAAAAJAMEADQL9xE0C/kROAv5ETgL9xEMAAAAJAMEAEAL9xFAC/kRRAv5EUQL 9xEMAAAAJAMEAEwL9xFMC/kRUAv5EVAL9xEMAAAAJAMEAFgL9xFYC/kRXAv5EVwL9xEMAAAAJAME AGQL9xFkC/kRaAv5EWgL9xEMAAAAJAMEAHAL9xFwC/kRdAv5EXQL9xEMAAAAJAMEAHwL9xF8C/kR gAv5EYAL9xEMAAAAJAMEAIgL9xGIC/kRjAv5EYwL9xEMAAAAJAMEAJQL9xGUC/kRmAv5EZgL9xEM AAAAJAMEAKAL9xGgC/kRpAv5EaQL9xEMAAAAJAMEAKwL9xGsC/kRsAv5EbAL9xEMAAAAJAMEALgL 9xG4C/kRvAv5EbwL9xEMAAAAJAMEAMQL9xHEC/kRyAv5EcgL9xEMAAAAJAMEANAL9xHQC/kR1Av5 EdQL9xEMAAAAJAMEANwL9xHcC/kR4Av5EeAL9xEMAAAAJAMEAOgL9xHoC/kR7Av5EewL9xEMAAAA JAMEAPQL9xH0C/kR+Av5EfgL9xEMAAAAJAMEAAAM9xEADPkRBAz5EQQM9xEMAAAAJAMEAAwM9xEM DPkREAz5ERAM9xEMAAAAJAMEABgM9xEYDPkRHAz5ERwM9xEEAAAALQEFAAQAAAAtAQMACQAAAPoC AAACAAAAAAAAACIABAAAAC0BCQAFAAAAFAL4ERwMBQAAABMC5BH/CwQAAAAtAQMABAAAAPABCQAJ AAAA+gIAAAIAAAAAAAAAIgAEAAAALQEJAAUAAAAUAvgRHAwFAAAAEwILEv8LBAAAAC0BAwAEAAAA 8AEJAAQAAAACAQEABAAAAAIBAQAEAAAALQEFAAkAAAAdBiEA8ACEAO8DrxF6DAQAAAAtAQUABAAA AAIBAQADAAAAHgAHAAAAFgQrEmEQtxGCDAQAAAACAQEABAAAAC0BBAAgAAAAMgq6EYIMDgAEAAAA AABiEG8TSC4yNDUgbWVzc2FnZXM8ABcALgAuAC4AFwBHAC4AKgAqAC4ALgAuACoABAAAAAIBAQAE AAAAJwH//wQAAAACAQEABAAAAC0BBQAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEJAAcAAAAbBAwO +Q+ODTYNBAAAAC0BAwAEAAAA8AEJAAQAAAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgQDDu8PmA0/ DQQAAAACAQEABAAAAC0BBAAXAAAAMgqbDe8NCAAEAAAAAABiEG8TT19BY3RpdmVBAC4ANwAqABcA EgApAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEACQAAAPoCAAAGAAAAAAAAACIABAAAAC0BCQAF AAAAFALeBpQOBQAAABMCJgiUDgQAAAAtAQMABAAAAPABCQAEAAAALQECAAkAAAD6AgAAAQAAAAAA AAAiAAQAAAAtAQkACgAAACQDAwCrDh8IfQ4fCJQOPAgEAAAALQEFAAQAAAAtAQMABAAAAPABCQAE AAAAAgEBAAQAAAACAQEABAAAAC0BAgAEAAAALQEHAAwAAAAkAwQA6gltCOoJbwjuCW8I7gltCAwA AAAkAwQA9gltCPYJbwj6CW8I+gltCAwAAAAkAwQAAgptCAIKbwgGCm8IBgptCAwAAAAkAwQADgpt CA4KbwgSCm8IEgptCAwAAAAkAwQAGgptCBoKbwgeCm8IHgptCAwAAAAkAwQAJgptCCYKbwgqCm8I KgptCAwAAAAkAwQAMgptCDIKbwg2Cm8INgptCAwAAAAkAwQAPgptCD4KbwhCCm8IQgptCAwAAAAk AwQASgptCEoKbwhOCm8ITgptCAwAAAAkAwQAVgptCFYKbwhaCm8IWgptCAwAAAAkAwQAYgptCGIK bwhmCm8IZgptCAwAAAAkAwQAbgptCG4KbwhyCm8IcgptCAwAAAAkAwQAegptCHoKbwh+Cm8Ifgpt CAwAAAAkAwQAhgptCIYKbwiKCm8IigptCAwAAAAkAwQAkgptCJIKbwiWCm8IlgptCAwAAAAkAwQA ngptCJ4KbwiiCm8IogptCAwAAAAkAwQAqgptCKoKbwiuCm8IrgptCAwAAAAkAwQAtgptCLYKbwi6 Cm8IugptCAwAAAAkAwQAwgptCMIKbwjGCm8IxgptCAwAAAAkAwQAzgptCM4KbwjSCm8I0gptCAwA AAAkAwQA2gptCNoKbwjeCm8I3gptCAwAAAAkAwQA5gptCOYKbwjqCm8I6gptCAwAAAAkAwQA8gpt CPIKbwj2Cm8I9gptCAwAAAAkAwQA/gptCP4KbwgCC28IAgttCAwAAAAkAwQACgttCAoLbwgOC28I DgttCAwAAAAkAwQAFgttCBYLbwgaC28IGgttCAwAAAAkAwQAIgttCCILbwgmC28IJgttCAwAAAAk AwQALgttCC4LbwgyC28IMgttCAwAAAAkAwQAOgttCDoLbwg+C28IPgttCAwAAAAkAwQARgttCEYL bwhKC28ISgttCAwAAAAkAwQAUgttCFILbwhWC28IVgttCAwAAAAkAwQAXgttCF4LbwhiC28IYgtt CAwAAAAkAwQAagttCGoLbwhuC28IbgttCAwAAAAkAwQAdgttCHYLbwh6C28IegttCAwAAAAkAwQA ggttCIILbwiGC28IhgttCAwAAAAkAwQAjgttCI4LbwiSC28IkgttCAwAAAAkAwQAmgttCJoLbwie C28IngttCAwAAAAkAwQApgttCKYLbwiqC28IqgttCAwAAAAkAwQAsgttCLILbwi2C28ItgttCAwA AAAkAwQAvgttCL4LbwjCC28IwgttCAwAAAAkAwQAygttCMoLbwjOC28IzgttCAwAAAAkAwQA1gtt CNYLbwjaC28I2gttCAwAAAAkAwQA4gttCOILbwjmC28I5gttCAwAAAAkAwQA7gttCO4LbwjyC28I 8gttCAwAAAAkAwQA+gttCPoLbwj+C28I/gttCAwAAAAkAwQABgxtCAYMbwgKDG8ICgxtCAwAAAAk AwQAEgxtCBIMbwgWDG8IFgxtCAwAAAAkAwQAHgxtCB4MbwgiDG8IIgxtCAwAAAAkAwQAKgxtCCoM bwguDG8ILgxtCAwAAAAkAwQANgxtCDYMbwg6DG8IOgxtCAwAAAAkAwQAQgxtCEIMbwhGDG8IRgxt CAwAAAAkAwQATgxtCE4MbwhSDG8IUgxtCAwAAAAkAwQAWgxtCFoMbwheDG8IXgxtCAwAAAAkAwQA ZgxtCGYMbwhqDG8IagxtCAwAAAAkAwQAcgxtCHIMbwh2DG8IdgxtCAwAAAAkAwQAfgxtCH4MbwiC DG8IggxtCAwAAAAkAwQAigxtCIoMbwiODG8IjgxtCAwAAAAkAwQAlgxtCJYMbwiaDG8ImgxtCAwA AAAkAwQAogxtCKIMbwimDG8IpgxtCAwAAAAkAwQArgxtCK4MbwiyDG8IsgxtCAwAAAAkAwQAugxt CLoMbwi+DG8IvgxtCAwAAAAkAwQAxgxtCMYMbwjKDG8IygxtCAwAAAAkAwQA0gxtCNIMbwjWDG8I 1gxtCAwAAAAkAwQA3gxtCN4MbwjiDG8I4gxtCAwAAAAkAwQA6gxtCOoMbwjuDG8I7gxtCAwAAAAk AwQA9gxtCPYMbwj6DG8I+gxtCAwAAAAkAwQAAg1tCAINbwgGDW8IBg1tCAwAAAAkAwQADg1tCA4N bwgSDW8IEg1tCAwAAAAkAwQAGg1tCBoNbwgeDW8IHg1tCAwAAAAkAwQAJg1tCCYNbwgqDW8IKg1t CAwAAAAkAwQAMg1tCDINbwg2DW8INg1tCAQAAAAtAQUABAAAAC0BAwAEAAAAAgEBAAQAAAAtAQAA AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAAC AAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAACgAAAACAAAAAEAAABIAAAA DwAAAFAAAAAEAAAAXAAAAAUAAABkAAAABgAAAGwAAAALAAAAdAAAABAAAAB8AAAADAAAAIQAAAAC AAAA5AQAAB4AAAABAAAAAMAAAAMAAAAANAAAAwAAAAEAAAADAAAAAQAAAAsAAAAAAAAACwAAAAAA AAAMEAAAAgAAAB4AAAABAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAAoAEAABIAAAABAAAAmAAAAAIAAACgAAAAAwAAAKwAAAAEAAAAuAAAAAUAAADU AAAABgAAAOAAAAAHAAAA7AAAAAgAAAAAAQAACQAAABwBAAASAAAAKAEAAAoAAABQAQAACwAAAFwB AAAMAAAAaAEAAA0AAAB0AQAADgAAAIABAAAPAAAAiAEAABAAAACQAQAAEwAAAJgBAAACAAAA5AQA AB4AAAABAAAAAAAAAB4AAAABAAAAAAQAAB4AAAARAAAASmVhbi1DbGF1ZGUgRGFuZwA6RwAeAAAA AQAAAAAAAAEeAAAAAQAAAAAAAAAeAAAACwAAAG5vcm1hbC5kb3QAAB4AAAARAAAASmVhbi1DbGF1 ZGUgRGFuZwDwABYeAAAAAgAAADIARgAeAAAAHgAAAE1pY3Jvc29mdCBXb3JkIGZvciBXaW5kb3dz IDk1AAAAQAAAAAAAAAAAAAAAQAAAAAD6hfJj17kBQAAAAAB4cpYeRr4BQAAAAADgNvgmRr4BAwAA AAEAAAADAAAAAQAAAAMAAAAKAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////AQkCAAAAAADAAAAAAAAARhUA AABJbWFnZSBNaWNyb3NvZnQgV29yZAAKAAAATVNXb3JkRG9jAA8AAABXb3JkLlBpY3R1cmUuNgD0 ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIABkmfB8AAAEACQAAA9oG AAAJAB8AAAAAABQAAAAmBg8AHgD/////BAAUAAAAV29yZA4ATWljcm9zb2Z0IFdv3KVoAFfgDAQA AAAAZQAAAAAAAAAAAAAAAAMAAGkDAADPFgAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFwAAAAAAAAAAAAAAAAKAAA8BAAAAAoAADwEAAA8DgAAAAAAADwOAAAAAAAAYA4A AAAAAABgDgAAAAAAAGAOAAAUAAAAig4AABQAAACKDgAAAAAAAJ4OAAAAAAAAng4AAAAAAACeDgAA AAAAAJ4OAAAKAAAAqA4AAAoAAACKDgAAAAAAABIWAAAxAAAAsg4AAAAAAACyDgAAAAAAALIOAAAA AAAAsg4AAAAAAACyDgAAAAAAACQPAAAAAAAAJA8AAAAAAAAkDwAAAAAAACQPAAACAAAAJg8AAAAA AAAmDwAAAAAAACYPAAA2AAAAXA8AAEwDAACoEgAATAMAAPQVAAAeAAAAQxYAAFgAAACbFgAANAAA ABIWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAOAAAAAAAAJA8AAAAAAAAAAAMABAABAAEAsg4AAHIA AAAkDwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkDwAAAAAAACQPAAAAAAAAEhYAAAAAAAAkDwAAAAAA ADwOAAAAAAAAPA4AAAAAAACyDgAAAAAAAAAAAAAAAAAAAAAAAAAAAACyDgAAAAAAACQPAAAAAAAA JA8AAAAAAAAkDwAAAAAAACQPAAAAAAAAPA4AACQAAACyDgAAAAAAAGAOAAAAAAAAsg4AAAAAAAAk DwAAAAAAAAAAAAAAAAAAIOvAECdGvgF0DgAACAAAAHwOAAAOAAAAPA4AAAAAAAA8DgAAAAAAADwO AAAAAAAAPA4AAAAAAAAkDwAAAAAAACQPAAAAAAAAJA8AAAAAAAAkDwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACAgICAgICAgICAgNSU5BUA0NR0sNDVJBUwtRLjkzMQtILjI0NQ0N UkFTC1EuOTMxC0guMjQ1DQ1NZWRpYSBzdHJlYW1zDQ1ILjMyMyBUZXJtaW5hbA0NSC4zMjMgVGVy bWluYWwNDQ0NGwChAQCkwE6lwE6mBxqnIR+oIhupxyGqAACrCQAAADIAAQEEMAAAAgQoAEQlpxzv AloBAAAAACgABQD///8AAAAhUQAAAAAAAAAAAAAUAAAAMAABAQYwAAABACYAzCQ/GwEADAQAAAsE AAAAAAAAAAAFAAIAGQAZAAAAAAAAAAAAMAABAQIwAAABACYAJCeyIHQF6gcAAAAAcwXpBwAAAAAF AAAAGgAaAAAAAAAAAAAAMAABAQEwAAABACYA1ByyIKEF2wegBQAAAADaBwAAAAAFAAAAGgAaAAAA AAAAAAAAMgABAQAwAAACBCgAdCJZH7EEwgIAAAAABQAAAP///wAAACFRAAAAAAAAAAAAABQAAAAy AAEBBTAAAAIEKAADKgsiwgLRAgAAAAAoAAUA////AAAAIVEAAAAAAAAAAAAAFAAAADIAAQEFMAAA AgQoAHocOCLCAtECAAAAACgABQD///8AAAAhUQAAAAAAAAAAAAAUAAAAMgABAQQwAAACBCgACyJB KEYGWgEAAAAAKAAFAP///wAAACFRAAAAAAAAAAAAABQAAAAwAAEBAzAAAAEAJgCVH+UpjQoBAAAA AACMCgAAAAAAACgAAAAaABoAAAAAAAAAAAAyAAEBADAAAAIEKAAwKpsosQTCAgAAAAAFAAAA//// AAAAIVEAAAAAAAAAAAAAFAAAADIAAQEAMAAAAgQoAOUafSixBMICAAAAAAUAAAD///8AAAAhUQAA AAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAsDAAAMAwAA EgMAABUDAABoAwAAaQMAAKQFAAD5AAD3AAD1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQADYxgAC3UBRAQAAAAAYQAEAAcAAwAADAMAABEDAAAS AwAAFQMAABYDAAAmAwAAJwMAADcDAAA4AwAARgMAAEcDAABWAwAAVwMAAGYDAABnAwAAaAMAAGkD AAD+AAGXFeQA+wABywLkAP4AAAAAAAD2AAGFBBQB/gAAAAAAAPsAA54C5AD+AAAAAAAA+wADmwLk AP4AAAAAAAD7AAEiBuQA/gAAAAAAAPEAAoUE5AD+AAAAAAAA8QAChQTkAP4AAAAAAAD+AAAAAAAA /gABlxXkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAAUBFVAAAAAEAAAFARWgAAAAAgAABQEAAQAAEQ4AEwAIAAEASwAPAAAA AAAcAABA8f8CABwABk5vcm1hbAACAAAABgBdAgBhDARYAAFAAQACAFgAB1RpdHJlIDEAAEAAAQAN ARXgARbwAAw0AAABBAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAVYFcAAJAAQDyAFwAB1RpdHJlIDIAAEAAAgANAhXwABZ4AAw0AAAABAAAAYAAAAEAAACQ AAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAVYFjFgAAXAADQAEAEgFcAAdU aXRyZSAzAABAAAMADQMVeAAWeAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAFAF4BYxYAAF4ABEABAAIAXgAHVGl0cmUgNAAAQgAEAAgBDQQV8AAW PAAMNAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF AFWBXQIAAFwABUABAAIAXAAHVGl0cmUgNQAAQAAFAA0FFfAAFjwADDQAAQAEAAABgAAAAQAAAJAA AAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBdAgBjFgBcAAZAAQACAFwAB1Rp dHJlIDYAAEAABgANBhXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAUAVoFjFgAAXAAHQAEAAgBcAAdUaXRyZSA3AABAAAcADQcV8AAWPAAM NAABAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAF0C AGMUAF4ACEABAAIAXgAHVGl0cmUgOAAAQAAIAA0IFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAA AC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACABWgV0CAGMUAGAACUABAAIAYAAHVGl0 cmUgOQAAQAAJAA0JFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACgBVgVaBXQIAYxIAHgBBQPL/oQAeABFQb2xpY2UgcGFyIGTpZmF1dAAA AAAAAAAAAAAAACIA/k8BAfIAIgAOUmV0cmFpdE5vcm1hbDIABQAPABFuBAAAACIAHEABAAIBIgAO UmV0cmFpdCBub3JtYWwABQAQABHEAgAAACIA/k/xABIBIgAOUmV0cmFpdE5vcm1hbDMABQARABEY BgAAACYAIEABACIBJgAMUGllZCBkZSBwYWdlAAwAEgAPCAAC0xJvIwECAAAAAAAABgAAAAoAAAAb AAAALAAAADsAAABLAAAAWwAAAF4AAAAAAAAAaQAAAAsAaQMAAAAA/////wEABCD//wEAAAAAAGkA AAAAAAAAAAAAAAAADQAAAGkAAAAGAAAABgAAAAADAACkBQAAAwAAAwAAaQMAAAQAAAAAAAEAAAAC AAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAABpAAAAhgMAAAEAuAMAAAAA6AMAAAAA GAQAAAAASAQAAAEAegQAAAEArAQAAAEA3gQAAAEAEAUAAAAAQAUAAAEAcgUAAAEA/0BIUCBMYXNl ckpldCA0MDAwIFBTAExQVDE6AFBTQ1JJUFQASFAgTGFzZXJKZXQgNDAwMCBQUwBIUCBMYXNlckpl dCA0MDAwIFBTAAAAAAAAAAAAAAAAAAAEAwSUALgCH3cAAAEACQCaCzMIZAABAAcAWAIBAAIAWAID AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAADAEgAAyBkAAAEAAAAAAAAA AQAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAguRrvWc6a2z8tgUAAgABAAAAAAABAAAAAAACAAIAAQBS AwAAwgEAAAAAAAAAAGQAAAAAAAMA//8DAP//AQD//wAA//8BAP//AAD//wAA//8AAP//AQD//wEA //8AAP//AQD//wEA//8AAP//AAD//wAA//8AAP//AQD//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//1BhZ2UgcGVyc29ubmFsaXPpZSAxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhDAAC0QwAAAAAAAFBhZ2UgcGVyc29ubmFs aXPpZSAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhDAAC0 QwAAAAAAAFBhZ2UgcGVyc29ubmFsaXPpZSAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFhDAAC0QwAAAAAAAAAAAAAAAAAASFAgTGFzZXJKZXQgNDAwMCBQUwAA AAAAAAAAAAAAAAAABAMElAC4Ah93AAABAAkAmgszCGQAAQAHAFgCAQACAFgCAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAwBIAAMgZAAABAAAAAAAAAAEAAAACAAAAAAAA AAAAAAAAAAAAAAAAAILka71nOmts/LYFAAIAAQAAAAAAAQAAAAAAAgACAAEAUgMAAMIBAAAAAAAA AABkAAAAAAADAP//AwD//wEA//8AAP//AQD//wAA//8AAP//AAD//wEA//8BAP//AAD//wEA//8B AP//AAD//wAA//8AAP//AAD//wEA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//9QYWdlIHBlcnNvbm5hbGlz6WUgMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdl IHBlcnNvbm5hbGlz6WUgMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABYQwAAtEMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAgAAAAwAAQABAAAAAAABAAAAAAAAADEA FRaQAQAAVGltZXMgTmV3IFJvbWFuAAwWkAECAFN5bWJvbAALJpABAABBcmlhbAAiAAQAAwOMGFYM xAIAAKkBAAAAADC0MQZwtDGmAAAAAAIAAAAAAAEAAAAKAAAAAQABAAAABACDAAEAAAAAAAAAAAAA AAEAAQAAAAEAAAAAAAAAIQNWDAAANAAAAAAAAAAQSmVhbi1DbGF1ZGUgRGFuZxBKZWFuLUNsYXVk ZSBEYW5nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACG AAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQA AACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAA AKMAAACkAAAApQAAAP7///+nAAAA/v///6kAAACqAAAAqwAAAP7///+tAAAArgAAAK8AAACwAAAA sQAAALIAAACzAAAA/v////7///+2AAAA/v///7gAAAD+//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////9yZAUAAAALAgAAAAAFAAAADAJwBwAJ DQAAAPsCAAAAAAAAAAAAAAAAAAAAAAABAAwEAAAALQEAAAQAAAACAQEAEAAAAPsCrf8AAAAAAACQ AQAAAAAEAAAiQXJpYWwAKgAEAAAALQEBAAUAAAAJAgAAAAAEAAAAAgEBAAQAAAACAQEABwAAAPwC AQAAAAAAAAAEAAAALQECAAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQMABwAAABsE6AJ4BcIBgwMJ AAAA+gIAAAAAAAAAAAAAIgAEAAAALQEEAAQAAADwAQMABwAAAPwCAAD///8AAAAEAAAALQEDAAQA AAACAQEAAwAAAB4ABwAAABYE3wJuBcsBjAMEAAAAAgEBABAAAAD7Apz/AAAAAAAAkAEAAAAABAAA IkFyaWFsAFQABAAAAC0BBQAOAAAAMgoRAjQEAgAEAAAAAAAACXAHR0tOAEMABAAAAAIBAQAEAAAA JwH//wQAAAACAQEABAAAAC0BAgAJAAAA+gIAAAIAAAAAAAAAIgAEAAAALQEGAAcAAAAbBMQGsQid BbwGBAAAAC0BBAAEAAAA8AEGAAQAAAAtAQMABAAAAAIBAQADAAAAHgAHAAAAFgS6BqcIpgXFBgQA AAACAQEABAAAAC0BAQATAAAAMgrKBUcHBQAEAAAAAAAACXAHSC4zMjMAPAAXAC4ALgAuAAQAAAAC AQEABAAAAAIBAQAEAAAALQEBABcAAAAyCikGEwcIAAQAAAAAAAAJcAdUZXJtaW5hbDQALgAcAEcA EgAuAC4AEgAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQECAAkAAAD6AgAAAgAAAAAAAAAi AAQAAAAtAQYABwAAABsEtwZSApEFXQAEAAAALQEEAAQAAADwAQYABAAAAC0BAwAEAAAAAgEBAAMA AAAeAAcAAAAWBK4GSAKaBWYABAAAAAIBAQAEAAAALQEBABMAAAAyCr4F6AAFAAQAAAAAAAAJcAdI LjMyMwA8ABcALgAuAC4ABAAAAAIBAQAEAAAAAgEBAAQAAAAtAQEAFwAAADIKHQa0AAgABAAAAAAA AAlwB1Rlcm1pbmFsNAAuABwARwASAC4ALgASAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAkAAAD6 AgAAAgAAAAAAAAAiAAQAAAAtAQYABQAAABQCYwJ3AwUAAAATAoUFOAEEAAAALQEEAAQAAADwAQYA BwAAAPwCAAAAAAAAAAAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQcACgAAACQDAwBP AY0FKQFyBSsBlwUEAAAALQEDAAQAAAAtAQQABAAAAPABBwAEAAAALQEGAAkAAAD6AgAAAQAAAAAA AAAiAAQAAAAtAQcACgAAACQDAwBfA1wChQN3AoMDUQIEAAAALQEDAAQAAAAtAQQABAAAAPABBwAE AAAAAgEBAAQAAAACAQEACQAAAPoCAAACAAAAAAAAACIABAAAAC0BBwAFAAAAFAJjAoQFBQAAABMC iwWwBwQAAAAtAQQABAAAAPABBwAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQcACgAA ACQDAwC+B3gFmQeSBbwHnQUEAAAALQEDAAQAAAAtAQQABAAAAPABBwAEAAAALQEGAAkAAAD6AgAA AQAAAAAAAAAiAAQAAAAtAQcACgAAACQDAwB1BXcCmgVdAncFUQIEAAAALQEDAAQAAAAtAQQABAAA APABBwAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAARAAAAAAAAACIABAAAAC0BBwAFAAAAFAInBncC BQAAABMCJwaRBgQAAAAtAQQABAAAAPABBwAEAAAALQEGAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAt AQcACgAAACQDAwCEBgUGhAZIBrYGJwYEAAAALQEDAAQAAAAtAQQABAAAAPABBwAEAAAALQEGAAkA AAD6AgAAAQAAAAAAAAAiAAQAAAAtAQcACgAAACQDAwCDAkgGgwIFBlECJwYEAAAALQEDAAQAAAAt AQQABAAAAPABBwAEAAAAAgEBAAQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgQrAeEFqgC3BAQA AAACAQEABAAAAC0BAQARAAAAMgqtAOoEBAAEAAAAAAAACXAHSU5BUBcAPAA3ADcABAAAAAIBAQAE AAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgQBBu0FgAVfAwQAAAACAQEABAAAAC0B AQAfAAAAMgqDBZQDDQAEAAAAAAAACXAHTWVkaWEgc3RyZWFtcwBFAC4ALgASAC4AFwAqABcAHAAu AC4ARwAqAAQAAAACAQEABAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEBgTIB+kC sQYEAAAAAgEBAAQAAAAtAQEAEAAAADIK7ALnBgMABAAAAAAAAAlwB1JBUwA8ADcANwAEAAAAAgEB AAQAAAACAQEABAAAAC0BAQATAAAAMgpLA8sGBQAEAAAAAAAACXAHUS45MzEAQQAXAC4ALgAuAAQA AAACAQEABAAAAAIBAQAEAAAALQEBABMAAAAyCqoDzQYFAAQAAAAAAAAJcAdILjI0NQA8ABcALgAu AC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgQZBCQC/AIOAQQA AAACAQEABAAAAC0BAQAQAAAAMgr/AkQBAwAEAAAAAAAACXAHUkFTADwANwA3AAQAAAACAQEABAAA AAIBAQAEAAAALQEBABMAAAAyCl4DKAEFAAQAAAAAAAAJcAdRLjkzMQBBABcALgAuAC4ABAAAAAIB AQAEAAAAAgEBAAQAAAAtAQEAEwAAADIKvQMqAQUABAAAAAAAAAlwB0guMjQ1ADwAFwAuAC4ALgAE AAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAALQEGAAkAAAD6AgUAAAAAAP///wAiAAQAAAAtAQcA DAAAACQDBAB8BLsBfgS7AX4EtwF8BLcBDAAAACQDBAB8BK8BfgSvAX4EqwF8BKsBDAAAACQDBAB8 BKMBfgSjAX4EnwF8BJ8BDAAAACQDBAB8BJcBfgSXAX4EkwF8BJMBDAAAACQDBAB8BIsBfgSLAX4E hwF8BIcBDAAAACQDBAB8BH8BfgR/AX4EewF8BHsBDAAAACQDBAB8BHMBfgRzAX4EbwF8BG8BDAAA ACQDBAB8BGcBfgRnAX4EYwF8BGMBDAAAACQDBAB8BFsBfgRbAX4EVwF8BFcBDAAAACQDBAB8BE8B fgRPAX4ESwF8BEsBDAAAACQDBAB8BEMBfgRDAX4EPwF8BD8BDAAAACQDBAB8BDcBfgQ3AX4EMwF8 BDMBDAAAACQDBAB8BCsBfgQrAX4EJwF8BCcBDAAAACQDBAB8BB8BfgQfAX4EGwF8BBsBDAAAACQD BAB8BBMBfgQTAX4EDwF8BA8BDAAAACQDBAB8BAcBfgQHAX4EAwF8BAMBDAAAACQDBAB8BPsAfgT7 AH4E9wB8BPcADAAAACQDBAB8BO8AfgTvAH4E6wB8BOsADAAAACQDBAB8BOIAfgTiAH4E3gB8BN4A DAAAACQDBAB8BNYAfgTWAH4E0gB8BNIADAAAACQDBAB8BMoAfgTKAH4ExgB8BMYADAAAACQDBAB8 BL4AfgS+AH4EugB8BLoADAAAACQDBAB8BLIAfgSyAH4ErgB8BK4ADAAAACQDBAB8BKYAfgSmAH4E ogB8BKIADAAAACQDBAB8BJoAfgSaAH4ElgB8BJYADAAAACQDBAB8BI4AfgSOAH4EigB8BIoADAAA ACQDBAB8BIIAfgSCAH4EfgB8BH4ADAAAACQDBAB8BHYAfgR2AH4EcgB8BHIADAAAACQDBAB8BGoA fgRqAH4EZgB8BGYADAAAACQDBAB8BF4AfgReAH4EWgB8BFoADAAAACQDBAB8BFIAfgRSAH4ETgB8 BE4ADAAAACQDBAB8BEYAfgRGAH4EQgB8BEIADAAAACQDBAB8BDoAfgQ6AH4ENgB8BDYADAAAACQD BAB8BC4AfgQuAH4EKgB8BCoADAAAACQDBAB8BCIAfgQiAH4EHgB8BB4ADAAAACQDBAB8BBYAfgQW AH4EEgB8BBIABAAAAC0BAwAEAAAALQEEAAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQgABQAAABQC DAB9BAUAAAATAikAZgQEAAAALQEEAAQAAADwAQgACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAF AAAAFAIMAH0EBQAAABMCKQCUBAQAAAAtAQQABAAAAPABCAAJAAAA+gIAAAIAAAAAAAAAIgAEAAAA LQEIAAUAAAAUArsBfQQFAAAAEwKeAZQEBAAAAC0BBAAEAAAA8AEIAAkAAAD6AgAAAgAAAAAAAAAi AAQAAAAtAQgABQAAABQCuwF9BAUAAAATAp4BZgQEAAAALQEEAAQAAADwAQgABAAAAAIBAQAEAAAA LQEAAAMAAAAAAAAAAABMAAAAAAAAAAAACAAZJgAAfB8AAJkVAADZEQAAAAAAAAAAAAAAAAAAAAAA AOgDAADoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC 1c3VnC4bEJOXCAArLPmuMAAAAKAAAAAIAAAAAQAAAEgAAAAPAAAAUAAAAAQAAABcAAAABQAAAGQA AAAGAAAAbAAAAAsAAAB0AAAAEAAAAHwAAAAMAAAAhAAAAAIAAADkBAAAHgAAAAEAAAAAAAAAAwAA AABAAAADAAAAAQAAAAMAAAABAAAACwAAAAAAAAALAAAAAAAAAAwQAAACAAAAHgAAAAEAAAAAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACgAQAAEgAAAAEA AACYAAAAAgAAAKAAAAADAAAArAAAAAQAAAC4AAAABQAAANQAAAAGAAAA4AAAAAcAAADsAAAACAAA AAABAAAJAAAAHAEAABIAAAAoAQAACgAAAFABAAALAAAAXAEAAAwAAABoAQAADQAAAHQBAAAOAAAA gAEAAA8AAACIAQAAEAAAAJABAAATAAAAmAEAAAIAAADkBAAAHgAAAAEAAAAATkoAHgAAAAEAAAAA AAAAHgAAABEAAABKZWFuLUNsYXVkZSBEYW5nAIRJAB4AAAABAAAAAAAAAB4AAAABAAAAAACEyR4A AAALAAAAbm9ybWFsLmRvdAAAHgAAABEAAABKZWFuLUNsYXVkZSBEYW5nAAAPAB4AAAACAAAAMgBI AB4AAAAeAAAATWljcm9zb2Z0IFdvcmQgZm9yIFdpbmRvd3MgOTUAAABAAAAAAIyGRwAAAABAAAAA APqF8mPXuQFAAAAAAGwvVVZEvgFAAAAAAGB6/l5EvgEDAAAAAQAAAAMAAAACAAAAAwAAAAwAAAAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAP7/AwoAAP////8BCQIAAAAAAMAAAAAAAABGFQAAAEltYWdlIE1pY3Jvc29mdCBXb3Jk AAoAAABNU1dvcmREb2MADwAAAFdvcmQuUGljdHVyZS42APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAEwAAAAAAAAAAAAIAD8gAAC8FAAASBIAAMELAAAAAAAAAAAAAAAA AAAAAAAA6AMAAOgDAAAAAAAAAAAAAAAAAADcpWgAV+AMBAAAAABlAAAAAAAAAAAAAAAAAwAAbQMA AO0YAAAAAAAAAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXQAAAAAAAAAAAAAA AAwAADwEAAAADAAAPAQAADwQAAAAAAAAPBAAAAAAAABgEAAAAAAAAGAQAAAAAAAAYBAAABQAAACK EAAAFAAAAIoQAAAAAAAAnhAAAAAAAACeEAAAAAAAAJ4QAAAAAAAAnhAAAAoAAACoEAAACgAAAIoQ AAAAAAAAMBgAADEAAACyEAAAAAAAALIQAAAAAAAAshAAAAAAAACyEAAAAAAAALIQAAAAAAAAQhEA AAAAAABCEQAAAAAAAEIRAAAAAAAAQhEAAAIAAABEEQAAAAAAAEQRAAAAAAAARBEAADYAAAB6EQAA TAMAAMYUAABMAwAAEhgAAB4AAABhGAAAWAAAALkYAAA0AAAAMBgAAAAAAAAAAAAAAAAAAAAAAAAA AAAAYBAAAAAAAABCEQAAAAAAAAAABAAFAAEAAQCyEAAAkAAAAEIRAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEIRAAAAAAAAQhEAAAAAAAAwGAAAAAAAAEIRAAAAAAAAPBAAAAAAAAA8EAAAAAAAALIQAAAA AAAAAAAAAAAAAAAAAAAAAAAAALIQAAAAAAAAQhEAAAAAAABCEQAAAAAAAEIRAAAAAAAAQhEAAAAA AAA8EAAAJAAAALIQAAAAAAAAYBAAAAAAAACyEAAAAAAAAEIRAAAAAAAAAAAAAAAAAAAgh7MAX0S+ AXQQAAAIAAAAfBAAAA4AAAA8EAAAAAAAADwQAAAAAAAAPBAAAAAAAAA8EAAAAAAAAEIRAAAAAAAA QhEAAAAAAABCEQAAAAAAAEIRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgI CAgICAgICAgICA1UQ1ANDVVEUA0NSVANDUgyMjUuMA0NUkFTIGNoYW5uZWwNDWNhbGwgY29udHJv bCAoUS45MzEgYmFzZWQpDQ1ILjI0NQ1tZWRpYSBjaGFubmVsIGNvbnRyb2wNDQ0NGwChAQCkwE6l wE6mdR6nBh6ocSOpkB+qAACrCQAAADIAAQH6LwAAAgQoADcjAiuTBDwBAAAAAAUABQD///8AAAAh UQAAAAAAAAAAAAAUAAAAMgABAfovAAACBCgAXSoRK5MEPAEAAAAABQAFAP///wAAACFRAAAAAAAA AAAAABQAAAAwAAEBCTAAAAEAJgC4KZkqAQAOAgAAAAAAAA0CAAAAAAUAAAAYABgAAAAAAAAAAAAy AAEB+y8AAAIEKABwJvEsOwIPAQAAAAAFAAUA////AAAAIVEAAAAAAAAAAAAAFAAAADAAAQH9LwAA AQAmAB0flyylEAEAAAAAAKQQAAAAAAAABQAAABgAGAAAAAAAAAAAADAAAQH8LwAAAwAmAB0fGCSl EEIKAAAAAAUAAAD///8AAAAhUQAAAAAAAAAAAAAAADIAAQEIMAAAAgQoAAUoFyXQAzwBAAAAAAUA BQD///8AAAAhUQAAAAAAAAAAAAAUAAAAMAABAQcwAAABACYAviP3JvULAQAAAAAA9AsAAAAAAAAF AAIAGAAYAAAAAAAAAAAAMAABAQUwAAABACYAuCkGJwEAlAMAAAAAAACTAwAAAAAFAAIAGAAYAAAA AAAAAAAAMgABAQMwAAACBCgAbCokJ4QEhgIAAAAABQAFAP///wAAACFRAAAAAAAAAAAAABQAAAAy AAEBAjAAAAIEKAAnJDMnRwWGAgAAAAAFAAUA////AAAAIVEAAAAAAAAAAAAAFAAAADAAAQEGMAAA AQAmAL4jGCQBAIIGAAAAAAAAgQYAAAAABQAAABgAGAAAAAAAAAAAADIAAQEBMAAAAgQoALMfUyWU A/0DAAAAAAUABQD///8AAAAhUQAAAAAAAAAAAAAUAAAAMAABAQQwAAABACYAHR+ZKqUQAQAAAAAA pBAAAAAAAAAFAAAAGAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAOAwAADwMAABMDAAAUAwAAGAMAABkDAAAcAwAAHQMA ACQDAAAlAwAAMQMAADIDAABNAwAATgMAAGoDAABsAwAAbQMAADgGAAD5APUA9QD1APUA9QD1APUA APMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ1AQAG XQIAYxQAAAt1AUQEAAAAAGEABAASAAMAAA8DAAATAwAAFAMAABgDAAAZAwAAHAMAAB0DAAAkAwAA JQMAADEDAAAyAwAATQMAAE4DAABUAwAAagMAAGsDAABsAwAAbQMAAP4AAUYSGwH7AAFvBOQA/gAA AAAAAPsAAW0E5AD+AAAAAAAA+wABFwLkAP4AAAAAAAD7AAGqA+QA/gAAAAAAAPsAAl4E5AD7AAAA AAAA+wACIwXkAP4AAAAAAAD7AAFxA+QA+wADcQPkAP4AAAAAAAD+AAAAAAAA/gABRhIbAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIAAAUBAAEAABIOABMACAABAEsADwAAAAAAHAAAQPH/AgAcAAZOb3JtYWwAAgAA AAYAYQwEYxgAWAABQAEAAgBYAAdUaXRyZSAxAABAAAEADQEV4AEW8AAMNAAAAQQAAAGAAAABAAAA kAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAFWBXAACQAEA8gBcAAdUaXRy ZSAyAABAAAIADQIV8AAWeAAMNAAAAAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAFAFWBYxYAAFwAA0ABABIBXAAHVGl0cmUgMwAAQAADAA0DFXgAFngADDQA AQAEAAABgAAAAQAAAJAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBeAWMW AABeAARAAQACAF4AB1RpdHJlIDQAAEIABAAIAQ0EFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAA AC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBVgV0CAABcAAVAAQACAFwAB1RpdHJl IDUAAEAABQANBRXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAYAXQIAYxYAXAAGQAEAAgBcAAdUaXRyZSA2AABAAAYADQYV8AAWPAAMNAAB AAQAAAGAAAABAAAAkAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAFaBYxYA AFwAB0ABAAIAXAAHVGl0cmUgNwAAQAAHAA0HFfAAFjwADDQAAQAEAAABgAAAAQAAAJAAAAAAAC4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgBdAgBjFABeAAhAAQACAF4AB1RpdHJlIDgA AEAACAANCBXwABY8AAw0AAEABAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAgAVoFdAgBjFABgAAlAAQACAGAAB1RpdHJlIDkAAEAACQANCRXwABY8AAw0AAEA BAAAAYAAAAEAAACQAAAAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAVYFWgV0C AGMSAB4AQUDy/6EAHgARUG9saWNlIHBhciBk6WZhdXQAAAAAAAAAAAAAAAAiAP5PAQHyACIADlJl dHJhaXROb3JtYWwyAAUADwARbgQAAAAiABxAAQACASIADlJldHJhaXQgbm9ybWFsAAUAEAARxAIA AAAiAP5P8QASASIADlJldHJhaXROb3JtYWwzAAUAEQARGAYAAAAmACBAAQAiASYADFBpZWQgZGUg cGFnZQAMABIADwgAAtMSbyMBAgAAAAAAAAUAAAAKAAAADgAAABYAAAAjAAAAPwAAAFwAAABfAAAA AAAAAG0AAAAIAG0DAAAAAP////8BAAQg//8BAAAAAABtAAAAAAAAAAAAAAAAABAAAABtAAAABgAA AAYAAAAAAwAAOAYAAAQAAAMAAG0DAAAFAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAAbQAAAIoDAAABALwDAAABAO4DAAAAAB4EAAABAFAEAAAA AIAEAAAAALAEAAABAOIEAAAAABIFAAAAAEIFAAABAHQFAAABAKYFAAAAANYFAAABAAgGAAAAAP9A SFAgTGFzZXJKZXQgNDAwMCBQUwBMUFQxOgBQU0NSSVBUAEhQIExhc2VySmV0IDQwMDAgUFMASFAg TGFzZXJKZXQgNDAwMCBQUwAAAAAAAAAAAAAAAAAABAMElAC4Ah93AAABAAkAmgszCGQAAQAHAFgC AQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAwBIAAMgZAAAB AAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAAAILka71nOmts/LYFAAIAAQAAAAAAAQAAAAAA AgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAADAP//AwD//wEA//8AAP//AQD//wAA//8AAP//AAD/ /wEA//8BAP//AAD//wEA//8BAP//AAD//wAA//8AAP//AAD//wEA//8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9QYWdlIHBlcnNvbm5hbGlz6WUgMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAABQYWdlIHBl cnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABYQwAAtEMAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYQwAAtEMAAAAAAAAAAAAAAAAAAEhQIExhc2VySmV0IDQw MDAgUFMAAAAAAAAAAAAAAAAAAAQDBJQAuAIfdwAAAQAJAJoLMwhkAAEABwBYAgEAAgBYAgMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAMASAADIGQAAAQAAAAAAAAABAAAA AgAAAAAAAAAAAAAAAAAAAAAAAACC5Gu9ZzprbPy2BQACAAEAAAAAAAEAAAAAAAIAAgABAFIDAADC AQAAAAAAAAAAZAAAAAAAAwD//wMA//8BAP//AAD//wEA//8AAP//AAD//wAA//8BAP//AQD//wAA //8BAP//AQD//wAA//8AAP//AAD//wAA//8BAP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP//UGFnZSBwZXJzb25uYWxpc+llIDEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAUGFnZSBwZXJzb25uYWxpc+ll IDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWEMAALRDAAAA AAAAUGFnZSBwZXJzb25uYWxpc+llIDMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAWEMAALRDAAAAAAAAAAAAAAAAAAADgAEAAAAAAAAAAAAJAAEAAQAAAAAAAAAA AAAAAAAxABUWkAEAAFRpbWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAAQXJpYWwAIgAE AAMDjBhWDMQCAACpAQAAAACWojEG2KIxZgAAAAACAAIAAAACAAAADAAAAAEAAQAAAAQAgwABAAAA AAAAAAAAAAABAAEAAAABAAAAAAAAACEDVgwAADQAAAAAAAAAEEplYW4tQ2xhdWRlIERhbmcQSmVh bi1DbGF1ZGUgRGFuZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAgAPyC8FAAAAQAJAAADOAoAAAkAHwAAAAAAFAAAACYGDwAeAP////8EABQA AABXb3JkDgBNaWNyb3NvZnQgV29yZAUAAAALAgAAAAAFAAAADALmBJ4HDQAAAPsCAAAAAAAAAAAA AAAAAAAAAAABAAwEAAAALQEAAAQAAAACAQEAFQAAAPsCnP8AAAAAAACQAQAAAAAEAAASVGltZXMg TmV3IFJvbWFuACQABAAAAC0BAQAFAAAACQIAAAAABAAAAAIBAQAEAAAAAgEBAAQAAAACAQEAAwAA AB4ABwAAABYEpAPcAzADAwIEAAAAAgEBABAAAAD7Aq3/AAAAAAAAkAEAAAAABAAAIkFyaWFsAN8D BAAAAC0BAgAQAAAAMgozA5sCAwAEAAAAAACeB+YEVENQADQAPAA3AAQAAAACAQEABAAAACcB//8E AAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEqgPWBjYD/gQEAAAAAgEBAAQAAAAtAQIAEAAAADIK OQOSBQMABAAAAAAAngfmBFVEUAA8ADwANwAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEB AAMAAAAeAAcAAAAWBF8EOgT+A1sDBAAAAAIBAQAEAAAALQECAA4AAAAyCgEEogMCAAQAAAAAAJ4H 5gRJUBcANwAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAHAAAA/AIBAAAAAAAAAAQAAAAtAQMACQAA APoCAAACAAAAAAAAACIABAAAAC0BBAAHAAAAGwSNBDYHRgBGAAkAAAD6AgAAAAAAAAAAAAAiAAQA AAAtAQUABAAAAPABBAAHAAAA/AIAAP///wAAAAQAAAAtAQQABAAAAAIBAQAEAAAAAgEBAAkAAAD6 AgAAAgAAAAAAAAAiAAQAAAAtAQYABQAAABQC0ANGAAUAAAATAtADNQcEAAAALQEFAAQAAADwAQYA BAAAAAIBAQAEAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEawL7AdEAjAAEAAAAAgEBAAQAAAAt AQIAEwAAADIK1ADUAAUABAAAAAAAngfmBEguMjQ1ADwAFwAuAC4ALgAEAAAAAgEBAAQAAAACAQEA BAAAAC0BAgATAAAAMgozAdEABQAEAAAAAACeB+YEbWVkaWEARwAuAC4AEgAuAAQAAAACAQEABAAA AAIBAQAEAAAALQECABYAAAAyCpIBsQAHAAQAAAAAAJ4H5gRjaGFubmVsACoALgAuAC4ALgAuABIA BAAAAAIBAQAEAAAAAgEBAAQAAAAtAQIAFgAAADIK8QHGAAcABAAAAAAAngfmBGNvbnRyb2wAKgAu AC4AFwAcAC4AEgAEAAAAAgEBAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEBAAMAAAAeAAcAAAAWBJcC iwSZAWcCBAAAAAIBAQAEAAAALQECAB0AAAAyCpwBsgIMAAQAAAAAAJ4H5gRjYWxsIGNvbnRyb2wq AC4AEgASABcAKgAuAC4AFwAcAC4AEgAEAAAAAgEBAAQAAAACAQEABAAAAC0BAgAfAAAAMgr7AW4C DQAEAAAAAACeB+YEKFEuOTMxIGJhc2VkKQAcAEEAFwAuAC4ALgAXAC4ALgAqAC4ALgAcAAQAAAAC AQEABAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEkQLWBpMBBAUEAAAAAgEBAAQA AAAtAQIAEAAAADIKlgGXBQMABAAAAAAAngfmBFJBUwA8ADcANwAEAAAAAgEBAAQAAAACAQEABAAA AC0BAgAWAAAAMgr1AVsFBwAEAAAAAACeB+YEY2hhbm5lbAAqAC4ALgAuAC4ALgASAAQAAAACAQEA BAAAACcB//8EAAAAAgEBAAkAAAD6AgAAAgAAAAAAAAAiAAQAAAAtAQYABQAAABQC/AJGAAUAAAAT AvwCNQcEAAAALQEFAAQAAADwAQYABAAAAAIBAQAEAAAAAgEBAAcAAAD8AgAAAAAAAAAABAAAAC0B BgAJAAAA+gIFAAAAAAD///8AIgAEAAAALQEHAAwAAAAkAwQAsAR/AbIEfwGyBIMBsASDAQwAAAAk AwQAsASLAbIEiwGyBI8BsASPAQwAAAAkAwQAsASXAbIElwGyBJsBsASbAQwAAAAkAwQAsASjAbIE owGyBKcBsASnAQwAAAAkAwQAsASvAbIErwGyBLMBsASzAQwAAAAkAwQAsAS7AbIEuwGyBL8BsAS/ AQwAAAAkAwQAsATHAbIExwGyBMsBsATLAQwAAAAkAwQAsATTAbIE0wGyBNcBsATXAQwAAAAkAwQA sATfAbIE3wGyBOMBsATjAQwAAAAkAwQAsATrAbIE6wGyBO8BsATvAQwAAAAkAwQAsAT3AbIE9wGy BPsBsAT7AQwAAAAkAwQAsAQDArIEAwKyBAcCsAQHAgwAAAAkAwQAsAQPArIEDwKyBBMCsAQTAgwA AAAkAwQAsAQbArIEGwKyBB8CsAQfAgwAAAAkAwQAsAQnArIEJwKyBCsCsAQrAgwAAAAkAwQAsAQz ArIEMwKyBDcCsAQ3AgwAAAAkAwQAsARAArIEQAKyBEQCsAREAgwAAAAkAwQAsARMArIETAKyBFAC sARQAgwAAAAkAwQAsARYArIEWAKyBFwCsARcAgwAAAAkAwQAsARkArIEZAKyBGgCsARoAgwAAAAk AwQAsARwArIEcAKyBHQCsAR0AgwAAAAkAwQAsAR8ArIEfAKyBIACsASAAgwAAAAkAwQAsASIArIE iAKyBIwCsASMAgwAAAAkAwQAsASUArIElAKyBJgCsASYAgwAAAAkAwQAsASgArIEoAKyBKQCsASk AgwAAAAkAwQAsASsArIErAKyBLACsASwAgwAAAAkAwQAsAS4ArIEuAKyBLwCsAS8AgwAAAAkAwQA sATEArIExAKyBMgCsATIAgwAAAAkAwQAsATQArIE0AKyBNQCsATUAgwAAAAkAwQAsATcArIE3AKy BOACsATgAgwAAAAkAwQAsAToArIE6AKyBOwCsATsAgwAAAAkAwQAsAT0ArIE9AKyBPgCsAT4AgQA AAAtAQQABAAAAC0BBQAEAAAAAgEBAAQAAAACAQEACQAAAPoCAAACAAAAAAAAACIABAAAAC0BCAAF AAAAFAJGADMCBQAAABMC/AIzAgQAAAAtAQUABAAAAPABCAAEAAAAAgEBAAQAAAACAQEABAAAAC0B BgAEAAAALQEHAAwAAAAkAwQAMwJ3ATMCeQE3AnkBNwJ3AQwAAAAkAwQAPwJ3AT8CeQFDAnkBQwJ3 AQwAAAAkAwQASwJ3AUsCeQFPAnkBTwJ3AQwAAAAkAwQAVwJ3AVcCeQFbAnkBWwJ3AQwAAAAkAwQA YwJ3AWMCeQFnAnkBZwJ3AQwAAAAkAwQAbwJ3AW8CeQFzAnkBcwJ3AQwAAAAkAwQAewJ3AXsCeQF/ AnkBfwJ3AQwAAAAkAwQAhwJ3AYcCeQGLAnkBiwJ3AQwAAAAkAwQAkwJ3AZMCeQGXAnkBlwJ3AQwA AAAkAwQAnwJ3AZ8CeQGjAnkBowJ3AQwAAAAkAwQAqwJ3AasCeQGvAnkBrwJ3AQwAAAAkAwQAtwJ3 AbcCeQG7AnkBuwJ3AQwAAAAkAwQAwwJ3AcMCeQHHAnkBxwJ3AQwAAAAkAwQAzwJ3Ac8CeQHTAnkB 0wJ3AQwAAAAkAwQA2wJ3AdsCeQHfAnkB3wJ3AQwAAAAkAwQA5wJ3AecCeQHrAnkB6wJ3AQwAAAAk AwQA8wJ3AfMCeQH3AnkB9wJ3AQwAAAAkAwQA/wJ3Af8CeQEDA3kBAwN3AQwAAAAkAwQACwN3AQsD eQEPA3kBDwN3AQwAAAAkAwQAFwN3ARcDeQEbA3kBGwN3AQwAAAAkAwQAIwN3ASMDeQEnA3kBJwN3 AQwAAAAkAwQALwN3AS8DeQEzA3kBMwN3AQwAAAAkAwQAOwN3ATsDeQE/A3kBPwN3AQwAAAAkAwQA RwN3AUcDeQFLA3kBSwN3AQwAAAAkAwQAUwN3AVMDeQFXA3kBVwN3AQwAAAAkAwQAXwN3AV8DeQFj A3kBYwN3AQwAAAAkAwQAawN3AWsDeQFvA3kBbwN3AQwAAAAkAwQAdwN3AXcDeQF7A3kBewN3AQwA AAAkAwQAgwN3AYMDeQGHA3kBhwN3AQwAAAAkAwQAjwN3AY8DeQGTA3kBkwN3AQwAAAAkAwQAmwN3 AZsDeQGfA3kBnwN3AQwAAAAkAwQApwN3AacDeQGrA3kBqwN3AQwAAAAkAwQAswN3AbMDeQG3A3kB twN3AQwAAAAkAwQAvwN3Ab8DeQHDA3kBwwN3AQwAAAAkAwQAywN3AcsDeQHPA3kBzwN3AQwAAAAk AwQA1wN3AdcDeQHbA3kB2wN3AQwAAAAkAwQA4wN3AeMDeQHnA3kB5wN3AQwAAAAkAwQA7wN3Ae8D eQHzA3kB8wN3AQwAAAAkAwQA+wN3AfsDeQH/A3kB/wN3AQwAAAAkAwQABwR3AQcEeQELBHkBCwR3 AQwAAAAkAwQAEwR3ARMEeQEXBHkBFwR3AQwAAAAkAwQAHwR3AR8EeQEjBHkBIwR3AQwAAAAkAwQA KwR3ASsEeQEvBHkBLwR3AQwAAAAkAwQANwR3ATcEeQE7BHkBOwR3AQwAAAAkAwQAQwR3AUMEeQFH BHkBRwR3AQwAAAAkAwQATwR3AU8EeQFTBHkBUwR3AQwAAAAkAwQAWwR3AVsEeQFfBHkBXwR3AQwA AAAkAwQAZwR3AWcEeQFrBHkBawR3AQwAAAAkAwQAcwR3AXMEeQF3BHkBdwR3AQwAAAAkAwQAfwR3 AX8EeQGDBHkBgwR3AQwAAAAkAwQAiwR3AYsEeQGPBHkBjwR3AQwAAAAkAwQAlwR3AZcEeQGbBHkB mwR3AQwAAAAkAwQAowR3AaMEeQGnBHkBpwR3AQwAAAAkAwQArwR3Aa8EeQG0BHkBtAR3AQwAAAAk AwQAvAR3AbwEeQHABHkBwAR3AQwAAAAkAwQAyAR3AcgEeQHMBHkBzAR3AQwAAAAkAwQA1AR3AdQE eQHYBHkB2AR3AQwAAAAkAwQA4AR3AeAEeQHkBHkB5AR3AQwAAAAkAwQA7AR3AewEeQHwBHkB8AR3 AQwAAAAkAwQA+AR3AfgEeQH8BHkB/AR3AQwAAAAkAwQABAV3AQQFeQEIBXkBCAV3AQwAAAAkAwQA EAV3ARAFeQEUBXkBFAV3AQwAAAAkAwQAHAV3ARwFeQEgBXkBIAV3AQwAAAAkAwQAKAV3ASgFeQEs BXkBLAV3AQwAAAAkAwQANAV3ATQFeQE4BXkBOAV3AQwAAAAkAwQAQAV3AUAFeQFEBXkBRAV3AQwA AAAkAwQATAV3AUwFeQFQBXkBUAV3AQwAAAAkAwQAWAV3AVgFeQFcBXkBXAV3AQwAAAAkAwQAZAV3 AWQFeQFoBXkBaAV3AQwAAAAkAwQAcAV3AXAFeQF0BXkBdAV3AQwAAAAkAwQAfAV3AXwFeQGABXkB gAV3AQwAAAAkAwQAiAV3AYgFeQGMBXkBjAV3AQwAAAAkAwQAlAV3AZQFeQGYBXkBmAV3AQwAAAAk AwQAoAV3AaAFeQGkBXkBpAV3AQwAAAAkAwQArAV3AawFeQGwBXkBsAV3AQwAAAAkAwQAuAV3AbgF eQG8BXkBvAV3AQwAAAAkAwQAxAV3AcQFeQHIBXkByAV3AQwAAAAkAwQA0AV3AdAFeQHUBXkB1AV3 AQwAAAAkAwQA3AV3AdwFeQHgBXkB4AV3AQwAAAAkAwQA6AV3AegFeQHsBXkB7AV3AQwAAAAkAwQA 9AV3AfQFeQH4BXkB+AV3AQwAAAAkAwQAAAZ3AQAGeQEEBnkBBAZ3AQwAAAAkAwQADAZ3AQwGeQEQ BnkBEAZ3AQwAAAAkAwQAGAZ3ARgGeQEcBnkBHAZ3AQwAAAAkAwQAJAZ3ASQGeQEoBnkBKAZ3AQwA AAAkAwQAMAZ3ATAGeQE0BnkBNAZ3AQwAAAAkAwQAPAZ3ATwGeQFABnkBQAZ3AQwAAAAkAwQASAZ3 AUgGeQFMBnkBTAZ3AQwAAAAkAwQAVAZ3AVQGeQFYBnkBWAZ3AQwAAAAkAwQAYAZ3AWAGeQFkBnkB ZAZ3AQwAAAAkAwQAbAZ3AWwGeQFwBnkBcAZ3AQwAAAAkAwQAeAZ3AXgGeQF8BnkBfAZ3AQwAAAAk AwQAhAZ3AYQGeQGIBnkBiAZ3AQwAAAAkAwQAkAZ3AZAGeQGUBnkBlAZ3AQwAAAAkAwQAnAZ3AZwG eQGgBnkBoAZ3AQwAAAAkAwQAqAZ3AagGeQGsBnkBrAZ3AQwAAAAkAwQAtAZ3AbQGeQG4BnkBuAZ3 AQwAAAAkAwQAwAZ3AcAGeQHEBnkBxAZ3AQwAAAAkAwQAzAZ3AcwGeQHQBnkB0AZ3AQwAAAAkAwQA 2AZ3AdgGeQHcBnkB3AZ3AQwAAAAkAwQA5AZ3AeQGeQHoBnkB6AZ3AQwAAAAkAwQA8AZ3AfAGeQH0 BnkB9AZ3AQwAAAAkAwQA/AZ3AfwGeQEAB3kBAAd3AQwAAAAkAwQACAd3AQgHeQEMB3kBDAd3AQwA AAAkAwQAFAd3ARQHeQEYB3kBGAd3AQwAAAAkAwQAIAd3ASAHeQEkB3kBJAd3AQwAAAAkAwQALAd3 ASwHeQEuB3kBLgd3AQQAAAAtAQQABAAAAC0BBQAEAAAAAgEBAAQAAAACAQEABAAAAAIBAQADAAAA HgAHAAAAFgQtAYsFuAAEBAQAAAACAQEABAAAAC0BAgAUAAAAMgq7AEEEBgAEAAAAAACeB+YESDIy NS4wPAAuAC4ALgAXAC4ABAAAAAIBAQAEAAAAJwH//wQAAAACAQEACQAAAPoCAAACAAAAAAAAACIA BAAAAC0BCAAFAAAAFAL8ArEEBQAAABMC1gOxBAQAAAAtAQUABAAAAPABCAAEAAAAAgEBAAQAAAAt AQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcA HAAHAIEAEEplYW4tQ2xhdWRlIERhbmcsQzpcTWVzIGRvY3VtZW50c1xFVFNJXFNQUzNcQ29udHJp Yi0wMS05OS5kb2MHQ0hBVFJBUyBcXFAtTFlOWFxEQUNcQXJzXEJDXENvbnRyaWIzLmRvYwdDSEFU UkFTD0E6XENvbnRyaWIzLmRvY/9ASFAgTGFzZXJKZXQgNDAwMCByZWN0by12ZXJzbwBscHQxOgBw c2NyaXB0AEhQIExhc2VySmV0IDQwMDAgcmVjdG8tdmVyc28ASFAgTGFzZXJKZXQgNDAwMCByZWN0 AQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4BAAAP AQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAAHAEAAB0B AAAeAQAAHwEAACABAAAhAQAAIgEAAP7///8kAQAAMgEAACYBAAAnAQAAKAEAACkBAAAqAQAAKwEA ACwBAAAtAQAALgEAAC8BAAAwAQAA/v////7///8zAQAANAEAADUBAAA2AQAANwEAADgBAAA5AQAA OgEAAFMBAAA8AQAAPQEAAD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABFAQAARgEAAEcBAAD+ ////SQEAAEoBAABLAQAATAEAAE0BAABOAQAATwEAAFABAABRAQAAUgEAAP7////+////VgEAAP3/ //9XAQAAWAEAAFkBAAD+////WwEAAFwBAABdAQAAXgEAAF8BAABgAQAAYQEAAGIBAABjAQAAZAEA AGUBAABmAQAAZwEAAGgBAABpAQAAAgAAAP3///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9v LXZlcnNvAAAAAAAEAwSUALgCH3cAAAEACQCaCzMIZAABAAcALAEBAAIALAEDAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAABgCQAA5AwAAAEAAAAAAAAAAQAAAAIAAAAAAAAA AAAAAAAAAAAAAAAAS9PnriCIJ87HVUEBAgABAAAAAAABAAAAAAACAAIAAQBSAwAAwgEAAAAAAAAA AGQAAAAAAAIA//8CAP//AQD//wQA//8AAP//AAD//wAA//8AAP//AAECWAIBAAAABQECDgCHAAEA AlgCAQUEEgBzBAcAAACwBAEAAACxBAIAAAC0BAsAAQDWBA4AAQCyBAQAAABwBAUAAQDXBAIBAADY BAMBAADaBAQBAADZBAUBAADbBAYBAADcBAcBAADdBAgBAADeBAkBAADfBAoBAADgBAsBAADhBAwB AAAAAAAAAAAAAAAAAAAAAAAACQAHAAEABwABAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//1BhZ2UgcGVyc29ubmFsaXPpZSAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJBCAACQQgAAAAAAAFBhZ2UgcGVyc29ubmFsaXPpZSAyAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJBCAACQQgAAAAAAAFBhZ2Ug cGVyc29ubmFsaXPpZSAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJBCAACQQgAAAAAAAAAAAAAAAAAASFAgTGFzZXJKZXQgNDAwMCByZWN0by12ZXJzbwAAAAAA BAMElAC4Ah93AAABAAkAmgszCGQAAQAHACwBAQACACwBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAAAAYAkAAOQMAAABAAAAAAAAAAEAAAACAAAAAAAAAAAAAAAAAAAAAAAA AEvT564giCfOx1VBAQIAAQAAAAAAAQAAAAAAAgACAAEAUgMAAMIBAAAAAAAAAABkAAAAAAACAP// AgD//wEA//8EAP//AAD//wAA//8AAP//AAD//wABAlgCAQAAAAUBAg4AhwABAAJYAgEFBBIAcwQH AAAAsAQBAAAAsQQCAAAAtAQLAAEA1gQOAAEAsgQEAAAAcAQFAAEA1wQCAQAA2AQDAQAA2gQEAQAA 2QQFAQAA2wQGAQAA3AQHAQAA3QQIAQAA3gQJAQAA3wQKAQAA4AQLAQAA4QQMAQAAAAAAAAAAAAAA AAAAAAAAAAkABwABAAcAAQBkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//9Q YWdlIHBlcnNvbm5hbGlz6WUgMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACQQgAAkEIAAAAAAABQYWdlIHBlcnNvbm5hbGlz6WUgMgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQQgAAkEIAAAAAAABQYWdlIHBlcnNvbm5hbGlz 6WUgMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQQgAAkEIA AAAAAAAAAAAAAAAAAAGAAQAAAAAAAAAAAAcAAQABAAAAAAAAAAAAAAAAAEsAFRaQAQAAVGltZXMg TmV3IFJvbWFuAAwWkAECAFN5bWJvbAALJpABAABBcmlhbAAZIpABAA1Vbml2ZXJzIChXMSkAQXJp YWwAACIABAACA4gYVgzEAgAAqQEAAAAA5LQxpuS0MabjtDGmAgAAAAAAAQMAACIRAAAFAAgAAAAE AIMAJAAAAAAAAAAAAAAABQABAAAAAQAAAAAAAAAhA1YMAAA1AAAAClJhcHBlbCA6IEgAAAAQSmVh bi1DbGF1ZGUgRGFuZwdDSEFUUkFTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANylaABX 4AwEAAAAAGUAAAAAAAAAAAAAAAADAABcGAAAeUkAAAAAAAAAAAAAAAAAAAAAAADHFAAAAAAAAJQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAABgUAAAAiAAAGBQAABicAAAAAAAAGJwAAAAAA AAYnAAAAAAAABicAAAAAAAAGJwAAFAAAAHAnAAD0AQAAcCcAAAAAAABkKQAAAAAAAGQpAAAAAAAA ZCkAAAwAAABwKQAAEAAAAIApAAAQAAAAcCcAAAAAAAChSAAASwAAAJApAAAAAQAAkCoAAAAAAACQ KgAAAAAAAJAqAAAAAAAAkCoAAAAAAACQKgAAAAAAAJAqAAAAAAAAkCoAAAAAAAChQQAAAgAAAKNB AAAAAAAAo0EAAAAAAACjQQAASAAAAOtBAABMAwAAN0UAAEwDAACDSAAAHgAAAOxIAABYAAAAREkA ADUAAAChSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGJwAAAAAAAJAqAAAAAAAAAAANAA8AAgACAJAq AAAAAAAAkCoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkCoAAAAAAACQKgAAAAAAAKFIAAAAAAAAIEEA AAAAAAAGJwAAAAAAAAYnAAAAAAAAkCoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkCkAAAAAAAAgQQAA AAAAACBBAAAAAAAAIEEAAAAAAACQKgAAkBYAAAYnAAAAAAAAkCoAAAAAAAAGJwAAAAAAAJAqAAAA AAAAoUEAAAAAAAAAAAAAAAAAAOBbtTE2Rr4BGicAACAAAAA6JwAANgAAAAYnAAAAAAAABicAAAAA AAAGJwAAAAAAAAYnAAAAAAAAkCoAAAAAAAChQQAAAAAAACBBAACBAAAAIEEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFNvdXJjZToJRlJBTkNFIFRFTEVDT00NVGl0bGU6CUlOIGFu ZCBILjMyMw0NDQ0NDQ0NSW50cm9kdWN0aW9uDUluIGEgcHJldmlvdXMgY29udHJpYnV0aW9uIGl0 IHdhcyBwcm9wb3NlZCB0aGF0IFNQUzMgc3R1ZGllcyB0aGUgbWFwcGluZyBvZiBJTiBtb2RlbHMg YW5kIHByb3RvY29scyB0byBILjMyMyBUZWxlcGhvbnkuIFRoaXMgZG9jdW1lbnQgZnVydGhlciBl bGFib3JhdGVzIG9uIHRoaXMgdG9waWMuDUguMzIzIGNhbGwgY29udHJvbA1SZWNvbW1lbmRhdGlv biBILjMyMyBjb3ZlcnMgbXVsdGltZWRpYSBjb21tdW5pY2F0aW9ucyBvbiBJUCBuZXR3b3Jrcy4g SW4gdGhlIEguMzIzIGFyY2hpdGVjdHVyZSBhIEdhdGVrZWVwZXIgaXMgYW4gKG9wdGlvbmFsKSBl bnRpdHkgd2hpY2ggY29udHJvbHMgSC4zMjMgdGVybWluYWxzIGluIGEgZ2l2ZW4gem9uZS4gRmln dXJlIDEgZGVzY3JpYmVzIHRoZSBwcm90b2NvbCBzdGFja3MgZm9yIGNhbGwgY29udHJvbC4NDRMg SU5DT1JQT1JFUiBXb3JkLlBpY3R1cmUuNiAgFAEVC0ZpZ3VyZSATIFNFUSBGaWd1cmUgXCogQVJB QkUgFDEVIC0gSC4zMjMgQ2FsbCBjb250cm9sIHByb3RvY29sIHN0YWNrcw0NSC4yMjUuMCBzcGVj aWZpZXMgdGhlIGNhbGwgY29udHJvbCBwcm90b2NvbCB3aGljaCBpcyBiYXNlZCBvbiBRLjkzMSBh bmQgdGhlIFJBUyAoUmVnaXN0cmF0aW9uIEFkbWlzc2lvbiBTdGF0dXMpIHByb3RvY29sIHdoaWNo IGlzIHVzZWQgYmV0d2VlbiBhbiBILjMyMyB0ZXJtaW5hbCBhbmQgYSBHYXRla2VlcGVyIGZvciBy ZWdpc3RyYXRpb24gYWRtaXNzaW9uLCBiYW5kd2l0ZGggbWVzc2FnZXMgYW5kIGFkZHJlc3MgdHJh bnNsYXRpb24uDUguMjQ1IHNwZWNpZmllcyB0aGUgbWVkaWEgY2hhbm5lbCBjb250cm9sIHByb3Rv Y29sIHVzZWQgYmV0d2VlbiB0ZXJtaW5hbHMgZm9yIHRoZSBuZWdvY2lhdGlvbiBvZiB0cmFuc21p dHRpbmcgY2FwYWJpbGl0aWVzIGFuZCB0aGUgY29udHJvbCBvZiBsb2dpY2FsIGNoYW5uZWxzLg1I LjMyMyBhbGxvd3MgZm9yIHRoZSBzaWduYWxpbmcgbWVzc2FnZXMgKEguMjI1LjAgYW5kIEguMjQ1 KSB0byBiZSByZWxheWVkIGJ5IHRoZSBHYXRla2VlcGVyIGluc3RlYWQgb2YgYmVpbmcgc2VudCBm cm9tIG9uZSBlbmRwb2ludCB0byB0aGUgb3RoZXIgKEdhdGVrZWVwZXIgUm91dGVkIENhbGwgU2ln bmFsaW5nKS4gTWVkaWEgc3RyZWFtcyBob3dldmVyIGFyZSBub3Qgcm91dGVkIHRocm91Z2ggdGhl IEdhdGVrZWVwZXIgYW5kIGFyZSBlc3RhYmxpc2hlZCBkaXJlY3RseSBiZXR3ZWVuIGVuZHBvaW50 cyAoRmlndXJlIDIpLg0NEyBJTkNPUlBPUkVSIFdvcmQuUGljdHVyZS42ICAUARUNRmlndXJlIBMg U0VRIEZpZ3VyZSBcKiBBUkFCRSAUMhUgLSBTaWduYWxpbmcgYW5kIG1lZGlhIHBhdGhzIGZvciBH YXRla2VlcGVyIFJvdXRlZCBDYWxsIFNpZ25hbGluZw1CQ1NNIGZvciBILjMyMyB0ZWxlcGhvbnkg Y2FsbHMNSW4gdGhlIHJlc3Qgb2YgdGhpcyBkb2N1bWVudCB3ZSBjb25zaWRlciB0aGUgY2FzZSBv ZiB0ZWxlcGhvbnkgY2FsbHMgYW5kIG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCBHYXRla2VlcGVy IFJvdXRlZCBDYWxsIFNpZ25hbGluZyBpcyB1c2VkIHNvIHRoYXQgdGhlIEdhdGVrZWVwZXIgY2Fu IG1vbml0b3Igc2lnbmFsaW5nIG1lc3NhZ2VzIGJldHdlZW4gSC4zMjMgZW5kcG9pbnRzLg0NVGhl IHVzZSBvZiBRLjkzMSBmb3IgY2FsbCBzaWduYWxpbmcgc3VnZ2VzdHMgdGhhdCBhIEdhdGVrZWVw ZXIgY291bGQgbW9kZWwgYSBCQ1NNIGFuZCBwcm92aWRlIHRoZSBmdW5jdGlvbmFsaXR5IG9mIGEg U1NGL0NDRi4gRmlndXJlIDMgc2hvd3MgdGhlIG1lc3NhZ2UgZmxvd3MgZm9yIGFuIG9yZGluYXJ5 IEguMzIzIHZvaWNlIGNhbGwuIERpZmZlcmVudCBhcnJvdyBzdHlsZXMgYXJlIHVzZWQgdG8gaW5k aWNhdGUgZGlmZmVyZW50IHByb3RvY29scy4gQSBwb3NzaWJsZSBzZXF1ZW5jZSBvZiBzdGF0ZSB0 cmFuc2l0aW9ucyBmb3IgYW4gT3JpZ2luYXRpbmcgQkNTTSBpcyBpbmRpY2F0ZWQgb24gdGhlIHJp Z2h0IG9mIHRoZSBmaWd1cmUuIE1hcHBpbmcgb2YgYSBUZXJtaW5hdGluZyBCQ1NNIHdvdWxkIGJl IHNpbWlsYXIuIEluIHRoaXMgZXhhbXBsZSB3ZSBoYXZlIG1hcHBlZCBILjIyNS4wL1EuOTMxIG1l c3NhZ2VzIHRvIEJDU00gdHJhbnNpdGlvbnMuIE5vIHVzZSB3YXMgbWFkZSBvZiBILjI0NSBtZXNz YWdlcyBiZWNhdXNlIGEgdGVsZXBob255IGNhbGwgd2FzIGFzc3VtZWQuIFN1cHBvcnQgZm9yIG11 bHRpbWVkaWEgY29tbXVuaWNhdGlvbnMgd2lsbCByZXF1aXJlIG1hcHBpbmcgb2YgSC4yNDUgdG8g YSBzdGF0ZSBtb2RlbC4gVGhpcyBzaG91bGQgYmUgZG9uZSBpbiB0aGUgY29udGV4dCBvZiB0aGUg d29yayBvbiB0aGUgc2VwYXJhdGlvbiBvZiBjYWxsIGFuZCBjb25uZWN0aW9uLiBTdXBwb3J0IGZv ciB0aGUgdHJpZ2dlcmluZyBvZiB2YWx1ZSBhZGRlZCBzZXJ2aWNlcyBvbiByZWdpc3RyYXRpb24g b3IgYWNjZXNzIHJlcXVlc3RzIHdpbGwgcmVxdWlyZSBtYXBwaW5nIG9mIFJBUyBtZXNzYWdlcyB0 byB0aGUgQlVDU00uIA1NYXBwaW5nIG9mIElOQVAgb3BlcmF0aW9ucw1JZiBhIEdhdGVrZWVwZXIg aXMgdG8gaW1wbGVtZW50IGFuIFNTRiBmdW5jdGlvbmFsaXR5IHNvIHRoYXQgaXQgY2FuIGJlIGNv bnRyb2xsZWQgYnkgYSBTQ0YsIElOQVAgU1NGLVNDRiBvcGVyYXRpb25zIG5lZWQgdG8gYmUgdHJh bnNwb3NlZCB0byB0aGUgSC4zMjMgY29udGV4dC4NDUZvciBldmVudCByZWxhdGVkIG9wZXJhdGlv bnMgYW5kIG9wZXJhdGlvbnMgd2hpY2ggZG8gbm90IG1vZGlmeSB0aGUgc2VxdWVuY2Ugb2YgYSBi YXNpYyBjYWxsIChJbml0aWFsRFAsIENvbnRpbnVlLCBSZWxlYXNlQ2FsbCwuLi4pLCB0aGUgbWFw cGluZyBvZiBwYXJhbWV0ZXIgdmFsdWVzIHdvdWxkIGJlIG5lZWRlZCwgYnV0IHRoZSBhY3Rpb25z IHRvIGJlIGV4ZWN1dGVkIGJ5IHRoZSBHYXRla2VlcGVyIHdvdWxkIGJlIHN0cmFpZ2h0Zm9yd2Fy ZC4NDU9wZXJhdGlvbnMgd2hpY2ggbW9kaWZ5IHRoZSBjb25uZWN0aW9uIHZpZXcgc3VjaCBhcyBT cGxpdExlZyBvciBNZXJnZUNhbGxTZWdtZW50cyBhcmUgbm90IHNvIGVhc2lseSB0cmFuc3Bvc2Vk IGluIGEgSC4zMjMgY29udGV4dC4gVGhpcyBpcyBiZWNhdXNlIHRoZSBtZWRpYSBzdHJlYW1zIGFy ZSBlc3RhYmxpc2hlZCBkaXJlY3RseSBiZXR3ZWVuIGVuZHBvaW50cyBhbmQgYXJlIG5vdCByZWxh eWVkIGJ5IHRoZSBHYXRla2VlcGVyLg1BIHBvc3NpYmxlIHdheSB0byBzb2x2ZSB0aGlzIHByb2Js ZW0gaXMgdG8gZm9yY2UgdGhlIG1lZGlhIHN0cmVhbXMgdG8gZ28gdGhyb3VnaCBhbiByZWxheWlu ZyBlbnRpdHkgd2hpY2ggY291bGQgYmUgY29udHJvbGxlZCBieSB0aGUgR2F0ZWtlZXBlci4gU3Vj aCBhIGNvbmZpZ3VyYXRpb24gY291bGQgYmUgbmF0dXJhbCBpZiB0aGUgY2FsbCBpcyBlc3RhYmxp c2hlZCBmcm9tIGEgbG9jYWwgbmV0d29yayB0byB0aGUgb3V0c2lkZSB3b3JsZCBhbmQgYSBwcm94 eSBpcyB1c2VkIHRvIGZpbHRlciB0cmFmZmljIGxlYXZpbmcgdGhpcyBuZXR3b3JrLiBJdCB3b3Vs ZCBhbHNvIGJlIHJlbGV2YW50IGluIHRoZSBjYXNlIG9mIGNhbGxzIGVzdGFibGlzaGVkIGJldHdl ZW4gYW4gSC4zMjMgdGVybWluYWwgYW5kIGEgdGVybWluYWwgb24gdGhlIFBTVE4gYXMgdGhlc2Ug Y2FsbHMgbXVzdCBiZSByb3V0ZWQgdGhyb3VnaCBhIGdhdGV3YXkuIFRoZSBnYXRld2F5IGFyY2hp dGVjdHVyZSBjdXJyZW50bHkgZmF2b3JlZCBieSB0aGUgSUVURiB1c2VzIGEgZ2F0ZXdheSBjb250 cm9sIHByb3RvY29sIGJldHdlZW4gdGhlIG1lZGlhIGdhdGV3YXkgYW5kIHRoZSBjb250cm9sbGlu ZyBlbnRpdHkgKHRoaXMgd291bGQgYmUgaW4gdGhlIEdhdGVrZWVwZXIgd2hpY2ggd291bGQgcGxh eSB0aGUgcvRsZSBvZiBNZWRpYSBHYXRld2F5IENvbnRyb2xsZXIpLiBDYW5kaWRhdGUgcHJvdG9j b2xzIGFyZSBmb3IgZXhhbXBsZSBNR0NQIGFuZCBNRENQLiBGaWd1cmUgNCBzaG93cyB0aGUgZGlm ZmVyZW50IGVudGl0aWVzIGludm9sdmVkLiBJbiBvcmRlciB0byBlbXVsYXRlIGEgU1NGLCBJTkFQ IG9wZXJhdGlvbnMgd291bGQgaGF2ZSB0byBiZSB0cmFuc2xhdGVkIGJ5IHRoZSBHYXRla2VlcGVy IGluIHRlcm1zIG9mIHRoZSBnYXRld2F5IGNvbnRyb2wgcHJvdG9jb2wgYW5kIHRoZSBzaWduYWxp bmcgcHJvdG9jb2wgb24gdGhlIFBTVE4gc2lkZS4gRmlndXJlcyA1LTcgc2hvdyBob3cgc29tZSB0 eXBpY2FsIElOQVAgc2VxdWVuY2VzIGNvdWxkIGJlIHRyYW5zbGF0ZWQgaW50byB0aGUgZGlmZmVy ZW50IHByb3RvY29scy4gSC4zMjMgbWVzc2FnZXMgaGF2ZSBub3QgYmVlbiBkZXRhaWxlZCBhbmQg dXNlIG9mIE1HQ1AgaXMgYXNzdW1lZCBiZXR3ZWVuIE1lZGlhIEdhdGV3YXkgYW5kIE1lZGlhIEdh dGV3YXkgQ29udHJvbGxlci4NDVRoZSBjb25zdHJhaW50IG9mIGZvcmNpbmcgdGhlIG1lZGlhIHN0 cmVhbXMgdG8gYmUgcmVsYXllZCB0aG91Z2ggYW4gaW50ZXJtZWRpYXRlIHBvaW50IG1heSBub3Qg YmUgY29udmVuaWVudCBmb3IgYWxsIGNhbGxzIGluc2lkZSB0aGUgbG9jYWwgbmV0d29yay4gQW5v dGhlciBwb3NzaWJpbGl0eSBjb3VsZCBiZSB0byByZXF1aXJlIHN1cHBvcnQgaW4gSC4zMjMgdGVy bWluYWxzIG9mIHN1cHBsZW1lbnRhcnkgc2VydmljZXMgc3VjaCBhcyBDYWxsIEhvbGQgYW5kIENh bGwgVHJhbnNmZXIuIFRoZXNlIHNlcnZpY2VzIHdvdWxkIHNlcnZlIGFzIGJ1aWxkaW5nIGJsb2Nr cyBmb3IgdGhlIG9wZXJhdGlvbnMgbWFuaXB1bGF0aW5nIHRoZSBjb25uZWN0aW9uIHZpZXcgc3Rh dGVzLg0NEyBJTkNPUlBPUkVSIFdvcmQuUGljdHVyZS42ICAUARUNRmlndXJlIBMgU0VRIEZpZ3Vy ZSBcKiBBUkFCRSAUMxUgLSBILjMyMyBtZXNzYWdlIGZsb3dzIGFuZCBjb3JyZXNwb25kaWcgT19C Q1NNIHRyYW5zaXRpb25zDRMgSU5DT1JQT1JFUiBXb3JkLlBpY3R1cmUuNiAgFAEVDUZpZ3VyZSAT IFNFUSBGaWd1cmUgXCogQVJBQkUgFDQVDQ0NDQ0NDQ0TIElOQ09SUE9SRVIgV29yZC5QaWN0dXJl LjYgIBQBFQ1GaWd1cmUgEyBTRVEgRmlndXJlIFwqIEFSQUJFIBQ1FSAtIENvbm5lY3QNEyBJTkNP UlBPUkVSIFdvcmQuUGljdHVyZS42ICAUARUNRmlndXJlIBMgU0VRIEZpZ3VyZSBcKiBBUkFCRSAU NhUgLSBJbml0aWF0ZUNhbGxBdHRlbXB0IGZvbGxvd2VkIGJ5IENvbm5lY3QNDQ0NDQ0NDRMgSU5D T1JQT1JFUiBXb3JkLlBpY3R1cmUuNiAgFAEVDUZpZ3VyZSATIFNFUSBGaWd1cmUgXCogQVJBQkUg FDcVIC0gRGlzY29ubmVjdExlZyBmb2xsb3dlZCBieSBDb25uZWN0DUV1cm9wZWFuIFRlbGVjb21t dW5pY2F0aW9ucyBTdGFuZGFyZCBJbnN0aXR1dGUgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFRELTAwDUVUU0kgU1RDIFNQUzMLIA1Tb3BoaWEgQW50aXBvbGlzLCBGcmFuY2UsIDI1LTI5 IEphbnVhcnkgMTk5OQ0NDQ0NHwCPAaEBAJkQpIMupchBpooFp4oFqIoFqYoFqgAAqwkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAOkEAADqBAAABgUAAAcF AAAIBQAACQUAABEFAAASBQAAJwUAACgFAAApBQAAKgUAABgIAAAZCAAANQgAADYIAAA3CAAAOAgA AEAIAABBCAAAVggAAFcIAABYCAAAWQgAAN0VAADeFQAA+hUAAPsVAAD8FQAA/RUAAAUWAAAGFgAA GxYAABwWAAAdFgAAHhYAAFkWAABaFgAAdhYAAHcWAAB4FgAAeRYAAIEWAACCFgAAlxYAAJgWAACZ FgAAmhYAAKIWAACjFgAAvxYAAMAWAADBFgAAwhYAAMoWAADLFgAA4BYAAOEWAADiFgAA4xYAAO4W AADvFgAACxcAAAD7APHr+wD7APvp+wD7AN/Z+wD7APvp+wD7AM/J+wD7APvp+wD7AL+5+wD7APvp +wD7AK+p+wD7APvp+wD7AAAAAAAAAAAAAAAAAAAAAAAAAAAKdQFEBJU7UzpLAQASdQFEBJU7Uzpd AABhAAR2AUsBAAp1AUQEfDVTOksBABJ1AUQEfDVTOl0AAGEABHYBSwEACnUBRASsq0g6SwEAEnUB RASsq0g6XQAAYQAEdgFLAQAKdQFEBNZBUDpLAQASdQFEBNZBUDpdAABhAAR2AUsBAANhAAQKdQFE BNY0UDpLAQASdQFEBNY0UDpdAABhAAR2AUsBAAh1AUQEAAAAAD8LFwAADBcAAA0XAAAOFwAAFhcA ABcXAAAsFwAALRcAAC4XAAAvFwAAYRcAAGIXAAB+FwAAfxcAAIAXAACBFwAAiRcAAIoXAACfFwAA oBcAAKEXAACiFwAAxxcAACsYAABYGAAAWxgAAFwYAACZGAAA9vDrAOsA6+nrAOsA39nrAOsA6+nr AADWAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAnUBAAVVgWMYAAp1AUQEtkFTOksBABJ1AUQEtkFTOl0AAGEABHYBSwEAA2EABAh1AUQE AAAAAAAKdQFEBAU/UzpLAQASdQFEBAU/UzpdAABhAAR2AUsBGwADAAAXAwAAKwMAACwDAAAtAwAA LgMAAC8DAAAwAwAAMQMAADIDAAA/AwAA5wMAAPoDAADoBAAA6QQAAFAFAABRBQAASwYAAOsGAAAX CAAAGAgAADkIAACbCAAAuggAAJQJAACVCQAA/QwAABgNAAC4DQAAuQ0AALoOAAC7DgAAsg8AAFoU AABbFAAA3BUAAN0VAAD+FQAAWRYAAHoWAACbFgAAnBYAAJ0WAACeFgAA/gAAAAAAAPkAAXAj8AD3 AAFwI+YA9wABcCPmAPcAAXAj5gD3AAFwI+YA9wABcCPmAPcAAXAj5gD3AAFwI+YA9QABcCPwAPcA AnAj5gD1AAFwI/AA9wADcCPmAPcAAXAj5gDzAAAAAAAA9wABcCPmAPcAA3Aj5gD3AAJwI+YA9wAE cCPmAPcAAXAj5gDwAAFwI9oR8wABcCPwAPUAAXAj8AD3AANwI+YA9wABcCPmAPcACXAj5gD1AAFw I/AA9wACcCPmAPcAAXAj5gD3AANwI+YA9wABcCPmAPcAA3Aj5gD3AA1wI+YA9wABcCPmAPcABHAj 5gD3AAFwI+YA8AABcCNQJfMAAXAj8ADwAAFwI9oR8wABcCPwAPcAAXAj5gD3AAFwI+YA9wABcCPm AAAAAAIAAAUBAAEUAAABAQAAAQAAAAQTABGKBRN2+gABEwArgQAAAIIAAACDAAAAhAAAAP7///+G AAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAA/v///5QA AACxAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAA/v// /6MAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAA /v///7IAAAAjAQAAtAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/ AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAMoAAADLAAAAzAAAAP7/ ////////zwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAA ANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA 6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4 AAAA+QAAAPoAAAD7AAAA/AAAAP0AAAD+AAAA/wAAAAABAAA= ------_=_NextPart_000_01BE4ACD.1B0B3CE8-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jan 28 21:23:29 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA12236 for ; Thu, 28 Jan 1999 21:23:29 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CE3E87FF0; Thu, 28 Jan 1999 20:23:18 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 424057FF2; Thu, 28 Jan 1999 20:23:18 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Lotus-FromDomain: ASCEND From: Frohike@ascend.com To: GroupShield.Notification.List@ascend.com Message-ID: <88256708.000705CB.00@smtp-mta.ascend.com> Date: Thu, 28 Jan 1999 20:19:21 -0500 Subject: Found virus from "CHATRAS Bruno CNET/DAC/ISS" : Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Error NWall.Sfarun(984.13.264): Failed to extract file attachment: e:\TEMP\0000009A\0000006B.doc. The message is currently suspended in SCAN.BOX on CN=Frohike/O=Ascend/C=US. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jan 29 00:26:40 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA15725 for ; Fri, 29 Jan 1999 00:26:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8957E7FF2; Thu, 28 Jan 1999 23:26:50 -0500 (EST) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D32477FF3; Thu, 28 Jan 1999 23:26:49 -0500 (EST) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <36B136FF.9A904536@dnrc.bell-labs.com> Date: Thu, 28 Jan 1999 23:20:15 -0500 From: Jonathan Rosenberg Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: epabhm@epa.ericsson.se Cc: Ami Amir , "ronald h. davis" , ming.lu@globalone.net, Sebastien Ducarne , IP Telephony Subject: Re: VOIP question ?? References: <99Jan28.202021ist.113798@firewall.radvision.rad.co.il> <36B0E36D.86E9BD24@epa.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Bjarne Munch wrote: > > The question that occur to me is how much control will the operator wish to > have over this IPT network ? And how much self discovery and routing > adaptability > will an operator wish to have? > > Call me a 'bell-head' but as an example; implementing an automatic gateway > discovery may limit the possibility for operators to control the cost structure > for > terminating and originating calls to/from these gateways. The assumption of adaptive routing and management/control being mutually exclusive is not accurate. Existing IP routing protocols are usually tied to policy decisions in routers. For IP telephony, the "routing" protocol (GLP) allows a Location Server (gatekeeper or SIP server in most cases) to have a set of gateways from which it can make policy decisions, resulting in a final routing table. > > I dont see this as a part of H.323, but rather the routing applicating utilising > H.323. > And this routing application does not nessecarily require an 'adaptive' routing > protocol. GLP is neither part of H.323 or SIP, and neither does it utilize them. Rather, a gatekeeper or SIP server would make use of GLP as a method for constructing routing databases (and perhaps not the only means of constructing the database). -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List.